On 7/23/2020 2:38 PM, Remi Forax wrote:
Don't do deconstruction now ! We are not ready :)
Now I'm confused. Didn't I say exactly that in the first paragraph?
On guards, they do not work well with exhaustiveness. Still not sure
they are useful.
It works fine, it's just more work for the user to get right.
We induce a domination ordering on patterns. If `T <: U`, then `T t` <
`U u` (`T t` is less specific than `U u`.) Similarly, for all guard
conditions g, `P & g` < `P`. What this says is that if you want
exhaustiveness, you need an unguarded pattern somewhere, either:
case A:
case B & g:
case B: // catches B & !g
case C:
or
case A:
case B & g:
case C:
case Object: // catches B & !g
I understand your diffidence about guards, but I'm not sure we can do
nothing. The main reason that some sort of guards feel like a forced
move (could be an imperative guard, like `continue`, but I don't think
anyone would be happy with that) is that the fall-off-the-cliff behavior
is so bad. If you have a 26-arm switch, and you want the equivalent of
the second of the above cases -- B-but-not-g gets shunted into the
bottom clause -- you may very well have to refactor away from switch, or
at least mangle your switch badly, which would be pretty bad.
On nullity, I prefer the total pattern to be explicit instead of
implicit (given we have var, the type on the expression taken by the
switch can be fuzzy for someone doing a quick look to the code), case
any x, case _ x or whatever the syntax is, is more readable IMO.
It is unfortunate that `var x` is more fuzzy about types, but less fuzzy
about totality (`var x` is always total.) It is also unfortunate that
`default` can't be our "any" clause. Not sure that introducing a third
thing is helpful, though.
