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 

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.

Reply via email to