A generic tragedy — Tempest

A generic tragedy

PHP devs talk about generics in real life

by Brent on June 15, 2026

Most likely, PHP isn't getting generics. There's nothing new under the sun. Some internals have written very elaborate blog posts on why runtime-erased generics are a bad idea, and why they are voting no on the current RFC.

However, there's another side of the PHP community that are very much in favor of this RFC, who also wants to voice their opinion. Some of them don't have the platform to do so themselves, which is why I want to give the other side of the story a voice, here on this page. These are the stories and comments from PHP developers who use generics in real life and have embraced static analysis as a core part of PHP. They'd like to share their thoughts.

Nicolas Grekas<br>Márk Magyar<br>Azjezz<br>Nuno Maduro<br>Brent Roose<br>You?

From Nicolas, core maintainer of Symfony

There's extensively-documented prior research on generics in PHP. The conclusion is bold: the PHP engine can't efficiently implement generics (challenges are inference to not ruin DX, performance to not ruin costs and many others). The only practical solution is an ahead of time static analyser. Dreaming of one built into PHP itself, likely written in C, is fine but not realistic: PHP static analyzers were developed in PHP for a reason. This allowed fast iterations, by people focused on their proficiency language. Moving this experience to the engine-side would eject the very people that made SA in PHP a thing. That'd be a too big loss for the community.

Erased generics as proposed are a direct continuation on this path, which is already proved viable and useful. Thanks to IDEs, SA in PHP has a much wider user-base than just the active users of phpstan, psalm, et al. With LLMs generating code, it's even more critical for PHP to have a stronger verification step. SA tools are a mandatory part of the loop nowadays. We did already wait and dream for years about babysteps towards generics. Even generic arrays has been ruled out as too hard. We waited long enough to draw the conclusion: erased-generics are the only realistic step forward. I'd be happy to be wrong. Let's see in some years (if people/LLMs still write PHP then).

From Márk, Tempest core developer and full-time PHP dev

First and foremost, I need to tell you: I will be extremely disappointed if this RFC doesn't pass. But let me start with the least controversial thing I can possibly say. I've been writing generics in PHP for years, and so have you.

If you've ever opened a Laravel, Doctrine, Symfony, PHPUnit or PSL class, you've read @template. It's in over 202,000 files on GitHub. It's how every serious collection, repository, and result type in this ecosystem describes itself. We have been shipping erased generics — types that a static analyzer checks and the engine ignores — for about a decade now. So when people talk about this RFC as if it's some exotic new thing, I get a little confused. The only thing the Bound-Erased Generic Types RFC actually proposes is to stop writing those generics inside a comment and pretending it doesn't count.

And the comment tax is real. Think about what a generic Laravel class looks like today. It's written in two languages at once: PHP types in the signatures, PHPDoc types in the docblock right above them. The parser validates one and silently trusts the other. You rename a property in a refactor and the comment quietly goes stale. ReflectionClass::getName() hands you Collection, never CollectionTKey, TModel>. PHPStan, Psalm and Mago each read the tricky cases a bit differently, because there's no actual language for any of them to be right about.

This RFC fixes all of that, at exactly zero runtime cost, and at the moment I'm writing this it's losing 4 yes / 12 no / 3 abstain. I want to talk about why, because the why is the actual tragedy here, and it's more frustrating than "internals hate generics." They don't. The real reasons are worse than that.

"But native syntax shouldn't lie"

The strongest argument against this RFC isn't stupid, so I'm not going to try to headbutt it. Rowan Tommins put it best on the list:

But right now, PHP's native syntax does not lie - a property marked "private" really is private, a return type marked "int" really is always an integer... This proposal would fundamentally change that - it would introduce syntax which looks like it's part of the standard, enforced, type system; but, in many cases, would do absolutely nothing.<br>Derick Rethans seconds it from experience, saying users were "almost exclusively confused when it became clear these types weren't enforced." Tim Düsterhus sharpens the knife further: static analyzers "can only prove the presence of errors, but not the absence of them", and he's right that you cannot fully type-check a PHP program without actually running it.

I sat with that for a while, because it sounds airtight. But... there is always a but. It's an argument about...