Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:117914 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 23047 invoked from network); 12 Jun 2022 13:35:52 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 12 Jun 2022 13:35:52 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 70D8A18037E for ; Sun, 12 Jun 2022 08:22:53 -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,HTML_MESSAGE, 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-il1-f178.google.com (mail-il1-f178.google.com [209.85.166.178]) (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 08:22:52 -0700 (PDT) Received: by mail-il1-f178.google.com with SMTP id s1so2707165ilj.0 for ; Sun, 12 Jun 2022 08:22:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TSFIUkn1aiuBETmidp8Ck0mj8aXhDACoc4Qrt33DMw4=; b=iXSlBdh4Cn+IdELHvlNqgYCB11nFzDAVYpCVj9Vp9zdejQKdt9kz6MN3U7ef5SyYID 6jvspIrzirpJenIkcD8s1U5KDdDYOMO70DdoAzfIdiJ3SvnWIB8YC+7BIKi7WN14wPfp YPYZL/d5nI0WeTJKIbwaXXhkNTZ/XbzO4HQ1m9h+FUQlsuOyLgziUgxktLZdQrI90V+S BmgsUSWPy6YCBgjj9DVs/t0TwS58ynhNJjeG/1AOixhARg1fgwjesfbPTjE/MOVUrZUq XN9fb7VDIE9gb3HAxiChcUxvechawrmf0bB+Gs+YOoEFooJ9601ddvKsvEUIrwi144AE zcVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TSFIUkn1aiuBETmidp8Ck0mj8aXhDACoc4Qrt33DMw4=; b=Nrk8HOzB59ECk7D+b2hH8VfpoufdJYx8a2MFCPYJXmk5yWSl3VWPfDNLZ53+GNAhFW tsZ5cRsal9/j69feJ4+5cr6s6cGN6ILxgu6r4YM1pYSB7Hk6cRUbbR8sj61jihOoVYm8 LWGvvYxGmZmYPCKFPVUVXVkR31Huz0BCgCy7BRuaOYCUsHKjz9k8BWtwvWcRjOhqVUM4 J1Rbc4Ay7qIB1gvA1NC+gaFfgm4/6Y7dl5h8A9l+rjK9MN234xZ/L8uqkW5IBlSpVIUX k1g7L5J1E5dxnWVon5ezWYvWTmsHFLfUhT4eXDXmfagpFTpqQr7kKuqpYczlXxMq7NGU 19JQ== X-Gm-Message-State: AOAM530zTZfSJUfLbFBIcAoadW/tVulDbf+Pk6IcA4UUGAhZPmxmxmBb jL9XJq8Tvf+VB9AK222cwP/qnS+FXhkkIdJwIBM= X-Google-Smtp-Source: ABdhPJyxk0WbELByiQXXn2XUXtVP4I53Q5sckfliQ9Jx316S1yKLTsXoTrNrW6ITjhUbp1jqwDdHQOg8EKz6czwfZao= X-Received: by 2002:a05:6e02:1849:b0:2d3:f382:bb30 with SMTP id b9-20020a056e02184900b002d3f382bb30mr29246558ilv.144.1655047371961; Sun, 12 Jun 2022 08:22:51 -0700 (PDT) MIME-Version: 1.0 References: <2b35605f-8da8-46b1-aec3-00bd1bfe47fd@www.fastmail.com> <8310f3fd-0011-970e-5379-b2b6e03942b2@gmail.com> <886c9053-4ed6-6e40-3040-9feba6bcbe71@gmail.com> In-Reply-To: <886c9053-4ed6-6e40-3040-9feba6bcbe71@gmail.com> Date: Sun, 12 Jun 2022 17:22:15 +0200 Message-ID: To: Rowan Tommins Cc: PHP internals Content-Type: multipart/alternative; boundary="000000000000b13aa605e141be27" Subject: Re: [PHP-DEV] [RFC] Short Closures 2, aka auto-capture take 3 From: deleugyn@gmail.com (Deleu) --000000000000b13aa605e141be27 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Jun 12, 2022 at 2:29 PM Rowan Tommins wrote: > 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". > And to me that's not an argument to deny what people want. > 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? > I often don't indulge such hypotheticals because we will never truly be able to make progress based on such an assumption. A breaking change that changes how closure works is just not gonna happen. Given the current state in the world we're in, what can we do to have a better DX on anonymous functions? > > > 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. > > Honestly I don't think it was a mistake. It was designed more than a decade ago and there was no way of predicting the future. I've seen code written 20~10 years ago and I've seen code written 5~0 years ago. I think the best decision was taken at the time it was taken and the world of development has changed enough for us to make different decisions now. It's not that I'm trying to have it both ways, I'm just not assuming my view is the right one. I do believe that if such an RFC is approved, I will almost never reach for `function () use ()` anymore because I will prefer the short syntax. If I need a new scope I will reach for an invocable class. But that doesn't mean other teams/projects/people are forced to agree or follow the same practices as me or my team. > > > 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. > > If someone decides to implement `function () use (*)` on a separate RFC, I would abstain from that because it's not something I'm interested in using and it doesn't address the aesthetic issue we have today. I just don't like it being considered an alternative to the current RFC because it's not. The purpose is to replace long lists of captured variables while addressing the aesthetic issue caused by `use ()`, which is the only place in the language we use this construct. It seems to me that you agree that there is a chance the proposed syntax is going to be perceived as better and people will not want to use the old syntax anymore and that makes you not want to accept the RFC. Regards, > > -- > Rowan Tommins > [IMSoP] > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > > --=20 Marco Aur=C3=A9lio Deleu --000000000000b13aa605e141be27--