Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:113834 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 47723 invoked from network); 28 Mar 2021 16:44:53 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 28 Mar 2021 16:44:53 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 9859D1804B7 for ; Sun, 28 Mar 2021 09:41:41 -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=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL, SPF_HELO_PASS,SPF_NONE autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (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 ; Sun, 28 Mar 2021 09:41:40 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id AD4F51654 for ; Sun, 28 Mar 2021 12:41:39 -0400 (EDT) Received: from imap8 ([10.202.2.58]) by compute4.internal (MEProxy); Sun, 28 Mar 2021 12:41:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=GuhAoryW8u3g6Huyisg6lsF8Q4hWuGPdw91AOzZdz Hk=; b=n/FYWCEzR5yHicwUJGxUPpabTKnD3SpY92SVU/4/VU1F3a2w/y692YK4k QPU5GJv8rSOvrYvzz3mxc8BLVYYs9Tt5TWZ++xT0HBYIh2rxHjul1syRHV/KitGB uj6qKrwlWGA9zgNMrWG8NguBTAoJnxP+BjIWAJF9A1HaQYiE1AeWPXn00PWAvchX Rg8eJUrHOuBSVtMVafiIeR3u8f+GdzKHH/sWDykDkCmoT7pxkplDoUIcBqfniPBJ 27l2PVx/jNsVq7zo7alSHiOTb+pGbwF/oEyHxqizVzVoKw6t2hqyi1gFIPDx482E fJsbtp5uvVyCtxY8QJAMhj+xeSXnw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrudehiedguddthecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefofgggkfgjfhffhffvufgtgfesthhqredtreerjeenucfhrhhomhepfdfn rghrrhihucfirghrfhhivghlugdfuceolhgrrhhrhiesghgrrhhfihgvlhguthgvtghhrd gtohhmqeenucggtffrrghtthgvrhhnpeeggeehgfetjeehgefggefhleeugefgtdejieev vdethfevgeeuudefleehvdetieenucffohhmrghinhepphhhphdrnhgvthenucevlhhush htvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehlrghrrhihsehgrghr fhhivghlughtvggthhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 1883D3A0958; Sun, 28 Mar 2021 12:41:39 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-273-g8500d2492d-fm-20210323.002-g8500d249 Mime-Version: 1.0 Message-ID: <69ed552b-a083-4dd9-835b-987cee990409@www.fastmail.com> In-Reply-To: References: <88c9eb5f-f80c-4869-b7f8-1b58b9e2eaa3@www.fastmail.com> <605bae82.1c69fb81.f49f7.d11eSMTPIN_ADDED_MISSING@mx.google.com> <919e30e7-3e5e-d955-7bb4-1e1b5825cdd1@gmail.com> <635DD146-FC6F-4991-8D2C-5A6B492722D5@newclarity.net> <734f12de-da98-6b76-c2fe-8682f4d177aa@gmail.com> <36E45DD6-E2BD-4801-BAAE-4355C83D1AC3@newclarity.net> <15AE4315-A456-4ED8-990A-49EBD76C5B46@newclarity.net> <5501FE70-FBED-47EB-8010-173644BC064F@newclarity.net> <3d453ce7-db16-fb75-91b4-9a2a71994164@gmail.com> Date: Sun, 28 Mar 2021 11:41:17 -0500 To: "php internals" Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: =?UTF-8?Q?Re:_[PHP-DEV]_[RFC]_Auto-capture_multi-line_closures_and_short?= =?UTF-8?Q?functions_take_2?= From: larry@garfieldtech.com ("Larry Garfield") On Sun, Mar 28, 2021, at 7:34 AM, Deleu wrote: > > > > but then we can bring up the side running RFC from > > Larry which proposes to make the same short syntax available for oth= er > > function declarations, how would this work then with this mindset of= > > `fn` meaning auto capture? Does that mean a procedural function > > declared with `fn` will now inherit the scope from which it was > > declared (usually the global scope)? What about methods declarations= , > > do they import properties into the local scope? How does traits > > interact here, same as methods? > > >=20 > I think I remember the 1st version of Larry's RFC proposing `public fn= > classMethod(): bool =3D> $this->myAttr;` as a class method which seems= to > match what you're trying to say here, but that has been withdrawn and = the > RFC no longer proposes the fn keyword for class methods or function > declarations, which is discussed under *Background* of RFC > https://wiki.php.net/rfc/auto-capture-closure. Larry and Nuno may corr= ect > me if I'm wrong but as far as I understood, that change happened to ad= dress > exactly the points you're describing here: what does `public fn > classMethod(): bool` would capture? There's actually little to no reas= on to > do it. Larry's RFC still proposes a great improvement for > getters/setters/short methods and Nuno's RFC allows us to write code t= hat > is naturally expected to work, such as `fn () =3D> {...}`. >=20 > As for making `fn` an alias of `function` I believe that is already br= oken > because of 7.4 arrow functions. As you describe, that would be "an > exception" to PHP syntax, but more pressing it means that we would be > wasting the potential of 2 separate keywords having different goals. I= > think it was Nikita that once said that we have a very limited budget = on > what we can do/offer through programming syntax and throwing `fn` out = would > be such a waste of that limited budget. >=20 > --=20 > Marco Aur=C3=A9lio Deleu The short-functions RFC as initially proposed had two variants, one whic= h just used =3D>, and one with used both =3D> and fn. Personally I don'= t have that strong of a feeling about function vs fn in that case. Howe= ver, when discussing with Nuno using "fn" to indicate auto-capture made = the most sense, as =3D> already very clearly means "evaluates to express= ion." I'm personally not wedded to any specific syntax, as long as the net res= ult is consistent and self-evident to both writers and readers, and allo= ws for both auto-capturing lambdas and expression-style functions. I'm not wild about function and fn being universally synonymous. As Mik= e notes, it would create another coding style battlefront of when you sh= ould use one or the other since both are synonymous. What we'd likely e= nd up with is drifting toward the whole language using fn because it's e= asier to type, but not everyone, so you'd have a lot of inconsistency be= tween projects. If function and fn mean different things, there is no r= oom for subjective preference. You use the keyword that means the behav= ior you want. As a thought experiment, let's play with the "auto" keyword for a moment= . (As I'm typing this I don't know what it will produce.) $c =3D 1; // Existing syntax. $f =3D function($a, $b) use ($c) { return $a * $b * $c * $this->d; }; // If you want to DISABLE object binding. $d =3D $this->d; $f =3D static function($a, $b) use ($c, $d) { return $a * $b * $c * $d; }; // If you want to ENABLE auto-capture. $f =3D auto function($a, $b) { return $a * $b * $c * $this->d; }; // If you want to DISABLE object binding but ENABLE auto-capture. $d =3D $this->d; $f =3D static auto function($a, $b) { return $a * $b * $c * $d; }; So we end up with one enable toggle and one disable toggle. That's gene= rally considered a bad idea. It also means that what I believe is *usua= lly* the most common desired configuration (don't capture $this, but cap= ture anything else) the one that involves the most typing. That doesn't seem ideal. --Larry Garfield