Update behavior of augmented null coalescing operator #3614
Conversation
x ??= y now behaves like x ?? (x = y) rather than x = x ?? y These are equivalent when x is null. When x is non-null, we avoid an unnecessary re-assignment step, which also allows for the possibility of using this operator with immutable hash tables without raising errors when keys already exist. Closes: Macaulay2#3612
| then ( | ||
| e := tryEval(x.lhs); | ||
| if tryEvalSuccess then lexpr = e) |
There was a problem hiding this comment.
I'm a little confused. Where is the actual assignment to lexpr happening now?
There was a problem hiding this comment.
We don't need it anymore when the left-hand side is non-null since we return right away. And when it's null, we've already assigned lexpr as nullE a couple lines earlier.
There was a problem hiding this comment.
I'm still confused. Where does the x = y in x ?? (x = y) is happening? I thought here lexpr was x.
There was a problem hiding this comment.
The assignment happens in one of several places, depending on what the code looks like.
lexpr is the evaluated left-hand side. But we still have the original unevaluated Code object, which we need to figure out what type of assignment we'll end up doing (global, local, assigning an element of a list/hash table, etc.). Here's the basic gist:
- Go ahead and evaluate the left hand side (
lexpr) and stuff it in anevaluatedCodeobject (left). We also check for errors here and whether someone has installed an augmented assignment method for this operator for the class oflexpr. If so, call that and return the result. - Now go back and look at the original unevaluated
Codeobject to figure out how to assign things. But instead of using thisCodeobject, we swap it out withleftto avoid re-evaluating the left-hand side.
|
Unrelated to this PR, but I just noticed this: i1 : (a,b) ??= (1,2)
-*dummy position*- error: augmented assignment not implemented for this code |
|
Ok yeah -- at the very least we should fix the |
|
Yeah, I don't necessarily need that to work (at least it's not a priority), but the dummy position surprised me. |
x ??= ynow behaves likex ?? (x = y)rather thanx = x ?? y.These are equivalent when x is null.
When x is non-null, we avoid an unnecessary re-assignment step, which also allows for the possibility of using this operator with immutable hash tables without raising errors when keys already exist.
Closes: #3612