Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130818
Content-Type: multipart/alternative;
 boundary="------------rgzA0XabGqxnXY0a9tendP2z"
Message-ID:
 <SVAP279MB0383FF15C871B57AFC01B5E4E23B2@SVAP279MB0383.NORP279.PROD.OUTLOOK.COM>
Date: Mon, 11 May 2026 00:28:38 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] [RFC] [Discussion] Bound-Erased Generic Types
To: Seifeddine Gmati <azjezz@carthage.software>,
 php internals <internals@lists.php.net>
References: <CAFyg4HhZsH_gMjvJteYvA2h7sMm48-Hz=UxQ_+Ezu4pneRfr8A@mail.gmail.com>
Content-Language: en-US
In-Reply-To: <CAFyg4HhZsH_gMjvJteYvA2h7sMm48-Hz=UxQ_+Ezu4pneRfr8A@mail.gmail.com>
Precedence: list
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SVAP279MB0383:EE_|SV0P279MB0983:EE_
X-MS-Office365-Filtering-Correlation-Id: 79064277-2b95-46d4-1a18-08deaee37c69
X-Microsoft-Antispam:
	BCL:0;ARA:14566002|9400799043|37011999003|51005399006|25031999004|24021099003|8060799015|23021999003|12121999013|15080799012|41001999006|12050799012|19110799012|5072599009|1602099012|40105399003|3412199025|4302099013|440099028|10035399007|26104999009;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?bW9TWVlJVUlSWFdXRWNhTmFpdGJraU15WmxUd3FLSDE0eDcxMFBwODg5cGdI?=
 =?utf-8?B?bHRyelRwQU5IMzBOeE1FSy9HSUNOTW5EMVZMK0dYOUxEdy9BQ1FrTWhNYUZv?=
 =?utf-8?B?RW9wT3NYQndWMXpScEtyaVpCQmVsUXh2VTZwMkhYU1hrSWVucXhZV0xpMVgw?=
 =?utf-8?B?aXc0UGtkWUlOZGYxNDJEdVg3Z0FYTUtYWnFaM0JHRzcwN2haT25Qc2tVMmVM?=
 =?utf-8?B?MFNNTy8zT0xkZXVyN0p4dGxGdVQ2ZkpRcmVYSklubVZUVnhFQjJCOE5Fdksx?=
 =?utf-8?B?ZVcvUCs0V25aQWllVjdjNytEUTdHQUNVQnFUc0V1YVQrY0puNzRvUEhHLzBG?=
 =?utf-8?B?OU1rS0c2USs3RFJxdFd5a3hEaFpmblIxS3IrbDN6NnJERUhQQ0NOcHYyTkV6?=
 =?utf-8?B?Rklma1Q5cnVoWExPZU1BWUUzMjVVTUQrRmRuaGpUR1ZUVWFGbTY5WUZCeDcy?=
 =?utf-8?B?VkppK0ZCVW9lVDR4Sno1cFBhL2ZDMGJvRXFZK0dGSVpiRStZRXRSbVB1MFMr?=
 =?utf-8?B?WmVNUVNkV1U1cDhaY2RWem9FZjBBWG1ERXc4WlN3cnFSaGtNQjcyVnB1bG5s?=
 =?utf-8?B?bHhiOWYzSHlKNDdLOCszM1V0RloxUDRJQUF5STRINXRLcFpzTnRoMjVSV0lz?=
 =?utf-8?B?RkZDaSsyUWRBQ1dmdWl5QWxDdENhN3JTWFFyZTVvcVQzNkZ0eEtUanFWcER4?=
 =?utf-8?B?NkhmbUZ5cFVuN0xkK05DYTh1aE5zKy80MjErWnQ4ZGJpOG1admJjdy9yOUgw?=
 =?utf-8?B?VjZnQ28wWHJpRjV4YjdWSEh1NjVDRkZlZ1lvc2QyenBSY1E2dlo5UUYvYkdr?=
 =?utf-8?B?aTI2NStXN0xNbi91anV3ek9TYjQ5WExlYVAvN2dRWC8vdTVRZ1dZZE1FVzIz?=
 =?utf-8?B?WWlGT0dJMzl6Q200Z0MrTldpTlEvWVhFSzBOWVhaUU1FRmx5OHpkbmEzb0VF?=
 =?utf-8?B?Z1ZHQXFyYkFXM2sxR1pReEFKemtUSjNXMDBkTUtGYWlBYzhyL01jYXJacktR?=
 =?utf-8?B?eWl3ZWQvZEVvOGpuc0VaV2RsY0M1NVBrQXBmQm4wZW1SWVZpL2lNazBMdGJK?=
 =?utf-8?B?em1kOFZuZUo1V3ZVdXN0THZSaXRqNHZqUzhvbE5mWUcxM3cycXI1ZGxpdFBp?=
 =?utf-8?B?a3R1QlREQlNyNlpESUoxV1dBVmN3TUVpY1hEcWpmS1VkS0RIUllPeHRJOGh2?=
 =?utf-8?B?N0FGdzRLMTFSVklUY294RllhNzZWdlNTYjhGZHg1eHpXREJHSDVpU0RQNzZp?=
 =?utf-8?B?bDNlaTF5djZPcVI4TVhDVzZaQlFNUmV4em9QTlVWbFdwYnlJUmhBcE1IeFhw?=
 =?utf-8?B?YTFaUVJaYis4UmxTME9YUENtL3FmRGtldk5FdUo4cEk0N1NRYWlEVzZhZGow?=
 =?utf-8?B?N1BVcGorSzNkUmh0QW5PSHNvb1phRU1sQmhuMk5mM0FnejVVRlFQYXQ1R04x?=
 =?utf-8?B?a0RnRUFiY2tUaWdFYysvVnZibm54ZTJQSGI1NE5Gb0ZSVDFUbGlJUmhpU2VK?=
 =?utf-8?B?dXJaeEVCNFZGQ1RtdVJiWUZ2b0xmK3FSWm1MeklTUjc5QWhyWGtWSkNIcEpt?=
 =?utf-8?B?YVFlcUtMdzlVSlhqNDRuUlhGUXdHUHVMM1d0MU05RnRJV0RiT28yTXQzV0FQ?=
 =?utf-8?Q?U9VHgPKFLurGkdPvjI59EYt7ftgmLSf9LrzIYLwR1LsA=3D?=
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?VzdJK09IODd0WFZaZ0gyY2g0SkpiUU1lMkhBQTZQbnVzNEdGZzlQNWV0S0Jh?=
 =?utf-8?B?dzFSa2xTakxxN0x0YzJxaXA2dkpYcFJrK040WW0xUyt1OWRuZmUvN0YrVjcw?=
 =?utf-8?B?SjRIWjZXRmpyTHRkbnRMWlU4VFhJcHFyNVRicUtzNWk2RURrdFlsNnZHeHVG?=
 =?utf-8?B?WlBHT0szVjA3ZEN4Z3Q3SWJ6L2NWbkhYU3NGWUl0d2lxenhKM2RobHNXSU1a?=
 =?utf-8?B?akVNMHEvbjh2WEVPd3ZkckhjN3orVExBVTRUVFNWdXFpU1psTGVIMjZEOVZV?=
 =?utf-8?B?d3RYWTVzcGZYa2FsdGNvT2tMa2RiNHdGWkpDR0ozbUJLNXNEdW1zWlRmc0dr?=
 =?utf-8?B?Qk1zRlAvTVRYT3A2TS8vSFhDVzczL25XR1J5emFTOFllNGVrRlluTnRtTEZs?=
 =?utf-8?B?RDc2bFAxQkpvWEV1YzMxMmMybGhTMDRkME95WmxpZElTOWlrUGNSSC9sMnVl?=
 =?utf-8?B?NXBRYWJXelB4Nm1wUFRhalBCa0hkdTFRY0hPOVJTVERDNituR2pPNGg2ZDJT?=
 =?utf-8?B?aUlNblRPVFEwUGdOWkIwSDNHNkVhTVB0WDRRam5JMEFYQUk0Q1lJQjNTdk4w?=
 =?utf-8?B?TFQvZ3RsTGltL2htK2Iwc2NyR092Q0hDYmxDSkt5V3BQSFJXazR1OHFydDJj?=
 =?utf-8?B?eWdPS2lwZ2JzaHc2NVNqUytQZ1BCS0xwS1BlZW9aSVVkVDVIaFppMThPdEcy?=
 =?utf-8?B?RWh3cStrc3o4UTZaR1BQV2MrNEQ2TTJicEc4SURYUjFVMk9OWHVQbUpReGRZ?=
 =?utf-8?B?NmxIVUUxU1NEMlcxVTZMenRvKzRPWWloYUVtdTUvK0JISXlkeWJOQm5FNUVZ?=
 =?utf-8?B?N2ZUOUV2L3RHV3Q4Q096dW8yTW0veHlrTUh3MkhtcDMwTy9FMnJxQ0o1T0dP?=
 =?utf-8?B?L3lUK0x1U3hLVXI0Z0l0WEFsOHlxZU9ueWZySlI5cHFRR0xBYnVxVU5RZ1Ft?=
 =?utf-8?B?aUJMNExheHdWRCtQWXZkYjN5NUdDUzd1U3lNTG43cHljcHRwSVQ5RnZObzgy?=
 =?utf-8?B?WG1MTkxaSk9hUktWc1VZWFZaQmphTUdjdXlRUlUxTTRKVHlMek5aS2pOaUFH?=
 =?utf-8?B?Q21tVUlKR1E0UWkyWGNLaWpLMWxoTnZrT1ZLSmpqK0o0cmQ3aU5FZGtkZFRt?=
 =?utf-8?B?OWkwcVNTdUZ6Q2hZa0JFMTFRV09hY3Iwd3VLU3BQdlZqeVdEMmV0QUFFcFAy?=
 =?utf-8?B?bnExVkE3MVFPTFRWZjF6b0toWnNHaFd0dmo0N1M5NWx3SjJDdE8reDBvTkJp?=
 =?utf-8?B?UWRiMCtGamduQS96NkhXK3lHS3pOdjNjL0FkSVRqTm9QUDBTc2N5enJnU0RN?=
 =?utf-8?B?RmF4OWY1ZUZnL2t4TFhpTVYxb2pkR1FJYi9WckcxNzVzaEova1ZVRmNwT3gv?=
 =?utf-8?B?N0EyS05jK3hIeWpaZFE2ajlBU3JTUmlJTVhqVEVZRHNQSzlJTkhTQXdTRk9k?=
 =?utf-8?B?NHpiYkdmSEc3VDkyajlMRithVzMzSEs5N0s5bkJBcUkwSXpMZ1RRQlBtSzc2?=
 =?utf-8?B?WXM1RjhhZWtDUDJCRnlMdTZ2Y0VTQ25DNVFubDc0QWRoT1pwR29GS1I2WTB2?=
 =?utf-8?B?Szd0NFVhOEZXUXJENTFOOXFUK0dCblh0Y09OcnNVZ2gyMGRpWSt1N0s1d1Rv?=
 =?utf-8?B?Z1daOGFmTjl6L3lUSVEyR0RWcmdOam1Qb1BWMFZ5c1JURmF0MmdpZENLWGRO?=
 =?utf-8?B?ZlZocTczRmtWdWlwa0hrTzViNmpxZTZMWisxSDJkbG8ydElNaldPbnI0V2FQ?=
 =?utf-8?B?SmRvYW10REhwQmRVZlpLVHk5aVRSVTRoUEFMSzdtekNoRkl3R2FJZDNvQUVJ?=
 =?utf-8?B?WDBqZDEyanZYdm9EaStzN0VNNjBZRUJjSGNqU2JIWGNKeTR2bHRxc0xFa1lo?=
 =?utf-8?B?d3R3QmYrY0k3bW1QbkZaWGpQejh4Q3AxLy9FMEh6bEdaYVhXY1ZERWJ3QWVF?=
 =?utf-8?Q?ZL9qcY6eMn4EG4zaDZN983Yi1ZtfBM2Q?=
