[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 15:45:41
> Objet: Re: [pattern-switch] Totality

>> While i agree with the general idea, i disagree with the fact that the compiler
>> should handle the null and total cases, it can not handle the total case, it
>> has to be handled by the by the runtime, not the compiler.

>> I will use '?' for the total type, by example this switch is "total enough"
>> sealed interface Stuff permits Pixel, Car {}
>> record Pixel(int x, int y, Color color) implements Stuff {}
>> record Car(Color color) implements Stuff {}
>> switch(stuff) {
>> case Pixel(? x, ? y, Color color) -> color;
>> case Car(Color color) -> color
>> }

>> We have agreed during one of our first meetings that we want that if Pixel is
>> changed to record Pixel(BigInteger x, BigInteger y, Color color) {} with or
>> without recompilation of the switch it should be Ok.

> 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 

> It seems that you are arguing that the use site of a pattern match should be
> unaffected by (possibly incompatible) changes in the declaration of the
> pattern. But this can't possibly be what you are suggesting.
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, 

> (If you want to have a conversation on what declaration changes are behaviorally
> compatible, that is a fine conversation!)

>> That doesn't mean that '?' can not be spelt 'var', but it demonstrates that the
>> corner cases should be managed by the runtime, not the compiler.

> I don't understand what you mean by this distinction. The compiler identifies
> the corner cases, and generates runtime code to handle them, just like it does
> with expression enum switches today.
My point is that a some patterns like the type pattern is a runtime check. 
If for a total pattern being total is a runtime property and not a compile time property. 

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. 

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