Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:117918 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 42222 invoked from network); 12 Jun 2022 16:18:11 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 12 Jun 2022 16:18:11 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id C8C19180384 for ; Sun, 12 Jun 2022 11:05:14 -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-f54.google.com (mail-vs1-f54.google.com [209.85.217.54]) (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 11:05:13 -0700 (PDT) Received: by mail-vs1-f54.google.com with SMTP id d39so3931363vsv.7 for ; Sun, 12 Jun 2022 11:05:13 -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=41RWOOPR+jBLns3sX0MrW8fk4NBN2GV/j7UkypWBv5I=; b=BjopkX/TqC4sHM//N8bq7wwL++0OoA3zm1TTVVlhJe21MIWCU1l+j8uRakUNcLPR/j IFzJRfRk0n5aPFN2zbGoWPPmmHeNRXNc1LrpSurrVufwD6JvldiN7wWm9DH+mCghOwbn Fn0+jAgbjqgqbw9LbR/IWLJ0qhPvUsfZdcyhpX+MLgxiWgXN4WOWu/erIw2BG1W0RZNm G9HeBY5QeICokVXJKtogf700AZoSjd+sbwowFx5PXn2gyRlvilSPi0UzdSCPIDyIqlYt CDaYGjHQEnoIBraKfrK2EVqUaYER+r8/+WY0Culu9zxSwZ/+39ntAoZ+39y2ZRB/DX0v EJGw== 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=41RWOOPR+jBLns3sX0MrW8fk4NBN2GV/j7UkypWBv5I=; b=NeInxmp/N+szo0LXdrBteROuZFfq4HapiVQSwH8j/gLr1Az8QMXQrSiaL1Eu03Yg2v Y0hNyZAQ4iXLTvnGSuIoH9lXzngDVHZJKZmWCWqAJG1Iw1DlEbiiKPnLgcyGGfsEfy4o paDTs4Cm2fNswbsDW2QC/ig3GijcfvkGa3KW9esyQW91t2OGXBo5hlOfIS/EEAlKL2xf +thxzX7E3K4B7ZI3jQ9okwNRqmo1AJykN+2xokWvegDYGF4miVBPkx0o48HcDDE4DvuU 3slhl8HPo2ycz9Jf/YMw7fdGVaUO1iT+NBKxzrTpnCyma+4kvVDgI2OWoZvpExxJUol9 3vOA== X-Gm-Message-State: AOAM533/ruRK5g3qRsalCwrf/LS6va/uibY2znQDlRxPfhmdqzUMYEiE M3iDL+lBpUqn+rd3EfTJW7mo3EnugMJiE4qw1CG/oA== X-Google-Smtp-Source: ABdhPJw+YtX+KkPztrF+08BchmdSwpc3s6JltsWM95jLs9LAztDYQIxqJ29fI5sg4gxOR40eYnZ+4MIWeGYIkeWsniw= X-Received: by 2002:a67:ea85:0:b0:34b:912f:2c66 with SMTP id f5-20020a67ea85000000b0034b912f2c66mr21425049vso.42.1655057113273; Sun, 12 Jun 2022 11:05:13 -0700 (PDT) MIME-Version: 1.0 References: <2b35605f-8da8-46b1-aec3-00bd1bfe47fd@www.fastmail.com> In-Reply-To: <2b35605f-8da8-46b1-aec3-00bd1bfe47fd@www.fastmail.com> Date: Sun, 12 Jun 2022 19:05:02 +0100 Message-ID: To: Larry Garfield Cc: php internals 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) On Thu, 9 Jun 2022 at 17:34, Larry Garfield wrote: > > That RFC didn't fully go to completion due to concerns over the performance impact I don't believe that is an accurate summary. There were subtle issues in the previous RFC that should have been addressed. Nikita Popov wrote in https://news-web.php.net/php.internals/114239 > I'm generally in favor of supporting auto-capture for multi-line closures. > > There are some caveats though, which this RFC should address: > > Subtle side-effects, visible in debugging functionality, or through destructor > effects (the fact that a variable is captured may be observable). I think it > nothing else, the RFC should at least make clear that this behavior > is explicitly unspecified, and a future implementation may no longer capture > variables where any path from entry to read passes a write. To be clear, I don't fully understand all those issues myself (and I have just enough knowledge to know to be scared to look at that part of the engine) but my understanding is that the concerns are not about just performance, they are deep concerns about the behaviour. It would produce a better discussion if the RFC document either said how those issues are resolved, or detail how they are still limitations on the implementation. It also probably would have been better (imo) to create a new RFC document. The previous RFC went to vote, even if the vote was cancelled. Diskspace is cheap. Having different (though similar) RFCs under the same URL makes is confusing when trying to understand what happened to particular RFCs. cheers Dan Ack