Proposal: Struct based RAII in C# (Copy constructor, Move constructor, Destructor)

[redradist]

Overview

One feature I miss a lot RAII like in C++
You will ask why ? C# already have using for resource ...
using for resources has one drawback it should be used only in on method, but what if I want:

1. To pass resource somewhere and then it will not be used by anyone to dispose it deterministically !!
2. ...

Maybe it is time to add a destructor to struct ?
If C# would allow something like RAII it would be possible to implement zero-overhead abstractions (std::shared_ptr, std::unique_ptr and etc.) + GC without using C++

Design example

Below is taken C++\Rust approach for resource with RAII:

public struct Handle
{
    public Handle()
    {
      ...
    }
    ...
    // If copy constructor is not defined, then default one generated if possible
    public Handle(in Handle handle)
    {
       // Copy constructor logic
       ...
    }
    // If move constructor is not defined, then default one generated if possible
    public Handle(move Handle handle)
    {
       // Move constructor logic
       ...
    }
    ...
    // Destructor for handling some logic
    ~Handle()
    {
       ... 
    }
}

void Main()
{
    Handle handle = new Handle();
    Handle handle2 = move handle;    // Move to handle2, handle is not accessible
    handle.Method();                 // Compilation error, handle is moved into handle2
    Handle handle3 = handle2;        // Copy to handle3, handle2 is still accessible
    handle.Method();                 // Okay
}

This design introduce 2 new constructors and destructor for struct + one extra keyword move

Consider one extra example that will prevent coping of the struct:

// This token can only be transferred, not copied due to security reason
public struct SecretToken
{
    public SecretToken()
    {
      ...
    }
    ...
    // Copy constructor is deleted
    public SecretToken(in Handle handle) = delete;

    // If move constructor is not defined, then default one generated if possible
    public SecretToken(move Handle handle)
    {
       // Move constructor logic
       ...
    }
}

void Main()
{
    SecretToken secretToken = new SecretToken();
    secretToken secretToken2 = move secretToken;    // Move to secretToken2, handle is not accessible
    secretToken.Method();                 // Compilation error, secretToken is moved into handle2
}

[HaloFour]

See: https://github.com/dotnet/csharplang/blob/3c8559f186d4c5df5d1299b0eaa4e139ae130ab6/meetings/2015/LDM-2015-02-11.md#1-destructible-types

IIRC the biggest problem came out of the lack of ownership (and transfer of ownership) semantics. Also see https://github.com/dotnet/roslyn/issues/160

[redradist]

Seems like there you postpone the issue ...
Why not consider it again ?
RAII types could potentially to allow to write code without overhead like in C++ and to write in C# drivers, because it will not require runtime GC (it could be optional)

[HaloFour]

RAII types could potentially to allow to write code without overhead like in C++ and to write in C# drivers, because it will not require runtime GC (it could be optional)

I severely doubt that. Maybe it's a lack of imagination on my part but I don't see how this effort would extend to heap-allocated reference types or any of the existing runtime/BCL.

[qrli]

Because it is not necessary to have RAII. In modern frameworks, it is a bit uncommon to still require explicit dispose.

• The early frameworks like WinForm/GDI+ are indeed bad on this, majority classes are disposable and we would like to dispose as soon as possible, rather than relying on GC.
• Then WPF made majority types dispose free
• Now in ASP.NET Core, many app developers are not even aware of dispose, as the last a few scenarios are handled by dependency injection container.

To me, there is more in resource management design. I have moved away from the traditional C++ way where individual objects manage resources and handling ownership transfer etc. Instead, the resources are better centrally managed as a service while most-used surrounding types can be dispose free.

[erik-kallen]

I don't think your third point is accurate. File streams, connections, and such must still be disposed of.

[bernd5]

I can imagine RAII only with struct like types - we could add a struct finalizer which would be implicitly called and could dispose all other resources.
But we would need to add move semantics, too - or we would need to mark such structs as non copyable.
And can it be used as a field in managed types? If yes, when should it be released?
It needs definitely some design work...

Perhaps it could be a new kind of type like what we have with records - it's name could be resource.
Under the hood it could be normal struct - but at every call site it could add implicit Dispose / Move calls.

[msedi]

@redradist:

but I did not get what is the current status of proposal

I think one of the biggest problems is that

1. there is not so much interest
2. there are many ideas, obviously, but no one knows how to do it right

I suppose we both worked with C++ and Rust

Currently only C++, but yes you are right I'm missing some features of C++ where in most cases I could have helped myself, because I simply could. In C# there are a few situations where I cannot help myself, but have to wait until the JIT or the language team has done it (but I assume this has also be the case with C++ in the early days, e.g. move semantics have not always been there ;-)

