Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:113828 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 23294 invoked from network); 28 Mar 2021 12:08:12 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 28 Mar 2021 12:08:12 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 336CB1804D8 for ; Sun, 28 Mar 2021 05:04:58 -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=-1.4 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from mail-pj1-f48.google.com (mail-pj1-f48.google.com [209.85.216.48]) (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 05:04:57 -0700 (PDT) Received: by mail-pj1-f48.google.com with SMTP id gb6so4713786pjb.0 for ; Sun, 28 Mar 2021 05:04:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=NfWxAxFSKf7Zlp9ekojhAToZNBpLSk4KQoIXA4oHveg=; b=FmvTMcYYnJliYEUyO+pMxlFvIfUP7iSMvhPuT2O7IniFKqslUuM1cxPGv9Olc2v5pU fuk9Te5BYdSqm1KnDpdKIFjZUFQ5RgCWVGj42ssgZ2sHws5tJotv9LZkUxZ3iwUzKqOz 3FpWWt8IxP00qwv9IhH20V0yHERjAFqfuiW9iOGMV55RTLC9KyS7xAhteZBG/4JanhIC ZnaRhjLr9JQnxxf/1ax6whMnTX+rxkXW/OoMv4s3Fft8FOpiH+NS95JfVepl2Eok/vpu s2nArhAKJO1XlFyREohYgYI+Y+nkVOBTcl3q2CjQDEOwZFWAXbuwzu2b1y6vXQMMIbgQ aNhQ== X-Gm-Message-State: AOAM531EQ116PIZnnRoXTxbE7qpXVYtL0EFq9bXtmjU9O3Rx+gmRM22j WoSHUo2WIjgUMufPlgtPNwIJQObMBKoGth0GBc0RMexxmF4= X-Google-Smtp-Source: ABdhPJzBhR2zKfX+jaQ7RKLAD3N6wd/PmuTo+8Pgd1JWIrflJyAT8c/MUEyf8k1NfZbwCY4JVsC4D/C7KvR5vmwOcGY= X-Received: by 2002:a17:90b:515:: with SMTP id r21mr21729824pjz.42.1616933091215; Sun, 28 Mar 2021 05:04:51 -0700 (PDT) MIME-Version: 1.0 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> In-Reply-To: Date: Sun, 28 Mar 2021 15:04:40 +0300 Message-ID: To: Deleu Cc: Rowan Tommins , PHP Internals Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [PHP-DEV] [RFC] Auto-capture multi-line closures and shortfunctions take 2 From: kalle@php.net (Kalle Sommer Nielsen) Den s=C3=B8n. 28. mar. 2021 kl. 14.30 skrev Deleu : > > The fact that short closure is inconsistent with the rest of PHP is a don= e deal since the voting passed prior to 7.4 release. Unless there's a follo= w-up to deprecate the 7.4 short closure auto capture without `auto` keyword= and make it look like PHP can't make up it's mind, I feel that your perspe= ctive doesn't match the proposed RFC. The RFC is extending short closure to= support multiple statements and defining good semantics on how developers = will interpret fn, =3D> and {} throughout the language. I think we have some sort of conundrum. I am not saying auto capture is not good semantics if that is what you are implying, I more than anyone would like consistency in the language but it is not a good language design to have two very similar features separated by a shorter keyword which implies totally different semantics. I don't find this a very intuitive way nor a good developer experience. I can understand that the connection of the `fn` keyword already having the meaning it has, but then we can bring up the side running RFC from Larry which proposes to make the same short syntax available for other 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? This is why I think having the `fn` being an alias of `function` neutralizes the argument of what happens for exactly those reasonings above, this allows arrow functions to continue being auto capture without any keyword. And again; adding an `auto` keyword is also not an alien thing to Closures because we already have the `static` keyword which acts as a feature flag, something which arrow functions already support which also is a case that can easily mess up the order of which objects are destructed in if you make a Closure that does not interact with `$this` from an object context without declaring it as `static`. While I did not agree with this in the initial RFC that implemented arrow functions, I do see its value and agree with it due to the narrow scope of which arrow functions have, and therefore I think it is fine to have the exception of making arrow functions behave this way and would have voted as such had it come to my desk today. And again, kindly stop top posting. --=20 regards, Kalle Sommer Nielsen kalle@php.net