[Proposal]: Allow with keyword for classes containing constructor expecting itself

[gumbarros]

Allow with keyword for classes containing constructor expecting itself

• Proposed
• Prototype: Not Started
• Implementation: Not Started
• Specification: Not Started

Summary

Enable the use of the with keyword for classes that contain a constructor expecting an instance of the same class, allowing for non-destructive mutation similar to records.

Motivation

Currently, the with keyword is only available for record types in C#. This proposal aims to extend this functionality to regular classes, given that they have a constructor that takes an instance of the same class. This will enable developers to create new instances of a class with modified properties without affecting the original instance, promoting immutability and reducing boilerplate code.

Detailed design

Syntax

The syntax for using the with keyword in classes will be similar to that in records:

public class Person
{
    public string FirstName { get; }
    public string LastName { get; }

    public Person(string firstName, string lastName)
    {
        FirstName = firstName;
        LastName = lastName;
    }

    public Person(Person other)
    {
        FirstName = other.FirstName;
        LastName = other.LastName;
    }
}

var person1 = new Person("Gustavo", "Mauricio");
var person2 = person1 with { LastName = "Barros" };

Console.WriteLine(person1); // Output: Person { FirstName = Gustavo, LastName = Mauricio }
Console.WriteLine(person2); // Output: Person { FirstName = Gustavo, LastName = Barros }

Semantics

• The with expression creates a new instance of the class.
• It uses the constructor that takes an instance of the same class (Person(Person other) in the example above) to copy properties from the original instance.
• Only the properties specified in the with expression are modified; all other properties are copied from the original instance.

Specification Changes

Changes are required in the following sections of the C# language specification:

• Expressions: Introduce the syntax and semantics of the with keyword for classes.
• Classes: Define the requirements for a class to support the with keyword, specifically the need for a constructor that takes an instance of the same class.

Drawbacks

• Increased complexity in the language specification and compiler implementation.
• Potential for misuse if developers are not aware of the immutability principles.

Alternatives

• Continue using manual copy constructors and property assignment.
• Utilize records instead of classes where non-destructive mutation is required.

Unresolved questions

• Should there be additional constraints or best practices for the implementation of the copy constructor to ensure consistency and prevent unintended side effects? Can a interface like ICloneable be used?
• How will this feature interact with inheritance and polymorphism in classes?

Design meetings

None yet.

---

[gumbarros]

Sorry, saw that a discussion needs to be created first just now, any maintainer please feel free to convert this to a discussion.

[Zastai]

How would the compiler know that such a constructor is a “copy constructor”?

Consider Employee(Employee lineManager) or LinkedListNode(LinkedListNode next). You can’t retroactively enforce semantics on constructors of that shape.

With ICloneable, perhaps - or a tagging interface or attribute (ICopyConstructible/[CopyConstructible]) letting the author make the semantic claim (but then why not write a record in the first place).

[gumbarros]

An attribute sounds a good idea

[ChadNedzlek]

I don't see what the value of tying it specifically to constructors is. Especially with an interface, implementing ICopyConstructable<TSelf> { TSelf Copy(); } seems like a more direct way to indicate what you want (and means you can also have Employee(Employee manager) AND still be copyable)

[jaredpar]

How will this feature interact with inheritance and polymorphism in classes?

In my opinion this is one of the key problems to think about. The with in record works across inheritance hierarchies and it would be likely surprising if this version didn't as well.

The problem with using the constructor is that there is no virtual dispatch so it will not work polymorphically:

public class Person { ... }
public class PersonWithAge(string firstName, string lastName, int age) 
  : Person(firstName, lastName) 
{
    public int Age { get; } = age;
}

Person person1 = new PersonWithAge("Jared", "Parsons", TooOld);
var person2 = person1 with { LastName = "Oops" };

In this case the with expression actually fairly fundamentally changed the object: instead of being a PersonWithAge it is now a Person. In order for it to copy the running instance there needs to be a virtual method involved. This is how record work under the hood. There is a virtual method that is unspeakable that acts like a constructor of sorts.

The idea of generalizing this to all classes was discussed when we did record initially. The rough concept we had was factory methods. There are some notes available you may be interested in:

• https://github.com/dotnet/csharplang/blob/main/meetings/2020/LDM-2020-04-20.md
• https://github.com/dotnet/csharplang/blob/main/meetings/2020/LDM-2020-05-04.md#factory-methods
• https://github.com/dotnet/csharplang/blob/main/meetings/2020/LDM-2020-07-01.md#confirming-unspeakable-clone-method-implications