Re: [RFC] [Discussion] Bound-Erased Generic Types

> 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.