Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:118138 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 94749 invoked from network); 30 Jun 2022 13:56:13 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 30 Jun 2022 13:56:13 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 478B01804F8 for ; Thu, 30 Jun 2022 08:47:44 -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, 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-yb1-f181.google.com (mail-yb1-f181.google.com [209.85.219.181]) (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 08:47:43 -0700 (PDT) Received: by mail-yb1-f181.google.com with SMTP id v185so24962946ybe.8 for ; Thu, 30 Jun 2022 08:47:43 -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; bh=FSUrkDJP5C7gR/5/F7gedifOo7q8cgcK4ro5KFi5MqQ=; b=VafXStPvJF2BP2lWBNeAUHxZYGe6zZeEAKv8FvdKKATdN0xyz/WNKhrfmNDFd9/Khv dWRMCWSIvkWryQB0fRWiA2rKW74z5j9E7e7ADMIOpz4Tw+mNOJNOEI1YbtZHv5bdiwhP PMMbderDHFOwaQMe1WAHX/RfHCCdYN/seDCWQpVtZtEcEWcoOZxg4wixjvhehEZh5DTQ VF7OilBFU5mOmvbMIBCmX4kdMaYG28EJ2GLHIVM2IZtYOOA011AcCkA6onSwykM/YAMQ 1xPgP10qD4c5Z7mHAInJSKGgku5hKCz7PKR0kudaFR7rCVOXJ0owTusG+/4/UI/JZ8MF RNCg== 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; bh=FSUrkDJP5C7gR/5/F7gedifOo7q8cgcK4ro5KFi5MqQ=; b=a5pvOVIUWY/XZlIFF659lK3m9LbgCQtrl3SO3RBFoJlEo/cusUpwDCZZ9742GXRDlO jgRrnGkTb8njpb3STClufGqEL40JpQG/OEdv8mnbR7/R6v2lav2aL9BHiUrnDh0vbFPU kkgISUThb3aEyQOMVCXcGuV6ATp3kCc+yZUOwSf+HmfW8Z0tJdbniuakiR69guaaQadh Xh1J3G/tTlNdenbHKeHC47apv9Eam4mLFF/RPD4kWCKrR9bKh18YA7uNQD9RC0bYZrJ+ xNHwQOhDi8FyZvD81nnhZKQFuR9jX5qlEd945XXhHwElE9cqsvC8y4rc/DdZ+KOdmGIb r6XA== X-Gm-Message-State: AJIora+EpygE6dTup5qsGZk8yR7txqQ6iYzx8RGQyqg1wwVSDhk+VPDl qmRjhv+VrVlRluav2H9A7ssCrOGo1II3g9UdOumtMZS35g== X-Google-Smtp-Source: AGRyM1syrLbiyJU6YWEpMsq+QSzT9jZgYCMQyDnGDrOj+vOWT41CtnAaZc6iuxj19dfuNZha84BRRJVgeCeEAk/H5Y8= X-Received: by 2002:a25:50c7:0:b0:66c:95d2:c7e5 with SMTP id e190-20020a2550c7000000b0066c95d2c7e5mr10414117ybb.156.1656604063242; Thu, 30 Jun 2022 08:47:43 -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: Date: Thu, 30 Jun 2022 17:47:31 +0200 Message-ID: To: internals Content-Type: text/plain; charset="UTF-8" Subject: Re: [PHP-DEV] [RFC] Short Closures 2, aka auto-capture take 3 From: guilliam.xavier@gmail.com (Guilliam Xavier) On Thu, Jun 30, 2022 at 3:26 PM Dan Ackroyd wrote: > > 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: But the RFC has been updated since (notably the DateTime example); do you find the current wording still inaccurate? > 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. Am I missing something here? To me, it has been explained (and shown) by Rowan (and me) that the code example you gave would *not* work as expected *even without the optimization* (for it to work it would need to either capture by *reference*, or use e.g. `$some_resource->close();` [or `close($some_resource);`] instead of a destructor); but maybe we don't "expect" the same behavior in the first place? > 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. This indeed seems a valid point (that adding a `var_dump($some_resource);` before the `$some_resource = null;` changes it from "not captured" to "captured", with an effect on its lifetime). But are there "real" cases where it would *actually* matter? > > 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". Same as above. On Thu, Jun 30, 2022 at 4:19 PM Robert Landers wrote: > > Rowan wrote: > > No, the captured value is tied to the lifetime of the closure itself, > not the variable inside the closure. > > With the "optimization," it won't be captured at all by the closure, > possibly causing some resources to go out of scope early. And it has been explained that conversely, capturing it would possible cause some resources to "remain in scope" late. > Are > optimizations going to be applied to single-line arrow functions (I > didn't see that in the RFC, but I admittedly didn't look that hard and > I vaguely remember reading something about it in one of these > threads)? Seems so: https://github.com/php/php-src/pull/8330/files#diff-85701127596aca0e597bd7961b5d59cdde4f6bb3e2a109a22be859ab7568b4d2R7318-R7320 > If so, it will probably change some behaviors in existing > applications if they were relying on it. Perhaps static analysis tools > can detect this and inform the developer. Here too, do you have a "real" case where it would *actually* matter? > Here's Dan's code: https://3v4l.org/99XUN#v8.1.7 that he just sent, > modified to not capture the $some_resource and you can see that it is > indeed released earlier than if it were captured. And here it is "un-modified": https://3v4l.org/gZai2 where you see that calling $fn() (which internally nullifies *its local copy of* $some_resource) does *not* release; is it really what you expect? are you creating the closure only to extend the lifetime of $some_resource? Regards, -- Guilliam Xavier