Next up for patterns: type patterns in switch

[Remi Forax]

On July 23, 2020 6:52:50 PM UTC, Brian Goetz <brian.goetz at oracle.com> wrote:
>
>
>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?

Yes, we agree.

>
>> 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.

I am worry about the whole complexity.

What about guard clauses with an order
switch(a) {
 case Object & a instanceof A -> 
 case Object & a instanceof B ->
}
Can the two cases be swapped ?

And the size of the JLS section that will explain how to compute the exhaustiveness. 

By example
switch(p) {
 case P & v >= 0 ->
 case P & v < 0 ->
}
Can be ok or not depending if v is an int or  a double.

or
switch(opt) {
  case Optional & opt.isPresent() ->
  case Optional & opt.isEmpty() ->
}

You will have to draw a line somewhere and because Java uses a lot of abstraction in libraries collection, optional, etc you may have to go pretty far.

>
>> 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.

var x and default are not on the same plane. So it's not really a third thing.
We are introducing something special for the bottom, null, but not for the top ?

Remi

--
On mobile