Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:117912 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 9558 invoked from network); 12 Jun 2022 10:42:18 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 12 Jun 2022 10:42:18 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id B0F901801FD for ; Sun, 12 Jun 2022 05:29:17 -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.2 required=5.0 tests=BAYES_20,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,NICE_REPLY_A, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS15169 209.85.128.0/17 X-Spam-Virus: No X-Envelope-From: Received: from mail-wm1-f45.google.com (mail-wm1-f45.google.com [209.85.128.45]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Sun, 12 Jun 2022 05:29:17 -0700 (PDT) Received: by mail-wm1-f45.google.com with SMTP id c130-20020a1c3588000000b0039c6fd897b4so186387wma.4 for ; Sun, 12 Jun 2022 05:29:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :references:from:in-reply-to:content-transfer-encoding; bh=+8MV0B60+2kItLbIvlIuitVyFL2WCbtpkh/uEOpE7XY=; b=OgQN7iqVNSAS+gtM1R5aNvJpwFMeLlvhPDDMhnlAdpsz4MQzXClaFEzcCML5vx2+v3 SvsnlnxGFJpEDNoxdYbO8LNPLJawk0CZ/Sg8gdtDjZmgm83diWjdgzFLtl5JQkuSGxud ARiLbFheCgADP+ygnsO3OyksFqWSNfJft4NdAYeGmAgAlx5YBotuBARUH4n+a4Kw8XqC 2fNfyEf8C9k55EdTepvmrqcyVI4wM2VhcJ3uwJaOyVv037zp6zjTG4VQN14iwY3rrkCl ZNDaTCXj10b0yFKKkuIQ0JZuk3ypTgl7l7zE3O+BvnJicsxOnpmJAGORZCwtsQYPFX16 /ZKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=+8MV0B60+2kItLbIvlIuitVyFL2WCbtpkh/uEOpE7XY=; b=Tk/vW8mSmS/tcAMweQcUQunYyE/x7oeKMGSDjRQ5bpuUx5is7/1t/qCEHlf88MZBFd WCJDQKLIz7gfc1uqaqjLgDZ+iIqTu5uNBILJd/9uS7JPARvafnsl0UQ2HXXOCCMsV1qA CXQKiHytLpT2foJi2eLoQ+qJJ38V2EhTUpdhAiy6Khrn3XDFIsSGMjPb0oRQbzoiM9bF ZwcKhT4rbX5vY2oypzmQKfSlS7ApVeOLNOIrtxiVjQr++hCp5denUuHSjlNmdqRlhUbo JP1Aa0w4TNsoCMBtESGaNK929/w+qLq01CECM/EjW7oT2aUk4jYqpEoSRnMkL6jTlV6b +5qg== X-Gm-Message-State: AOAM53029d6E3mxTr7rkyw9lyjeN+XzalNXGYUxcBJ9bsMP9py+RkFBO eSNnaIF4YF+IfX+qO2cfP+Tl5FymuqM= X-Google-Smtp-Source: ABdhPJzOFmMGiz7yj7wHsNc4HSTdrrtxeHrRWJV/G6JWD0Hhcp2PgXxmfV2YiQ1U8SBJWPTqCQF6rg== X-Received: by 2002:a05:600c:3493:b0:39c:8731:84c3 with SMTP id a19-20020a05600c349300b0039c873184c3mr6424247wmq.45.1655036956007; Sun, 12 Jun 2022 05:29:16 -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 h62-20020a1c2141000000b0039c151298b7sm9788487wmh.10.2022.06.12.05.29.14 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 12 Jun 2022 05:29:15 -0700 (PDT) Message-ID: <886c9053-4ed6-6e40-3040-9feba6bcbe71@gmail.com> Date: Sun, 12 Jun 2022 13:29:13 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0 Content-Language: en-GB To: PHP internals References: <2b35605f-8da8-46b1-aec3-00bd1bfe47fd@www.fastmail.com> <8310f3fd-0011-970e-5379-b2b6e03942b2@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] [RFC] Short Closures 2, aka auto-capture take 3 From: rowan.collins@gmail.com (Rowan Tommins) On 11/06/2022 23:01, Deleu wrote: > The RFC does mention that the existing Anonymous Function Syntax > remains untouched and will not be deprecated. Whether the new syntax > is better for nearly all closures will be a personal choice. I honestly don't think this is how it will be perceived. If this syntax is approved, people will see "fn" as the "new, better way" and "function" as the "old, annoying way". To put it a different way: imagine we had no closure support at all, and decided that we needed two flavours, one with explicit capture and one with implicit capture. Would we choose "function" and "fn" as keywords? > The previous discussions talked about use(*) or use(...) and most > people I know that would love this RFC to pass would also dislike that > alternative. It does not have the greatest asset for short closure: > aesthetics. [...] All I can say is that use(*) is not a replacement > for the RFC. I think you're trying to have it both ways here: if you really believed that the two syntaxes were going to live side by side, there would be no reason for "aesthetics" to be any more important for one than the other. Some people are of the opinion that automatic capture should always have been the default, and the current syntax is a mistake. I'm fine with that opinion, but I want people to be honest about it rather than pretending they're just adding a new option for a narrow use case. > Any attempt to make it explicit defeats the purpose of the RFC. That depends what you think the purpose of the RFC is, which is what I want people to be honest about. If the purpose is to replace long lists of captured variables, an explicit "capture all" syntax like "use(*)" achieves that purpose perfectly fine. > Ultimately, I see fn() as "an opt-in to not create a separate scope > for a function". I disagree with both parts of this: 1) I don't think users will see "fn" as an "opt-in", they'll see it as "the new normal", and "function" as a rare "opt-out" or a "legacy version". 2) It does still create a separate scope, it just creates a *nested* scope, which combines two sets of variables, in a way that PHP currently never does. Regards, -- Rowan Tommins [IMSoP]