Record with keyword used with inheritance seems to replace the reference with it's own

[bogdan-patraucean]

I think I discovered an issue with how records work in combination with inheritance. Updating an object and making a copy of it using the with keyword will replace the old reference of the base class with it's own (the derived class).

To showcase this we need 3 classes, and as example (fiddle here) I chose state management:

• an abstract record GenericState class to define what a state is
• a State class where we will store all our data
• a Substate class that's part of the State (which is the root/parent)

public abstract record class GenericState
{
  public GenericState? Parent {get; init; }
  
  public abstract string Name {get; }
  
  public GenericState(GenericState? parent)
  {
    this.Parent = parent;
  }
}

public record class Substate: GenericState
{
  public override string Name => "Child";
  
  public int Property {get;set;}
  
  public Substate(State parent): base(parent) { }
}

public record class State: GenericState
{
  public override string Name => "Parent";
  
  public State(GenericState parent): base(parent)
  {
    child = new(this);
  }
  
  private Substate child;
  public Substate Child
  {
    get => child;
    init
    {
      if (child == value)
      {
        return;
      }
      
      child = value;
    }
  }
}

And here is what I do, I create a state with a child, and I specify the parent to the child so it always knows who the parent is. The state will not have any parent so I initialize it with null since it's the root. When I try to update the state by updating the child's property to 4 the reference to the parent will be replaced with the reference of the child.

So, the first log to console will display Parent, while the second will display Child, tho, with should copy everything as is.

var state= new State(null);
var newState = state with { Child = state.Child with { Property = 4 } };

Console.WriteLine(state.Child.Parent.Name);
Console.WriteLine(newState.Child.Parent.Name);

Am I doing something wrong? For me this seems like an issue, as I would expect the reference to be kept, not replaced.

Note

The same example without the abstract record class works as expected (fiddle here).

[HaloFour]

You're using with on the Child, so it is expected to be replaced with the new modified instance. Is that not what you're seeing?

[333fred]

Halo is correct. When you manually override the copy constructor like this, you get what you implemented.

[HaloFour]

I can see where it would be confusing, especially if you're not aware that records rely on a copy constructor or that you can override it. Positional records do appear to forbid declaring a primary constructor that only accepts the record type as the only argument, but there's no guardrails for non-positional records. But given it's something that some developers will want to do intentionally it certainly doesn't feel like it should emit a warning either.

[bogdan-patraucean]

And how could I avoid this and obtain the behavior I need? Not using inheritance works in the same way.

[HaloFour]

I think you'd might need to use the init property to set the Parent state. If that doesn't enforce the contract you want you might need to use a static factory method to create new instances of the state. Or if there is other required state you can include that parameter in the constructor so it's not confused with the copy constructor.

[huoyaoyuan]

When you manually override the copy constructor like this, you get what you implemented.

I'd like to see some IDE support that tells you this will be used as copy constructor. Users not familiar with records may not even be aware to find the doc about this.

[bogdan-patraucean]

I confirm that adding another parameter to differentiate itself from the copy constructor of the record achieves what I want. Thanks @HaloFour for pointing this out, an updated fiddle can be found here. Tho, a question still remains: do we want the copy constructor to be overriden so easely and by mistake?

Is there nothing we can do to prevent that?

[Richiban]

It may be because your example has been reduced, but I don't see why you've written your own constructors for these types at all. Did the primary constructors not give you some functionality you wanted?

[bogdan-patraucean]

I'm not sure I follow you. Primary constructors only allow public properties, they should not be used in combination with abstraction just for the sake of it. There are some limits and using them doesn't really link to my issue which is with records.

[HaloFour]

I guess the question is that the example in your OP could have been written to use primary constructors. There may be other aspects that were reduced out that would have precluded this. However, attempting to use primary constructors would have run into the error that the primary constructor and copy constructor would have collided.