Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:92307 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 59165 invoked from network); 14 Apr 2016 17:33:51 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 14 Apr 2016 17:33:51 -0000 Authentication-Results: pb1.pair.com smtp.mail=php@fleshgrinder.com; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=php@fleshgrinder.com; sender-id=unknown Received-SPF: error (pb1.pair.com: domain fleshgrinder.com from 212.232.28.125 cause and error) X-PHP-List-Original-Sender: php@fleshgrinder.com X-Host-Fingerprint: 212.232.28.125 mx204.easyname.com Received: from [212.232.28.125] ([212.232.28.125:55151] helo=mx204.easyname.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id B4/B0-53665-C74DF075 for ; Thu, 14 Apr 2016 13:33:49 -0400 Received: from cable-81-173-133-226.netcologne.de ([81.173.133.226] helo=[192.168.178.20]) by mx.easyname.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1aql9D-0003vc-7B; Thu, 14 Apr 2016 17:33:43 +0000 Reply-To: internals@lists.php.net References: To: Levi Morrison , Tom Worster Cc: php-internals Message-ID: <570FD463.9060205@fleshgrinder.com> Date: Thu, 14 Apr 2016 19:33:23 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="CsIAKPmTmEcdIKV1HrBk65ofSeJE4ciG7" X-ACL-Warn: X-DNSBL-BARRACUDACENTRAL Subject: Re: [PHP-DEV] [RFC] Nullable Return Type Declaration From: php@fleshgrinder.com (Fleshgrinder) --CsIAKPmTmEcdIKV1HrBk65ofSeJE4ciG7 Content-Type: multipart/mixed; boundary="8mKrNFThlu9AGfk5ISlVCADBFVnrupgXJ" From: Fleshgrinder Reply-To: internals@lists.php.net To: Levi Morrison , Tom Worster Cc: php-internals Message-ID: <570FD463.9060205@fleshgrinder.com> Subject: Re: [PHP-DEV] [RFC] Nullable Return Type Declaration References: In-Reply-To: --8mKrNFThlu9AGfk5ISlVCADBFVnrupgXJ Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 4/14/2016 6:35 PM, Levi Morrison wrote: > On Thu, Apr 14, 2016 at 9:39 AM, Tom Worster wrote: >> I would like to introduce for discussion an RFC proposing and arguing = for >> Nullable Return Type Declaration in 7.1 and deferring for now more gen= eral >> relaxations of 7.0 type as proposed in Levi's two RFCs. >> >> https://wiki.php.net/rfc/nullable_returns >> >> If anyone would like to collaborate on the RFC, I have a repo you may = fork: >> https://gist.github.com/tom--/e95a10fbe4d34f8a72c9 (although guthub's >> formatting isn't lovely). I'm looking for help with implementation. >> >> Tom >> >> >> >=20 > I can appreciate that you want only the restricted union with null. > However, I do not see the point of disallowing it for parameter types > while allowing it for return types: >=20 > function setLeft(Node $n =3D null) { > $this->left =3D $n; > $this->updateHeight(); > } >=20 > Why disallow the explicit union with null here instead of the default > parameter which does not exactly capture the desired semantics? > Calling `$node->setLeft()` is just odd, almost as if it was a mistake. > I would much prefer `$node->setLeft(null)` here. Basically, if we have > a feature for return types that exactly matches the semantics that we > occasionally want for the parameter types why forbid it? >=20 > Additionally, on occasion I'll see functions like this: >=20 > function foo(Bar $b =3D null, $not_optional_param); >=20 > Why not allow nullable types on parameters to avoid that wonkiness > caused by default values of null? >=20 > function foo(Bar | Null $b, $not_optional_param); >=20 > This is much better. >=20 My guess is that this RFC only wants to get it for return because it might be an easier vote? I do not like the fact that only the long version of union types is supported and prefer the question mark approach as a short hand. Can this RFC be either extended to include that as well or removed so it does not get in the way of the other two RFCs? --=20 Richard "Fleshgrinder" Fussenegger --8mKrNFThlu9AGfk5ISlVCADBFVnrupgXJ-- --CsIAKPmTmEcdIKV1HrBk65ofSeJE4ciG7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXD9RsAAoJEOKkKcqFPVVrsmoP/1b575VTLAq8L0W48nXo28iN 9T7nbyGpbzaNP2N80mWwXDqIAr5yaLcDEM4moX9CHnEAg5/VFCYMBylKnO+QblOC ihuvaA8A0DCRLoa0nYE6b8YZM2AmLXnCEps7ssCNmocF0jJvinu54hWc9Rx0Ced/ eRj4aWY2IiEQtjYK9yjegHemLwgUyR91/dpPUPP+Twc4+KriESEoPehuc9OqgL03 J9kjtoFJOQXXr1D1tH/DnA+/g15KtZ8fwoHsfGi67sY9ULgex4YDHVoFuAUM2iUW yHYEIaQQKoL/FHam+6h2e7qpzZoRsW5YQ/ULGWW7vAcUIeYEGwled02hD6cqR2qn J6sG2Spcd1qWyoueJmQLcza8J3yrHoeQoNrsmsO1vNKRxD18JbMAfuTLUq4x3+uT iDBkAc89TmELvxnBhVdZDqNKULdDrWjA73ChMuH190rRxxsSsE4Bc/cZ2xJqg7zf YNVkvlcrruj01pXSokxi6VJT0fYYihF8lJBp3wtNfsrKTBM63tAqej2vBSOUziAS OTWGshStYp/6cpP5/9v36cKGhJ7YUPoqy8n4BDpPtJGTIas298yrSfmb9YxHPeBU 3WwnuCdQ1L0kPQvffMIBmEvlYQ7JfZb61h95qi76SHOD5c8d7l59SOVuKpZp1urP OoLYbuBHOYQekB8TkgH2 =vhfP -----END PGP SIGNATURE----- --CsIAKPmTmEcdIKV1HrBk65ofSeJE4ciG7--