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

On Tue, Jun 9, 2026, at 09:26, Brent Roose wrote: > Hi Rob > > Very interesting. If this is what it takes to get enough people on board, then so be it. > > On a personal note, but don't let this prevent you from further exploring this option: I > hope that at some point we get a way to opt out of runtime type checks (generics or types in > general). A 2x performance penalty is a serious issue. > > To reiterate what I've said before: generics aren't a runtime tool. Their value comes > from static analysis and reflection for meta programming, and I see no reason why generic code > should be type-checked at runtime when it has already been type-checked before. As both a PHP user > and a representative for one of PHP's most used static analysers, I want three things: a proper > spec, proper syntax, and proper reflection. All these problems are solved with the current RFC; > without runtime type checking, and without performance penalties. > > Maybe this is just a necessary process for PHP to go through; and who knows, in a couple of > years, practical experience will have shown and convinced enough people that it's unnecessary. > I'll happily deal with the performance overhead and will continue to hope for an opt-out > mechanism in the future. > > Thanks for the work and effort, really interesting! > > Brent Please remember to "bottom post" (put your reply at the bottom, not the top, of the email). > 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. > 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