Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128392
Feedback-ID: ifab94697:Fastmail
Precedence: list
MIME-Version: 1.0
Date: Tue, 05 Aug 2025 08:19:47 +0200
To: "Levi Morrison" <levim@php.net>, "Larry Garfield" <larry@garfieldtech.com>
Cc: "php internals" <internals@lists.php.net>
Message-ID: <9e43bf45-af3c-428e-8cf2-16772382d25b@app.fastmail.com>
In-Reply-To: 
 <CAFMT4NrfyJgv1JAkYe=XKGpk8QquO11599tiyouE1Px663L_5A@mail.gmail.com>
References: <c8a2439d-2690-4e0e-a13b-718714728bd5@app.fastmail.com>
 <CAFMT4NrfyJgv1JAkYe=XKGpk8QquO11599tiyouE1Px663L_5A@mail.gmail.com>
Subject: Re: [PHP-DEV] Blog post: If we can get partial generics, should we?
Content-Type: multipart/alternative;
 boundary=0b060c17862047519a0a757ff2a5ba2d
From: rob@bottled.codes ("Rob Landers")

--0b060c17862047519a0a757ff2a5ba2d
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


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@garfieldt=
ech.com> wrote:
> >
> > Hi folks.  I recently wrote a blog post on behalf of the PHP Foundat=
ion about some work Gina has been doing regarding generics.  It's a foll=
ow-up to last year's post on a similar topic.  We are especially looking=
 for feedback from the Internals crew, and voters in particular, on whet=
her 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 plea=
se!"
> >
> > --
> >   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

I have a few different ideas for unions/intersections, but to implement =
them now would be refactoring for the sake of refactoring. There would b=
e no benefit to implement any of it now.

Earlier this year I tried interning types, so that type checking could b=
e simple pointer equality. From there, I implemented a tri, such that in=
tersections and unions were very fast to check.=20

The result is that it was virtually useless with today=E2=80=99s php, ex=
cept for the most pathological cases. PHP doesn=E2=80=99t do much type c=
hecking =E2=80=94 currently.

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 (suc=
h as with runtime generics), it might be worth it.

All that being said, we are talking about *compile-time* generics. If th=
ere is a time to be less efficient, it is during compilation, which gene=
rally happens once (esp with opcache). Further, pathological type checki=
ng is quite rare in codebases (most types are relatively simple without =
deep hierarchical intersections and unions), so I assume it will be fine=
 to enable them.

=E2=80=94 Rob
--0b060c17862047519a0a757ff2a5ba2d
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>On Mon, Aug 4, 2025, at 22:49, Levi Morrison wrote:</div><blockquote =
type=3D"cite" id=3D"qt" style=3D""><div>On Mon, Aug 4, 2025 at 9:26=E2=80=
=AFAM Larry Garfield &lt;<a href=3D"mailto:larry@garfieldtech.com">larry=
@garfieldtech.com</a>&gt; wrote:</div><div>&gt;</div><div>&gt; Hi folks.=
&nbsp; I recently wrote a blog post on behalf of the PHP Foundation abou=
t some 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 looki=
ng for feedback from the Internals crew, and voters in particular, on wh=
ether or not to proceed.</div><div>&gt;</div><div>&gt;&nbsp;<a href=3D"h=
ttps://thephp.foundation/blog/2025/08/05/compile-generics/">https://thep=
hp.foundation/blog/2025/08/05/compile-generics/</a></div><div>&gt;</div>=
<div>&gt; Wearing my Internals/voter hat, my stance is a very strong "ye=
s please!"</div><div>&gt;</div><div>&gt; --</div><div>&gt;&nbsp;&nbsp; L=
arry Garfield</div><div>&gt;&nbsp;&nbsp;&nbsp;<a href=3D"mailto:larry@ga=
rfieldtech.com">larry@garfieldtech.com</a></div><div><br></div><div>I pl=
ayed with a few iterations of Gina's work. My opinion at that time</div>=
<div>was that there are too many restrictions to be very useful. Based o=
n</div><div>those evaluations, I would not consider it to be "80% of the=
</div><div>benefit.". With that said, maybe Gina has removed some of the=
</div><div>restrictions. Based on the article it , but I'll commit to tr=
ying it</div><div>out again.</div><div><br></div><div>One thing the arti=
cle says we're missing and that we we definitely</div><div>need is union=
s, or at the very least the union with null. Nullable</div><div>types ar=
e everywhere, and even in your interfaces it's going to show</div><div>u=
p. For instance, if we had interfaces for Set, Map, etc, there are</div>=
<div>going to be operations which return nullable values. Sure, exceptio=
ns</div><div>can be thrown in some cases but not all of them. For instan=
ce, if you</div><div>are building a caching data structure, throwing an =
exceptions on a</div><div>cache miss would be very bad for performance*.=
 You can separate it</div><div>into has + get, but this has two lookups =
which is not desirable for</div><div>performance. You can return a "tupl=
e" like `[found, $value]` where</div><div>`$value` may be null, but this=
 loses 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 pro=
bably other "edges" that are important and should be</div><div>handled i=
n this first pass, but missing nullable types is not a small</div><div>t=
hing.</div><div><br></div><div>* We'll get a mini-optimization in PHP 8.=
5 for making the exception</div><div>object faster to construct, but it =
doesn't speed up the backtrace,</div><div>which is where most of the per=
formance cost comes from in practice. If</div><div>you are benchmarking =
this, make sure to include cases where your stack</div><div>is a few doz=
en frames deep. I work for an observability company for my</div><div>day=
 job, and it is insanely normal for there to be 10+ frames, and</div><di=
v>still fairly common to be 30+ frames. Think about routing, frameworks,=
</div><div>middleware, helper functions, libraries and abstractions, etc=
. If you</div><div>use middleware in particular, expect 50+ frames to be=
 normal.</div><div><br></div></blockquote><div><br></div><div>I have a f=
ew different ideas for unions/intersections, but to implement them now w=
ould be refactoring for the sake of refactoring. There would be no benef=
it to implement any of it now.</div><div><br></div><div>Earlier this yea=
r 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.&nbsp;</div><div><br></div><div>The resul=
t 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.</div><div><br></div><div>In any case, the changes requ=
ired to pull it off (not counting opcache) were huge. If we were to run =
into 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 a=
re talking about&nbsp;<b>compile-time</b> generics. If there is a time t=
o be less efficient, it is during compilation, which generally happens o=
nce (esp with opcache). Further, pathological type checking is quite rar=
e in codebases (most types are relatively simple without deep hierarchic=
al intersections and unions), so I assume it will be fine to enable them=
.<br></div><div><br></div><div id=3D"sig121229152">=E2=80=94 Rob</div></=
body></html>
--0b060c17862047519a0a757ff2a5ba2d--