For me I have currently one main reason why I need RAII (deterministic finalization), for example if I hand over a struct that contains some array from the ArrayPool. The receiver of the struct does not know about it and should not be allowed to return the struct to the ArrayPool via Dispose, because it is forwarded in a chain of algorithms, each algorithm needs to create another result (some sort of functional programming).

Some could say that an analyzer could take care of this, but I prefer to prevent instead of inform about mistakes.

[redradist]

Actually I do not think that it is hard to design and implement ... it is not spacecraft engineering, we have already plenty of example
I would suggest to use Rust approach:

public resource Handle
{
  ...
};

void Main()
{
    Handle handle = new Handle();
    Handle handle2 = handle; // Move to handle2, handle is not accessible
    Handle handle3 = handle2.Clone(); // Copy to handle3, handle2 is not accessible
}

[HaloFour]

Nothing about assignment implies transfer of ownership in C#.

[redradist]

@HaloFour I thought about it and for backward compatibility it is possible to reverse the syntax:

public resource Handle
{
  ...
    ~Handle()
    {
      if (ref_atomic == 0)
      {
        ...
      }
    }
};

void Main()
{
    Handle handle = new Handle();
    Handle handle2 = handle; // Copy to handle2 if Clone() method is available, otherwise compilation error
    Handle handle3 = handle2; // Copy to handle3 if Clone() method is available, otherwise compilation error
}  // At the end of scope destructor for all 3 resource-s will be called

And to avoid all unnecessary copies optimizer compiler could implement something that called in C++17 guaranteed copy elision

[theunrepentantgeek]

Actually I do not think that it is hard to design and implement ... it is not spacecraft engineering, we have already plenty of example

I don't know whether the Rust folks would be horrified that all their hard work can be so glibly hand waved away, or actually pleased that they've made a really complex area so easy to consume.

Regardless, the implementation details - including how the feature interacts with other C# language features, with the billions of lives of existing C# code, and with code written in other .Net languages - are very far from simple.

[redradist]

@msedi @HaloFour @MadsTorgersen @bernd5 @theunrepentantgeek

I have update design for this proposal, now it looks more like in C++, but in C# style ;)

[redradist]

@CyrusNajmabadi It is not the same, in my example reference counting happens automatically on creation and deletion of struct, but ReferenceCountedDisposable requires calling Dispose manually of by using again, it does not work automatically

[redradist]

@CyrusNajmabadi

Your example seems extremely thread-unsafe. It also seems well out of scope of what the original proposal is asking for.

No, you are not right !!
It is just one use case for original proposal, there are lots of others

[CyrusNajmabadi]

t does not work automatically

Yes. i'm not seeing the value of that. I would much prefer having the consumption code be clear about the lifetimes here, knowing though that the underlying value would only go away when safe to do so.

[CyrusNajmabadi]

It is just one use case for original proposal,

My point is that your use case that you've shown:

1. seems very unsafe.
2. is solvable through a library.
3. isn't solved with your proposal.

As such, adding it as a lang feature doesn't make sense.

there are lots of others

can you show them? We'd need a compelling case here that doesn't suffer from teh above 3 problems to motivate doing this.

[redradist]

@CyrusNajmabadi Okay, lets start discuss one by one:

seems very unsafe.

For me it seems okay to have unsafe code inside of some kind of wrapper to avoid it outside. It works in lots of languages: Rust, C++ and so on

is solvable through a library.

No it is not, the ReferenceCountable that you shown will be allocated in GC heap and it is not possible to implement application and library without heap.
My solution will allow to create ReferenceCountable that also will be allocated in heap or any other storage (even on stack thought stackalloc) and avoid GC overhead

isn't solved with your proposal.

No it is solved, you just need to see parallels with Rust (Box, Rc, Arc in Rust) and C++ (std::unique_ptr, std::shared_ptr) to understand this proposal

[msedi]

At least from my perspective and from the code I see at my daily work a few idioms, like the IDiposable for deterministic disposal is not well understood. Even today I reviewed a code where my colleague put a using on a model structure because he thought "if it has a Dispose I need to call it".

The code was following (not fully working, just an example)

void ShowError()
{
  using ViewModel model = new ViewModel();
  ViewLocator.ShowWindow(model);
}

