When several patterns are total ?

[forax at univ-mlv.fr]

> De: "Tagir Valeev" <amaembo at gmail.com>
> À: "Brian Goetz" <brian.goetz at oracle.com>
> Cc: "Remi Forax" <forax at univ-mlv.fr>, "amber-spec-experts"
> <amber-spec-experts at openjdk.java.net>
> Envoyé: Dimanche 30 Août 2020 16:55:14
> Objet: Re: When several patterns are total ?

> Interesting!

> How about

> try {...}
> catch(Ex1 | Ex2 e) {
> switch (e) {
> case Ex1 -> ...
> case Ex2 -> ...
> }
> }

> ?

I also wonder if the precise exception trick should work: 

try { ... } 
catch(IllegalAccesException | NoSuchMethodException e) { 
throw switch(e) { 
case ReflectiveOperationException e -> e; 
}; 
} 

from the POV of the compiler, it's like throwing IllegalAccesException | NoSuchMethodException and not ReflectiveOperationException. 
so the code can be refactored to 
try { ... } 
catch(IllegalAccesException | NoSuchMethodException e) { 
throw e; 
} 

> With best regards,
> Tagir Valeev.

Rémi 

> вс, 30 авг. 2020 г., 21:38 Brian Goetz < [ mailto:brian.goetz at oracle.com |
> brian.goetz at oracle.com ] >:

>> ,
>>> i've hinted that there is an issue with intersection type and totality, but we
>> > did not follow up.

>> > Here is the issue
>> > var value = flag? "foo": 42;
>> > switch(value) {
>> > case String s -> ...
>> > case Integer i -> ...
>> > case Serializable s ->
>> > case Comparable<?> c ->
>> > }

>>> given that the type of value is an intersection type Serializable &
>> > Comparable<?> & ...
>>> the last two cases are total with respect to the type of value. which does not
>> > go well with the current semantics that can only have one total case.

>> Let’s separate the issues here. The type involved is an infinite type, which I
>> think we can agree is a distraction. But lets assume the type of value were
>> Serializable&Comparable (S&C for short.)

>> Because S&C <: S, the `case S` in your example is already total, so the `case C`
>> should be a dead case and yield a compilation error. According to the rule we
>> have, `case S` is total on any U <: S, so it is total on S&C, so the current
>> model covers this, and the `case C` is identified as dead by the compiler.
>> Which makes sense because there’s no value it can match.

>> I’m not seeing the problem?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20200831/976bd2a3/attachment.htm>