Draft Object Serialization Specification for records - construction/destruction

[Brian Goetz]

> You are not wrong. In fact, I had the very same thought ( and the implementation does similar ), but we want to leave room here for deconstructors/extractors. With the wording in the current draft, it will be possible to switch the implementation without the need to update the specification.

I think there is room to support the future.  Here are some ways we 
could extract the state from a record for serialization:

  A. Scrape the fields.
  B. Call the field accessors.
  C. Invoke the canonical deconstructor (when we have them.)
  D. Invoke a serialization-specific pattern if there is one (when we 
support them.)

Note that in a case of `record R(...) { }`, these are all the same -- 
the default accessors return the field values, and the default canonical 
deconstructor invokes the accessors.

Clearly, if the user provides an explicit serialization member (whatever 
that looks like), we should use that in preference to "default" 
serialization; this is true for classes and records alike, it's just 
that the default behavior differs between classes and records.  So when 
we get to New And Improved Serialization, D presents no migration 
problem; we can say "if there is a serialization pattern, use that, 
otherwise..."

We can make the same argument for C, since in the absence of an explicit 
dtor, which you can't write now, what you'd get from an implicit dtor is 
the result of B.  Same story: "if there is a canonical ctor, use that."

The real question is A vs B.  One can make an argument that 
serialization is about raw object state, which means that field-scraping 
is OK.  Or one can make the argument that we are trying to make 
serialization safer, so we should prefer the accessor (when there is 
one.)  Most of the time, though, if there is a nontrivial accessor, all 
it will do is make a copy (say, if the corresponding component is an 
array), so going through the accessor is a bit of a wasted effort.