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

From: Date: Tue, 26 May 2026 23:02:52 +0000
Subject: Re: [RFC] [Discussion] Bound-Erased Generic Types
References: 1 2 3 4 5  Groups: php.internals 
Request: Send a blank email to internals+get-131023@lists.php.net to get a copy of this message
On Tue, 26 May 2026 at 15:18, Larry Garfield <larry@garfieldtech.com> wrote: > On Tue, May 26, 2026, at 8:12 AM, Rowan Tommins [IMSoP] wrote: > > On 25 May 2026 20:26:41 BST, Matthew Brown <matthewmatthew@gmail.com> > wrote: > > >> > > >> https://thephp.foundation/blog/2025/08/05/compile-generics/ is > >> > >>That blog post is a year old, and the top comment on the attached Reddit > >>thread captures my view on it: > >> > >>> The problem with such an approach is that it locks generics to be > >>reified. > > > > > > I think the two proposals have a lot more overlap than their framing > > suggests. Both block us from having completely erased generics, because > > they include *some* reification/monomorphization, but nothing in > > Gina/Larry's blog post would actually block Seifeddine's proposal as > > far as I can see. > > > > Specifically, if you take everything Seifeddine has implemented, but 1) > > restrict generic declarations to only interfaces and abstract classes; > > and 2) remove the "turbofish" syntax completely; then you end up > > basically with what the blog post suggests. > > > > > > The main difference of opinion is what to do with those "missing" parts: > > > > - Larry & Gina proposed just leaving then forbidden until we decide how > > to implement them > > - Seifeddine proposed locking in the syntax with some partial checking, > > but mostly just reflection support > > I would agree. Seif's proposal is effectively a superset of what Gina was > working on, and should it pass, it would include all of the functionality > of Gina's proposal and then some. > > --Larry Garfield > Yes it's a superset of the syntax, and leaves the door open to some runtime checks being added in the future, per you & Gina's proposal.

« previous php.internals (#131023) next »