Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:111897
X-MailCleaner-return_path: brendt@stitcher.io
X-MailCleaner-sender_address: brendt@stitcher.io
X-MailCleaner-recipients: matthewmatthew@gmail.com, internals@lists.php.net
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
In-Reply-To: <AB0BDC26-89C5-4372-8FEA-D56603A0BFE6@gmail.com>
Date: Fri, 18 Sep 2020 06:28:37 +0200
Cc: PHP internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <92973D90-AAEF-4975-847B-5E62FEEBD1E2@stitcher.io>
References: <09DE673B-71B7-4C8E-A795-900B51F8E476@stitcher.io>
 <AB0BDC26-89C5-4372-8FEA-D56603A0BFE6@gmail.com>
To: Matthew Brown <matthewmatthew@gmail.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
X-MailCleaner-TrustedIPs: Ok
Subject: Re: [PHP-DEV] The case for transpiled generics
From: brendt@stitcher.io (Brent Roose)

Hi all

To make myself clear, since I realise I used a confusing term in the =
subject of my mail. What I'm proposing is runtime-erased generics, the =
way Matthew describes them: PHP completely ignores them during runtime, =
and wouldn't do anything with them during compile time. It's up to third =
party tooling to do type checks. And I just want to point out to people =
who haven't used any static analysers in PHP before: they are very_ =
insightful in knowning what your code does, without running it. I don't =
think there's reason to fear to not checking these types at runtime, =
since static analysis truly takes care of them.

Thanks Matthew for pitching in, I believe the opinion of the ones =
building and maintaining the current static analysis toolset in PHP is =
essential in this discussion.

Kind regards
Brent