If no one disposes the ViewModel (meaning an analyzer does not see someone calling Dispose) a warning is issued, that you either supress or ignore. I'm not sure if I want my codebase cluttered with pragmas to supress the warnings.
lets not discuss events (weak events) here, where a lot of people in my group do not know (and it's event not quite clear) who is responsible for removing the event: The subscriber or the object that hosts the event (in the Dispose, because the finalizer would never run. I have seen both in our codebase, and I think there is also no common way how to do it. But I think that another story and nothing for this discussion).

At least for me what I really need is a deterministic finalizer on structs, and since it was asked to show an example, I can present one here (I already had a discussion with @YairHalberstadt) about this topic and he guided me to an older discussion of why its not so easy to do them, but that doesn't mean there is another solution.

I have a IVolume that contains an array of (ISlice). Each ISlice contains data (an array of float e.g. 512x512). Additionally I have an IProcessor, that takes one or more IVolumes and produced another one or more IVolumes. But it is done in a pull based way, only when someone accesses the data an ISlice is created and filled with the slice data. Currently the ISlice has no IDisposable because it is a content of the IVolume and it does not make sense to allow to dispose the slice, while the IVolume exists.

Each slice currently only returns a float[] array when calling GetData(). But what I want to have is to return an ReadOnlySpan where the data could either come from a memory mapped file region, from a heap allocated memory, from an ArrayPool or from a CUDA managed memory, and a few more. But, if it comes from e.g. an ArrayPool I need to return it, because the slice rented it from there. So I find ReadOnlySpan is maybe not enough, I would rather return an ISliceData with an implicit cast to ReadOnlySpan. But, and here comes the problem, should I put an IDisposable on every GetData() that returns the ISliceData? Before I didn't needed it because the GC has taken over. For performance reasons I would prefer the newer approach, but I have the drawback that it would be a breaking change and the older method is used more than 2000 times in the code.

If yes, I can already see dramatic memory leaks because someone forgets to call IDisposable, no one warns you, and every now and then (depending on the system load) you can see OutOfMemoryExceptions and to find the leak in a highly parallel and non-determinstic processing chain of more than 100 processors running in parallel and ~200 volumes existing at the same time with T of data this will be a nightmare finding who is causing it. Putting a finalizer on it, and rely on the finalizer would create 100x200x10000 objects with finalizers attached to it, I have honestly no experience what this means, but ~ 200 millions and sometimes 6 billions of objects with finalizers would be created. At least I was told "take care with the amount of finalizers ;-)" and it would be non-deterministic since I don't know when the finalizers run and even then the GC does not know about my unmanaged objects (e.g. CUDA memory).

Just my thoughts because this is my daily work... ;-)

[AlseinX]

Instead of adding RAII to simple structs, my suggestion is adding a new type of value type (which must be defined with an extra syntax like record struct) to support rust-style RAII, which has the following rules:

• Default move semantics, which means that all assignations transfer the ownership.
• Internally supports null value, so that a null value could be left over when a field that the value is transferred out.
• Interfaces for copy and drop could be implemented by RAII value types if needed.

[redradist]

The problem with this solution is there are already plenty keywords that make harder to newbie learn C# language ...
But if to do it with new keyword I will still prefer to do it on struct with additional keyword like it done for record struct, for example:

public resource struct Handle
{
    public Handle()
    {
      ...
    }
    ...
    // If copy constructor is not defined, then default one generated if possible
    public Handle(in Handle handle)
    {
       // Copy constructor logic
       ...
    }
    // If move constructor is not defined, then default one generated if possible
    public Handle(move Handle handle)
    {
       // Move constructor logic
       ...
    }
    ...
    // Destructor for handling some logic
    ~Handle()
    {
       ... 
    }
};

[qrli]

The RAII topic bumps up every so often. I think there are reasons new generation of programming languages do not use it.

Back in the days I still actively wrote C++, I often ask some RAII questions in an interview, and I found many candidates stuck on these questions:

1. What if constructor failed or throwed an exception? Is the object constructed or not? Is the memory allocated or not?
2. What if the object also contains other RAII member objects and the constructor throw? What if 1st object member succeeded while 2nd object member throwed?
3. In above case, will destructor run? And which destructors run? And when? How does the generated code track that?
4. Yes there are recommendations to disable exception. But what if you cannot? At least, out-of-memory will always throw by spec.

And over the years, I forget the exact answers myself. And there were new special cases showed up from time to time. And yes, move semantics. And more new syntaxes for special case of move in later specs. So, I removed C++ from my toolbox.

[msedi]

I have created an example (not working completely), A small explanation, I have an interface that can keep many forms of a pointer (managed, unmanaged, from an arraypool, cuda, or some other memory that can be addressed with the pointer form). Since it is a pointer (a very simple variable, like a Span) I do not want an IDisposable on it is even not always necessary. If the IDisposable is not available using would not work and I would have to add the IDisposable for this case.

// See https://aka.ms/new-console-template for more information
using System.Buffers;
using System.Runtime.InteropServices;

using var pointer = MemoryManager.Create<float>(10);

public unsafe interface IPointer<T> where T : unmanaged
{
    Span<T> AsSpan();
}

public unsafe readonly struct PointerManaged<T> : IPointer<T> where T : unmanaged
{
    private readonly T[] Data;

    public PointerManaged(int size)
    {
        Data = GC.AllocateUninitializedArray<T>(size);
    }

    public Span<T> AsSpan() => Data;
}

