[PHP-DEV] Generics
Henrik Skov <[email protected]> Tue, 4 Aug 2026 15:27:05 +0200
| Newsgroups | gmane.comp.php.devel |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format.
--------------33jlgB2Jlk0vpK33hBWt1jR7
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Hi list !
As someone who wants generics in PHP, please make the generics opt-in
(via INI setting or declare()) - PHP is slow enough as it stands now -
and adding reified generics will just make it even slower.
I was very sad to see that the only feasable kind of generics (type
erased) in PHP had its RFC declined.
By making the reified generics opt-in, extension authors may still
implement type erased generics and thus avoid the performance penalty -
altough as extension cannot change PHP parsing - their would rely on two
small changes to PHP itself (please see below)
Imagine two ways forward (to type-erased generics):
1. By wrapping generic "expressions" in comments ie.: $x = new
Collection/*<int>*/();
all IDEs would have no problems with generics - The community
might even make plugins for all popular IDEs that check such generic
expression against the codebase from inside the IDE (the place where it
actually matters) - I did one as an expieriment a while back for VSCode
myself
2. We might of course also imagine the slighty more troublesome path
forward:
Two new tokens were added to PHP:
|< (interpreted as /*)
and
>| (interpreted as */)
This option would of course need IDE plugins to be updated to understand
the new syntax
Regardless of going with 1 or 2, at compile time, all PHP would have to
do was to substitute generic function/method parameters (such as T, K or
V) with mixed
ie (in a class Collection/*<T>*/ :
.
public function add(T $item) : T {
}
T would be replaced by mixed - PHP would have to have a known list of
such generic type parameter names (T, K, V - but it might be
configurable as an INI setting)
A declare() at the top of a file could hint the compiler if this file
needs the replace / if it uses generics
This approach would then leave the actual checking of the validity of
any generic expressions/code to an extension (written in C) for instance
via a method such as:
/* {{{ proto int myextension_check_generics(string $dir)
Verify usage of generics in $dir recursively */
PHP_FUNCTION(myextension_check_generics)
{
....
RETURN_TRUE
}
This extension function would basically do what Psalm etc. do today -
just in C for much better performance
I am well aware that the internals list is set on reified generics, but
I still think that that would be another wrong turn by PHP (just like
the pipe operator and more)
I do agree that the wrapping |< and >| appears ugly but just wanted
something that required as few changes as possible.
Just my 5 cents...
/Henrik
--
Med venlig hilsen
Henrik Skov
/HSK Consulting/
Blegdamsvej 128B, 4
DK-2100 Copenhagen O
Tel.: +45 27 62 83 01
Email: [email protected]
--------------33jlgB2Jlk0vpK33hBWt1jR7
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>Hi list !<br>
<br>
As someone who wants generics in PHP, please make the generics
opt-in (via INI setting or declare()) - PHP is slow enough as it
stands now - and adding reified generics will just make it even
slower.<br>
<br>
I was very sad to see that the only feasable kind of generics
(type erased) in PHP had its RFC declined.<br>
<br>
By making the reified generics opt-in, extension authors may still
implement type erased generics and thus avoid the performance
penalty - altough as extension cannot change PHP parsing - their
would rely on two small changes to PHP itself (please see below)<br>
<br>
Imagine two ways forward (to type-erased generics):<br>
<br>
1. By wrapping generic "expressions" in comments ie.: $x = new
Collection/*<int>*/();<br>
all IDEs would have no problems with generics - The community
might even make plugins for all popular IDEs that check such
generic expression against the codebase from inside the IDE (the
place where it actually matters) - I did one as an expieriment a
while back for VSCode myself</p>
<p>2. We might of course also imagine the slighty more troublesome
path forward:<br>
Two new tokens were added to PHP:</p>
<p>|< (interpreted as /*)<br>
and<br>
>| (interpreted as */)<br>
<br>
This option would of course need IDE plugins to be updated to
understand the new syntax <br>
<br>
Regardless of going with 1 or 2, at compile time, all PHP would
have to do was to substitute generic function/method parameters
(such as T, K or V) with mixed<br>
ie (in a class Collection/*<T>*/ :<br>
.<br>
public function add(T $item) : T {<br>
<br>
}<br>
<br>
T would be replaced by mixed - PHP would have to have a known list
of such generic type parameter names (T, K, V - but it might be
configurable as an INI setting)<br>
<br>
A declare() at the top of a file could hint the compiler if this
file needs the replace / if it uses generics<br>
<br>
This approach would then leave the actual checking of the validity
of any generic expressions/code to an extension (written in C) for
instance via a method such as:</p>
<p>/* {{{ proto int myextension_check_generics(string $dir)<br>
Verify usage of generics in $dir recursively */<br>
PHP_FUNCTION(myextension_check_generics)<br>
{<br>
....<br>
RETURN_TRUE<br>
}<br>
<br>
This extension function would basically do what Psalm etc. do
today - just in C for much better performance<br>
<br>
I am well aware that the internals list is set on reified
generics, but I still think that that would be another wrong turn
by PHP (just like the pipe operator and more)<br>
<br>
I do agree that the wrapping |< and >| appears ugly but just
wanted something that required as few changes as possible.<br>
<br>
Just my 5 cents...<br>
<br>
<br>
/Henrik<br>
<br>
<br>
<br>
</p>
<div class="moz-signature">-- <br>
<br>
<br>
<br>
Med venlig hilsen<br>
<br>
Henrik Skov<br>
<i>HSK Consulting</i><br>
Blegdamsvej 128B, 4<br>
DK-2100 Copenhagen O<br>
Tel.: +45 27 62 83 01<br>
Email: <a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a><br>
</div>
</body>
</html>
--------------33jlgB2Jlk0vpK33hBWt1jR7--