Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129075
Feedback-ID: id5114917:Fastmail
Date: Tue, 04 Nov 2025 18:19:39 +0000
To: internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC][Discussion] use construct (Block Scoping)
User-Agent: K-9 Mail for Android
In-Reply-To: <CAFyg4HhrzQrE-q8D6WVkyq9tY+hzR=8rXiXLDPYpNKdYeydrVA@mail.gmail.com>
References: <CAFyg4HhrzQrE-q8D6WVkyq9tY+hzR=8rXiXLDPYpNKdYeydrVA@mail.gmail.com>
Message-ID: <1F3473C7-5D83-48D3-964E-A63D6F44D21E@rwec.co.uk>
Precedence: list
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: imsop.php@rwec.co.uk ("Rowan Tommins [IMSoP]")

On 3 November 2025 21:46:15 GMT, Seifeddine Gmati <azjezz@carthage=2Esoftwa=
re> wrote:
>Hello internals,
>
>Tim and I would like to open the discussion on our new RFC that we've bee=
n
>working on: "use construct (Block Scoping)"=2E


Hi both,=20

I agree with Ed and with Arnaud: this feels like it's trying to squeeze tw=
o different features into one syntax and ends up with an awkward version of=
 both=2E=20


For what Python calls "context managers", it offers very little: the progr=
ammer is still reliant on reference counting and cycle collection to actual=
ly clean up the resource, and objects can't directly interact with the cont=
ext life cycle=2E

Python in particular has a very carefully designed solution, and the PEP i=
s well worth reading: <https://peps=2Epython=2Eorg/pep-0343/> I think most =
of that could be directly ported to PHP=2E


For block scoping of "normal" variables it feels clunky to add an extra bl=
ock, rather than declaring the variable with a keyword like "let" or "var"=
=2E This is particularly obvious in the foreach example, where the variable=
 has to be named twice on one line:

use ($value) foreach ($array as &$value) {

Languages with a keyword for declaring variable scope instead let you writ=
e the equivalent of this:

foreach ($array as let &$value) {

I have said before that an opt-in block scope would solve my main concern =
about automatically capturing variables in closures, because you could writ=
e this to make scope explicit:=20

$foo =3D fn() {
    let $localVar;
    something($localVar, $capturedVar);
    something_else();
}

With this proposal, that would again be rather verbose: a mandatory extra =
set of braces, to put the scope inside the closure:=20

$foo =3D fn() {
    let($localVar) {
        something($localVar, $capturedVar);
        something_else();
    }
}


I think splitting the two use cases (context managers and scoped variables=
) would allow us to have much better solutions for both=2E



Rowan Tommins
[IMSoP]