public unsafe readonly struct PointerUnmanaged<T> : IDisposable, IPointer<T> where T : unmanaged
{
    private readonly T* Ptr;
    private readonly int Size;

    public PointerUnmanaged(int size)
    {
        Size = size;
        Ptr = (T*)Marshal.AllocHGlobal(size * sizeof(T));
    }

    public Span<T> AsSpan() => new(Ptr, Size * sizeof(T));

    public void Dispose()
    {
        if (Ptr != null)
            Marshal.FreeHGlobal((IntPtr)Ptr);
    }
}

public unsafe readonly struct PointerArrayPool<T> : IDisposable, IPointer<T> where T : unmanaged
{
    private readonly T[] Data;

    public PointerArrayPool(int size)
    {
        Data = ArrayPool<T>.Shared.Rent(size);
    }

    public Span<T> AsSpan() => new(Data);

    public void Dispose()
    {

        ArrayPool<T>.Shared.Return(Data);
    }
}

static class CudaInterop
{
    [DllImport("cuda.dll")]
    internal static extern IntPtr cuMemAllocManaged(int size);
    [DllImport("cuda.dll")]
    internal static extern IntPtr cuMemFreeManaged(IntPtr size);

}

public unsafe readonly struct PointerCuda<T> : IDisposable, IPointer<T> where T : unmanaged
{
    private readonly T* Ptr;
    private readonly int Size;


    public PointerCuda(int size)
    {
        Size = size;
        Ptr = (T*)CudaInterop.cuMemAllocManaged(size * sizeof(T));
    }

    public Span<T> AsSpan() => new(Ptr, Size * sizeof(T));

    public void Dispose()
    {
        if (Ptr != null)
            CudaInterop.cuMemFreeManaged((IntPtr)Ptr);
    }
}

public static class MemoryManager
{
    public static IPointer<T> Create<T>(int size) where T : unmanaged
    {
        int condition = 0;

        switch (condition)
        {
            case 0: return new PointerManaged<T>(size);
            case 1: return new PointerUnmanaged<T>(size);
            case 2: return new PointerArrayPool<T>(size);
            case 3: return new PointerCuda<T>(size);
            case 4: // stackalloc would be nice, doesn't work but thats another story.
            default: throw new NotSupportedException();
        }
    }
}

Years ago, when Span<T> was not available, I wanted to create my own Span<T> (MySpan<T> see below) as a struct and I had a few other requirements, but just the Span<T> as example. At the end, we decided not use it, because everyone that uses MySpan<T> would have needed to call IDisposable and for such simple vars the whole team said that they don't want to use it this way. And since the MySpan<T> can really be treated as a regular variable no one accepted to bloat the code since it's used very often. Also it would have been extremely dangerous if someone missed the Dispose call. Even if it's repeated millions of times ;-) I don't agree that an analyzer solves the problem, I'm still in the opinion that the language needs mechanisms to prevent you from doing obvious mistakes instead of hinting that you might do a mistake (like in stackalloc you cannot return a stackallocated Span<T> you could have also written an analyzer that tells you might get a problem sooner or later ;-)). Also the Span<T> itself works by some runtime magic that I can currently not do myself. So in the end there is something missing that the runtime can do that I cannot.

public readonly struct MySpan<T> : IDisposable where T : unmanaged
{
    private readonly T[] Data;
    public readonly int Length;
    private readonly GCHandle handle;

    public ref T this[int index] => ref Data[index];

    public MySpan(T[] data)
    {
        Data = data;
        Length = data.Length;
        handle = GCHandle.Alloc(Data, GCHandleType.Pinned);
    }

    public void Dispose()
    {
        if (handle.IsAllocated)
            handle.Free();
    }
}

[msedi]

I don't undertand how RAII would help with any of this. Being interfaces, how would the language know which of these it should release when it goes out of scope, and which it would not need to. If it's an interface, we would have no idea what hte rules of the backing type would be.

Yes, maybe the RAII topic goes a bit out of scope and I agree that this might be a problem. I have no answer to this.

[msedi]

This sounds not only reasonable, but highly desirable. You have many different backing forms here, some of which want to do nothing, and some which want to do something. So for the things that want to do nothing, you can impl disposal with a no-op. I'm not sure how the language or RAII could help here as definitionally we don't know what backs the interface you are working with.

So you are saying that this is the solution you would suggest (I mean the solution with the many usings)?

[CyrusNajmabadi]

Yes, maybe the RAII topic goes a bit out of scope and I agree that this might be a problem. I have no answer to this.

I genuinely don't know what is even being proposed here. How does raii help here at all?

[CyrusNajmabadi]

I don't think thats a good style to offer a method a NOP method,

How were you thinking raii would help here? Being an interface, then the compiler would have to insert some call to a cleanup method on the interface when it went out of scope. That call would have to be a no-op for the instances that needed no cleanup. So it would have the same issue.

How would you avoid having that with your proposal?

[msedi]

@CyrusNajmabadi: Yes, I agree things are getting out of scope. And I don't think we will find a solution here.

