Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128393
Feedback-ID: ifab94697:Fastmail
Precedence: list
MIME-Version: 1.0
Date: Tue, 05 Aug 2025 08:39:07 +0200
To: "Levi Morrison" <levim@php.net>, "Larry Garfield" <larry@garfieldtech.com>
Cc: "php internals" <internals@lists.php.net>
Message-ID: <b87fdf83-c2da-4708-93c6-f4dca61c8b8a@app.fastmail.com>
In-Reply-To: <9e43bf45-af3c-428e-8cf2-16772382d25b@app.fastmail.com>
References: <c8a2439d-2690-4e0e-a13b-718714728bd5@app.fastmail.com>
 <CAFMT4NrfyJgv1JAkYe=XKGpk8QquO11599tiyouE1Px663L_5A@mail.gmail.com>
 <9e43bf45-af3c-428e-8cf2-16772382d25b@app.fastmail.com>
Subject: Re: [PHP-DEV] Blog post: If we can get partial generics, should we?
Content-Type: multipart/alternative;
 boundary=50208afbc780482c997e9781c313517b
From: rob@bottled.codes ("Rob Landers")

--50208afbc780482c997e9781c313517b
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On Tue, Aug 5, 2025, at 08:19, Rob Landers wrote:
>=20
> On Mon, Aug 4, 2025, at 22:49, Levi Morrison wrote:
>> On Mon, Aug 4, 2025 at 9:26=E2=80=AFAM Larry Garfield <larry@garfield=
tech.com> wrote:
>> >
>> > Hi folks.  I recently wrote a blog post on behalf of the PHP Founda=
tion about some work Gina has been doing regarding generics.  It's a fol=
low-up to last year's post on a similar topic.  We are especially lookin=
g for feedback from the Internals crew, and voters in particular, on whe=
ther or not to proceed.
>> >
>> > https://thephp.foundation/blog/2025/08/05/compile-generics/
>> >
>> > Wearing my Internals/voter hat, my stance is a very strong "yes ple=
ase!"
>> >
>> > --
>> >   Larry Garfield
>> >   larry@garfieldtech.com
>>=20
>> I played with a few iterations of Gina's work. My opinion at that time
>> was that there are too many restrictions to be very useful. Based on
>> those evaluations, I would not consider it to be "80% of the
>> benefit.". With that said, maybe Gina has removed some of the
>> restrictions. Based on the article it , but I'll commit to trying it
>> out again.
>>=20
>> One thing the article says we're missing and that we we definitely
>> need is unions, or at the very least the union with null. Nullable
>> types are everywhere, and even in your interfaces it's going to show
>> up. For instance, if we had interfaces for Set, Map, etc, there are
>> going to be operations which return nullable values. Sure, exceptions
>> can be thrown in some cases but not all of them. For instance, if you
>> are building a caching data structure, throwing an exceptions on a
>> cache miss would be very bad for performance*. You can separate it
>> into has + get, but this has two lookups which is not desirable for
>> performance. You can return a "tuple" like `[found, $value]` where
>> `$value` may be null, but this loses even more type safety, and isn't
>> a very common pattern in PHP. You really want `T|null`.
>>=20
>> There are probably other "edges" that are important and should be
>> handled in this first pass, but missing nullable types is not a small
>> thing.
>>=20
>> * We'll get a mini-optimization in PHP 8.5 for making the exception
>> object faster to construct, but it doesn't speed up the backtrace,
>> which is where most of the performance cost comes from in practice. If
>> you are benchmarking this, make sure to include cases where your stack
>> is a few dozen frames deep. I work for an observability company for my
>> day job, and it is insanely normal for there to be 10+ frames, and
>> still fairly common to be 30+ frames. Think about routing, frameworks,
>> middleware, helper functions, libraries and abstractions, etc. If you
>> use middleware in particular, expect 50+ frames to be normal.
>>=20
>=20
> I have a few different ideas for unions/intersections, but to implemen=
t them now would be refactoring for the sake of refactoring. There would=
 be no benefit to implement any of it now.
>=20
> Earlier this year I tried interning types, so that type checking could=
 be simple pointer equality. From there, I implemented a tri, such that =
intersections and unions were very fast to check.=20
>=20
> The result is that it was virtually useless with today=E2=80=99s php, =
except for the most pathological cases. PHP doesn=E2=80=99t do much type=
 checking =E2=80=94 currently.
>=20
> In any case, the changes required to pull it off (not counting opcache=
) were huge. If we were to run into the pathological cases more often (s=
uch as with runtime generics), it might be worth it.
>=20
> All that being said, we are talking about *compile-time* generics. If =
there is a time to be less efficient, it is during compilation, which ge=
nerally happens once (esp with opcache). Further, pathological type chec=
king is quite rare in codebases (most types are relatively simple withou=
t deep hierarchical intersections and unions), so I assume it will be fi=
ne to enable them.
>=20
> =E2=80=94 Rob

It=E2=80=99s also worth pointing out that nullable or a union of null an=
d another type is technically just one type with the nullable bit set. S=
o, I suspect nullable types will still obey the =E2=80=9Csingle type=E2=80=
=9D rules proposed here.=20

