Cloning anything creates a new object of a known type (well, the runtime knows at least) and so if the object re-runs the init-properties of the known type then it will be the same as constructing that type afresh.

You could even imagine a compiler generated virtual method: `OnCloneReinitialiseFields()`, or something, that just re-ran the init-property setters (post clone operation).

Is there some other inheritance issue that is problematic here? Immutability isn't a concern, it's purely about what happens after cloning an object, whether the fields are immutable or not doesn't change the behaviour of the `with` operation.

The inheritance + immutability combination forces the compiler to use field-by-field copying rather than constructor chaining, which bypasses the property initialization logic that would maintain consistency between related fields.

I tend to agree. It’s always been my understanding that record types were strictly data holders and shouldn’t be embellished with behavior.

> SomeCalculatedValue in the second line still has the same value as in the first. This makes sense, as what happens when we use the with expression, is that the record is cloned and then the properties provided within the brackets are overwritten.

Shouldn't SomeCalculatedValue be "This is another some value *calculated*" when using with ?

Edit: Actually that is the problem, that it isn't "recalculating" due to the way that the initialization of read-only properties works in a C# record.

> wouldn't expect a clone

If I create a new object I would expect the 'init time' properties to be initialised. Regardless of how it was initialised. The current approach just leads to inconsistent data structures, with significant issues for debugging how a data structure got into an inconsistent state. Modern language features should not be trying to save nanoseconds like they did in the past. Or, should at least default to 'correct' with performance opts outs.

    using System;
    
    // same behavior with 
    // public sealed class Inner
    public struct Inner
    {
        public int Value { get; set; }
    }
    
    // same behavior with
    // public sealed record class Outer(Inner Inner)
    public record struct Outer(Inner Inner)
    {
        public bool Even { get; } = (Inner.Value & 1) == 0;
    }
    
    class Program
    {
        public static void Main(string[] args)
        {
            var inner = new Inner { Value = 42 };
    
            var outer = new Outer(inner);
    
            inner.Value = 43;
    
            Console.WriteLine("{0} is {1}", inner.Value, outer.Even);
        }
    }

> The behavior is expected

It isn't, that's why there's a blog article documenting how unexpected it is.

> that depend on mutable fields

The fields are not mutable. The `with` expression creates a whole new record, clones the fields, and then sets the field you're changing (the field is read-only, so this is the compiler going 'behind the scenes' to update the new record before it sets the reference). The reason for all this is performance: the new structure is allocated on the heap, a memcopy happens (old structure copied onto the new), and then the `with` changes are applied. It's just at this point the 'init time' properties aren't run on the new object.

In the language the fields are immutable. So, the argument is that a whole new record initialised with the fields of the old record (with some changes) should run the 'init time' properties so that they get set too, otherwise the data-structure can become inconsistent/poorly-defined.

> use a copy constructor instead

It's probably worth reading the article:

"Note that because Value is set after the cloning operation, we couldn’t write a copy constructor to do the right thing here anyway."

    private readonly Lazy<ComputedMembers> computed =
         new(() => new(Value), LazyThreadSafetyMode.ExecutionAndPublication);

> The biggest constraint was the schedule didn't support a new version of the .NET IL format (and reving the IL format is an expensive change for compat purposes, as well).

My biggest sadness reading this is that what MS have done is to outsource the issue to all C# devs. We will all hit this problem at some point (I have a couple of times) and I suspect we will all lose hours of time trying to work out WTF is going on. It may not quite be the Billion Dollar Mistake, but it's an ongoing cost to us all.

A possible approach I mentioned elsewhere in the thread is this (for the generation of the `with`):

    var n2 = n1.<Clone>$();
    n2.Value = 3;                  // 'with' field setters
    n2.<OnPostCloneInitialise>();  // run the initialisers

Then the <OnPostCloneInitialise>:

    public virtual void <OnPostCloneInitialise>()
    {
        base.<OnPostCloneInitialise>();

        Even = (Value & 1) == 0;    
    }

If the compiler could generate the <OnPostCloneInitialise> based on the initialisation code in the record/class, could that work?

That would just force the new object to initialise after the cloning without any additional IL or modifications.