Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:111895 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 44308 invoked from network); 17 Sep 2020 21:51:52 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 17 Sep 2020 21:51:52 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 96A3D1804D9 for ; Thu, 17 Sep 2020 14:00:35 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-0.6 required=5.0 tests=BAYES_00,BODY_8BITS, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, MIME_QP_LONG_LINE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from mail-qv1-f65.google.com (mail-qv1-f65.google.com [209.85.219.65]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Thu, 17 Sep 2020 14:00:35 -0700 (PDT) Received: by mail-qv1-f65.google.com with SMTP id db4so1745592qvb.4 for ; Thu, 17 Sep 2020 14:00:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=/Jm0uazjvlJgfjup7vaP5NIbj3eh2Ixo58O39y4FX/s=; b=lOn6US5SMSuHabJPlGEkOvDMXHTBdloy+0KWNTUeNEar3dpRvjJuTiwPq7fXkgqRDB fZ/iY747jYlP2W3nE0M0CuChw5dQWc1icedfC+vbs0d7nQfZ1ayOmFraAA3KgLkfiw0G ekTPr8DIQ1tqL5/ywvyDGzclysR7c/7Og1nO1R8r9nXbYP8aGqHAkSAF8eHfRtXFLQsM vn3hFLyOtZPEEU1OHx/GRcaKIJEOUSUH45ykgEiRrlfck4ujGp2JWLuYOGTtWpo/VUdO NfBKK1zNghiBUcqqD3aAPI79UpfCLDLB1RtqEb2X4s6G4vxbmfxCJdPw3bqzHIZfB+yY Zuyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=/Jm0uazjvlJgfjup7vaP5NIbj3eh2Ixo58O39y4FX/s=; b=Gq+IWkEYzB8rfbq3IKnY3qSXR8XtLqr+pURpGqVLadNxfmKLM/HcaoGsQN3yEsxDtE G+ZTx/Iv0iqf+hSQiKy3vGZSWcmt0/kvelrA7IGkNZyOLTQpxixk8tTEsN/AdefSh/aj BHAYv4GF01Epz41cKmLYqKwWD5i0iIUEMi5pa17iXHc5yc+PL9lz5xBHFNVMCfiUbsZ6 IJDOc0fMnNepUH3VXZ2F3FfM1OZrvdLSjiOsphRO8UV9wg+0LdZwAvnAtLG+ThwoaTq+ 85uR0zbdeghTq4S8mmyIR0msOEdr+ASVpmrEH4rJYaqii8ceO7O8L8+cCluNxoIDw8kg /TAA== X-Gm-Message-State: AOAM531PReyazG9pZTcPMMBPzGcbKZOooVA3zi87/yYsM8i5qwAYl0aG puVjRWWkjTj8WqhzhK/CJPYhu7R8c68nzw== X-Google-Smtp-Source: ABdhPJzhZtsga3PSSjODB71H+HYTshCp2ABz12xDePdvj245uuub+ZOj07pd7hkHiXCQPb0FOnzfvA== X-Received: by 2002:a0c:cdc4:: with SMTP id a4mr30805932qvn.31.1600376433304; Thu, 17 Sep 2020 14:00:33 -0700 (PDT) Received: from localhost.localdomain ([8.46.76.49]) by smtp.gmail.com with ESMTPSA id 2sm660582qtg.20.2020.09.17.14.00.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 17 Sep 2020 14:00:32 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Date: Thu, 17 Sep 2020 17:00:26 -0400 Message-ID: References: <09DE673B-71B7-4C8E-A795-900B51F8E476@stitcher.io> Cc: PHP internals In-Reply-To: <09DE673B-71B7-4C8E-A795-900B51F8E476@stitcher.io> To: Brent Roose X-Mailer: iPhone Mail (18A373) Subject: Re: [PHP-DEV] The case for transpiled generics From: matthewmatthew@gmail.com (Matthew Brown) I think the addition of runtime-erased generics would be a good thing for th= e language. I don=E2=80=99t think PHP should perform any sort of checking of generic par= ameters at compile time. No other equivalent interpreter performs those comp= ile-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 fixi= ng many bugs and filling various holes that have cropped up. Hack, introduce= d in 2014 and written by bunch of people far smarter than me, had at least o= ne hole in its type-checker=E2=80=99s generics handling that was only patche= d last year. PHP could develop a separate official type-checker to be used alongside its i= nterpreter, similar to Hack=E2=80=99s (hh_check) or TypeScript=E2=80=99s (ty= pescript-checker), but that=E2=80=99s an entirely separate conversation. =E2=80=94=E2=80=94=E2=80=94 If this proposal happens, the documentation should make it *super* clear tha= t all generic types are erased at runtime. Erased generics would not support code like this: ``` function filter(array $arr) : array { $new =3D []; foreach ($arr as $a) { if ($a instanceof T) { $new[] =3D $a; } } } ``` Instead PHP would need to support a type classname (or similar) to allow p= assing generic params explicitly. ``` function filter(array $arr, classname $t_class)= : array { $new =3D []; foreach ($arr as $a) { if ($a instanceof $t_class) { $new[] =3D $a; } } } ``` The implementation would also need a way of denoting covariant (pretty commo= n) and contravariant (very rare) generic parameters, like Hack does. > On Sep 17, 2020, at 7:34 AM, Brent Roose wrote: >=20 > =EF=BB=BFHello internals >=20 > Today I'd like to hear your thoughts on what might be a controversial topi= c, 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 ch= ecks at runtime. Please hear me out. >=20 > We've been discussing generics for years now [1][2], all without any resul= t. Nikita's latest attempt [3] stalled because, from what I gathered and amo= ngst other things, doing generic type checks at runtime has a significant im= pact on performance. >=20 > On the other hand, static analysers have been making their rise for a few y= ears now. Granted: not the whole community might like this kind of type stri= ctness, and PHP doesn't force them to; but still projects like PhpStorm ackn= owledge 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 i= n 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 i= n JavaScript: the core benefit that TypeScript adds is its robust static ana= lysis. Sure those developers need an extra compilation step to transpile the= ir code to plain old JavaScript, but it seems that they are=E2=80=A6 fine wi= th that? >=20 > I'd like to discuss a similar idea for PHP. If runtime generics aren't pos= sible because of performance issues, why not explore the other option: addin= g generic syntax that is ignored by the interpreter, but can be used by stat= ic analysis tools =E2=80=94 third party of built-into PHP, that's another di= scussion. I realise this thought goes against the "PHP mindset" we've been p= rogramming with for more than 20 years, but we I think we shouldn't ignore w= hat's happening in the PHP- and wider progamming community: static analysis i= s 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 alrea= dy support generics, using doc blocks. I'm not trying to argue that it's imp= ossible to achieve the same results with the toolset we have, but rather tha= t there's room for improvement from the developer's point of view. History h= as shown that such convenience additions to PHP have been a difficult pill t= o swallow for some, but on the other hand those kind of changes _have_ been h= appening more and more often anyway: property promotion, short closures, nam= ed arguments, attributes, yes even types themselves: you can write the same w= orking PHP program without any of those features, and yet they have been pro= ven so useful and wanted over the last years. >=20 > As a sidenote: the idea of transpiling is already present in PHP. Looking a= t constructor property promotion: a purely syntactical feature, which is tra= nsformed to simpler PHP code at runtime. Nikita called this principle "desug= aring" 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 TypeScrip= t > - 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 =20= > [2] https://wiki.php.net/rfc/generic-arrays =20 > [3] https://github.com/PHPGenerics/php-generics-rfc/issues/45 =20 > [4] https://blog.jetbrains.com/phpstorm/2020/07/phpstan-and-psalm-support-= coming-to-phpstorm/ =20 > [5] https://externals.io/message/101477#101592 =20 > [6] https://wiki.php.net/rfc/constructor_promotion#desugaring