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