[pattern-switch] Totality

[Remi Forax]

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

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

sum type => product type 

> 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/20200829/40471f5b/attachment-0001.htm>