On Mon, Jun 15, 2026, at 2:21 PM, Levi Morrison wrote: > On Mon, Jun 15, 2026 at 12:28 PM Rob Landers <[email protected]> wrote: >> >> >> >> On Mon, Jun 15, 2026, at 20:22, Matthew Brown wrote: >> >> On Mon, 15 Jun 2026 at 12:28, Levi Morrison <[email protected]> >> wrote: >> >> > Voting is now open on the Bound-Erased Generic Types RFC, as announced >> > in the Intent to Vote message earlier this week. >> > >> > The vote started on 2026-06-14 at 16:50 UTC and ends on 2026-06-28 at >> > 17:00 UTC. >> > >> > RFC: https://wiki.php.net/rfc/bound_erased_generic_types >> > Discussion thread: https://news-web.php.net/php.internals/130816 >> > Implementation: https://github.com/php/php-src/pull/21969 >> >> To my own surprise, I am voting yes on this proposal. >> >> I still believe that refied generics should be the goal. To that end, >> I think we should be able to merge this and in minor versions, fix >> "soundness" and implementation holes as "bug" fixes on that route. If >> internals can agree on this, and then the community can communicate >> this through education, promotion, documentation, etc, then this RFC >> is simply a useful stepping stone. >> >> This is based on my own experience playing with the RFC, which >> included reporting 2 bugs in the implementation on the RFC. To be >> honest, it's not too useful to me. I very quickly run up against some >> limitation when trying to build useful things. Most notably, we need >> to be able to define lower bounds (syntax pending, obviously):
> But this is tangential to my main point: if we accept that we are > moving towards fully reified generics, and this is only a stepping > stone, and we document this widely and educate about it, then in > future versions we can tighten from "bounds erased" to "fully > reified." Yes, there will still be breakages, but far, far fewer > breakages. This should be tolerable. > > I don't want this RFC to be our final form: I only want it to be a > stepping stone. I concur. My concern is, as Rob pointed out, it may not be possible to add enforced generics on top without API changes. Not just "your code was already broken and now we're telling you" changes, but changing the way catch blocks behave. I'm not sure if we're OK with that level of breakage if we incrementally add more enforcement. Is that concern valid? I'm not sure. We didn't get a chance to flesh it out before the vote was called. --Larry Garfield
