[pattern-switch] Totality

[Brian Goetz]

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

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

I think you need to back up and try to distill what you are actually 
worried about here.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20200828/262aaa00/attachment-0001.htm>