On Sat, 13 Jun 2026 at 22:39, Larry Garfield <[email protected]> wrote:
> > I know we've discussed this in chat, but I want to put it out to the list. > > 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 > Hello everyone, as someone purely on the userland side of things, I agree with Larry's plan. It's sensible and gives plenty of time to actually work out the kinks. As to the Erased Generics vs Monomorphized Generics and their performance hit, I honestly do not see why people are hung up on wanting no performance hit. As a userland developer, I expect generics to have a performance hit, and not a minor one. The more powerful the feature, the greater the performance impact. I also expect generics in PHP to do actual runtime type checking the same way the whole type system in PHP already does (I'm a strict type mode user through and through). If generics end up giving a performance hit of 30-40% in the places they are used compared to non-generics code - frankly, considering the benefits of code simplification, maintainability improvements, removing code we don't need any more and getting a major type safety at runtime - a server or two that might needed to be added is a small price to pay. We are not talking about overall PHP slowing down 30-40% just because a single generic collection or two are used in the code, right? As i understand, the slowdown is at the boundaries of the generic usage, not across all code. And it has been already said, that there are definite optimizations to be had - the effort just has to be put into it. Using try/catch incurs a performance hit, which everyone knows, yet we still use it. Because it is worth it. My 0.02$. -- Arvīds Godjuks +371 26 851 664 [email protected] Telegram: @psihius https://t.me/psihius