[redradist]

One additional thing why is this feature is useful - performance

Everyone knows that Garbage Collector could decrease performance, to make it more deterministic and high performance we need deterministic way to allocate and deallocate object ...

Even such languages like Rust allow to use deterministic destruction + garbage collector implementation in one application https://github.com/redradist/ferris-gc ... but C# offers only garbage collector ...

For example destructors, move constructors and copy constructors could be added only for ref struct which already main purpose to be used in high performance scenarios

[redradist]

@CyrusNajmabadi
C# team adding some syntactic sugar to language without real need ( aka new() ), but when we need a realy important feature in core language you say that if somebody could implement it as analyzer then we do not need it at core language !!

I consider it like inconsistent language design

[CyrusNajmabadi]

but when we need a realy important feature in core language you say that if somebody could implement it as analyzer then we do not need it at core language !!

Yes. That is my position. I don't view this as something that requires the language, and i've made it clear a strong argument would need to be made why it has to be done that way. If something is feasible by writing a library and an analyzer, then i consider that a much better approach that will likely take orders of magnitude less effort, and be usable today on anyone with any version of Roslyn taht supports analyzers (going back several language versions).

I get you want it in the language. But just because you want it that way doesn't mean that that will happen. The team actually has to believe that that is absolutely the best way forward here, and right now (at least from my perspective), the bar for making that happen has not been met.

C# team adding some syntactic sugar to language without real need ( aka new() )

First: "real need" is entirely subjective. We felt there was a need here, so we did it. Currently, we don't feel like there is the same need for things like RAII given the language and tooling available.

Second: syntactic sugar is an example of something that actually needs the language to change. You can't deliver sugar as an analyzer. Indeed, the point of sugar is that it is changing the grammar to make existing patterns simpler. This doesn't apply here. I think you could accomplish what is being asked for here with things like using and with explicit methods like Move instead of needing a keyword like move. I would prefer to see that avenue explored. And only if it really turns out that that is just non-viable, then we could discuss if we truly needed language support here.

I consider it like inconsistent language design

We take a pragmatic approach here, picking language features based on a multitude of criteria that we think delivers the most bang/buck.

[redradist]

Also you forgot that in my proposal not only move semantic, but also copy constructor that cannot be easily verifiable by analyzers and also it is harder to prevent it

[CyrusNajmabadi]

can you clarify why an analyzer could not verify that? what language support were you expecting here? And if the language could validate this, why would an analyzer nto be able to? thanks!

[AraHaan]

I do not think a copy constructor is needed at all because if I remember right, parameters to things are always copy by default (even assignment to another variable). Now if move was added to the language it will break 99.9999999999% of c# code today.

As much as I love RAII, I would rather it be scoped only to value types at least, but even then it might break someone as well.

The only thing of value I see in this proposal is struct destructors (to go with the constructor).

Which would work great on my end where I use structs to hold interop stuff with native code, where the struct is used to read what the native code returned in it’s native side. So a struct destructor could help clear the struct when the person sets their struct variable to default by the GC to avoid overhead (if they define one).

[msedi]

@CyrusNajmabadi : You are so insisting on analyzers. It would be nice to have a survey if people would prefer a language change over an analyzer for a certain feature. Just telling us to solve it with analyzers goes in the same direction as saying we need proof for a language change. I agree that language changes should be done with care, but there are currently so many things that I cannot do with the language or with dramatic and unmaintainble efforts (e.g. generic math or generic casts). For example:

   public readonly ref struct ConvertedValue<TFrom, TTo> where TFrom:unmanaged where TTo:unmanaged 
    {
        private readonly Span<TFrom> InternalValue;

        public TTo this[int index]
        {
            [SkipLocalsInit]
            [MethodImpl(MethodImplOptions.AggressiveInlining | MethodImplOptions.AggressiveOptimization)]
            get
            {
                if ((typeof(TFrom)==typeof(byte)) && (typeof(TTo)==typeof(float))) 
                    return (TTo)(object)(float)(int)(object)InternalValue[index];
                else if ((typeof(TFrom) == typeof(sbyte)) && (typeof(TTo) == typeof(float)))
                    return (TTo)(object)(float)(sbyte)(object)InternalValue[index];
                else if ((typeof(TFrom) == typeof(ushort)) && (typeof(TTo) == typeof(float)))
                    return (TTo)(object)(float)(ushort)(object)InternalValue[index];
                else if ((typeof(TFrom) == typeof(short)) && (typeof(TTo) == typeof(float)))
                    return (TTo)(object)(float)(short)(object)InternalValue[index];

                throw new NotSupportException();
            }
        }

        public ConvertedValue(Span<TFrom> value)
        {
            InternalValue = value;
        }
    }

At least for my team no one relies on analyzers and we even had severe performance drops and bugs introduced because the analyzer was applied. So currently people don't trust the analyers anymore.