X-OriginatorOrg: sct-15-20-9412-4-msonline-outlook-ecede.templateTenant
X-MS-Exchange-CrossTenant-Network-Message-Id: 79064277-2b95-46d4-1a18-08deaee37c69
X-MS-Exchange-CrossTenant-AuthSource: SVAP279MB0383.NORP279.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 May 2026 22:28:40.5667
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg:
	00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SV0P279MB0983
From: bobwei9@hotmail.com (Bob Weinand)

--------------rgzA0XabGqxnXY0a9tendP2z
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Hey Seifeddine,

On 10.5.2026 21:02:32, Seifeddine Gmati 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.

I have a bunch of questions and feedback:

The requirement of ordering seems unnecessary to me - why would we not 
want to be able to write <T: Box<U>, U: Box<T>>. Alternatingly recursive 
types are not unheard of. Seems like an arbitrary restriction; and for 
compilation purposes it only requires collecting all parameter names 
before evaluating them.

Your tests also show restrictions around intersection types, e.g. "Type 
parameter T with bound mixed cannot be part of an intersection type" for 
'class Foo {} function x<T>(): T & Foo {}'. What's the motivation behind 
it? This looks fairly natural to me: x() promises to return an instance 
of Foo which also fulfills the bound T. Any child class of Foo which 
happens to implement T will fulfill that contract.

