Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:118130 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 65278 invoked from network); 30 Jun 2022 08:37:53 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 30 Jun 2022 08:37:53 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 5904D180511 for ; Thu, 30 Jun 2022 03:29:22 -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-wr1-f44.google.com (mail-wr1-f44.google.com [209.85.221.44]) (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 03:29:21 -0700 (PDT) Received: by mail-wr1-f44.google.com with SMTP id b26so14205525wrc.2 for ; Thu, 30 Jun 2022 03:29:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=zxDkqVtTVhS7MxGJr6jjh2xp5fAprY8kai0NV5NdzmQ=; b=AiP5Gh7nSd87JdazdwNeZWpqrONQgZPuSuaeT5/FSRqhWD/Nrr28RpuKbAiLW9QSgJ f0vpw2B2N2uvEjZx4FQfbGdCL3+xiaqvS2ftV5iEsaHzMfGmXCS2su0aZT8Wh9GTMmlX DixJV6JIASrl/seLzSQUZEP0nJWZJR01i7O+3y3eIlu2xbjPaSC29YJuWKRuSpidwHAt IOib+8fQL4aj3cl9Y/UuzQ+UYtt/OPifouJ5OY4MQ2m8PV6E6d60qc3YHGoBU46C1sK0 MOlZmmiA2FaeWCNBg4qy2r0GI0dytamEM52MUhOPtHvLAy40oDNDItVhhD+8QdqOARoN 6PgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=zxDkqVtTVhS7MxGJr6jjh2xp5fAprY8kai0NV5NdzmQ=; b=r/vdfzc8hBpB8/qeD8vQ0mSrjh7mzJvTcLYbUR320TE8erdQWFDV3OaOy+J/GC/ob8 Jd3FZjV++j86xhnTdl+KdYYAbYwnYenuLUGWPB+G0MZ9sBgfyO4oIZz4LX8/v8lyknLw Pa71ul+1Mo7F0++wtEpNcDmwmKUrrPPe2b/eS2X0bMHxwDTNqYIx1VmhCXC79IJ5sE+b vBJ7ZHCqhu8ofgAxLozBRfSzrxc+pbnXll2VP9SB7UEujIbpSBJW2AQUKCCKuQ6Z2BER 7HJLgwcB/0ff+wJtml3ZWtSArdwq4buI+0ZYjbUri0ZsA4berqRkG1lbygxbmgLdeqmP ZGbg== X-Gm-Message-State: AJIora9LRUsoWWVWTThhpJYx2qn5mJfxL1KW4esHI1yAMZ44nyooybvp 8YYe+5Eckmr6WBowjQbgK1pMCL0X+aTYdg== X-Google-Smtp-Source: AGRyM1vbpckIzcEMRFpfy3AdGoIrNZXaZiZ7h+oWcoENxgC6fDS3RmAm1vK7xcwb1z44bHfj5yLUzg== X-Received: by 2002:adf:f147:0:b0:21b:9ff4:9e08 with SMTP id y7-20020adff147000000b0021b9ff49e08mr7560711wro.608.1656584960528; Thu, 30 Jun 2022 03:29:20 -0700 (PDT) Received: from arnaud-t490.localnet (2a01cb04054b5b009c33dfa7936925c8.ipv6.abo.wanadoo.fr. [2a01:cb04:54b:5b00:9c33:dfa7:9369:25c8]) by smtp.gmail.com with ESMTPSA id m2-20020a05600c3b0200b0039c63f4bce0sm2213098wms.12.2022.06.30.03.29.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 30 Jun 2022 03:29:19 -0700 (PDT) To: Larry Garfield , internals@lists.php.net Cc: php internals , Dan Ackroyd Date: Thu, 30 Jun 2022 12:29:18 +0200 Message-ID: <4662986.3VsfAaAtOV@arnaud-t490> In-Reply-To: References: <2b35605f-8da8-46b1-aec3-00bd1bfe47fd@www.fastmail.com> <84eb5551-cfaa-42e6-9a74-ae229d5e269c@www.fastmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [PHP-DEV] [RFC] Short Closures 2, aka auto-capture take 3 From: arnaud.lb@gmail.com (Arnaud Le Blanc) Hi, On jeudi 30 juin 2022 00:31:44 CEST Dan Ackroyd wrote: > 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. I feel that the RAII pattern aka SBRM / Scope-Bound Resource Management is not relevant in PHP context, and I don't believe that it's commonly used in PHP or in garbage collected language. Also, in this particular code example, using an explicit fclose() would be better in every way, including legibility and reliability, so this doesn't appear to be realistic code. Because of this, I don't think that we should be taking decisions on this feature based on this use case. I've used the RAII pattern in PHP to manage temporary files, as a best-effort way to remove them (in a destructor) when they are not used anymore. However I would not rely on this for anything more critical or anything that requires predictability in resource release timing. RAII is useful in C++ because memory is managed manually. This is not the case in PHP. It's also useful in C++ to manage other kinds of resources such as file pointers or locks. In PHP it would be dangerous because you don't realistically control the lifetime of values, so you also don't control the timing at which the resources are closed. It's too easy to extend the lifetime of a value accidentally. One way the lifetime of a value could be extended is via a reference cycle. These are easy to introduce and difficult to prevent or observe (e.g. in a test or in an assertion). An other way would be by referencing the value somewhere else. You can not guarantee that the lifetime of a value is unaffected after passing it to a function. In C++ it's different because no code would implicitly keep a reference to a variable passed to it unless it was part of that code's contract, or unless the variable was refcounted. Another factor that makes RAII un-viable in PHP is that the order of the destructor calls is unspecified. Currently, if multiple objects go out of scope at the same time, they happen to be called in a FIFO order, which is not what is needed when using the RAII pattern [0][1]. I think that RAII can only realistically be used in a non-managed, non- refcounted, non-GC language. GC or reference counting should not be used to manage anything else than memory allocation. Other languages typically have other ways to explicitly manage the lifetime of resources. Go has `defer()` [2]. Python has context managers / `with` [3], C# has `using` [4]. `with` and `using` can be implemented in userland in PHP. Because of all these reasons, I don't think that RAII in PHP is practical or actually used. So I don't think that we should be taking decisions on Short Closures based on this use case. > With the optimization in place, that code would not behave > consistently with how the rest of PHP works There exist no circumstance in PHP in which the existence of the statement `$a = null` would extend the lifetime of the value bound to `$a`. [0] Destructor order PHP: https://3v4l.org/iGAPj [1] Destructor order C++: https://godbolt.org/z/f78Pa9j69 [2] https://go.dev/doc/effective_go#defer [3] https://docs.python.org/3/reference/compound_stmts.html#with [4] https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/ keywords/using-statement Cheers, -- Arnaud Le Blanc