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.
