Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129629
Feedback-ID: i8414410d:Fastmail
Precedence: list
MIME-Version: 1.0
Date: Tue, 16 Dec 2025 16:21:56 -0600
To: "php internals" <internals@lists.php.net>
Message-ID: <bdf9d3cc-5139-4218-8524-6f47dd26288d@app.fastmail.com>
In-Reply-To: 
 <CAJp_myUfON=vHcd3Uf0o4tGDmtkk85tAU9tZ+8YdVxh3q03nEA@mail.gmail.com>
References: 
 <CAJp_myV9+kxx-eA+cja-Fu5dJhDZgzhgpBpiZFWqqW-_zrNreQ@mail.gmail.com>
 <70A79513-5503-467E-BC6F-2B0494A3EBB9@benramsey.com>
 <CADK1yXJgPsZJ5+qepDotrMMtRm8TtG95wS7UNpvd8D=Pm-+BOQ@mail.gmail.com>
 <D8927CEA-3D00-4ECF-807B-7C2C96C5B582@rwec.co.uk>
 <CADK1yXJUt3OLExBT5462mHu_vaxyRuUTKcVYF_kbwY04_y8TJA@mail.gmail.com>
 <cf0dc177-cce8-4703-9195-b91408ba694c@app.fastmail.com>
 <CAJp_myUfON=vHcd3Uf0o4tGDmtkk85tAU9tZ+8YdVxh3q03nEA@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Context Managers
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
From: larry@garfieldtech.com ("Larry Garfield")

On Tue, Dec 16, 2025, at 3:40 PM, Matthew Weier O'Phinney wrote:

>> If there's some better word than =>, we're still open to it, but I am going to insist on left-to-right reading.  $cm is created first, then it produces $cv.
>> 
>> 'as' is what we had originally, since that's what Python used.  However, it was pointed out that it was confusing as it implied the CM and CV were the same thing, or rather the expression on the left gets assigned to $cv, which is not the case.  Hence the change.
>
> I didn't find it ambiguous, but I can see where others might. That 
> said, I found it _less_ ambiguous than => here. 
>> 
>> A symbol does have the (dis?)advantage of a somewhat squishier meaning than a keyword.
>> 
> I want block scoping; I have been bitten by accidental re-assignment 
> within a block many times, and hate having to come up with an 
> ever-so-slightly-different variable name to disambiguate. I don't care 
> if it's this proposal or the "let" proposal in terms of how the engine 
> handles it - but the syntax of "using (expression => $var)" isn't going 
> to get my vote due to how easily it can be written incorrectly.
>
> I have no problem with the "using (expression as $var)" syntax, and the 
> "let($var = expression) syntax is just fine for me as well. 

I think it's important to realize that the two RFCs may be similar, but they're actually doing two VERY different things.

The `let` RFC is defining a guaranteed "unset this variable later".  That's it.

The CM RFC is defining a way to package up setup and teardown logic into a reusable component.  That happens to also involve unsetting a few variables, but that's not its primary design.  The primary design mandates the separation of the context manager from context variable.

The CM RFC does substantially more than the `let` approach would be capable of, and is a model proven in Python to be useful and effective.  (As I said elsewhere, I think `let` as an addition to existing structures would make more sense than using it for arbitrary new blocks, which would also avoid any confusion with CMs.)

So are you against the Context Manager proposal entirely, or would you be on board if we can find a non-confusing syntax?  Ie,

using (new CM() which produces $var) {

}

If we can find a less verbose way to spell "which produces", would you be on board?

--Larry Garfield