Non-copyable structs

[jbayardo]

There are cases where one is interested in having objects with few data members and a small amount of code to deal with them, but want to avoid copying.

A real use-case we had is a lock-free flag: we had a lot of places in the code base that used Interlock functions to basically set a bool to 0 or 1, or used Volatile in completely wrong ways. We created a struct that looks something like this:

public struct SingleUseFlag
{
    private int _state;

    public SingleUseFlag()
    {
        _state = 0;
    }

    public void RaiseOrDie()
    {
        if (Raise() == false)
            throw new InvalidOperationException($"Repeated Raise for a {nameof(SingleUseFlag)} instance");
    }

    public bool Raise()
    {
        return Interlocked.CompareExchange(ref _state, 1, 0) == 0;
    }

    public bool IsRaised()
    {
        return _state != 0;
    }
}

With a few inlined methods and some other things, in an attempt to make logic this less error-prone.

If you passed this struct as an argument to a function, a copy of the internal _state would ensue, and hence you would be keeping two separate flags. On the other hand, declaring this as a class adds the unwanted semantic of a shared flag, as well as unnecessary overhead for something that should be inlined and completely removed (although as a class it would be easy to prevent copying from happening).

In C++, this would be easily fixed by explicitly deleting the copy constructor, copy assignment, move constructor, and move assignment operators. It would be great to be able to specify a "this should never be copied" constraint for the struct in C#.

[HaloFour]

Considering that the copy behavior is the one major defining trait of structs in the CLR I don't really understand why (or how) you could eliminate that. Such a beast would be quite difficult to actually use since literally every assignment of a struct is a copy. How would you propose to actually use this data type? I don't see how it's possible to have both the lack of copying as well as non-shared state.

[kasajian]

You would pass the struct by reference. The point is that you may not accidentally invoke the copy-semantics without realizing it. Disabling it by default and have the code "opt-in" by using an entirely different method to do the copying would be the appropriate pattern in this case. C# has a lot of features today which at one time people claimed are not needed. This is one of them.

[Joe4evr]

So why is that a struct when it should logically be a class?

And you can forget using "muh allocations" as your answer. In Eric Lippert's words:

The relevant feature of value types is that they have the semantics of being copied by value, not that sometimes their deallocation can be optimized by the runtime.

[kasajian]

Joe, you're absolutely right for almost all code. But Eric Lippert's comment to all code. There are times when structs are used for performance. That's been done for ever by game developers using refs. Recently Microsoft has introduced more and more feature specifically for passing structs around by reference especially to facilitate this further. It's used in isolation, low-level code, for performance hot-spots. Ref locals and ref returns, in parameters, ref readonly methods, readonly structs and ref structs. Do you need to use this? Probably not, almost never. Are there legitimate use cases, yes, there are, probably ones that you might never run into. But they exist, and that's what we're talking about here.

[NickStrupat]

Eric Lippert was also against the using declaration/statement. He has a lot of very strong opinions.

[colejohnson66]

In .NET 9, objects can now be allocated on the stack. In some cases, this can avoid touching the heap entirely.

[Happypig375]

What about Swift behaviour that a struct is only copied when it is written to:
(Citing Swift on Wikipedia)

Similarly to C# and in contrast to most other OO languages, Swift offers built-in support for objects using either pass-by-reference or pass-by-value semantics, the former using the class declaration and the latter using struct...... To ensure that even the largest structs do not cause a performance penalty when they are handed off, Swift uses copy on write so that the objects are copied only if and when the program attempts to change a value in them.

[HaloFour]

@Happypig375

That's not automatic in Swift. That language has the same semantics as C#. To make a struct use CoW semantics you have to wrap it in a reference type. It's similar to String in the BCL. It is a reference type but also effectively immutable and modifications are performed through methods which copy and mutate the value.

https://marcosantadev.com/copy-write-swift-value-types/

[Happypig375]

@HaloFour If it were to be automatic, it would be very beneficial, and I don't think it would break existing code.

[HaloFour]

@Happypig375

Doesn't matter what mechanism of clean up that it's tied to, it still involves an allocation on the heap and passing that reference around. Doing such would have a drastic impact on the performance of existing code. Doing such automatically doesn't make sense in any language, including Swift. You either have reference semantics with shared state or you have value semantics with copying.

[tannergooding]

If you passed this struct as an argument to a function, a copy of the internal _state would ensue, and hence you would be keeping two separate flags

Why is ref or the upcoming ref readonly insufficient?

[tannergooding]

You may have a struct:

struct Size
{
    int x;
    int y;
}

You can then declare a method that takes this type as a parameter in several different ways:

void SetSize(Size size);                // C/C++: void SetSize(Size size)
void SetSize(ref Size size);            // C/C++: void SetSize(Size* size);
void SetSize(ref readonly Size size);   // C/C++: void SetSize(const Size* size);

