> De: "Remi Forax" <fo...@univ-mlv.fr> > À: "Brian Goetz" <brian.go...@oracle.com> > Cc: "Guy Steele" <guy.ste...@oracle.com>, "amber-spec-experts" > <amber-spec-experts@openjdk.java.net> > Envoyé: Vendredi 28 Août 2020 23:59:55 > Objet: Re: [pattern-switch] Totality
>> 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. 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
