Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:118132 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 78732 invoked from network); 30 Jun 2022 11:34:34 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 30 Jun 2022 11:34:34 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id A83F21804BD for ; Thu, 30 Jun 2022 06:26:01 -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-f50.google.com (mail-vs1-f50.google.com [209.85.217.50]) (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 ; Thu, 30 Jun 2022 06:26:01 -0700 (PDT) Received: by mail-vs1-f50.google.com with SMTP id z66so18253570vsb.3 for ; Thu, 30 Jun 2022 06:26:01 -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=mMkFHxQgpAGHTdf0PsVxx3W7bcCSiYFTULfwueAD0T0=; b=tMft9GfK8Mivk4ywUGBSiPMpQRB2jShMehT1BHvnAWF+LLrSKQTxaHnl7c7fFCMM5l 9yV65jSSEOOxCXxz3EFsas5qrNXVSk0bAjwBd0BTIAgv2bgSSf1SIGR/RcDvD67lpmUE H/C2dlJ3vGoZusYCI91qja4kVs7rGobGGvM2+EdTIdA3fPPipnE8gnAlgn3yNCkSSKG4 NkvHeEXX1InZOqxCR5AVzDkl9EBeRGYF0HZgLbtA3UTx68T63Fq0v5SqxL/57hRtzYA6 DzmPepkyjt3b3Z0XoB4/fORJZvFMMxQQEdUrSEJvrMfM92nSRjNO+Fi8LeHrMrK5WiP4 ZJmw== 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=mMkFHxQgpAGHTdf0PsVxx3W7bcCSiYFTULfwueAD0T0=; b=cSDZr9CtHuC4brGSbG6ajtdpCGfnnDLUPQ7x+VGyd/RHBdhcYg9DwjyjCstNvXSIj1 Gd68cxmFpImiHUZvaglimV1fvE7SttIlA/j6vI8jWdwXNtB+9g+8YfnzjFAixLN/IW3R sp2217SmF5/YugiImth+644XMssX7MMPmXPumAS5X1PNenIYk3cHbC1/MxzpnEC41WOV 708tLOvBVxtHxJuJjRiLwlA61Ncdc6UnU5MvBDz+ueE1GQrETK+6fshVH9foyMjgydKj qkd0801Uh212lL/uzs34IEgmUMokfTJf2YNq4J4MU9Y4e+qdo1FztdUwoFUmejVCFXyJ kjcA== X-Gm-Message-State: AJIora9BTMm2C1p3YnCNC7r9ufjYaZnEarGSSQHeONj5x7YTSxwtL4/d NDBCEL7ucewMnkW4uvc8vdskD3wZb5rzYpiFz8r970s1iCyj+Q== X-Google-Smtp-Source: AGRyM1tpMr0oBrwcr6haHKki/oMntVIDHl2yydq4Nb6QPtP9YA24k1UV41bMH8Ay251AsbFHE0Pv3oXWvghdyu07h0Y= X-Received: by 2002:a67:d318:0:b0:356:6fa0:b39b with SMTP id a24-20020a67d318000000b003566fa0b39bmr6707258vsj.2.1656595560337; Thu, 30 Jun 2022 06:26:00 -0700 (PDT) MIME-Version: 1.0 References: <2b35605f-8da8-46b1-aec3-00bd1bfe47fd@www.fastmail.com> <84eb5551-cfaa-42e6-9a74-ae229d5e269c@www.fastmail.com> <50894bde-74cc-b5a4-4bb7-ba0e682f952c@gmail.com> <2dcd5fe0-7284-138b-990c-512966141951@gmail.com> In-Reply-To: <2dcd5fe0-7284-138b-990c-512966141951@gmail.com> Date: Thu, 30 Jun 2022 14:25:48 +0100 Message-ID: To: Rowan Tommins Cc: 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) Hi Rowan, Rowan wrote: > For that to work, it would require the variable to be captured by > reference, not value. > ... > The only way for it to work would be using capture by reference (not > supported by the proposed short syntax): I wrote about this before. Some of the words in the RFC are, in my opinion, quite inaccurate: Danack wrote in https://news-web.php.net/php.internals/117938 : > Those statements are true for scalar values. They are not true for objects: With automatic capturing of variables, for the code example I gave the user would want the variable to be captured, and to them it looks like it should be, but because of an optimization it is not. When the code doesn't work as they expect it to, the programmer is likely to add a var_dump to try to see what is happening. Which makes it look like their code 'should' work, as their resource object is still alive. > In fact, the "optimisation" is in my opinion a critical part of the > semantics, to avoid the opposite problem: As I said, I think that problem is a lot easier to explain "either use long closures or change your variable name if you don't want it captured." than trying to explain "yes, the variable is referenced inside the closure, but it's not captured because you aren't reading from it". cheers Dan Ack For this code, comment the var_dump in/out to affect the lifetime of the object. class ResourceType { public function __destruct() { echo "Resource is released.\n"; } } function get_callback() { $some_resource = new ResourceType(); $fn = fn() { // // why is my lock released? var_dump($some_resource); // "Free that resource" $some_resource = null; }; return $fn; } $fn = get_callback(); echo "Before callback\n"; $fn(); echo "After callback\n"; // Without var_dump Resource is released. Before callback After callback // With var_dump Before callback object(ResourceType)#1 (0) { } After callback Resource is released.