Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:117936 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 45671 invoked from network); 13 Jun 2022 15:34:19 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 13 Jun 2022 15:34:19 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id B5D9118050B for ; Mon, 13 Jun 2022 10:21:36 -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.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE, 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-vs1-f41.google.com (mail-vs1-f41.google.com [209.85.217.41]) (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 ; Mon, 13 Jun 2022 10:21:36 -0700 (PDT) Received: by mail-vs1-f41.google.com with SMTP id q14so6498609vsr.12 for ; Mon, 13 Jun 2022 10:21:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=basereality-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FgAaQ5KpZ5tFw35Mm7AmfRN4tFHEq43VHGg6ZDR591g=; b=nSA3Wk8+QEyNqtndQ77KdtswONwf+d3hTNqZZQOeNBSLdACEvMV5DSGIRy4L/Knpm2 Zfs/LFKMmuM16ER7p/tcqL6ziZ6zJeyQLPC9fN0/OtjNB0FldwKwNvTd43B/ByBO+4tm 5ZlUHshp2xkMMqtLrz1oe5rkJ6OKHwwxdSZwp/VFLLKK6rRXdEEaqKq/xqZH6j5HpaK/ stMEBheE3jvUSCrz7YGkGbuDlhd9xNTZNri8bGM8MNGKNT9rpr4OMctfRfUkvvR99fY8 ewPLHWuLisSbafVqjYhSwoKAAAY9Ws1oVq6SbvS4A86DgcJIwVw+eWpgPeG44MFnm5Jq LhdA== 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=FgAaQ5KpZ5tFw35Mm7AmfRN4tFHEq43VHGg6ZDR591g=; b=2cg6JsusKENgd997R98bsC9DNlKMot3FweS5HN+92FSXNHgdRW9r08u49Eqpv5eip2 vDKfAV6AJNTra3tva9x/rSlupeEBFEeCIEqQ5AvKWuTkwY3HodIwFrF3EUjrDhr2hSYp xDr58H3oS1mhpS9aoUNcTD0e/qHAhEVPdUm1Lczfc5l+K07Et+yOXUNiEg5WqXYRr+Gb 6M7K7MbhsotJcNT9I5ydR/0f09Pab+3nMhdkq8c3uyluOVxT3YzP/c0A1YW1SdYT0A1o Ou5rfGez2gF0fFna3lcJMxD3+PGIhO1nUMAoc/4USNNtEWDTFrBbRcua9tpjevwMJ6I3 /+/g== X-Gm-Message-State: AJIora/7LyaJTCUb4tp0cAoSJS4tX3IQUB1kFq0Wo/5RzViPnPJNPfts LnN2muK0u9FRUvLdge650CLC2mODU7seW93Rs1F2eQ== X-Google-Smtp-Source: AGRyM1ujI85iNV+3SbcCzEXjcyvSzBpUvI1F4U1wI8IyksYofniX15N31jT94cZ6rKVqUT5f/CdF/tXIwqeu9oFZEn4= X-Received: by 2002:a67:df16:0:b0:32c:bac6:95ad with SMTP id s22-20020a67df16000000b0032cbac695admr195821vsk.29.1655140895504; Mon, 13 Jun 2022 10:21:35 -0700 (PDT) MIME-Version: 1.0 References: <2b35605f-8da8-46b1-aec3-00bd1bfe47fd@www.fastmail.com> <8310f3fd-0011-970e-5379-b2b6e03942b2@gmail.com> <2347345.PIDvDuAF1L@arnaud-t490> In-Reply-To: <2347345.PIDvDuAF1L@arnaud-t490> Date: Mon, 13 Jun 2022 18:21:23 +0100 Message-ID: To: Arnaud Le Blanc Cc: internals@lists.php.net, Rowan Tommins Content-Type: text/plain; charset="UTF-8" Subject: Re: [PHP-DEV] [RFC] Short Closures 2, aka auto-capture take 3 From: Danack@basereality.com (Dan Ackroyd) Hi Arnaud, Arnaud Le Blanc wrote: > > Following your comment, I have clarified a few things in the "Auto-capture > semantics" section. This includes a list of way in which these effects can be > observed. These are really marginal cases that are not relevant for most > programs. Cool, thanks. > Unfortunately, Arrow Functions already auto-capture today, so requiring a > `use(*)` to enable auto-capture would be a breaking change. I think there are two things that making this conversation be more adversial than it could be otherwise: 1. Some people really want implicit auto-capture, while others are deeply fearful of it. That comes more from the experience people have from writing/reading different types of code leading them to have different aesthetic preferences. Trying to persuade people their lived experience is wrong, is hard. 2. The current situation of having to list all variables is kind of annoying when it doesn't provide much value e.g. for stuff like: function getCallback($foo, $bar, $quux) { return function($x) use ($foo, $bar, $quux) { return $quux($foo, $bar, $x); } } Where the code that returns the closure is trivial having to list out the full of captured variables does feel tedious, and doesn't provide any value. I realise it's annoying when people suggest expanding the scope of an RFC, however...how would you feel about adding support for use(*) to the current 'long closures'? That way, people could choose between: * Explicit capture of individual variables: function($x) use ($foo, $bar, $quux) {...} * Explicit capture of all relevant variables: function($x) use (*) {...} * Implicit capture of all relevant variables, and fewer letters: fn($x) {...} People who don't want implicit capture would be able tell their code quality analysis tools to warn on any use of short closures (or possibly better, warn when a variable has been captured). People who do want implicit capture can use the short closures which always have implicit capture. cheers Dan Ack