> On 17 Sep 2020, at 23:00, Matthew Brown <matthewmatthew@gmail.com> =
wrote:
>=20
> I think the addition of runtime-erased generics would be a good thing =
for the language.
>=20
> I don=E2=80=99t think PHP should perform any sort of checking of =
generic parameters at compile time. No other equivalent interpreter =
performs those compile-time checks, and it=E2=80=99s also *very* complex =
=E2=80=94 since adding support for generics in Psalm I=E2=80=99ve spent =
the ensuing two years fixing many bugs and filling various holes that =
have cropped up. Hack, introduced in 2014 and written by bunch of people =
far smarter than me, had at least one hole in its type-checker=E2=80=99s =
generics handling that was only patched last year.
>=20
> PHP could develop a separate official type-checker to be used =
alongside its interpreter, similar to Hack=E2=80=99s (hh_check) or =
TypeScript=E2=80=99s (typescript-checker), but that=E2=80=99s an =
entirely separate conversation.
>=20
> =E2=80=94=E2=80=94=E2=80=94
>=20
> If this proposal happens, the documentation should make it *super* =
clear that all generic types are erased at runtime.
>=20
> Erased generics would not support code like this:
>=20
> ```
> function filter<T of object>(array<int, object> $arr) : array<int, T> =
{
>    $new =3D [];
>    foreach ($arr as $a) {
>        if ($a instanceof T) {
>            $new[] =3D $a;
>        }
>    }
> }
> ```
>=20
> Instead PHP would need to support a type classname<T> (or similar) to =
allow passing generic params explicitly.
>=20
> ```
> function filter<T of object>(array<int, object> $arr, classname<T> =
$t_class) : array<int, T> {
>    $new =3D [];
>    foreach ($arr as $a) {
>        if ($a instanceof $t_class) {
>            $new[] =3D $a;
>        }
>    }
> }
> ```
>=20
> The implementation would also need a way of denoting covariant (pretty =
common) and contravariant (very rare) generic parameters, like Hack =
does.
>=20
>=20
>> On Sep 17, 2020, at 7:34 AM, Brent Roose <brendt@stitcher.io> wrote:
>>=20
>> =EF=BB=BFHello internals
>>=20
>> Today I'd like to hear your thoughts on what might be a controversial =
topic, though I think it's worth having this discussion. I want to make =
the case for adding generic syntax, without actually enforing any =
additional type checks at runtime. Please hear me out.
>>=20
>> We've been discussing generics for years now [1][2], all without any =
result. Nikita's latest attempt [3] stalled because, from what I =
gathered and amongst other things, doing generic type checks at runtime =
has a significant impact on performance.
>>=20
>> On the other hand, static analysers have been making their rise for a =
few years now. Granted: not the whole community might like this kind of =
type strictness, and PHP doesn't force them to; but still projects like =
PhpStorm acknowledge their significance =E2=80=94 they will add built-in =
support for both psalm and PHPStan later this year [4]. Rasmus Lerdorf =
also showed interest in the idea of improving PHP's static analysis =
capabilities two years ago [5].
>>=20
>> That all to say that there's a significant part of the PHP community =
who's interested in embracing the benefits of static analysis.=20
>>=20
>> If we look outside of our PHP bubble, we can see the same thing =
happening in JavaScript: the core benefit that TypeScript adds is its =
robust static analysis. Sure those developers need an extra compilation =
step to transpile their code to plain old JavaScript, but it seems that =
they are=E2=80=A6 fine with that?
>>=20
>> I'd like to discuss a similar idea for PHP. If runtime generics =
aren't possible because of performance issues, why not explore the other =
option: adding generic syntax that is ignored by the interpreter, but =
can be used by static analysis tools =E2=80=94 third party of built-into =
PHP, that's another discussion. I realise this thought goes against the =
"PHP mindset" we've been programming with for more than 20 years, but we =
I think we shouldn't ignore what's happening in the PHP- and wider =
progamming community: static analysis is relevant, whether you want to =
use it or not, and a stricter type system is prefered by many.
>>=20
>> Now I know there are alternatives we can use today. Static analysers =
already support generics, using doc blocks. I'm not trying to argue that =
it's impossible to achieve the same results with the toolset we have, =
but rather that there's room for improvement from the developer's point =
of view. History has shown that such convenience additions to PHP have =
been a difficult pill to swallow for some, but on the other hand those =
kind of changes _have_ been happening more and more often anyway: =
property promotion, short closures, named arguments, attributes, yes =
even types themselves: you can write the same working PHP program =
without any of those features, and yet they have been proven so useful =
and wanted over the last years.
>>=20
>> As a sidenote: the idea of transpiling is already present in PHP. =
Looking at constructor property promotion: a purely syntactical feature, =
which is transformed to simpler PHP code at runtime. Nikita called this =
principle "desugaring" in the constructor property promotion RFC [6].
>>=20
>> So here's my case for transpiled generics summarized:
>>=20
>> - There's no significant runtime performance impact
>> - The PHP community is already embracing static analysis
>> - Transpiling has been proved to be a viable workflow, thanks to =
TypeScript
>> - As with all things-PHP: it's opt-in. You don't have to use the =
syntax if you don't want to and you won't experience any downsides
>>=20
>> So with all that being said, I'm looking forward to hearing your =
thoughts.=20
>>=20
>> Kind regards
>> Brent
>>=20
>> [1] https://wiki.php.net/rfc/generics =
<https://wiki.php.net/rfc/generics>=20
>> [2] https://wiki.php.net/rfc/generic-arrays =
<https://wiki.php.net/rfc/generic-arrays>=20
>> [3] https://github.com/PHPGenerics/php-generics-rfc/issues/45 =
<https://github.com/PHPGenerics/php-generics-rfc/issues/45>=20
>> [4] =
https://blog.jetbrains.com/phpstorm/2020/07/phpstan-and-psalm-support-comi=
ng-to-phpstorm/ =
<https://blog.jetbrains.com/phpstorm/2020/07/phpstan-and-psalm-support-com=
ing-to-phpstorm/>=20
>> [5] https://externals.io/message/101477#101592 =
<https://externals.io/message/101477#101592>=20
>> [6] https://wiki.php.net/rfc/constructor_promotion#desugaring =
<https://wiki.php.net/rfc/constructor_promotion#desugaring>