On Mon, 25 May 2026 at 11:29, Derick Rethans <[email protected]> wrote: > > I therefore do not believe this is a way forward, and await what the > result of https://thephp.foundation/blog/2025/08/05/compile-generics/ is > going to turn out to be. > > That blog post is a year old, and the top comment on the attached Reddit thread captures my view on it:
> The problem with such an approach is that it locks generics to be reified. If at some point PHP realizes it's not possible or feasible to implement reified generics for everything else (`new` construct, methods, compound types etc), then PHP will likely **never** implement erased generics for those missing features, or generics in general in PHP - due to backwards compatibility promise and/or consistency, and PHP will be stuck forever with half-baked feature that, arguably, doesn't even cover 50% of it's usage (although the article states it's 80%, I doubt that's true. In my experience generics in functions, methods as well as `new` instantiations account for more than half of all usages, if not much more). > I would much rather have "full" support of erased generics, than a <50% support of reified generics that will never get above that 50%. I would add to that: in 2004 adding runtime-checked parameter types at function boundaries made sense because there was no other widely-accepted way of checking those contracts. Adding checks at function boundaries made failures much easier to debug. It would take more than a decade before open-source static analysis tools began to be widely adopted by PHP developers — tools that can discover such bugs far earlier in the development process. In 2026 runtime-checked types don't make sense in all circumstances, not when static analysis tools can discover far more bugs, far earlier and faster, than runtime checks can ever hope to. The majority of new interpreted code being written today is in languages with erased generics. I feel that the decisions made in 2004 should not dominate decision-making today.
