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

On Tue, Jun 9, 2026, at 10:30 AM, Rob Landers wrote: >> A 2x performance penalty is a serious issue. > > This is a mischaracterization. To be more clear, the *call itself* > approaches a limit of 2x -- it isn't exactly 2x, and not all generic > calls are always 2x. I even gave real examples in my email showing real > world generic heavy code is only 30-50% slower. And this is without any > real optimization work. This is the ceiling, not a final result. > Further, it appears to bear the *same *cost as manually type checking > the generics. Also, as noted, the cost is born only when a generic type is checked. The impact on non-generic code is, seemingly, zero. That is important. >> I see no reason why generic code should be type-checked at runtime when it has already been >> type-checked before > > PHP does type checks at runtime because *it cannot be type-checked > before.* There is no point where the compiler can be sure about types > statically. Each file is compiled at a time, and some parts of > compilation even need to be deferred to runtime. This isn't a > limitation of PHP, it's how you can have two files with the same class > name in them and then load different ones depending on > capabilities/execution. (ie, loading generated mocks instead of the > real class or loading a php 8.3 version instead of a php 9 version of > the class). > > I know of absolutely zero static analysis tools that understand PHP's > dynamic loading system -- they all assume a PSR-4 (or similar) system > for autoloading. Thus, only in certain kinds of cases are they actually > useful. > >> All these problems are solved with the current RFC; without runtime type checking, and >> without performance penalties. > > I disagree, wholeheartedly. But that is likely because during my work, > I had to actually fix tests from the erasure branch that "looked" right > but were quite wrong. As I mentioned in my email, the cost turns out to > be nearly exactly the same as manual type checks. The performance issue > is a mirage if you want to do any type assertions -- and you probably > do. As I mentioned in my last email, you can simply write a script > today to remove all types in your code. There's nothing stopping you > from doing that to get some "speed". > > — Rob I will go a step further: There are certain things that PHP *cannot* do nicely in core/stdlib without generics. Gina's Fetch API proposal is one such case. (Replacing ArrayAccess with a series of smaller interfaces that are more targeted and well-designed..) All of the parameters of those methods would need to be typed mixed today, and implementations could not narrow it. If those interfaces are generic, that problem disappears. Collections is another. I want proper collection objects, badly. :-) That includes operator overloads, which means they must be done in C/stdlib (and even if we had user-space operator overloads, it would be faster in C rather than building them all atop arrays). That means they cannot rely on 4 slightly different user-space static analyzers for pseudo-generics. They need real generics, in the language, or they'll be largely useless. And no, trying to include stubs for auto-complete that match those 4 slightly different user-space static analyzers is not a solution. SA-only types are a hack, not a core language feature. That's what I meant with my earlier comments about a first-party SA tool. PHP the language needs to be an "internally complete" solution. Seif's RFC is a big step forward, with the major issue of introducing type erasure when PHP has never had that before. Rob's add-on seems to resolve that problem. I am not in a position to judge its implementation in detail, but if it passes muster, I think we may have finally found our way forward. And I am willing to eat some performance for that, as long as it only hits generic code. --Larry Garfield