[msedi]

@CyrusNajmabadi: I can of course accept that not every requests finds it way into the language. I can also accept that requests need to be challenged thorougly for their need. What I can not accept is the way how we are forced to bring evidence that has already been discussed by the language team by exactly the same motivations. Just to bring up a few words from the design proposal of the language team:

Destructible types offer a sweeping approach to deal with this, that is a complete departure from using and IDisposable and instead leans more closely on C++-like RAII features.

Hmmm. I'm not sure if I'm talking to the right person here? All these things have been brought up by @redradist. As far as I read here the RAII was in question here. Why do you mention it yourself?

Overall, we see how this adds value, but not enough that having these concepts in the face of all C# developers. It doesn't earn back it's -100 points.

Thats fine

Could we take a step back and have analyzers encourage practices that are less error prone? Yes. You just cannot have analyzers enforce correctness. And you cannot have them improve perf by affecting codegen. And they cannot do the heavy lifting for you.

Has been discussed here. You are saying analyzers are the way to go. As far as I can read it here, there are obviously also some concerns in the language team.

An analyzer can help you with where to put your using statements. FxCop tries to do that today, but has too many false positives (use vs ownership). Even if you could get rid of those, there's a lot of code you'd need to write.

Has also been brought up. You are saying we should use analyzers but at the same time the language team say that they are not the best way.

People do struggle with IDisposable today. They don't know when things are IDisposable, whether they are the ones who should dispose things.

It seems that also the language team recognizes the problem. So evidence has brought up by yourself. Here obviously it's sufficient to say from the language team that people struggle. But when we say it its considered not to be case. So you are using two different measures here.

We would like to solve the problem in C#, and pick over this proposal for ideas, but we'd need to noodle with it to make it a better fit. It would need to integrate better with current IDisposable.

That fine. If the idea how to do it is not completely clear - let's start over and keep it in the backlog.

[HaloFour]

The language team did recognize a problem, and they explored struct destructors and move semantics and found them to be more complicated than worth the effort. This proposal doesn't do anything new to address this, it just reiterates the same design and the same motivations. That's not good enough to revisit it.

Everything open here is in the backlog, but requires a champion from the LDM team to advance any further.

[CyrusNajmabadi]

Why do you mention it yourself?

I don't know what you mean. I never mentioned that myself.

[CyrusNajmabadi]

Has also been brought up. You are saying we should use analyzers but at the same time the language team say that they are not the best way.

That is not what we are saying. We were talking about specific analyzers around the IDisposable pattern.

That space is problematic as there was no enforcement, and a lot of disparate usage patterns that arose. Even when his information on his to use this API properly came about, there was still the problem of millions of lines of code being written that didn't follow this.

None of this applies to a new potential API that can now be shipped with an appropriate analyzer that pairs with it to use it correctly. In that case you effective get the same benefit as a language feature, just using existing language constructs without the need to define new ones.

[CyrusNajmabadi]

That fine. If the idea how to do it is not completely clear - let's start over and keep it in the backlog.

This is the backlog. I'm just providing information on why I do not think there is enough here to move this from the backlog too a championed feature.

Right now, my position is simply that there hasn't been a good enough argument made why this must be in the language. Every example and use case could be just as satisfied, it seems, with an API and analyzer.

I get that you really really want this as a language feature. However, the bar to clear there is very high. And a standard thing that every language feature has to justify is why it needs to exist and what it brings over what people can accomplish today.

[Xyncgas]

To add to the conversation, why don't we just get what we want all the times in the sense of as long a feature is useful enough we can forget about the things we hate about it and make it optional.
I am even fine for language features that might not last, just the ability to be able to roll them out as fast as possible letting people use it as fast as possible is a big push for creativity and development presence in the product to the market, though there is limited resrouces we can be both conservative and progressive at the same wit's end

[CyrusNajmabadi]

All parts of this propousal is topic to disscuss ...

Agreed. And looking at the proposal, i don't see why we need a language feature here.

If we do not see reason for move operator, then it could be removed from propousal and leaved only copy constructor and destructor

Ok. I don't see a need for a copy-constructor or destructor either. It feels like something a source-generator could create for the user as part of a general library for this pattern.

but even before this you did not liked this propousal

I've stated my reason why above. You gave it a thumbs down. I honestly don't really know how to make this conversation go forward. I've been clear on why these are my reasons for why i don't think this should be directly in the language. If you disagree, please address my points and explain why this definitely needs to be there, and can't just be a source-generator+analyzer feature. Thank you.

[redradist]

I disliked it, to show you my position on what you saying ...

Lots of smart people say, if you want to be better programmer, you need to know few languages and write in few of them ...

I do not say that you do not know few languages, I just saying that we have a different experience. Let me explain what I mean ...
When I writing code in modern C++ and in Rust I feel that code more maintainable and predictable then in high language like C#

