I don’t think my personal views on that EEP have changed since the github thread:
I like the current idea that I can reuse a previously bound variable in a
case (or any other conditional) expression’s clauses. It gives more power to pattern matching, in a way that I prefer to the accidental risk of blocking a match unintentionally.
I would in fact prefer if the
^ operator was used to say “in this specific case, I want you to rebind the value” – allow control to rebind, but keep a pattern match as the default.
I do agree that the shadowing in funs is annoying and working the guard is more work than ideal.
My sense about the language is that scoping rules in general are a bigger burden, namely that the variables bound within a
receive, and now
maybe) expression are bound outside of that expression. At least the compiler catches times where it’s not safe to reuse, but I find that more confusing than the re-matching
I think that addressing the ability to rebind in these conditional clauses patterns but without addressing the current scope (or lack thereof) of these expressions actually increases language complexity rather than decreasing it.
Giving these block expressions their own scope would spread that
fun ghosting issue, which I think should be tackled independently, and in that world, using
^Var to mean “Grab the value from the parent scope” would possibly make more sense.
But with the absence of a fixed scope, I don’t think the
^ from the EEP should be allowed anywhere but in places where you currently get shadowing warnings, which I believe is
funs, list comprehension generators, and nowhere else, and both of this is mostly simplifying having to pin the value with a guard.
The advantage of also keeping it only with warnings is that you could introduce the feature almost purely via these warnings. Of course you’d want documentation and whatnot, but it creates an interesting self-contained mechanism where shadowing tells you about the
^, and so does removing the
^ end up explaining what it does.
You could also safely add a warning or error when the
^ is used outside of where it makes sense (
"the '^' captures elements from the parent scope when there would otherwise be shadowing, but there is either no parent scope or no shadowing occurring") This is a bit more discoverable and usable than allowing it on any random pattern or head.
But in the form the EEP had, I’m unexcited about it and feel it makes things more complex than they are.