Signal: misusing a language feature

#php

I saw a new library, Signal were they are using PHP attributes as documentation. The idea on itself just blew my mind, because PHP attributes are the solution to keep metadata out of the comments. So that the comments provide the singular task of storing documentation.

Generics

For the people who follow PHP news there recently was a big debate about a generics proposal. 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.