Understand me correctly, I am writing a lot in C++ and a lot in C#, but in C# I strugling that I need to be more carful because memory leak could happens or resource will not be freed in predictable way ... It is non-sense !! In C++ I do not need to think when to delete something, when to close file, when to close socket, because library authors has tool that is called RAII !!
In C# I am struggling with miss of this feature ... of course we could try to solve it with analyzers or code generation, but it is crutch for language that could not solve simple problem that is already solved in other languages

[AraHaan]

All parts of this propousal is topic to disscuss ...

Agreed. And looking at the proposal, i don't see why we need a language feature here.

If we do not see reason for move operator, then it could be removed from propousal and leaved only copy constructor and destructor

Ok. I don't see a need for a copy-constructor or destructor either. It feels like something a source-generator could create for the user as part of a general library for this pattern.

but even before this you did not liked this propousal

I've stated my reason why above. You gave it a thumbs down. I honestly don't really know how to make this conversation go forward. I've been clear on why these are my reasons for why i don't think this should be directly in the language. If you disagree, please address my points and explain why this definitely needs to be there, and can't just be a source-generator+analyzer feature. Thank you.

agreed, then should structs that need a destructor inherit from IDisposable then and become disposables themselves?

[CyrusNajmabadi]

In C# I am struggling with miss of this feature

I don't think you understand my position. I'm not saying you shoudl not have this when developing in C#. I'm saying i think you don't need a specific language feature for this, but could instead provide this with a library and analyzer. So you'd get the same benefit, without having to wait on us implementing the feature for you directly in the language and compiler.

This also means you'd be able to ship and use libraries without requiring both the lib producer and consumer to be on C#11 and above (or whatever version we'd even ship this in).

[AraHaan]

Also cant they define types that use RAII if they make them exposed as .NET classes in C++/CLI (targeting .NET 5/6)? What requirement prevents them from that?

[panagiotidisc]

I am working on a custom mapping solution for one of my projects, and the problem I'm facing is what to do when a field or property is a plain struct or class with no special attribute markings.
struct assignment does a shallow copy, and class assignment passes a reference to the same (heap allocated) object.
There is no standard way to specify that you want a deep copy (aka move constructor), and debugging why a certain variable was or wasn't changed is made more difficult by the use of the exact same syntax for value and reference assignment.
Furthermore, the ICloneable interface is hacky solution as it cannot inform you whether it is doing a shallow or deep copy, which is the reason that microsoft discourages its use in public apis.
As such, my options for my mapper are:
1)Do a simple assignment (val1 = val2;) and hope nothing breaks further down the line,
2)Severely limit what is accepted by demanding it implements ICloneable (val1 = val2.Clone()), and hope it does a deep copy instead of a shallow copy,
3)throw an error

3. is the only option that will let me sleep at night, but also the most limiting in my design.

[iam3yal]

@panagiotidisc

There is no standard way to specify that you want a deep copy (aka move constructor)

This statement doesn't make a lot of sense.

Do a simple assignment (val1 = val2;) and hope nothing breaks further down the line,

Why would it break?

Severely limit what is accepted by demanding it implements ICloneable (val1 = val2.Clone()), and hope it does a deep copy instead of a shallow copy,

You can't demand anything from an interface but semantics and as you mentioned this isn't recommended in public API because it doesn't have clear semantics.

throw an error

What does this mean?

[theunrepentantgeek]

I am working on a custom mapping solution for one of my projects, and the problem I'm facing is what to do when a field or property is a plain struct or class with no special attribute markings.

FWIW, years ago, when I wrote a (potentially) similar mapping tool, I looked for a copy constructor on the type, and used that if available. That, plus custom support for standard framework types, got me where I needed to go without requiring any language support.

Strict enforcement of deep copying (where the resulting object is completely and entirely independent of the original, inside and out) has a number of drawbacks.

Two examples to illustrate:

• With an immutable data type, it's demonstrably safe to share members because, well, they're immutable. Strict enforcement of deep cloning precludes such sharing, increasing memory load and slowing things down unnecessarily.
• Even if the type isn't immutable, there are sometimes reasons to retain shared members - to share a cache, or for access to common configuration. Again, requiring deep cloning prevents this.

My key point here is that often a requirement for deep-cloning is really a requirement for an independent instance, which is subtly (but crucially) different.

[cos1110]

• C / C++ : Manual memory management and a lot of ways to control how the memory is used and when is used.

• C# : This style of programming, abstracts and hides all platform-dependent and machine-dependent details. However since the language has a lot of native code capabilities and interoperability features (unsafe code and raw pointers), these are supposed to be considered something extra, that allow some specific use-cases. Where it does matter most, is when there is a great need for more robust interoperability with native libraries (such as Silk Vulkan + OpenGL / SIMD Math / TensorFlow libraries etc) where you need to squeeze every possible percentage of perfomance.

