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.
