The key thing I'm hoping for in PEP 622 itself is that "Syntactic
compatibility with a possible future enhancement to assignment
statements" be considered as a constraint on the syntax for case
patterns.
That would certainly rule out ideas like writing stores as $x or x? or <x> etc., since it would be syntactically incompatible with *current* assignment statements.
Yeah, having stores be unmarked is perfectly consistent with existing assignment statements and expressions, so I now think the PEP is correct to propose that.
However, the two parts of the match lvalue proposal that are a genuine problem from a syntactic consistency perspective are:
* using "." to mark value constraints (already means attribute binding in assignment lvalues)
* using "_" to mark wildcard placeholders (already means a normal variable binding in assignment lvalues)
The conclusion I came to from that observation was that to allow for potential future syntactic consistency, it isn't variable bindings that need a symbolic prefix in match lvalues, it's value constraints.
That then leads to the idea of using "?" as a general "value constraint" marker in match expressions:
* bare "?": wildcard placeholder that allows any value without binding it
* prefix "?": constrains the value in that position without binding it
* infix "?": imposes a value constraint on a value that is being bound to a name (means the walrus matching pattern is only needed in cases where a value is being both bound and deconstructed - simple cases would be written like "name?None" rather than "name:=None")
With this spelling, the named value constraint example from the PEP would look like this (with an extra case added showing infix value constraints):
===
match color:
case (primary?GREEN, highlights?BLUE):
print("Two tone, huh? Nice!")
case ?BLACK | ?Color.BLACK:
print("Black suits every color")
case BLACK: # This will just assign a new value to BLACK.
...
===
I'll note that adopting this approach would likely mean that "?0", "?None", etc would qualify as legal value constraints, so a separate decision would need to be made if it was allowed to omit the prefix for literal constraints on values that weren't being bound to a name.
A decision would also need to be made on whether the RHS of "?" constraints was permitted to be a full expression or not (e.g. if function calls were allowed, I believe there would be significant potential for confusion with class constraints).
Cheers,
Nick.