Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:113823 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 10496 invoked from network); 28 Mar 2021 10:05:38 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 28 Mar 2021 10:05:38 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 4B5A31804C0 for ; Sun, 28 Mar 2021 03:02:22 -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 autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from mail-io1-f50.google.com (mail-io1-f50.google.com [209.85.166.50]) (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 03:02:21 -0700 (PDT) Received: by mail-io1-f50.google.com with SMTP id r193so9788863ior.9 for ; Sun, 28 Mar 2021 03:02:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZBxAsLfy0Z6V8rUChtAW2K9TcGjJMkKKIiMm5dkWx7g=; b=mAwI7plYmZWiGgs8obwtHAddOgmm5CYTVsJo6Jm1Xq0I806nqM5c/Kj2rm7vr/m8zw 0nNiHEFOgn64znOZqebzMhz7XgZ4UBlwx658tD8AMchU4MLlpilAjd+secEj5GALTpOt Cn1ybjVDUl1cobvlTosF/944ReyE1GnDvI6Vs6ki5m2gBie092eIdzczr4ytnHGV6II9 YZyVU+Ye6kmXL6kal/KnEP0w7Vtj6FkWBzMr+7XhDE+FNVKO6Ps8dhy+7WyowQT+0Kn7 owpOEGwIUdVJ0ZP1JS7FSm7Hu4nC+9JRu96Lib0T4RbV4GPdpUKSFAvuhSuB9OrTbuN1 W9mw== 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; bh=ZBxAsLfy0Z6V8rUChtAW2K9TcGjJMkKKIiMm5dkWx7g=; b=kEK3TLRSyYM2Ou3eKOL2XyMtRM6O/pqKbL19Ose5rBrTBqz3GHCU40xjzX5xSZCpyG 9TdrkGpwLZqln/6W9/HWqfnMoOJ385AvdGwi31U7oyy+gT1kOetrN7pF50+vptGclQmz 1vGdhG60RjbPvI9G7ggFPxf0dZRr+tmQtW3h2zPjx78N744sEJDZ3rnVtI8W2tHLQGkp aG9n7A6zNB8T4aaqVez6L0+1B/MNtzk/5sOQmRqjcyDidR134UFCJcg9D0iuuoCw602k 9cdQm0nTP1H5ysowW35pS0PtqdpypFlXxkT3R1NIWIARlHWavWAO9sgueCIAAsGSCQWm 2A4Q== X-Gm-Message-State: AOAM53259rxHKdZ7ds4Q/7QAZCUzMkOB2fLuHii2HN/BxTD+UaOtFn6S 9eaZgj9H8V2bw04Xboqtmcn+ffWV9kc7C+tCH84= X-Google-Smtp-Source: ABdhPJy8oDVIloIs5KW3kmQ1Lx3Os97yQEu6HTkWLofaijro/4izwbMut1prEiMR1GadEFKufnWjYxsoSUanxf0LssQ= X-Received: by 2002:a05:6602:2d83:: with SMTP id k3mr16232041iow.26.1616925738311; Sun, 28 Mar 2021 03:02:18 -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 12:02:06 +0200 Message-ID: To: Kalle Sommer Nielsen Cc: Rowan Tommins , PHP Internals Content-Type: multipart/alternative; boundary="00000000000042a1e305be95dcdc" Subject: Re: [PHP-DEV] [RFC] Auto-capture multi-line closures and shortfunctions take 2 From: deleugyn@gmail.com (Deleu) --00000000000042a1e305be95dcdc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable This would lead to inconsistent behavior in the language when short closures auto capture without the auto keyword while multi statements closure doesn't. One of the best features of these RFC are their cognitive definition that is clear, concise, consistent and simple. On Sun, Mar 28, 2021, 11:26 Kalle Sommer Nielsen wrote: > Hi Rowan > > Den l=C3=B8r. 27. mar. 2021 kl. 18.05 skrev Rowan Tommins < > rowan.collins@gmail.com>: > > Based on those, there seems to be no way to prevent a variable being > > captured, even if its value is immediately discarded each time the > > closure runs. This may be less than ideal: > > > > $results =3D getLargeReportFromDatabase(); > > // ... > > $fn =3D fn() { > > $results =3D []; // coincidentally the same name, immediately > > assigned its own value > > // ... > > } > > unset($results); // does not free the array, because $fn has captured > > the value > > I too am very concerned about this exact senario because it very > easily overlooked. While I understand the appeal of having very short > closures, I do think that such behavior needs to be explicit and would > much rather prefer something like this: > > - Make the `fn` keyword an alias of the `function` keyword > - Add a new `auto` (or similar) keyword for explicit auto capture > > Something like this: > ```php > return function () use ($v1, $v2, $v3, $v4) { > /* ... */ > }; > ``` > > Would then be abled to be turned into: > ```php > return auto fn () { > /* ... */ > }; > ``` > > That way it is very clear that the closure is intending on auto > capturing at this point, at the same time it also allows people like > me who prefers the `function` keyword to write. > > I personally don't think adding those 5 extra characters here for > explicitity is bad, I would like explicitly over implicitit, I can see > how many would simply just write `fn` without knowing there is a very > vitual difference (similar to `static` closures is rare if you don't > intend on binding `$this`). > > -- > regards, > > Kalle Sommer Nielsen > kalle@php.net > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > > --00000000000042a1e305be95dcdc--