So far, we've taken a middle-of-the-road position on records and
serialization, where we generate a `readResolve()` method that pipes the
at-rest state through the canonical constructor, to gain the benefit of
validation checks. Some have argued to do less, but I think we can do a
little more, and in light of the direction outlined earlier today for
serialization, we should do more.
The semantics of a record are that we derive all of an object's standard
protocols -- construction, deconstruction (whether through pattern match
or accessors), equality, hashing, and string representation -- from the
state description. Deriving the serialization protocol from the state
description similarly makes sense. Which would mean: the state
description is also the serialized form. So not only do we want to
generate a readResolve() method as we currently have, but we probably
want to prohibit specifying explicit readResolve(), readObject(), and
writeObject() methods (and other serialization knobs) on Serializable
records -- the canonical constructor should be the line of defense
against bad data for both the front-door and back-door APIs.
This also, as it turns out, yields the serialization protocol we'd get
if we implicitly marked the canonical constructor with `@Deserializer`
and the canonical deconstruction pattern with `@Serializer`, as per the
doc dropped today.