I would like to plead to skip the arity validation, except for "more 
parameters than allowed":
- This inhibits graceful addition of generics - any library adding them 
requires callers to immediately update all caller sites.
   - It would also make addition of generics to Iterator classes etc. 
completely uncontroversial.
- This would be more in line with PHP's general "no type is effectively 
the highest possible bound" approach. I.e. "class A extends Box" and 
"class A extends Box<mixed>" would be equivalent.
- This would also allow for future incremental runtime generics: you'd 
start with <never> and as you call stuff with values, the type becomes 
broader.


This is the one thing which makes the whole RFC a non-starter for me if 
required:

Typing is optional in PHP!


Your tests show that this specific example is allowed, which strikes me 
as odd. Why would we not check the arity here?

class Container {}
function f(Container<int> $x): Container<string> { return $x; }


Diamond checks:

Are these necessarily problematic? if you inherit Box<int> and 
Box<string>, it simply means that the generic parameter, when placed in 
a contravariant location will accept int|string, when placed into return 
or property types it'll evaluate to never.

If you disagree (that's possibly fine), a diamond covariant parameter 
should be allowed in any case though, i.e. if Box<+T>, then an interface 
shall be able to implement Box<string>, Box<int>. At least at a glance I 
don't find such a test - if it already works, nice, then please just add 
the test!


Is class ABox implements Box<self> allowed, or do we need to write 
implements Box<ABox>?


I'm also not sold on the turbofish syntax. I hate it in Rust, which I 
have to write nearly daily. I forget these :: SO often. And then the 
Linter yells at me and I correct it.
I understand that there are language limitations, in particular with the 
array syntax, but honestly, I'd rather just have the parser shift in 
favor of the existing syntax - for these rare conflicting cases forcing 
parenthesis around the generic would be nicer, i.e. `[A<B, B>(C)]` would 
continue carrying the meaning it has today, and we'd require writing 
`[(A<B, B>(C))]` for that case.


I'm not quite sure if + and - are the proper choices. I'm more used to 
C# myself with in and out being more obvious to me. I also admit that I 
initially assumed "+" to be covariant - the sum of stuff accepted, and 
"-" contravariant, subtracting what can be returned. But this particular 
bikesheds color is not too important to me.


Otherwise, it's a pretty solid RFC which should be extensible with 
runtime generics eventually. (In particular runtime generics on the 
class inheritance level should be a no-brainer to add with the existing 
syntax.)


Thanks,
Bob

--------------rgzA0XabGqxnXY0a9tendP2z
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    <p>Hey Seifeddine,</p>
    <div class="moz-cite-prefix">On 10.5.2026 21:02:32, Seifeddine Gmati
      wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:CAFyg4HhZsH_gMjvJteYvA2h7sMm48-Hz=UxQ_+Ezu4pneRfr8A@mail.gmail.com">
      <pre wrap="" class="moz-quote-pre">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: <a class="moz-txt-link-freetext" href="https://wiki.php.net/rfc/bound_erased_generic_types">https://wiki.php.net/rfc/bound_erased_generic_types</a>
- Implementation: <a class="moz-txt-link-freetext" href="https://github.com/php/php-src/pull/21969">https://github.com/php/php-src/pull/21969</a>

Thanks,
Seifeddine.</pre>
    </blockquote>
    <p><span style="white-space: pre-wrap">I have a bunch of questions and feedback:</span></p>
    <p><span style="white-space: pre-wrap">
</span></p>
    <p><span style="white-space: pre-wrap">The requirement of ordering seems unnecessary to me - why would we not want to be able to write &lt;T: Box&lt;U&gt;, U: Box&lt;T&gt;&gt;. Alternatingly recursive types are not unheard of. Seems like an arbitrary restriction; and for compilation purposes it only requires collecting all parameter names before evaluating them.</span></p>
    <p><span style="white-space: pre-wrap">
</span></p>
    <p><span style="white-space: pre-wrap">Your tests also show restrictions around intersection types, e.g. &quot;Type parameter T with bound mixed cannot be part of an intersection type&quot; for 'class Foo {} function x&lt;T&gt;(): T &amp; Foo {}'. What's the motivation behind it? This looks fairly natural to me: x() promises to return an instance of Foo which also fulfills the bound T. Any child class of Foo which happens to implement T will fulfill that contract.</span></p>
    <p><span style="white-space: pre-wrap">
</span></p>
    <p>I would like to plead to skip the arity validation, except for
      &quot;more parameters than allowed&quot;:<br>
      - This inhibits graceful addition of generics - any library adding
      them requires callers to immediately update all caller sites.<br>
      &nbsp; - It would also make addition of generics to Iterator classes
      etc. completely uncontroversial.<br>
      - This would be more in line with PHP's general &quot;no type is
      effectively the highest possible bound&quot; approach. I.e. &quot;class A
      extends Box&quot; and &quot;class A extends Box&lt;mixed&gt;&quot; would be
      equivalent.<br>
      - This would also allow for future incremental runtime generics:
      you'd start with &lt;never&gt; and as you call stuff with values,
      the type becomes broader.</p>
    <p><br>
    </p>
    <p>This is the one thing which makes the whole RFC a non-starter for
      me if required:</p>
    <p>Typing is optional in PHP!</p>
    <p><br>
    </p>
    <p>Your tests show that this specific example is allowed, which
      strikes me as odd. Why would we not check the arity here?</p>
    <p>class Container {}<br>
      function f(Container&lt;int&gt; $x): Container&lt;string&gt; {
      return $x; }</p>
    <p><br>
    </p>
    <p>Diamond checks:</p>
    <p>Are these necessarily problematic? if you inherit Box&lt;int&gt;
      and Box&lt;string&gt;, it simply means that the generic parameter,
      when placed in a contravariant location will accept int|string,
      when placed into return or property types it'll evaluate to never.</p>
    <p>If you disagree (that's possibly fine), a diamond covariant
      parameter should be allowed in any case though, i.e. if
      Box&lt;+T&gt;, then an interface shall be able to implement
      Box&lt;string&gt;, Box&lt;int&gt;. At least at a glance I don't
      find such a test - if it already works, nice, then please just add
      the test!</p>
    <p><br>
    </p>
    <p>Is class ABox implements Box&lt;self&gt; allowed, or do we need
      to write implements Box&lt;ABox&gt;?</p>
    <p><br>
    </p>
    <p>I'm also not sold on the turbofish syntax. I hate it in Rust,
      which I have to write nearly daily. I forget these :: SO often.
      And then the Linter yells at me and I correct it.<br>
      I understand that there are language limitations, in particular
      with the array syntax, but honestly, I'd rather just have the
      parser shift in favor of the existing syntax - for these rare
      conflicting cases forcing parenthesis around the generic would be
      nicer, i.e. `[A&lt;B, B&gt;(C)]` would continue carrying the
      meaning it has today, and we'd require writing `[(A&lt;B,
      B&gt;(C))]` for that case.</p>
    <p><br>
    </p>
    <p>I'm not quite sure if + and - are the proper choices. I'm more
      used to C# myself with in and out being more obvious to me. I also
      admit that I initially assumed &quot;+&quot; to be covariant - the sum of
      stuff accepted, and &quot;-&quot; contravariant, subtracting what can be
      returned. But this particular bikesheds color is not too important
      to me.</p>
    <p><br>
    </p>
    <p>Otherwise, it's a pretty solid RFC which should be extensible
      with runtime generics eventually. (In particular runtime generics
      on the class inheritance level should be a no-brainer to add with
      the existing syntax.)</p>
    <p><br>
    </p>
    <p>Thanks,<br>
      Bob</p>
  </body>
</html>

--------------rgzA0XabGqxnXY0a9tendP2z--