[pattern-switch] Totality

[forax at univ-mlv.fr]

> De: "Brian Goetz" <brian.goetz at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Guy Steele" <guy.steele at oracle.com>, "amber-spec-experts"
> <amber-spec-experts at openjdk.java.net>
> Envoyé: Vendredi 28 Août 2020 21:40:02
> Objet: Re: [pattern-switch] Totality

>>> I don't recall agreeing to anything like this, so perhaps you can dig up a
>>> reference, and I can try to reconstruct what I thought I was agreeing to?
>> [ https://cr.openjdk.java.net/~briangoetz/amber/pattern-match-translation.html |
>> https://cr.openjdk.java.net/~briangoetz/amber/pattern-match-translation.html ]
>> section Migration Compat

> Haha, OK. Yes, that was a first draft from before we really understood the
> problem. In light of further exploration and understanding, I'm fine to see
> that particular sentence go under the bus. It was a reasonable
> stake-in-the-ground about compatibility given what we knew at the time.

>> It should not be affected by compatible changes, obviously, the question is what
>> a compatible change is.
>> Compatible changes and a switch being total are intertwined,

> Realistically, any significant change in the type hierarchy is likely to be
> incompatible. Consider:

> case SonOfFoo:
> case Foo:

> If we change from Foo extends SonOfFoo to the opposite, compiled switches won't
> work the same way. Oh well.
yes, 
hierarchy changes can be checked once at runtime but i'm not suggesting that, 
in my opinion, a cascade of if ... instanceof and a switch on types should have the same constraints, we can evaluate if we want to catch more errors at runtime but i think you should first to sure we have the same constraints as a if ... instanceof. 

>> If a case like case Pixel(var x, var y, var color) is total, and if x and y are
>> not used, having the type of x and y implicitly encoded in the bytecode makes
>> the refactoring from impossible,
>> thus the type on any inner pattern that follows a destructuring can only be
>> tested at runtime. Otherwise you will have a lot of ICCE that will be thrown
>> spuriously.

> What? Changing the signature of a member to use completely unrelated types is a
> refactoring that happens "a lot"? Makes no sense. (Nor can it reasonably be
> expected to be compatible.)
It's not rare to add components to a sum type, by example a MouseEvent is upgraded to add the number of mouse wheel scroll knobs. 

Again, it should work like a cascade of if ... instanceof, so 
case Pixel(var x, var y, var color) -> color 
should be equivalent to 
if x instanceof Pixel p { yield p.color() } 
or if its a total pattern 
Pixel p = x; 
yield p.color(); 

As you see there is no constraint on the other components of a Pixel apart on color. 

Rémi 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20200828/8c6ff204/attachment.htm>