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

On 16 May 2026 02:01:04 BST, Seifeddine Gmati <azjezz@carthage.software> wrote: >The only governance body that the ecosystem actually treats as >authoritative is internals. That's the structural fact behind this >RFC: not just "syntax in PHP is intrinsically better than syntax in >docblocks" (which is true), but "the standardisation step that would >make docblock generics consistent across tools requires authority no >party in the ecosystem currently has." I think this is a part I'm fuzzy on: which of the inconsistencies that currently exist are actually solved by the parts of this RFC which are enforced? Will users still get different results in different tools for the parts that are not enforced natively, or is PHP Internals going to become a standards body defining conformance tests for those parts? >The visual-distinction argument cuts both ways too. You're arguing >that ~~ makes the SA-checked layer visible to the reader. But >the >same argument applies to <...>: anything in angle brackets >is the >generic type layer, anything outside is the runtime-checked layer. I think you missed the point of the suggestion, which was to allow *all* unchecked type information to be included in the same place. Every single docblock annotation for guiding SA tools would be moved next to the "real" type it was qualifying. The base shape of the syntax would be standardized by PHP, but the semantics would be open to innovation and (dis)agreement by tool authors. It's also not true that <> is always present to make the distinction with generics; where the type parameter is *used*, it just looks like a real type: public function hasEdge(TNode $from, TNode $to): bool The actual checked type there is invisible - the "bound erasure" means that it might be just "mixed", but might be some base interface. Rowan Tommins [IMSoP]