Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130825
Precedence: list
MIME-Version: 1.0
References: <CAFyg4HhZsH_gMjvJteYvA2h7sMm48-Hz=UxQ_+Ezu4pneRfr8A@mail.gmail.com>
In-Reply-To: <CAFyg4HhZsH_gMjvJteYvA2h7sMm48-Hz=UxQ_+Ezu4pneRfr8A@mail.gmail.com>
Date: Mon, 11 May 2026 10:38:25 +0200
Message-ID: <CANSNCr0wkmLyh8pxAdtBdkL4A96i9OXBeAttW12FDMhe5q-7Gw@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] [Discussion] Bound-Erased Generic Types
To: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000036a383065186ac1d"
From: brent.roose@jetbrains.com (Brent Roose)

--00000000000036a383065186ac1d
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Thank you, Seifeddine, for all this work and effort; it was a very clear
and even pleasant read. To internals: I'd like to highlight a couple of
additional reasons why I think you should vote yes on this final RFC.

1. Although runtime-ignored generics are a paradigm shift compared to PHP's
current type system, it's important to note that the target audience for
this feature is already very familiar with this workflow. The value of
generics (and by extension, the whole type system) for them comes from
static type analysis, not the runtime type checker. Why do we need
dedicated syntax then, and not stick with docblocks? Because of the reasons
outlined in the RFC: a consistent spec and consistent syntax.
2. Regarding the consistent specification, you may know I work at PhpStorm,
so I'd like to highlight how much of a pain the current situation is for us
(and also other static analysis vendors). There is no consistency in the
details. We have a huge backlog of issues regarding generic type checking
that are unsolvable without a proper and consistent spec. PHPStan does X,
Psalm does Y, Mago does Z; and most developers expect PhpStorm to support
everything. Furthermore, performance is much more a concern for us, as we
run our type checker in real time. We would love to improve our generic
type support, but a proper spec is required to ensure consistency and a
clear path forward. Full disclosure, we tried bringing all static analysis
vendors together five or six years ago to create this consistent spec
ourselves. These efforts failed, and the only viable option we see is if
the spec came from internals.
3. Regarding adding new syntax that doesn't really do anything, there is
precedent with attributes. Similar to generics, annotations were a
docblock-only feature that got dedicated syntax, without any runtime effect
besides reflection. That's exactly the mindset this RFC embraces, and
attributes were very well received by the PHP community. I understand some
people may fear runtime-ignored generics causing confusion, but I don't
think this will be a problem, given that the target audience is: one, used
to this workflow already; and, two, attributes already introduced this
concept of "syntax that has no runtime effect".

