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

From: Date: Tue, 19 May 2026 07:39:40 +0000
Subject: Re: [RFC] [Discussion] Bound-Erased Generic Types
References: 1 2 3 4 5 6 7 8 9 10  Groups: php.internals 
Request: Send a blank email to internals+get-130955@lists.php.net to get a copy of this message
On 18 May 2026 17:50:55 BST, Larry Garfield <larry@garfieldtech.com> wrote: >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. On the contrary, it's that partial enforcement that the idea is trying to help with. Right now, if I write "function foo(_ $x)" then no matter what type I put in place of "_", the answer to "is it enforced?" is "yes". With the current proposal, that answer might be: - Yes - No: it's an unbounded type parameter which erases to "mixed" - Partially: it's a bounded type parameter which erases to the bound; or it's a parameterised type which erases to a normal one (e.g. Box<int> to Box) - Maybe: it's a type parameter on an abstract class, and sub-classes might be monomorphized, but might be generic themselves The syntax won't give any hint which is which, and the same syntax in different places is enforced to different extents. In the current shape, I will vote No, because I think that will be horrible to work with. Shinji Igarashi suggested an "erased" keyword to leave the main syntax free for reified generics, and it got me thinking how we could generalise that to indicate the difference between "real" type declarations, and reflection-only type hints. I'm not claiming to have a ready-to-ship proposal with all the details, just looking for a compromise that would give the standardisation and reflection capabilities Seifeddine wants, but keeps it clear to users which types are actually enforced. Rowan Tommins [IMSoP]

« previous php.internals (#130955) next »