Copy constructors

[hez2010]

Motivation

While experimenting with compound assignment operators in C# 14, I found a severe problem that with structs it's impossible to properly implement in-place updates for structs because of the copy semantic coming with structs.

Taking the following code as an example,

using System;

class Program
{
    static void Main()
    {
        var foo = new Foo();
        var bar = foo;
        foo += 4;
        Console.WriteLine(foo.Value); // 4
        Console.WriteLine(bar.Value); // 4
    }
}

struct Foo
{
    private int[] _array;

    public Foo()
    {
        _array = [0];
    }

    public void operator += (int x)
    {
        _array[0] += x;
    }

    public int Value => _array[0];
}

Here foo is copied to bar, and the following += is operated on foo. But foo and bar shares the same _array so that you cannot properly implement in-place updates for Foo. BigInteger will suffer from exactly the same problem.

Copy constructors

Here I propose to introduce copy constructors. A copy constructor is a constructor that takes a ref (or a readonly ref) of the containing type. For example:

public Foo(in Foo other)
{
}

When the compiler sees any assignment from the same type, it emits a call to the copy constructor if there's one, so that var bar = foo becomes var bar = new Foo(in foo).

And when the compiler sees a struct implementing a compound assignment operator, it should warn the user to implement a copy constructor if there isn't any.

The implementation of Foo will be:

using System;

class Program
{
    static void Main()
    {
        var foo = new Foo();
        var bar = foo; // var bar = new Foo(in foo)
        foo += 4;
        Console.WriteLine(foo.Value); // 4
        Console.WriteLine(bar.Value); // 0
        Test(bar); // Test(new Foo(in bar))
        Console.WriteLine(bar.Value); // 0
    }

    static void Test(Foo foo)
    {
        foo += 4;
    }
}

struct Foo
{
    private int[] _array;

    public Foo()
    {
        _array = [0];
    }

    public Foo(in Foo other)
    {
        _array = Copy(other._array);
    }

    public void operator += (int x)
    {
        _array[0] += x;
    }

    public int Value => _array[0];
}

But with this approach we may need runtime support to achieve proper behavior for generics, for example:

void Test<T>(T foo) where T : IFoo
{
    var bar = foo; // need runtime support
    foo += 4;
    Console.WriteLine(bar.Value);
}

interface IFoo
{
    void operator += (int x);
    int Value { get; }
}

struct Foo : IFoo
{
    public void operator += (int x) { ... }
    public int Value => ...;
}

Alternatives

An alternative is to allow overloading assignment operator =.

static TSelf operator=(in TOther foo) { ... }

Now we can finally implement in-place updates for structs properly:

using System;

class Program
{
    static void Main()
    {
        var foo = new Foo();
        var bar = foo; // var bar = Foo.operator=(in foo)
        foo += 4;
        Console.WriteLine(foo.Value); // 4
        Console.WriteLine(bar.Value); // 0
    }
}

struct Foo
{
    private int[] _array;

    public Foo()
    {
        _array = [0];
    }

    public static Foo operator=(in Foo other)
    {
        return new Foo { _array = Copy(other._array) };
    }

    public void operator += (int x)
    {
        _array[0] += x;
    }

    public int Value => _array[0];
}

And when the compiler sees a struct overloading a compound assignment operator, it should warn the user to overload the assignment operator.

In generic context, the compiler should emit operator= if the generic type has an available implementation of operator= in the generic constraints:

void Test<T>(T x) where T : IAssignmentOperators<T, T>
{
    T y = x; // y = T.operator=(x);
}

struct Foo : IAssignmentOperators<Foo, Foo>
{
    ...
}

interface IAssignmentOperators<TSelf, TOther>
{
    abstract static TSelf operator=(in TOther other);
}

However, this won't be sufficient to resolve all the issues, for example:

Foo foo = new Foo();
Test(foo);
Console.WriteLine(foo.Value); // 4

void Test(Foo foo)
{
    foo += 4;
}

So ultimately, we would still need copy constructors.

cc: @AlekseyTs

[timcassell]

Wouldn't this be a breaking change for structs that already have a ctor of that shape?

[hez2010]

I added an alternative that allows user-defined assignment operator to mitigate this problem.

[hez2010]

user-defined assignment operator won't be enough btw, we still need copy constrcutors.

[huoyaoyuan]

I haven't thought about this in depth, but is this enough? Do we also need move semantic/borrow check etc. to make this safe?

[HaloFour]

This also falls apart with generics, or anywhere a struct would be assigned outside of the language's control.

[tannergooding]

While experimenting with compound assignment operators in C# 14, I found a severe problem that with structs it's impossible to properly implement in-place updates for structs because of the copy semantic coming with structs.

I wouldn't call this a severe issue. It's not blocking at all either.

You get the same issue with all mutable structs or structs that can mutate their indirect contents. That is, you get the same "issue" with myStruct.Add(other).

For existing structs, like BigInteger, there is a consideration of how it can impact existing code on recompile and whether it can introduce a behavioral change. It is not an issue for new structs, like the TensorSpan types, nor for types providing such APIs via extension methods, or for many other scenarios where the underlying data was already mutable via certain APIs.

[AlekseyTs]

It feels like implementation of the operator should account for the fact that array could be used elsewhere, and not be as simple as _array[0] += x; Perhaps, it should allocate a new array and do something like _array = [_array[0] + x];. Or, quite possibly, it is simply not appropriate to implement a compound assignment operator on a struct like that. Either way, I think a user has all the tools at hand and no additional language support is necessary.