I hope that, along with all the arguments Seifeddine made in the RFC, you
seriously consider voting yes on the final RFC, even if you yourself aren't
the target audience for this feature. The vast majority of people who would
benefit from generics are the people already using static analysis.
Speaking with them for years both online and offline, I know most are on
board with this approach. (I say "most of them", but truthfully, everyone I
spoke with over the years is on board. I just avoid saying "all" because
I'm sure someone somewhere disagrees).

Have a good day!

Brent

On Sun, May 10, 2026 at 9:04=E2=80=AFPM Seifeddine Gmati <azjezz@carthage.s=
oftware>
wrote:

> Hello Internals,
>
> I'd like to start the discussion on a new RFC adding bound-erased
> generics types to PHP.
>
> Generic type parameters can be declared on classes, interfaces,
> traits, functions, methods, closures, and arrow functions, with
> bounds, defaults, and variance markers. Type parameters erase to their
> bound at runtime; the pre-erasure form is preserved for Reflection and
> consumed by static analyzers.
>
> - RFC: https://wiki.php.net/rfc/bound_erased_generic_types
> - Implementation: https://github.com/php/php-src/pull/21969
>
> Thanks,
> Seifeddine.
>

--00000000000036a383065186ac1d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Thank you, Seifeddine, for all this work and effort; it wa=
s a very clear and even pleasant read. To internals: I&#39;d like to highli=
ght a couple of additional reasons why I think you should vote yes on this =
final RFC.<div><br></div><div>1. Although runtime-ignored generics are a pa=
radigm=C2=A0shift compared to PHP&#39;s current type system, it&#39;s impor=
tant to note that the target audience for this feature is already very fami=
liar with this workflow. The value of generics (and by extension, the whole=
 type system) for them comes from static type analysis, not the runtime typ=
e checker. Why do we need dedicated syntax then, and not stick with docbloc=
ks? Because of the reasons outlined in the RFC: a consistent spec and consi=
stent syntax.</div><div>2. Regarding the consistent specification, you may =
know I work at PhpStorm, so I&#39;d like to highlight how much of a pain th=
e current situation is for us (and also other static analysis vendors). The=
re is no consistency in the details. We have a huge backlog of issues regar=
ding generic type checking that are unsolvable without a proper and consist=
ent spec. PHPStan does X, Psalm does Y, Mago does Z; and most developers ex=
pect PhpStorm to support everything. Furthermore, performance is much <span=
 style=3D"background-color:rgba(247,236,254,0.118)">more a concern for us, =
as we run our type checker in real time. We would love to improve our gener=
ic type support, but a proper spec is required to ensure consistency and a =
clear path forward.=C2=A0Full disclosure, we tried bringing all static anal=
ysis vendors together five or six years ago to create this consistent spec =
ourselves. These efforts failed, and the only viable option we see is if th=
e spec came from internals.=C2=A0</span></div><div><span style=3D"backgroun=
d-color:rgba(247,236,254,0.118)">3. Regarding adding new syntax that doesn&=
#39;t really do anything, there is precedent with attributes. Similar to ge=
nerics, annotations were a docblock-only feature that got dedicated syntax,=
 without any runtime effect besides reflection. That&#39;s exactly the mind=
set this RFC embraces, and attributes were very well received by the PHP co=
mmunity. I understand some people may fear runtime-ignored generics causing=
 confusion, but I don&#39;t think this will be a problem, given that the ta=
rget audience is: one, used to this workflow already; and, two, attributes =
already introduced this concept of &quot;syntax that has no runtime effect&=
quot;.</span></div><div><span style=3D"background-color:rgba(247,236,254,0.=
118)"><br></span></div><div><span style=3D"background-color:rgba(247,236,25=
4,0.118)">I hope that, along with all the arguments=C2=A0</span>Seifeddine =
made in the RFC, you seriously consider voting yes on the final RFC, even i=
f you yourself aren&#39;t the target audience for this feature. The vast ma=
jority of people who would benefit from generics are the people already usi=
ng static analysis. Speaking with them for years both online and offline, I=
 know most are on board with this approach. (I say &quot;most of them&quot;=
, but truthfully, everyone I spoke with over the years is on board. I just =
avoid saying &quot;all&quot; because I&#39;m sure someone somewhere disagre=
es).</div><div><br></div><div>Have a good day!</div><div><br></div><div>Bre=
nt</div></div><br><div class=3D"gmail_quote gmail_quote_container"><div dir=
=3D"ltr" class=3D"gmail_attr">On Sun, May 10, 2026 at 9:04=E2=80=AFPM Seife=
ddine Gmati &lt;azjezz@carthage.software&gt; wrote:<br></div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid=
 rgb(204,204,204);padding-left:1ex">Hello Internals,<br>
<br>
I&#39;d like to start the discussion on a new RFC adding bound-erased<br>
generics types to PHP.<br>
<br>
Generic type parameters can be declared on classes, interfaces,<br>
traits, functions, methods, closures, and arrow functions, with<br>
bounds, defaults, and variance markers. Type parameters erase to their<br>
bound at runtime; the pre-erasure form is preserved for Reflection and<br>
consumed by static analyzers.<br>
<br>
- RFC: <a href=3D"https://wiki.php.net/rfc/bound_erased_generic_types" rel=
=3D"noreferrer" target=3D"_blank">https://wiki.php.net/rfc/bound_erased_gen=
eric_types</a><br>
- Implementation: <a href=3D"https://github.com/php/php-src/pull/21969" rel=
=3D"noreferrer" target=3D"_blank">https://github.com/php/php-src/pull/21969=
</a><br>
<br>
Thanks,<br>
Seifeddine.<br>
</blockquote></div>

--00000000000036a383065186ac1d--