The exact semantics of each depends on the underlying calling convention.
At least on Windows:

• The first shadow copies the struct to the stack and passes a reference to it (either in a register or on the
  stack, depending on which convention).
• The second and third do not shadow copy and just pass a reference to the struct (no shadow-copying).
  • The second allows the user to easily modify the original struct
  • The third prevents the user from modifying the original struct, unless they remove the readonly modifier (System.Runtime.CompilerServices.Unsafe) or if they remove the const modifier (C/C++, const_cast).

[Thaina]

I know the usage and think it's good, I like it, but I don't think this will really be used much to worth being feature

Still if this feature would develop I think we need to bring back C style constructor

Such as

fixed struct Vector3
{
    public float X,Y,Z;
}


Vector3 position(0,0,0);

[Happypig375]

@Thaina How is that any better than this?

struct Vector3
{
    public float X, Y, Z;
}

var position = new Vector3 { X = 0, Y = 0, Z = 0 };

With Records (#39) and target-typed new expressions (#100) this will become even better:

struct Vector3(float X, float Y, float Z);

Vector3 position = new(0, 0, 0);

[jnm2]

I've worked with C style constructors a number of times and I hate them. There's no way (besides non-compiler-checked comments) to notate which field each value goes to. Vector3 is a specially understood structure where that isn't an issue but in the majority of cases the clarity would be beneficial.

[Thaina]

@Happypig375 I mean if this 859 "Non-copyable structs" feature will be implemented. You cannot write

var position = new Vector3 { X = 0, Y = 0, Z = 0 };

Because that was copying new Vector3 into var position. So only C style constructor can make this kind of struct call its constructor

I just point out the fact that "Non-copyable structs" cannot call constructor by any of current C# syntax

[ufcpp]

In some case, mutable structs are very useful for obtaining high performance. For example:

• ResizableArray in corefxlab
• JsonWriter in Utf8Json, 441-stared very popular library

However, mutable structs are evil for now. Non-copyability of mutable structs are the most feasible solution for this evil issue.

[ufcpp]

@Thaina

Rust's memory ownership model solves such a problem.

static void Main()
{
    var p1 = new Vector3 { X = 0, Y = 0, Z = 0 }; // ownership is transferred from LHS to p1

    Write(p1); // OK. pass by reference

    var p2 = p1; // transfer ownership again

    Write(p2); // OK. pass by reference

    Write(p1); // NG. p1 no longer has ownership
}

static void Write(in Vector3 p)
{
    Console.WriteLine($"({p.X}, {p.Y}, {p.Z})");
}

[ufcpp]

see also:

• Destructible Types
• https://www.microsoft.com/en-us/research/wp-content/uploads/2017/07/snowflake-extended.pdf

[ufcpp]

I've created an analyzer for non-copyable structs: https://github.com/ufcpp/NonCopyableAnalyzer

[drewnoakes]

Why is ref or the upcoming ref readonly insufficient?

@tannergooding mutable ref structs are still subject to copying. Sometimes you want to enforce a single copy of some state, where it just happens to live on the stack.

An example would be a version of Lazy<T> that lives on the stack. Currently you can write:

public ref struct StackLazy<T>
{
    private readonly Func<T> _func;

    public T ValueOrDefault { get; private set; }

    public bool IsCreated { get; private set; }

    public StackLazy(Func<T> func) : this() => _func = func;

    public T Value
    {
        get
        {
            if (!IsCreated)
            {
                ValueOrDefault = _func();
                IsCreated = true;
            }

            return ValueOrDefault;
        }
    }
}

This will work within the current frame, or if you pass by ref, but as soon as you pass without ref the recipient has a copy and you can double-initialise the value. Having the compiler enforce non-copyability would provide correctness here.

Other examples might be scope-based utilities for nestable operations such as logging entry/exit, timing, etc.

The C++ equivalent would be a deleted copy ctor and assignment operator.

[tmds]

I like C++ RAII. I think a C# version would be a non-copyable struct that has a destructor(/Dispose method).

Maybe because non-copyable structs require passing by ref, that should be the default behavior: the ref keyword is implicit (because the struct is 'refonly').

[drewnoakes]

Another example, this time not stack-constrained. The issue for such types is the method of assigning fields initially, in the absence of something like C++ constructor initializer lists).

public nocopy struct DoubleCheckedLazy<T> where T : class
{
    private readonly Func<T> _func;
    private readonly object _lock;
    private T _value;

    public DoubleCheckedLazy(Func<T> func, object lock = default)
    {
        _func = func;
        _lock = lock ?? new object();
    }

    public T Value
    {
        get
        {
            if (_value == null)
            {
                lock (_lock)
                {
                    if (_value == null)
                    {
                        _value = func();
                    }
                }
            }

            return _value;
        }
    }
}

