Some days back Mark Shannon posted his view/proposal pattern matching on github. While reading it I realised an intermediate step between matching and variable assignment might do away with part of the discussion. I wrote it in an issue with the view/proposal (https://github.com/markshannon/pattern-matching/issues/1)
Thinking about it a bit longer, it really might be worth exploring the idea more, so let me repeat it here: 1. In a pattern the values to match are marked with a special symbol (‘$’, ‘!’ or ‘?’ seem candidates). 2. A matching case produces a tuple of matched values. The tuple may be nested to reflect the matched structure. 3. The tuple may be deconstructed according to the usual rules.
As an example:
example_value = Example("bar", Embedded(None, "foo"), 42, "baz")
match example_value: case Example($, Embedded($, "foo"), 42, $) as t: # t = ("bar”, (None, ), "baz”) pass case Example($, Embedded($, "foo"), 42, $) as pre, *rest: # pre = "bar", rest = ((None, ), "baz”) pass
match example_value: case pre, *rest = t = Example($, Embedded($, "foo"), 42, $): # pre = "bar", rest = ((None, ), "baz”) # t = ("bar”, (None, ), "baz”) pass
Just my $0.02
I don't love the way it moves the variable name away from the capture location, but it does offer a decent solution for anonymous placeholder variables (other than _ or __), and makes it clear which variables are being bound (only those in front of an = sign) vs limiting potential matches (anything after the = sign)