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

Reply via email to