Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130826
Feedback-ID: id5114917:Fastmail
Date: Mon, 11 May 2026 13:10:49 +0100
To: internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] [Discussion] Bound-Erased Generic Types
User-Agent: K-9 Mail for Android
In-Reply-To: <CAFyg4HhZsH_gMjvJteYvA2h7sMm48-Hz=UxQ_+Ezu4pneRfr8A@mail.gmail.com>
References: <CAFyg4HhZsH_gMjvJteYvA2h7sMm48-Hz=UxQ_+Ezu4pneRfr8A@mail.gmail.com>
Message-ID: <8E4D29B2-A8FC-4CEC-8B74-C939521A102F@rwec.co.uk>
Precedence: list
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: imsop.php@rwec.co.uk ("Rowan Tommins [IMSoP]")

On 10 May 2026 20:02:32 BST, Seifeddine Gmati <azjezz@carthage=2Esoftware> =
wrote:
>Hello Internals,
>
>I'd like to start the discussion on a new RFC adding bound-erased
>generics types to PHP=2E

Hi Seifeddine,

Thanks for putting together this proposal=2E

However, I am generally against any *unenforced* implementation of generic=
s=2E 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 parti=
cular signatures, but actually does not=2E

There is lots of background in the RFC, but one relevant comparison not re=
ferenced is Python, where all type hints are unenforced=2E Static analysis =
has to be run manually, so code can be written, and even published as a lib=
rary, with completely incorrect type information=2E Users of that code then=
 make reasonable assumptions based on the published types, and get unexpect=
ed run-time behaviour=2E

Note that this is fundamentally different from the experience of languages=
 like Java or TypeScript, where type information may be erased, but is stil=
l *enforced*, because static analysis is a compulsory part of the compilati=
on process=2E

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 ge=
nerics, and publish it to Packagist without actually checking it; or write =
supposed invariants which only hold if the user also analyses their own cod=
e=2E This is true today, of course, but the claims are much weaker, sitting=
 in docblocks not native syntax=2E

Once we go down this route, it will be very hard to change our minds, beca=
use enforcing types in code which previously ignored them would be a breaki=
ng change=2E

I think the only options I would personally support are:

a) run-time enforced generics in limited positions (as in the blog post yo=
u 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]