Bound-Erased Generic Types
This RFC adds generic type syntax to PHP. Classes, interfaces, traits, functions, methods, closures, and arrow functions can declare type parameters; those parameters carry bounds, defaults, and variance markers; type arguments may be supplied at use sites and at call sites via turbofish.
final readonly class Pair<+L, +R> { public function __construct( public L $left, public R $right, ) {} public function swap(): Pair<R, L> { return new Pair($this->right, $this->left); } } final readonly class Box<+T> { public function __construct( public T $value, ) {} public function map<U>(callable $fn): Box<U> { return new Box(($fn)($this->value)); } public function zip<O>(O $value): Box<Pair<T, O>> { return new Box(new Pair($this->value, $value)); } } function identity<T>(T $value): T { return $value; } $greeting = new Box::<string>("hello, world"); $paired = $greeting->zip::<int>(42); $swapped = $paired->value->swap(); $result = identity::<Pair<int, string>>($swapped);
I've been writing about this for years. If we ever want generics in PHP, this is the way.
I don't often use generic definitions in docblocks today, but when I do, it's a mess. I think this RFC is the right move at the right time, and cost (both runtime and syntax) appears zero to minimal at best. It'd be really great to see generics land in PHP. It's been a long time coming.
Generics are one of the most requested feature since PHP met the OOP paradigm and for me, this will step to set the boundaries to its OOP complete adherence.
We will be able to describe complex classes or dynamically typed ones, increase readability and move type hinting away from comments.
generics in PHP , the next step
It's one step closer to moving type safety from the doc blocks to the actual code.
I vote yes because this solves a real problem for library authors. In my own Result Flow library, the API depends on generic relationships like Result<TSuccess, TFailure> flowing through methods such as map, then, flatMap, match, and unwrap. Today those relationships mostly live in PHPDoc and PHPStan, not as native PHP syntax that the parser, Reflection, and tools can rely on. This RFC would make those types clearer and more useful to the PHP ecosystem, while keeping PHP’s runtime model practical through bound erasure.
in the syntax function identity<T>(T $value): T { return $value; }
why adding a <T>. we already have info of type of param in param list and type of return after the :
This makes life easier for those who already use generics with PHPdoc and changes nothing for those who don't use them and don't want to use them.
I’ ve been waiting for this feature for a long time.
This should be native to the language.
Along with the host of all previously mentioned advantages, I find that this could open the door for much more in-depth compiler analysis leading to better performance in the future!
Generics and Async are two of the fundamental pillars of modern PHP, and we need to achieve them.
finally, please let it pass
I'm more in the doubting camp, but there is only YES or NO vote available.
I'm really concerned about the cognitive load while reading the code, it adds complexity, PHP's selling point was its simplicity, features like Aviz, and other make it harder and harder to read and understand quickly.
So, be careful what you wish for)
Check out another RFCs
Chain method on newly created objects without parentheses
This RFC proposes a way to have multi-line short closures — closures that don't need explicit use statements, but can still have multiple lines and a return statement.