On 10. 5. 2026 at 21:02:32, Seifeddine Gmati <[email protected]> wrote:
> Hello Internals, > > I'd like to start the discussion on a new RFC adding bound-erased > generics types to PHP. > > Generic type parameters can be declared on classes, interfaces, > traits, functions, methods, closures, and arrow functions, with > bounds, defaults, and variance markers. Type parameters erase to their > bound at runtime; the pre-erasure form is preserved for Reflection and > consumed by static analyzers. > > - RFC: https://wiki.php.net/rfc/bound_erased_generic_types > - Implementation: https://github.com/php/php-src/pull/21969 > > Thanks, > Seifeddine. > Hi, PHPStan creator and maintainer here. I like this RFC, especially the depth at which it explains why a substantial portion of PHP developers would welcome this addition to the language. Some people here and on other channels voiced their concerns about types not being enforced at runtime. My view is that this RFC is for an audience that has been experiencing this every day already while developing in PHP for many years. Because the PHP type system is currently insufficient in expressing types, we use generics in PHPDocs for this job. And they don’t mean anything for the runtime. But we make sure to run static analysers to check our code. This RFC will make the experience of developing in PHP nicer for this audience. I’d compare it to Constructor Property Promotion RFC which reduced the need to mention the same property name in code from 4 to 1. Today if we want to accept a generic object in a parameter, we have to write it like this: /** * @param Collection<Foo> $collection */ function doFoo(Collection $collection): void { } So the parameter name and the class name have to be repeated. In this RFC the code above instead becomes this: function doFoo(Collection<Foo> $collection): void { } Without making things worse for anyone. But making it better for the audience who has been using generics with no runtime enforcement for many years. Which version would you rather write? Prior art in other languages is the proof this makes sense. Let’s say this RFC passes and is released in the next PHP version. If I don’t use static analysers today and a library I depend on introduces native generics, nothing changes for me. Same way I violated @template PHPDocs before, now I’m violating native generics instead. If someone uses @template PHPDocs today in their own code, you can assume they almost certainly also runs a static analyser. No one is forcing anyone to adopt all language features. Same way the match expression isn’t for everyone, bound-erased generic types don’t have to be for everyone. But there are many PHP developers who would welcome this and have been beating the drum for many years. The PHP documentation about this feature could mention the compromises needed to deliver this anticipated feature. And if someone misuses that (introduces generics in their code without checking with static analyser), well, that's a bug they've introduced — the same class of bug already possible today with @template. Ondřej Mirtes
