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.
