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
