Pattern Matching for switch (Second Preview)

[Gavin Bierman]

Hi Remi,

Just circling back to this suggestion of yours:

> On 22 Sep 2021, at 21:37, Remi Forax <forax at univ-mlv.fr> wrote:
> 
> And i think we should also fix the following
> 
> 4. a case that mix constants and a type pattern (or a guard) of a supertype of the types of the constants should be allowed
>   By example,
>     case 3, Integer i -> 
>   or
>     case 4, Object o ->

I’m not really convinced this carries its own weight. Both examples are a little odd as the type pattern subsumes the constant, so they don’t really offer much in terms of expressiveness. I tried following this train of thought and fiddled around with new ways of writing enum constant labels, but still the benefits seems modest at best, at least to me.

I think my main concern about this train of thought is that it is really tinkering at the level of switch labels. (I know we did something for null, but null is very special/annoying.) I believe it will be more profitable for us to consider better *patterns* in this area. For example, (nested) constant patterns - e.g. Point(=0, var y) - range patterns - e.g. Point(0..42, var y) etc.

Thanks,
Gavin