proposal: ref struct should support destructor

[ygc369]

Since ref struct is stack-only, it could have a destructor, which would be executed when the struct goes out of scope. If I write a function library for others, although I provide dispose function, users can still ignore it and forget to release resources. I can't force them to use "using". But if ref struct supports destructor, I can use it to wrap my functions to ensure releasing resources.

For example:

ref struct A
{
    FileStream file;
    public A(string filename)
    {
        file = new FileStream(filename, FileMode.Open);
    }
    ......  //other member functions
    ~A() //destructor 
    {
        if(file)
        {
           file.Close();
           file=null;
        }
    }
}

static void test()
{
    A a=new A("D:\test.txt");
    ......
} //destructor of "a" would be executed here automatically

related issue: #231

---

Add a rule: ref struct with destructor can't assign each other.

[jnm2]

Not thrilled with having two subtly different ways to do the same type of thing. If people get excited about using this construct where they would have used Dispose for resource cleanup, instead of just checking whether the type is IDisposable I now also have to check if it has a destructor and create an inner scope in which to put the declaration to deterministically clean up before running the next code in the method.

[benaadams]

Destructible Types #121

[ygc369]

@jnm2
The class lib author should choose just one way, not provide both ways. If he chooses this way, you can use it easier, not harder.

[jnm2]

@ygc369 Exactly, the class library authors will only provide one way and that means that I'll have to remember to look for both ways every time I use something resource-y.

[ygc369]

@jnm2
You don't have to remember to look for both ways, you can just do the same as before. Because if the class lib author use this way, you could just use it and don't have to release anything, the destructor would be called automatically.

[jnm2]

@ygc369 That only works if I don't care how long the resource is held. Sometimes I need to release it before the end of the method. A trivial example is something holding a file lock.

[ygc369]

@jnm2
You can always remember to release resources, so you don't need this feature. But for those people who always forget to release resources, they would be very happy to have this feature.

[jnm2]

For those people who always remember to release resources, this feature will slow us down and make it hard to express what's going on when we add an inner scope.

[ygc369]

@jnm2
Look at this:

ref struct A: IDisposeable
{
    FileStream file;
    public A(string filename)
    {
        file = new FileStream(filename, FileMode.Open);
    }
    
    ......  //other member functions

    public void Dispose()
    {
        if(file)
        {
           file.Close();
           file=null;
        }
    }

    ~A() //destructor 
    {
        Dispose();
    }
}

static void test()
{
    A a=new A("D:\test.txt");
    ......
} //destructor of "a" would be executed here automatically

You can still call "Dispose" method, if you want to release resources earlier. But once you forget, the destructor would help you. Does this satisfy you?

[CodingMadness]

I could not understand what the jnm2 guy could not grasp, this is an awesome feature..!

[theunrepentantgeek]

Instead of adding the new concept of a destructor when .NET already has both IDisposable and finalizers, what if IDisposable was used to clean up a ref struct?

That is, if the ref struct implements IDisposable, the compiler emits a call to Dispose() automatically, ensuring the resource is cleaned up when it leaves scope.

