Records: migration compatibility

[Brian Goetz]

In the course of exploring serialization support for records, Chris 
asked about the compatible evolution modes for records.  We have 
explored this briefly before but let's put this down in one place.

Since we are saying that records are a lot like enums, let's start with:

  A. Migrating a record-like class to a record
  B. Migrating a record to a record-like class

(which is analogous to refactoring between an enum and a class using the 
type-safe enum pattern.)

Migration A should be both source- and binary- compatible, provided the 
original class has all the members the record would have -- ctor, dtor, 
accessors.  Which in turn requires being able to declare the members, 
including dtor, but we'll come back to that.

What about serialization compatibility?  It depends on our serialization 
story (Chris will chime in with more here), but its fair to note that 
while migrating from a TSE to an enum is not serialization compatible 
either.

Migration B is slightly more problematic (for both records and enums), 
as a record will extend Record just as enums extend Enum. Which means 
casting to, or invoking Record methods on, a migrated record would 
fail.  (Same is true for enums.)  Again, I'll leave it to Chris to fill 
in the serialization compatibility story; we have a variety of possible 
approaches there.

What about changing the descriptor of a record?

  C.  Removing components
  D.  Reordering components
  E.  Adding components

Removals of all sorts are generally not source- or binary- compatible; 
removing components will cause public members to disappear and 
constructors to change their signatures.  So we should have no 
compatibility expectations of C.

D will cause the signature of the canonical ctor and dtor to change.  If 
the types of the permuted components are different, it may be possible 
for the author to explicitly implement the old ctor/dtor signature, so 
that the existing set of members is preserved.  However, I think we 
should describe this as not being a compatible migration, even if it is 
possible (in some cases) to make up the difference.

E is like D, in that it is possible to add back the old ctor/dtor 
implementations, and rescue existing callsites, but I think it should be 
put in the same category.