Usage in a type might then be:

public class Foo
{
    private readonly DoubleCheckedLazy<Bar> _bar;

    public Foo()
    {
        // this would have to not be considered a copy
        _bar = new DoubleCheckedLazy<Bar>(() => ExpensiveBarConstruction());
    }

    public Bar Bar => _bar.Value;
}

This can be done safely today if DoubleCheckedLazy<T> is a class, but if you want to avoid the allocation then the consumer of a struct form has to be so careful to not copy that it's more danger than it's worth.

I suspect that if we had nocopy structs then quite a few stateful programming patterns could be made reusable with zero additional cost.

It's probably simpler to allow nocopy ref struct than nocopy struct. It's probably simpler to make it a compiler restriction than a runtime one.

[ceztko]

Are "non-copyable structs" actually coming anytime soon? I don't see a champion for them. The poster use case has some uses but the fact you can really turn the struct into a class at the cost of making it shared seems like a good balance between what you can achieve with encapsulation and the need to keep the number of features into the language to not grow indefinitely (similarly to the balance achieved introducing the internal access modifier: sometimes you can't create coupled classes that are fully safe to use within the same assembly boundary, but it's usually considered not a big deal). Instead I don't think the C++ RAII motivation to add such feature to C# super strong: sure, C++ can disable copy, but it also has guarenteed copy elision and move semantics, which make it very comfortable to create guards, transactions or resource cleaners in general and pass them trough different boundaries, which would not be easily available in C# (not part of the language, at least). For RAII purpose I suggest to extend warning for Dispose method not being called in structs, as I discuss better in #1110.

[Joe4evr]

Are "non-copyable structs" actually coming anytime soon? I don't see a champion for them.

As long as there's no Champion on the language team, the answer is pretty much guaranteed to be "No".

[tmds]

move semantics

This should be considered also for non-copyable C# structs.

[redradist]

This proposal can be achieved with my proposal with RAII and delete copy constructor ...
Single feature multiple benefits

RAII C#: #4808

Example how it could be implemented:

public struct Handle
{
    public Handle()
    {
      ...
    }
    ...
    // Delete copy constructor
    public Handle(in Handle handle) = delete;
    ...
}

[ceztko]

After initially having partially advocated against more advanced value types language support, I suddenly changed my mind in the middle of some advanced native interop scenarios. The problem is that one would need all the C++ features "pack" at once: non-copyable structs, destructors and move semantics, maybe others. While I feel/hope this could be done in a compact C# way, the fear that attempting to introduce such features turns into mimicking the huge syntax complexity of C++ is high.

[ghost]

I just need non-copyable structs. I think move semantics and destructors is optional, not required.

[redradist]

@X-maple

I just need non-copyable structs. I think move semantics and destructors is optional, not required.

Such thinking only about some particular feature and not considering other makes all of them inconsistent with each other.
It should be consistent set of features, otherwise C# will become like Perl where user can do the same thing in 100 ways !!

[ghost]

I like non-copyable structs, don't like move semantics and destructors.
Because I think move semantics and destructors will make struct more complex.
Unless you add a new value type, not struct.

[ceztko]

I think move semantics and destructors will make struct more complex.

As usual, C# is not pretending programming is easy. The point would be introducing advanced struct features in a elegant/non redundant way.

No, C++ syntax complexity not due to these features

I know there are features way more complex than move semantics (eg. variadic templates). What I meant is, for example, that it would be very uncomfortable have to define both assignment and move constructor as it happens now in C++. For this scenario I would appreciate C# to help me reducing the amount of boilerplate code.

[ghost]

I think move semantics and destructors will make struct more complex.

I think non-copyable struct should be a subset of struct.
But if non-copyable struct has destructor, non-copyable struct will be not a subset of struct, beacuse struct doesn't support destructor.

[colejohnson66]

This is such a niche problem, I'm not sure having a built-in solution is a good idea. Also, with modern C# tooling, an analyzer could be written to enforce usage of in or ref on all usages of the struct.

If you're lazy, .NET 9's new stack-allocated objects could help with performance of a class solution.

[timcassell]

It may be niche, but it can prevent a class of problems. For example, it's almost certainly a bug to pass a SpinLock by value. If the runtime were to add more value types that are unsafe to pass by value (like perhaps a ValueAtomic<T>), it would be more palatable if the language prevents misuse.

Stack-allocated objects doesn't help for types that are intended to be fields (like SpinLock).

[jilles-sg]

Stack-allocated objects doesn't help either if the type is a ref struct, such as to use a caller's stackalloc buffer or to avoid thread-safety issues. An example is the internal ValueStringBuilder.