Record in C# 9 (proposal)

[John Rose]

On Dec 7, 2019, at 11:37 AM, forax at univ-mlv.fr wrote:
> 
> not sure to follow ...
> given that we need to construct a new Record, so you have to write all the components of the new record anyway.

One bit you’re missing is simple:  If the old record already holds most of
the new record’s values, it is wasted effort (data motion, IR complexity)
to break up the old record into components just to put them back together
almost the same way.

(This objection can be handled almost as simply:  Make sure that the
indy BSM that handles with-methods makes it easier for the JIT to
swallow the request, by clearly identifying which components are
changed and which are not.  With indy we can reduce the practical
complexity by ensuring that the JIT sees stuff in the form it prefers.)

A deeper bit, not yet mentioned, is that records (and objects in general)
often apply special validation (error rejection) and normalization (e.g.
clipping or defensive copying) to new operands which they don’t apply
to values already stored in their fields.  We don’t have a way, yet, to
attach such logic to individual fields, but when we do, the cost of
breaking up and reassembling components will be nothing like your
description.  A canonical constructor will want to be accompanied by
a canonical *reconstructor* which has a tricky API surface (like I
mentioned) that can respond to a request to update any subset of
the record’s fields, leaving the others unchecked, and already
normalized.  (That’s what we call a proof by construction in math.)

We can start the ball rolling before we get field-specific constructor
logic and reconstructors per se, by pretending that the problem is
“only” data motion reduction, and designing reasonable reconstruction
translation strategies, based on indy of course.

Make sense?

— John