Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:118125 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 12211 invoked from network); 29 Jun 2022 20:40:35 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 29 Jun 2022 20:40:35 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id CB0C61804F8 for ; Wed, 29 Jun 2022 15:31:56 -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-f53.google.com (mail-vs1-f53.google.com [209.85.217.53]) (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 ; Wed, 29 Jun 2022 15:31:56 -0700 (PDT) Received: by mail-vs1-f53.google.com with SMTP id o13so16533316vsn.4 for ; Wed, 29 Jun 2022 15:31:56 -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=YHa2C4rag4lgl5Mb8/x3JnRgVSA9OKMPbiE4oToAOFw=; b=X9sxzQbDC8ZSXtNtk8rvpd3abjUWcu4f2Ont/E5RtfHGQNaSD3fVLw/9k8TQbMr4Z7 aamyA6DIOPX3lPULLGQww4TgaWmOO96CbVHI8Zyjui3CFN6urdjzZZDwVjmMJHrOv1I4 aAwQTaJeNv/eAOfsYhkb8wrVuNpiGCNXDOsVNaTLUJ8FtP17jAuFrgLgkZxpuzaQsCuE q2S++As0W/ohxG0snNQLHqKfwb9tcCYLxqFQ08jYkCv5lveeqjrVTBOc0yH8XukCi7ym 8nrBn4cy47en0ygLXy9Lhs20JymCQ5+Hl8M3BcrBSy/grcttveDcHLLkKq0VrPNGXdrE T6LQ== 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=YHa2C4rag4lgl5Mb8/x3JnRgVSA9OKMPbiE4oToAOFw=; b=HIlpfugcNeQiD/N2acnilV7M78tf9j7xcKEsbIkBvypwhsMQH1gYTLLCfdTq0chGni EIwZr96EKeSDADOINDYq5RdyzgtEGch/izkbEa/9QQk7QXxMQPdMAtSwsEQI8O9GqhDI YztYuZNXRl+rTMO3Aak1up2qxxqeYtQagFF2I5GuYFkljELqOM5EcDRuSavHd+Re00FE kitP+iIBHM8NYcnPNkOkHJAcTVmYHdV5DsSRQrg8h/pzeMQH5EFp9Ra1L3kxZhUWg90V 7I/VZCcDLiDJzfwqYUiLb24ILBZTtoUBj2tiNyPPZXncFOF49vlPO+bD5Wviq+PQNotd CKBQ== X-Gm-Message-State: AJIora+J5ZnOiYXZrYhF+yOFXRJSREIDD1ucN0Qx3Yftn7haAeJ8b8/F fo8yPS/RlpFErYfhjCVcCQvDUutXibDsg5rrUaXc+743VrGxsw== X-Google-Smtp-Source: AGRyM1vtw7thhimHixUm4ek6fBId8k7daMETACE0AgDSlXLpuG7lEITyfTCz2IVhiaK/kifmS+K9XZqv4dUl6iWj5VQ= X-Received: by 2002:a05:6102:124d:b0:354:6208:b75b with SMTP id p13-20020a056102124d00b003546208b75bmr6803240vsg.9.1656541915559; Wed, 29 Jun 2022 15:31:55 -0700 (PDT) MIME-Version: 1.0 References: <2b35605f-8da8-46b1-aec3-00bd1bfe47fd@www.fastmail.com> <84eb5551-cfaa-42e6-9a74-ae229d5e269c@www.fastmail.com> In-Reply-To: <84eb5551-cfaa-42e6-9a74-ae229d5e269c@www.fastmail.com> Date: Wed, 29 Jun 2022 23:31:44 +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 Wed, 29 Jun 2022 at 18:30, Larry Garfield wrote: > > The conversation has died down, so we'll be opening the vote for this tomorrow. I think I've just thought of a problem with the optimization bit of 'not capturing variables if they are written to before being used inside the closure'. Imagine some code that looks like this: // Acquire some resource e.g. an exclusive lock. $some_resource = acquire_some_resource(); $fn = fn () { // Free that resource $some_resource = null; } // do some stuff that assumes the exclusive // lock is still active. // call the callback that we 'know' frees the resource $fn(); That's a not unreasonable piece of code to write even if it's of a style many people avoid. I believe in C++ it's called "Resource acquisition is initialization", though they're trying to change the name to "Scope-Bound Resource Management" as that is a better description of what it is. With the optimization in place, that code would not behave consistently with how the rest of PHP works, where the lifetime of an object is reasonably well defined with "The destructor method will be called as soon as there are no other references to a particular object,". From the RFC: > This approach would result in a waste of memory or CPU usage. For the record, all of my previous concerns about scoping rules have been about making code hard to reason about, and behave sanely. Memory itself is cheap. Although not having that optimization might mean that some variables last longer than they should, that is at least explainable*. Having variables not last as long as they should (because of an optimization) is harder to explain, and harder to explain how to work around. cheers Dan Ack * either use long closures or change your variable name if you don't want it captured.