Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125916
Precedence: bulk
MIME-Version: 1.0
Date: Wed, 06 Nov 2024 11:15:12 +0100
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Subject: Re: [PHP-DEV] RFC: Support Closures in constant expressions
In-Reply-To: <e92efb74-3689-4861-ab9f-9472aecb470e@app.fastmail.com>
References: <15da4c13445d7e9c9d768c60c19768d4@bastelstu.be>
 <3b458165-406c-4b70-97bc-6e98d6c44c72@app.fastmail.com>
 <6f39dce9e6b0579baa51bc84cb8140b9@bastelstu.be>
 <fe2230a0-6d1c-4256-8846-ee6de3589451@app.fastmail.com>
 <219e4bbc0b94c35d2410fb640db6c477@bastelstu.be>
 <6bffc58a-b869-495e-9be8-0590822e6d79@app.fastmail.com>
 <2sPXJojAve1IIS8SoHTv2VumjKcVe0iTwygretTEfvf8KVMw_qPZf3vKUfC1GrOk979EvXmKm86igz06Dk6VpOkkMMeU5vYvB4qghjyuk6g=@gpb.moe>
 <e92efb74-3689-4861-ab9f-9472aecb470e@app.fastmail.com>
Message-ID: <34e82090b2b234b16fe9dc956d7b3c3c@bastelstu.be>
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=C3=BCsterhus?=)

Hi

Am 2024-11-05 18:49, schrieb Larry Garfield:
>>> My expectation is that it's confusing, and therefore we should simply 
>>> disallow it. Which roughly translates to detecting if a closure tries 
>>> to use an unbound variable statically. Which is probably more 
>>> difficult than I make it sound. :-)
>> 
>> Which is why short closures are being disallowed.
>> The value of it *is* limited, and the semantics of it are confusing.
>> I am struggling to see why this is such a big deal.
> 
> I suspect, since several people have asked about it, it's because most 
> of the use cases for having a default Closure value are going to be 
> short; the sort of short cases that short-closures and FCC are designed 
> for.  If it's long, then you're probably better off moving it to a 
> private method and making a FCC reference to that private method the 
> default value instead.

Even though the initial example is one that uses a default parameter 
value, we see the primary use case in supporting Closures in attribute 
parameters. That’s why that’s the use case mentioned in the first 
paragraph and that’s why all the snippets in the “Use Cases” section 
showcase attributes.

> I'm not asking for a detailed description of the engine nuances of 
> detecting unbound variables.  Just something along the lines of "this 
> would require detecting unbound variables, that's hard, so we'll save 
> that for later."  Which is a level of detail I frequently do provide in 
> my RFC future-scopes.

The extent of investigation I did regarding the implementation was 
verifying that “yes, it indeed does crash”, because you can’t build an 
implementation if you do not know what the expected behavior should be 
in the first place. It is not at all obvious how variable capturing (or 
rather: variables in general) should work from a semantic perspective, 
as you confirmed yourself (“it’s confusing, and therefore we should 
simply disallow it” [1]). We disagree with adding another special-case 
to PHP’s semantics by introducing a “non-capturing short closure” as a 
third type of Closure [2] and figuring out what the semantics of 
variables within const-expr should be is out of scope for this RFC.

In any case, the “Constraints” section already explains why those 
constraints exist.

Best regards
Tim Düsterhus

[1] My personal expectation for parameter default values would be that 
any previous parameter would be legal to access and capture.
[2] Or fourth, if you consider FCC to be a type of Closure.