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

On 13 May 2026 17:19:21 BST, Seifeddine Gmati <azjezz@carthage.software> wrote: >> 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. I don't think this is true at all. Users were writing "array", and class/interface types, in their code for many years before PHP 7.0, *and having them natively enforced*. Most of those users had never heard of static analysers, but as soon as static types became available, using them was entirely natural. If you survey current code bases, I bet you a drink of your choice that you will find code bases with some use of scalar types outnumbering code bases which have been tested with a Static Analyser by an order of magnitude. >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. Of course they will, because it will suddenly be much more visible. Every "what's new in PHP" blog post will describe the new syntax, and people will start playing with it. People who see docblocks as "just documentation" will see frameworks and libraries putting it in "actual types" and copy it into their own code. And this is a good thing! We *want* new language features to be interesting to more people. But we also want them to be *useful* to those people, not documented in the manual as "advanced users only; if you're the target audience for this, you probably don't need this page". >Attributes themselves are a counter-example. They shipped in PHP 8.0 >specifically to formalize what frameworks had been doing in docblocks. Attributes are very explicitly an *abstract extension point* for tooling to do what it wants with. PHP does not attempt to standardise their use; it doesn't even validate that attribute names correspond to valid classes unless you ask it to. PHP provides some attributes out of the box, but only when it also includes some *behaviour* for those attributes. In the same way, PHP provides the ability to define interfaces. It also provides interfaces to interact with included features, like SessionHandlerInterface. But it leaves it up to the community to agree interfaces for things that are not included with the language, like LoggerInterface or CacheInterface. That's not the same as what you're proposing. >Beyond that, expressing generics through attributes specifically >doesn't work. Fair enough. My point stands though: the language should provide abstract extension points, or working implementations, not empty syntax. There's also the elephant in the room that the proposal doesn't remove the need for standardising a docblock or attribute approach anyway, because it is inevitably going to miss things the SA tools support: class-string<T>, array<int,Foo>, iterable<Bar>, non-empty-string, ... That again follows from it not being an abstract extension point like docblocks and attributes. Advanced users, who you say are the target audience, will still have to work with both syntaxes; and will still find differences between tools which aren't covered by the subset of validation that PHP has taken ownership of. Rowan Tommins [IMSoP]