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

On Mon, May 18, 2026, at 3:33 AM, Seifeddine Gmati wrote: > The ~~Type proposal raises two questions I don't see clean > answers to: > > 1. *Lexical grammar inside ~~?* Whitespace breaks conditional > types > ($var is Foo ? A : B). $ breaks > variable-using expressions. { > breaks array shapes. < breaks generics. Every plausible > stopping rule > breaks a class of type expressions SA tools currently support. > > 2. *AST shape?* Either an opaque string (tools still parse it > themselves, still disagree, gain over docblocks is just location) or > structured (PHP has committed to an AST for type expressions it doesn't > enforce, which is the architectural pattern you wanted to avoid). > > The speed advantage of docblocks comes from PHP not parsing them at > all. Moving syntax into the language reduces that velocity regardless > of whether PHP enforces semantics. The RFC's trade-off is to move the > *enforceable* parts into the standard and leave the *innovation* parts > in docblocks. Future RFCs will incrementally move what's stable enough > to standardize, the docblock channel stays open for fast iteration. Rowan's "erased user-extensible type system" is an interesting idea, and I think it's worth exploring. But I don't think this RFC is the place for it. This is a partially-enforced-generics proposal, so using an "ignored by the engine" flag for its syntax would make things more confusing, not less. I'd rather move the discussion of a user-extensible type system to its own discussion. I don't think it's necessary for generics, which are already extensible in a well-defined and industry-standard way. --Larry Garfield