Hi!
> 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.
If one of the concerns is that `Collection<int>` looks like something
that will be checked at runtime, but actually will not be, would it
make sense to introduce erased generics together with syntax that
explicitly marks the type declaration as erased/unchecked?
For example:
```
function foo(erased Collection<int> $c): void {}
```
If the keyword is considered too verbose, a symbolic marker could also
be considered:
```
function foo(@Collection<int> $c): void {}
```
or:
```
function foo(-Collection<int> $c): void {}
```
The exact spelling is obviously bikeshedding. My point is more about
where the marker should be placed semantically: perhaps the marker
should be on the erased/unchecked form, rather than on a future
reified form.
In the current discussion, one possible answer to future reified
generics is that they could be introduced as an opt-in feature later.
However, if the disagreement is about the expectation that PHP type
declarations are enforced at runtime by default, then it seems more
consistent to mark the erased form explicitly.
That would give users three distinct forms:
```
Collection
// runtime class check only
// no claim about type arguments; raw/unparameterized/unknown
@Collection<User>
// erased generic annotation
// at runtime, only Collection is checked
// User is preserved for static analysis and Reflection
// the marker could be a keyword such as `erased`, or some symbol;
// the exact spelling is not the important part
Collection<User>
// left available for a future reified / runtime-checked meaning
```
This would avoid making the most natural spelling, `Collection<User>`,
mean “looks checked, but is actually erased”. Users who primarily want
static analysis support could still opt into the erased form
explicitly, while the unmarked syntax would remain available for a
future runtime-checked model.
Thanks!
--
Shinji Igarashi
2026年5月11日(月) 21:12 Rowan Tommins [IMSoP] <[email protected]>:
>
> 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.
>
> There is lots of background in the RFC, but one relevant comparison not
> referenced is Python, where all type hints are unenforced. Static analysis
> has to be run manually, so code can be written, and even published as a
> library, with completely incorrect type information. Users of that code then
> make reasonable assumptions based on the published types, and get unexpected
> run-time behaviour.
>
> Note that this is fundamentally different from the experience of languages
> like Java or TypeScript, where type information may be erased, but is still
> *enforced*, because static analysis is a compulsory part of the compilation
> process.
>
> Having most types enforced is obviously better than none, but as far as I can
> see the same risk exists - someone can write code that claims to use
> generics, and publish it to Packagist without actually checking it; or write
> supposed invariants which only hold if the user also analyses their own code.
> This is true today, of course, but the claims are much weaker, sitting in
> docblocks not native syntax.
>
> Once we go down this route, it will be very hard to change our minds, because
> enforcing types in code which previously ignored them would be a breaking
> change.
>
> I think the only options I would personally support are:
>
> a) run-time enforced generics in limited positions (as in the blog post you
> link to from Gina and Larry)
>
> b) generics which are erased at compile-time *by a tool that also enforces
> them* (as in Java, TypeScript, etc)
>
> Regards,
>
> Rowan Tommins
> [IMSoP]
