> This is an assumption that a lot of your reasoning seems to be based on, and
> as I've said already, I think it's a false assumption.
The PHP 7.0 type-declaration rollout is the closest empirical test.
Native scalar types shipped to a community that had been using PHPDoc
@param and @return annotations for years. They didn't suddenly create
a new population of developers who type their code, some popular
projects argued the new types were useless and refused to adopt them.
The audience that gained native syntax was the audience that had
already been typing their code. People who didn't see value in types
before PHP 7.0 mostly didn't see value after, either.
The same dynamic will apply here. People who don't care about generic
type information today won't suddenly care because PHP grew the
syntax. The audience that uses @template in docblocks is the audience
that will use native generics.
> if the audience for the feature really is existing users of third-party SA
> tools, then it shouldn't be shipped as part of php-src. The language should
> only provide the building blocks for those tools to work with - and
> attributes seem perfectly suited here.
Attributes themselves are a counter-example. They shipped in PHP 8.0
specifically to formalize what frameworks had been doing in docblocks.
Their audience at launch was framework users, exactly the kind of
"existing third-party-tool users" your argument says shouldn't justify
language-level support. PHP shipped them anyway, resulting in benefits
for everyone: first-class syntax, parser validation, Reflection
access, IDE support, cleaner code. The same applies to generics: the
ecosystem has been doing this work in docblocks for a decade;
formalizing it in the language is the consistent next step.
Beyond that, expressing generics through attributes specifically
doesn't work. Attribute syntax is in the form of name-call-arguments
(`#[Template("T", bound: "object")]`); it can't express type parameter
references, variance markers, bound-on-bound, or substitution into
method signatures. You'd end up with worse ergonomics than docblocks
for the same information, and the parser still wouldn't understand the
type relationships. The static analysis ecosystem explored and
rejected the "attributes are enough" path as too limited.
