Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:112022 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 10745 invoked from network); 7 Oct 2020 20:13:14 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 7 Oct 2020 20:13:14 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 88AD01804B5 for ; Wed, 7 Oct 2020 12:26:56 -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.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, 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-wm1-f68.google.com (mail-wm1-f68.google.com [209.85.128.68]) (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 ; Wed, 7 Oct 2020 12:26:56 -0700 (PDT) Received: by mail-wm1-f68.google.com with SMTP id f21so3649532wml.3 for ; Wed, 07 Oct 2020 12:26:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=xZXJW82Q8vr221sJGEHAKAAswLPtfmHbcBf9bIA35ko=; b=um3idbrotVeW0+S97kj1GDmdm7sdr+nIQb1aVNHlYBlljqnat7rE5LUs4VfmL7Wrft xg2l+9L3BOvP2Hgs9x/Tdj33XbxfeazK16ItX46vjlUH3pcV3pZKuHxdZxsNPHu/QYIZ aLSbnasWRF9pruuh8u6DkS5XpuYqUrJx6tZs1n9IanKsCbBoTBIrg48dZ1RSMSyb9zAy WmurCummoHfkYgUK0+0MSNt2LFcSYDN3qyZ0c1EiC148Sxl5IHQ0ryQiBm9lSitVhs/o KQl9bkLLBL0jlApeQlIVbnWxb3Z4xmx9dFtEhX7f0vRe3fU/yxW+2yAXslFJK9dffPAN t9pQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=xZXJW82Q8vr221sJGEHAKAAswLPtfmHbcBf9bIA35ko=; b=pnXsq01KoNcZchB+paiWqIiBAWQxiiaOt3F5CHsucOMb6wowHwWQxAPsS6ooNrM28S j9ajVkCEP00rtB5Le599L9vY74pgDPdwCncuS5apDygrQJc4qlCzAhPom5/bwtKoG0CT nnj4syCaH263E/N+1kcdBEpv/nLg0CTU2MSvERePdGWtrhTC33IUQv1mSTdE4fK2tQP1 XFOp/SZX0hxtpZsqttO5hIUHUvphr93ZZKfgoacj/VJm6Vdw3zoyiP7wNrAZFJXv4hae sH4i0FdAo5eWA1cvZ8EhOFiMghT/U3T0gAtW5hi4cZamVi20BTQ/87SjMkd1R4YHMjxB MA6A== X-Gm-Message-State: AOAM532gBupuFatJWu39uHuigN3f7WJnWPKCxETGUdhSws3PtL27L45k plF1d2UW2EtNOuhazDvkATt8cXKVp0g= X-Google-Smtp-Source: ABdhPJzHJZNtOaMz0O14i3tmDEOTPC5he1rpULgM6B9+EIDmj7YlNlVaS78R8HuQxi1EfzcYYuXrNg== X-Received: by 2002:a1c:770e:: with SMTP id t14mr1814412wmi.34.1602098813754; Wed, 07 Oct 2020 12:26:53 -0700 (PDT) Received: from [192.168.0.22] (cpc104104-brig22-2-0-cust548.3-3.cable.virginm.net. [82.10.58.37]) by smtp.googlemail.com with ESMTPSA id s6sm4198952wrg.92.2020.10.07.12.26.52 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 07 Oct 2020 12:26:52 -0700 (PDT) To: internals@lists.php.net References: <446c9894-191f-e53b-4534-31c4e7b91d7b@gmail.com> <881e2335-5f81-0d79-6a17-06bc20f14223@gmx.net> <873361ff-02c8-b9df-9b7a-c9e89e25a880@gmx.net> <7F014A40-2D47-4DA6-8A38-59518218F9CA@stitcher.io> Message-ID: <53b85d10-419b-000f-2c1a-8b8e6fb05299@gmail.com> Date: Wed, 7 Oct 2020 20:26:52 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 In-Reply-To: <7F014A40-2D47-4DA6-8A38-59518218F9CA@stitcher.io> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB Subject: Re: [PHP-DEV] RFC: Support for multi-line arrow functions From: rowan.collins@gmail.com (Rowan Tommins) Hi Brent, On 06/10/2020 09:53, Brent Roose wrote: > We can have the discussion again on whether we like short closures or not, but it turned out most of internals_and_ userland devs do — based on the vote count in the sigle line RFC and the reaction on Nuno's PR, as well as my experience from an OSS maintainer point of view. I don't know how much of the earlier discussion you saw at the time, or have looked back at, but it's worth noting that the arrow functions RFC which passed voting came after several long mailing list threads, and several complete rewrites of the proposal, at least one of which went to vote and was declined. The lack of multi-statement arrow functions wasn't an accident, it was part of how consensus was achieved. That doesn't mean we can't discuss multi-statement arrow functions now - they were listed as "Future Scope", and we are now in that Future. :) However, it does mean a new RFC doing so needs to set out its own justification, not assume that everyone who voted Yes on the previous RFC will vote Yes on this one as well. > Furthermore, the `use(*)` syntax misses the point of this proposal: it's not about being able to use all variables from the outer scope, it's about a clean syntax that's as short as possible Rather than "missing the point", I think it's a case of different people wanting different things from arrow functions. In one of the previous discussions [1] I suggested three perspectives of what people wanted them for: (a) an improved syntax for declaring closures (in the way that [$foo, $bar] is a shorter syntax for array($foo, $bar)) (b) improved *semantics* for declaring closures, where you don't have to list the variables to be captured (c) a new kind of closure designed for specific use cases, with its own syntax and semantics Those who wanted (c) are generally happy with what we have, with perhaps an interest in making more statements available as expressions, such as throw [2] and match [3]. Those who wanted (b) generally see the arrow syntax as a means to an end, and are open to alternative syntaxes that achieve the relevant semantics, such as use(*). Those who wanted (a) may see things the other way around: the short syntax is the goal, and auto-capture and implicit return are just the ways to achieve that goal. There's probably no way to please all three groups (and the various combinations and nuances I've over-simplified), but it's useful to acknowledge the existence of those who want *some* of what you want, but don't agree on all of it. I look forward to seeing the RFC if Nuno decides to proceed with it, because I am much more interested in how it will affect *users* of PHP than the technical details visible in the PR. [1] https://externals.io/message/98045#98209 [2] https://wiki.php.net/rfc/throw_expression [3] https://wiki.php.net/rfc/match_expression_v2 Regards, -- Rowan Tommins (né Collins) [IMSoP]