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

On Sun, Jun 14, 2026, at 10:53 AM, Seifeddine Gmati wrote: > Hello internals, > > Voting is now open on the Bound-Erased Generic Types RFC, as announced > in the Intent to Vote message earlier this week. > > There are two votes on the RFC page: > > 1. Primary vote, requires a 2/3 majority: accept the RFC as proposed. > 2. Secondary vote, simple majority, conditional on the primary > passing: variance marker syntax, +T / > -T (Hack, Scala) vs in T / > out T (C#, Kotlin). Semantically identical; only the surface > syntax > differs. > > 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: ˆÖ80‡ q > ùâ™/»Åhttps://news-web.php.net/php.internals/130816 > Implementation: https://github.com/php/php-src/pull/21969 > > Cheers::<>, > Seifeddine. I already posted this in the discussion thread, but since many people don't read deep into a thread I'm reposting it here for visibility: --- i strongly urge you to hold off on a vote. Generics would be the biggest PHP feature in *years*, and would generate a lot of very positive buzz, both within the community and externally. OTOH, generics getting voted down (for whatever reason) would be... very bad press, both within the community and externally. I don't feel like Rob's additions have been adequately investigated and evaluated, nor is there a clear consensus on what would be "good enough" for it to be acceptable. That is a problem that should be addressed directly. Additionally, Rob has noted that the current RFC does allow for code that would be broken and change behavior should generics become enforced in the future. That is a landmine we do not want. (And I reiterate, "if you care, use an SA tool" is an insufficient answer.) We basically have three options: 1. Erased generics, with all the limitations and problems that implies (basically Seif's current RFC). 2. Monomorphized generics, with the performance hit that implies (basically Rob's patch, with some further development.) 3. Pass on generics, again. In my mind, option 3 is the absolute worst option. I can think of at least three core features that would benefit from or require generics to be done properly, so having *something* in core is, in my mind, critical. Plus, as previously noted, "Internals rejects generics, even though basically everyone wants it" is going to be the headline (no matter how (in)accurate you feel that is). The only people that win in that scenario are Node.js fanbois. However, my read of the current discussion is that partially-erased generics (this RFC) is not going to pass. I've been struggling with it for a while, and still not sure how I'm going to vote. I really want to support it, but the gaps that Rob pointed out (around catch) are a problem. And again, they're worse than just "oh it's the wrong type so you get a type error." It completely changes the error pathway that gets executed. If partially-erased generics doesn't pass, that will leave us with monomorphized/reified generics. That always runs into the "but performance" problem, yet, there has never been a consensus as to what an acceptable CPU or memory hit would be. Because *there is guaranteed to be one*. If we want generics, then we either accept partial erasure or we accept some performance hit. We're going to have to deal with one or the other, and pretending that some magic free-reified implementation will appear is a fool's errand. So to anyone who plans to vote against the current RFC, please state what you would consider an acceptable performance hit for going all the way. *We need to agree on that*, so that Rob or anyone else can see if we can hit it. That's the step that hasn't been achieved yet (due in part to our current process having no way to handle that). What Rob has expressed so far frankly seems like an acceptable cost to me already, but I know others disagree. But holding out for zero-cost is simply impractical. My recommendation, in fact, would be to get one or more additional people involved to help on the performance front, and put forward an equivalent enforced-generics RFC. (Same syntax and semantics as the current one, which are pretty solid aside from the in/out question.) Let's bang on that and get it right, and then we can pass that. Given the timing, I would suggest such an RFC not target 8.6. Instead, we can plan ahead that 8.6 (this year) will be the end of the 8.x series, PHP 2027 will be PHP 9.0, and will include whatever the result of that further generics work is. That gives us plenty of time to: 1. Ensure it's rock solid, and as performant as we can manage 2. Develop additional features for core that can leverage generics, so when they ship we have stuff already using it. This also helps flush out any edge case bugs before it ships. 3. Gives us a clear path toward a major PR and press win (PHP 9.0, Now with Generics!), which the project desperately needs. I want to reiterate: "Internals votes down generics" is the absolute worst outcome, for literally everyone who cares about PHP. As we say in Chicago, "you don't call the vote until you know you have the votes." Right now, I don't think we have the votes. We need to take the time and do the work to get this *right*, and ensure not just passage, but broad support and endorsement, and the right tooling built on top of it. Voting on the current RFC right now will not get us there. --Larry Garfield