Signal: misusing a language feature

I saw a new library, . Basically the idea was to create generics that weren't enforced by the runtime. This is how static analysis tools like PHPStan use generics. But because there are differences in the keywords, the comments are not usable cross tool unless there is an extension that picks up the differences.

The main reason I brought it up here is because a far as I know nobody looked at attributes as a path forward to a unified way to define generics.

I think generics in the way that it is represented in the RFC it moves beyond being a comment, but at the same time I don't think it is actionable enough to be a language feature.

The library viewed from a DocBlock perspective

PhpStan uses the @template keyword to define a generic, which means of years people have extended the PHPDoc reference for their own benefit.

Would it be such a stretch to extend PHPDoc with the keywords you want to generate more structured context bound documentation?

There is already an @throws keyword so the Throws attribute is just doubling up the ways to provide documentation.

The library viewed from a framework/library perspective

The Route attribute is used by Symfony, so to use the library attribute an alias is needed to not interfere with the way the framework operates.

The attributes are very generic so the change that they need aliases is very high when a project is using multiple libraries.

I don't see a problem when a library adds an attribute with the same name if it provides functionality. But for documentation this goes too far.

Conclusion

I think the underlying idea is good, provide a way to generate more focused documentation. It is the implementation that I don't agree with.

It feels like an idea fixed on doing something with attributes, than a look at all the options plan before starting to build the solution.