=E2=80=94 Rob
--50208afbc780482c997e9781c313517b
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title></head><body><div><br></div><d=
iv><br></div><div>On Tue, Aug 5, 2025, at 08:19, Rob Landers wrote:</div=
><blockquote type=3D"cite" id=3D"qt" style=3D""><div><br></div><div>On M=
on, Aug 4, 2025, at 22:49, Levi Morrison wrote:</div><blockquote type=3D=
"cite" id=3D"qt-qt" style=3D""><div>On Mon, Aug 4, 2025 at 9:26=E2=80=AF=
AM Larry Garfield &lt;<a href=3D"mailto:larry@garfieldtech.com">larry@ga=
rfieldtech.com</a>&gt; wrote:</div><div>&gt;</div><div>&gt; Hi folks.&nb=
sp; I recently wrote a blog post on behalf of the PHP Foundation about s=
ome work Gina has been doing regarding generics.&nbsp; It's a follow-up =
to last year's post on a similar topic.&nbsp; We are especially looking =
for feedback from the Internals crew, and voters in particular, on wheth=
er or not to proceed.</div><div>&gt;</div><div>&gt;&nbsp;<a href=3D"http=
s://thephp.foundation/blog/2025/08/05/compile-generics/">https://thephp.=
foundation/blog/2025/08/05/compile-generics/</a></div><div>&gt;</div><di=
v>&gt; Wearing my Internals/voter hat, my stance is a very strong "yes p=
lease!"</div><div>&gt;</div><div>&gt; --</div><div>&gt;&nbsp;&nbsp; Larr=
y Garfield</div><div>&gt;&nbsp;&nbsp;&nbsp;<a href=3D"mailto:larry@garfi=
eldtech.com">larry@garfieldtech.com</a></div><div><br></div><div>I playe=
d with a few iterations of Gina's work. My opinion at that time</div><di=
v>was that there are too many restrictions to be very useful. Based on</=
div><div>those evaluations, I would not consider it to be "80% of the</d=
iv><div>benefit.". With that said, maybe Gina has removed some of the</d=
iv><div>restrictions. Based on the article it , but I'll commit to tryin=
g it</div><div>out again.</div><div><br></div><div>One thing the article=
 says we're missing and that we we definitely</div><div>need is unions, =
or at the very least the union with null. Nullable</div><div>types are e=
verywhere, and even in your interfaces it's going to show</div><div>up. =
For instance, if we had interfaces for Set, Map, etc, there are</div><di=
v>going to be operations which return nullable values. Sure, exceptions<=
/div><div>can be thrown in some cases but not all of them. For instance,=
 if you</div><div>are building a caching data structure, throwing an exc=
eptions on a</div><div>cache miss would be very bad for performance*. Yo=
u can separate it</div><div>into has + get, but this has two lookups whi=
ch is not desirable for</div><div>performance. You can return a "tuple" =
like `[found, $value]` where</div><div>`$value` may be null, but this lo=
ses even more type safety, and isn't</div><div>a very common pattern in =
PHP. You really want `T|null`.</div><div><br></div><div>There are probab=
ly other "edges" that are important and should be</div><div>handled in t=
his first pass, but missing nullable types is not a small</div><div>thin=
g.</div><div><br></div><div>* We'll get a mini-optimization in PHP 8.5 f=
or making the exception</div><div>object faster to construct, but it doe=
sn't speed up the backtrace,</div><div>which is where most of the perfor=
mance cost comes from in practice. If</div><div>you are benchmarking thi=
s, make sure to include cases where your stack</div><div>is a few dozen =
frames deep. I work for an observability company for my</div><div>day jo=
b, and it is insanely normal for there to be 10+ frames, and</div><div>s=
till fairly common to be 30+ frames. Think about routing, frameworks,</d=
iv><div>middleware, helper functions, libraries and abstractions, etc. I=
f you</div><div>use middleware in particular, expect 50+ frames to be no=
rmal.</div><div><br></div></blockquote><div><br></div><div>I have a few =
different ideas for unions/intersections, but to implement them now woul=
d be refactoring for the sake of refactoring. There would be no benefit =
to implement any of it now.</div><div><br></div><div>Earlier this year I=
 tried interning types, so that type checking could be simple pointer eq=
uality. From there, I implemented a tri, such that intersections and uni=
ons were very fast to check.&nbsp;</div><div><br></div><div>The result i=
s that it was virtually useless with today=E2=80=99s php, except for the=
 most pathological cases. PHP doesn=E2=80=99t do much type checking =E2=80=
=94 currently.</div><div><br></div><div>In any case, the changes require=
d to pull it off (not counting opcache) were huge. If we were to run int=
o the pathological cases more often (such as with runtime generics), it =
might be worth it.</div><div><br></div><div>All that being said, we are =
talking about&nbsp;<b>compile-time</b> generics. If there is a time to b=
e less efficient, it is during compilation, which generally happens once=
 (esp with opcache). Further, pathological type checking is quite rare i=
n codebases (most types are relatively simple without deep hierarchical =
intersections and unions), so I assume it will be fine to enable them.</=
div><div><br></div><div id=3D"qt-sig121229152">=E2=80=94 Rob</div></bloc=
kquote><div><br></div><div>It=E2=80=99s also worth pointing out that nul=
lable or a union of null and another type is technically just one type w=
ith the nullable bit set. So, I suspect nullable types will still obey t=
he =E2=80=9Csingle type=E2=80=9D rules proposed here.&nbsp;</div><div><b=
r></div><div id=3D"sig121229152">=E2=80=94 Rob</div></body></html>
--50208afbc780482c997e9781c313517b--