On Aug 28, 2021, at 2:42 PM, Remi Forax
<fo...@univ-mlv.fr<mailto:fo...@univ-mlv.fr>> wrote:
I think we should revisit that discussion and just not introduce the any
bindings in that case so the example above will compile but "literal" or
"funcall" are not added as local variable.
Some partial comments:
Allowing inconsistent/inaccessible binding names here
as a particular workaround would be a sharp edge,
since users would wonder where such a variable went,
and why they can’t use it.
I think this is really a feature-request for a type-only
pattern (with no binding). And having “T _” is a fine way
to bikeshed it.
That said, the next feature request in that vein would be
to allow variable-bindings (as today) for the sake of guard
expressions, and then we are back to the problem you cite.
Hmm… I guess the sharp edge has cause to stay, for the sake
of guard logic like this:
case Literal l && someGuard(l), FunCall f && someOtherGuard(f) -> …
So I’m sympathetic with your request. It’s really about
smuggling OR-expressions into switch-guards. Which isn’t
terrible at first.
A third request in this vein is for combining bindings
from arms of an OR-expression. That’s when it gets
more terrible:
case Literal lorf && decon1(l, n), FunCall lorf && decon2(f, n) -> {
lorf is an intersection type, and maybe n is int
if decon1/2 collude to make it so
}
Assembling one binding from several OR-branches
seems to be a requitable feature, but one that would
be really hard to make rational and predictable.
— John