This interoperates cleanly with a using clause because of the existing contract that allows Dispose() to be called multiple times (though, admittedly, it's not uncommon for developers to foul this up).

[ygc369]

@theunrepentantgeek

if the ref struct implements IDisposable, the compiler emits a call to Dispose() automatically, ensuring the resource is cleaned up when it leaves scope.

Does the C# team have the plan to support this? Or does the current ref struct already have the feature?

[Joe4evr]

@theunrepentantgeek One problem here is that ref structs are not allowed to implement interfaces.

[Joe4evr]

@ygc369 It looks like your problem really comes down to CS0575: Only class types can contain destructors, which applies to all structs.

As you are finding out, using a ref struct to hold on to resources is not something they should be used for. I get that you want to reap the performance benefits for this stuff, but the mantra here is

[ygc369]

@Joe4evr
What is the meaning of "use the new and shiny responsibly"?

[benaadams]

An issue is ref structs are still copied by value

static void test()
{
    A a = new A("D:\test.txt");
    A b = a;
    A c = a;
    ......
} // destructor of "a", "b" and "c" executed here automatically?

[stephentoub]

Is the Destructible Types #121 still in plan?

It was never a plan, merely a proposal.

[ygc369]

@stephentoub
It seems that you posted that proposal first. You work for Microsoft, do you know any progress with your proposal?
I think that if we add such a rule: "ref struct with destructor can't assign each other", then ref struct would become Destructible Type, do you think so?
Furtherly, if this proposal and Project Snowflake both come true, they could work together to provide a mechanism of automatic memory management, partly instead of GC.

[ygc369]

Any progress?

[ppervink]

I tend to think of a desire for stack based dispose as both a misunderstanding of the intent of a ref struct and a sign of misuse of the technology. Think of it more like a reference to a 'something' created (and managed) somewhere else higher in the call stack. For instance, Memory is a disposable struct (lets go of its handle making it invalid - even for other copies of that Memory struct), MemoryManager is a disposable class (actually manages memory lifetime, not just handles to it). If you have an instance of MemoryManager class, you can get a Memory struct to pass around a reference to that region of memory (an array or a GCHandle, which may or may not still be valid), but when you get a Span, it's more like saying there's something higher in the stack managing this reference (making it kind of a 'safe' pointer/contract for access to a certain kind of element). It can only live on the stack, so provided the dispose scope of your Memory is the only place calling methods with the Span it provides and the Manager (if) used to get the Memory isn't asynchronously disposed, your Span should remain valid through any method calls made with it.

A ref struct should, IMO, always follow this nature. It should be lightweight and specialized for a specific purpose with no need for cleanup, etc. within some parent scope (which is responsible for cleanup, etc).

Polymorphism makes no sense on a ref struct because it's specialized purpose should be known to consumers of it (it already is the specialized interface - you got it from somewhere and that somewhere is where your polymorphism comes in). Additionally, it can only live on the stack - it can't be boxed up for consumption by something looking for a specific interface.

[ygc369]

Now C# 8.0 has supported disposable ref structs (see https://blogs.msdn.microsoft.com/dotnet/2019/01/24/do-more-with-patterns-in-c-8-0/).
It's getting closer to this proposal, but still lack of following two features:
(1) forbid copy
(2) call dispose() automatically when going out of scope.

[qrli]

I don't think it will. It has already got using declaration, so I don't think we will have another way to do the same:

    using var fileStream = File.Open("abc.txt");

[ceztko]

For me using declaration is almost perfect and adds RAII to C# without really adding RAII. What I'm missing here is at least a warning for not calling the Dispose method in case of structs implementing IDisposable (or ref structs having a Dispose method, I guess). The warning could be automatically silenced if the struct is copied somewhere in the flow, for example in a return statement. Also ref variables should not issue warning. This assumes it makes no sense having a disposable struct passed to different terminal blocks and not calling Dispose in some of them, which I am not entirely sure it's always the case, but it makes 100% sense to me that the Dispose method has to be called in at least one terminal block, hence the need for a warning. Apart from silencing the warning, letting copy enabled for structs with IDisposable is actually useful/necessary for me: just think for example when passing a guard struct object through different wrapped objects, a pattern that is commonly used in C++. This should answer also @ygc369 who was asking struct that can't be copied, which I think can't really be added to C#. Would it make sense to suggest this warning to roslyn team?

[sharwell]

I think it would be difficult to implement this proposal before "Non-copyable structs (#859)"

[sebas77]

I found myself many times wanting a very simple ref struct destructor. It would be just a method that is called when the ref struct gets out of the scope. Nothing fancy, but I have use cases for it in my framework (I have never used disposing ref structs because I cannot trust the framework user to remember using the using keyword). This proposal is definitively a +1 for me.

[msedi]

There are currently so many discussions around this topic (#4808, #3450, #121, #5370 and a few others), wouldn't it make sense to merge this into one? Since it already has been discussed in https://github.com/dotnet/csharplang/blob/3c8559f186d4c5df5d1299b0eaa4e139ae130ab6/meetings/2015/LDM-2015-02-11.md#1-destructible-types it is obviously not completely uncommon and need deeper discussion where the ideas from all findings from ongoing discussions can flow in?

[ghost]

I think ref struct is a subset of struct, because struct can allocate on the stack or heap, and ref struct can only allocate on the stack.
But if ref struct has destructor, ref struct will be not a subset of struct, beacuse struct doesn't support destructor.

[ceztko]

@X-maple I think you're engaging a crusade against features for structs that you don't envision in C# using not super solid arguments, as it is now. As @sharwell (which is among the most authoritative commenters here) said:

I think it would be difficult to implement this proposal before "Non-copyable structs (#859)"

This mean to me that in general the struct being non copyable seems to be the governing condition to decide when/if implementing or not destructors for structs in C#. Restrict it to only ref structs may then be a wiser choice, at least initially, and that's what the issue creator seems to suggest. If you have non copyable structs with destructors then you may need to prolong the lifetime of the resources being freed by the distructor, that's where it comes into play move semantics. These features are all semantically linked together, and IMO implementing them in the right way and at the right timeframe won't reduce the elegance of C#, as you're trying to suggest using your set theory analogy.

[sebas77]

destructors should be only on ref structs, making it more generic than that is not what most of the people need and would be wrong under the c# design point of view, making it more complicated to develop. Ref struct are anyway already behaving differently as they can use the using keyword without implementing IDisposable interface.

[FICHEKK]

I am just here to give my support for this feature. I am creating a library and want to release internally used resource to the pool when ref struct goes out of scope. I also don't want to rely on users to use using construct, I want the release of resources to happen automatically. I am very sad that this has not yet been added. Please someone make it happen.

[NickStrupat]

I believe scoped locals in C# 11 will offer a partial solution. using would still be required though.

[CodingMadness]

Anything regarding this topic, this would be so valuable..

[NickStrupat]

What I have done in the meantime is give my ref structs a Dispose() method, do the typical releasing in there, and then use a .NET analyzer to make sure the instance is in a using statement/declaration.

[NickStrupat]

using Memory page = new(Environment.SystemPageSize);
page.Span.Fill(42);

public readonly ref struct Memory
{
	private readonly IntPtr ptr;
	private readonly Int32 size;
	public Memory(Int32 size) => (this.ptr, this.size) = (Marshal.AllocHGlobal(size), size);
	public void Dispose() => Marshal.FreeHGlobal(ptr);
	public unsafe Span<Byte> Span => new(ptr.ToPointer(), size);
}

<Project Sdk="Microsoft.NET.Sdk">

    <PropertyGroup>
        <TargetFramework>net7.0</TargetFramework>
        <ImplicitUsings>enable</ImplicitUsings>
        <Nullable>enable</Nullable>
        <LangVersion>latest</LangVersion>
        <AllowUnsafeBlocks>true</AllowUnsafeBlocks>
        <EnableNETAnalyzers>true</EnableNETAnalyzers>
        <AnalysisLevel>latest</AnalysisLevel>
        <AnalysisMode>AllEnabledByDefault</AnalysisMode>
        <WarningsAsErrors>CA2000</WarningsAsErrors>
    </PropertyGroup>

    <ItemGroup>
      <PackageReference Include="Microsoft.CodeAnalysis.NetAnalyzers" Version="7.0.0">
        <PrivateAssets>all</PrivateAssets>
        <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
      </PackageReference>
    </ItemGroup>

</Project>

[NickStrupat]

Just realized this will be bad if the struct is copied, which is not preventable at the moment.

[NickStrupat]

Anyone know of a roslyn analyzer that warns on struct copy?

[NickStrupat]

What about an attribute for ref structs that require the constructed instance to be in a using statement/declaration?

[CyrusNajmabadi]

@NickStrupat that would be very easy to do as an analyzer. Indeed, the use case of "an attribute restricts allowable usage contexts" is one of hte core patterns that analyzers were created for.

[CodingMadness]

So it would then prevent compilation, if that given attribute is set on a ref struct but the user forgets to write "using var myRefStruct = new(..)" and just does "var myRefStruct = new(..)"?

[CodingMadness]

Any news on this topic so far?

[NickStrupat]

Check out my reply on another comment in this issue: you can enable CA2000 warning to be an error
#1110 (reply in thread)

[iperov]

C# without a syncronous destructor on scope exits is just awful. It prevents C# from entering the realm of machine learning.

[theunrepentantgeek]

You should make sure to tell that to all the devs who are already building large ML systems with C#.

[iperov]

already building large ML systems with C#.

sure, in your dreams.

Torch is the best framework for training neural networks.
ML.TorchSharp is C# impl, but because C# doesn't have a destructor or some method called on an object when references are lost, the result is: https://github.com/dotnet/TorchSharp/blob/main/docfx/articles/memory.md

No one will mess around with that crap and will use python with pytorch.

[saint4eva]

https://dotnet.microsoft.com/en-us/platform/customers/mlnet