Re: [RFC] [Discussion] Bound-Erased Generic Types

Hi Seifeddine, > Good find. That's a bug in the implementation. I'll fix it before the RFC moves to > voting. I'm curious how you'd fix it. The fix has to be either (a) per-child bytecode specialization (which the RFC explicitly says it doesn't do), (b) runtime indirection at every entry (which adds dispatch cost the RFC doesn't acknowledge), or (c) something else not described. The architecture section makes a specific claim about where parameter checks happen; the bug-fix commitment implies something different. > For genuinely new developers, the path is the same as for every other feature: documentation > explains what generics do, the same way it explains classes, inheritance, functions, types, and so > on. Someone new won't be familiar with every single feature of PHP *except* generics. Either: > > 1. They know OOP in general: meaning they have already encountered generics in Java, Scala, > Kotlin, C#, or a similar language (which uses type erasure). > 2. They're genuinely new to programming; generics are no harder than any other feature > they'll need to learn from documentation. This binary misses a significant third group: PHP developers who've used PHP for years and never had reason to learn generics from another language. They're not new to programming, but they are new to this feature, and they form mental models from PHP runtime behavior because that's how they've always used PHP. The IntBox case demonstrates exactly what their first encounter will look like: write the code, refresh, output looks correct. They are precisely the "wide range of users" the RFC template asks you to consider. > I've worked on multi-million-line PHP codebases that used > @template [...] The 200k figure is evidence of widespread adoption, > not the totality of it. I said multi-million **files**, not lines. They are considerably different scales, multi-million files are hundreds of millions of lines, an order of magnitude or more beyond "multi-million-line codebases." The point was about the denominator: the broader PHP footprint is much larger than the population your GitHub search covers. On WordPress specifically (which runs 40+% of the web and is the canonical example of "PHP outside the @template ecosystem") I checked the codebase. There are exactly five files using @template. Two use @template TArrayShape of array<string, mixed> (explicitly out of scope per this RFC's own deferral). Two use @template Psr7Compatible of bool in SimplePie. One uses @template T with class-string<T> parameters (partial benefit at best, since class-string<T> itself is deferred). WordPress, even where it uses @template, would see essentially zero benefit from this RFC. A broader search of the public PHP ecosystem shows the majority of @template usage relies on patterns this RFC explicitly defers (array<K, V>, iterable<T>, class-string<T>, etc.). The 200k figure isn't just small relative to PHP's footprint ... it overstates the population that would actually benefit from what's being proposed. You responded to anecdotal evidence about scale with a smaller anecdote on the favored side of the ratio, presented as if it addressed the claim.. It doesn't. I've already said my stance on this RFC, so I won't argue about this further. But the dismissal isn't logical, and the empirical case underneath it doesn't hold up either. — Rob