On Mon, May 11, 2026 at 1:13 PM Rowan Tommins [IMSoP] <[email protected]> wrote:
> On 10 May 2026 20:02:32 BST, 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. > > Hi Seifeddine, > > Thanks for putting together this proposal. > > However, I am generally against any *unenforced* implementation of > generics. I choose that word carefully: it is not type erasure per se that > I am against, but the ability to write code which *looks like* it enforces > particular signatures, but actually does not. > I'm of course not a voter but I'd like to just expand on some possible concerns around the particular implementation that's being proposed; if it was just purely static generics in first party syntax, I think in some ways that would be better than what's actually being proposed. Instead the RFC, at least as I'm understanding it, seems to land in a potentially awkward middle ground between fully erased generics and runtime enforcement, where generics become semantically significant in inheritance and reflection but not for runtime type identity. One thing that stands out to me is that this introduces a jarring asymmetry with how types work in PHP in any other respect. The case today is that where there's type information in code, the engine is checking and enforcing it (subject to some well known caveats around coercion, but still, there is behaviour there). This breaks that model and I think it's something people who will be voting ought to consider. If this RFC passes as-is, we'll be in a place where all the things it introduces are sensitive to backwards compatibility indefinitely going forward. So it rules out any kind of reification in future, no generic-aware instanceof checks, no opcache optimizations, etc. And I know some people will say we will never have those things anyway and that this is better than no generics at all, and I can see the case for that, I'm just pointing out this isn't making a decision about a feature, it's making a fundamental, long-term decision about language architecture. The proposed form is introducing all the design complexity of generics for developers, but really only for the gain that existing static analysis tools already provide, while the primary runtime/pre-runtime and optimization benefits of generics in any other language are still missing. And I'm not convinced by pointing to Hack's reify keyword, because it's a different case. Hack had a comparatively very small and centralised ecosystem versus PHP, the reach of erased generics in PHP once it sets in, in terms of design decisions, framework adoption, etc will be so large that no future "opt in" retrofitting of anything else will be plausible in the same way. It may be that all these things are okay from a cost-benefit perspective. I'm not saying I'm against it here, just that everyone owes it to themselves and every user to make sure this is the right decision, just because of the magnitude and impact this RFC carries. I'm not personally competent to give any meaningful feedback on the actual C implementation, but I can see most of it came from a single, enormous commit which will undoubtedly make meaningful review difficult. I hope someone who is both more C proficient and familiar with the engine's internals is up to the task.