• Rust : A paradigm shift in memory management techniques, there is nothing to compare or contradict compared to C++, since is a different mental model.

• C# Rustification : This can be considered as the ideal way to solve some of the shortcomings of Unsafe C#, but there is a contradictory nature here. Because Rust is concerned with memory safety and hence it tries to avoid all of C++ pitfals by design. C++ on the other hand is concerned about robust and efficient code (aka zero cost abstractions).

In the context of C#, getting rustified is contradictory, because if you need safety you go for the features the DotNetRuntime offers. When you need to develop very robust and efficient libraries, you switch back to unsafe blocks and use raw pointers.

[iam3yal]

@cos1110

This style of programming, abstracts and hides all platform-dependent and machine-dependent details.

That's not really true though because C# itself has little to do it with it, it's a combination of IL, .NET libraries and the runtime that abstract over these details and today you have plenty of built-in hardware intrinsics and APIs to access many of the underlying machinery.

When you need to develop very robust and efficient libraries, you switch back to unsafe blocks and use raw pointers.

That's not true either because robustness and efficiency doesn't really depend on whether you're inside an unsafe block and I wouldn't actually say that dealing with pointers directly contribute to a more robust code, in fact, more often than not it's the exact opposite.

[cos1110]

C# itself has little to do it with it, it's a combination of IL, .NET libraries and the runtime that abstract over these details

OK, if you think about behind the scenes, then there are a lot of thousands of other optimizations that occur, on one hand you have this but on the other you get something else.

The idea of using unsafe blocks and raw pointers in C# primarily serves the purpose of having better direct interoperability with native libraries, minimizing as much as possible intermediate wrapper objects or type castings. Also there is another thing to note, about the performance gains that come from it.

Obviously, now using unsafe blocks in C# to write brand new codebase, is an ideology that originates from C development and perhaps up to some extent from C++. In these languages you can't help it because is the nature of how things work. But in C# you might have up to a great extent some different results.

I have seen a dozen of libraries that use raw pointers to achieve better efficiency. Such as in CPU intensive libraries, say game physics or image filter operations (cpu based). BEPUphysics engine in C# does use unsafe code and raw pointers in certain performance-critical sections to optimize its physics calculations.

I am not saying specifically about the pros and cons (safety -vs- efficiency) of using raw pointers, but to point out that this style of programming makes you more deterministic. Though still as you say the compiler might do it's own things behind the scenes, but at least up to a great extent you can over-impose your intent towards the compiler and do not let it think in any random way. You direct the compiler in a certain way on how you want the data to be stored in memory and how they need be accessed and when, is somehow like you want to direct things in a certain way and expect the equivalent results as an output.

And to fall back into the initial question of the thread. What Rustification of C# means? Obviously 100% safety. But this means that you get the equivalent performance and efficiency as the unsafe raw pointer version?

[iam3yal]

@cos1110 I'm not denying the benefits of using unsafe and pointers when they are necessary, they are there for a reason, especially when it comes down to interoperability but now more than ever, each year .NET get incredible performance improvements through new abstraction and mechanisms so you can write both safe and fast code without ever using 'unsafe` and get the exact same results.

Going back to this topic I think the OP and his fellow companion in arms should research this topic more. :)

[En3Tho]

@cos1110 In C# you still have to work with os-level dependencies which are designed to be released explicitly in your code. Having a strict lifetime/ownership system would be a great help in such cases.

I can write that code in Rust, yes, but I still would have to glue those layers together and it's quite possible that Rust code would return some kind of releaseable handle too which would require manual management in C#.

And even if we don't touch the topic of native resources we still have plain old IDisposable right here. And the same question arises: who is an owner of that IDisposable? Now programmers have to resort to things like bool disposeHandler in HttpClient for example which is error prone and in no way compares to proper type-system/compiler feature

[redradist]

@En3Tho

@cos1110 In C# you still have to work with os-level dependencies which are designed to be released explicitly in your code. Having a strict lifetime/ownership system would be a great help in such cases.

I can write that code in Rust, yes, but I still would have to glue those layers together and it's quite possible that Rust code would return some kind of releaseable handle too which would require manual management in C#.

And even if we don't touch the topic of native resources we still have plain old IDisposable right here. And the same question arises: who is an owner of that IDisposable? Now programmers have to resort to things like bool disposeHandler in HttpClient for example which is error prone and in no way compares to proper type-system/compiler feature

Yes, these all reasons why I propose this feature, but unfortunately mic-team is too close-minded (((

[theunrepentantgeek]

You're making an unwarranted assumption here - that the reason they're disagreeing with you is because they're close-minded.

I don't believe that to be true. I've found the C# language team to be super open minded, willing to discuss the merits (or not) of a wide variety of ideas, all with a focus on what's best for the long term future of the language.

Now, nobody agrees with all their decisions, and you might not like their decision in this case, but that's a different matter.