> De: "Brian Goetz" <brian.go...@oracle.com>
> À: "Remi Forax" <fo...@univ-mlv.fr>
> Cc: "Guy Steele" <guy.ste...@oracle.com>, "amber-spec-experts"
> <amber-spec-experts@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
