On 12/4/20 11:15 AM, Jim J. Jewett wrote:
To be more specific, I'm not sure what is intended for the 2nd or 3rd case below, which reuse a variable "bound" by the first (failed) match. Nor am I sure whether it matters that the first match fails on the guard predicate, instead of immediately on the match.
Here's my understanding of it:
case (a, b, c) if f(): # assume f() returns false
a, b, and c and are initially bound from matches to the object in question, whether they remain bound after f() fails is implementation dependent and should not be relied upon
case (a, b) if a == c: # is a still bound from case above? Is that implementation-dependent?
a and b are initially bound from matches to the object in question, and the `a` in `a == c` has that new value; `c`, however, could be the `c` from the first, failed, match -- presumably this is simply a bug in the above match block because it seems like a bad idea to overwrite an already present variable (`c` in this case) in a first match when later matches depend on it.
case (d = a): # is a still bound from case above? Is that implementation-dependent? Is it even still possible to put restrictions in before the guard clause, like d=4?
`a` is bound to the `d` attribute of the match object.
The implementation defined aspect is whether names remain bound after match and/or guard failures. In the above code that uncertainty only affects the name `c` as it's the only one used both inside one match and in a guard in a different match.