Prevent IDisposable structs from being boxed

[AFatNiBBa]

Problem

The following struct

public struct MyStruct : IDisposable
{
    public void Dispose()
    {
        // ...
    }
}

Can be used in an using block

using (var something = new MyStruct())
{
    // ...
}

That will be lowered to this

MyStruct something = default(MyStruct);
try
{
    // ...
}
finally
{
    ((IDisposable)something).Dispose();
}

This code will box the struct and allocate it on the heap, which is not optimal.
This was probably done because the cast would be needed if the struct was defined like so

public struct MyStruct : IDisposable
{
    // (Explicit interface implementation)
    void IDisposable.Dispose()
    {
        // ...
    }
}

Known solution

You could fix the problem by making a ref struct

public ref struct MyStruct
{
    public void Dispose()
    {
        // ...
    }
}

Which would be used like this behind the scenes

MyStruct something = default(MyStruct);
try
{
    // ...
}
finally
{
    something.Dispose();
}

But it would make the struct not capable of escaping the stack, which would be an unnecessary limitation in this case

Proposal

Create a generic static method that handles disposals

//                            ↓ (Preferably by ref)
public static void Dispose<T>(ref T value) where T : IDisposable => value.Dispose();

That would be called like this behind the scenes

MyStruct something = default(MyStruct);
try
{
    // ...
}
finally
{
    SomeClass.Dispose(ref something);
}

Which would prevent boxing, allow for explicit interface implementations and would work with classes too

[colejohnson66]

((IDisposable)something).Dispose() does not box. It’s a "constrained call" and the JIT elides the actual boxing.

[huoyaoyuan]

They are two separated concepts:

((IFace)variable).Method() compiles into box instruction, and JIT cancels the box as an optimization. .NET Framework JIT doesn't cancel the boxing: https://sharplab.io/#v2:EYLgHgbALANALiAhgZwLYB8ACAmAjAWACgjk4AnAVwGM4ACAYVpFoEkARAS2QAcB7ZRMAA2AUyIBvIrWm1MUVpx79BogHSK+yEQAoAlFJmTCM2gekBfM6eMzMuCLPkBZPVaMmTAN0RlaVWgC8tAB2IgDuDHoA3FYm2trsXJoqIrpUuupJ/Dq6MTYWROZAA==

constrained. prefix is also used for generics: https://sharplab.io/#v2:EYLgHgbALANALiAlgGwD4AEBMBGAsAKAIGc4AnAVwGM4ACAYRpBoEkARRIgBwHsiBDYMgCmBAN4Eakmuigt2XXgOEA6eTyJCAFAEoJU8fik09kgL4njhqemwRpsgLI6LBo0YBufUjUo0AvDQAdkIA7vQ6ANwWRgDiQsGkiJRqvFqkQgBmPtpRVmYWFjZ2MjRxCUkpGgA8ACoAfJrpWTU0ACYc6kpC2jQhABZC6TQtTGwdioIieTSubpLtCvyTquMakRbm+KZAA==
Here no box instruction is used.

where T : IFace is a well-known trick to using struct as interface without boxing. The boxing optimization makes it less necessary now.

[bbarry]

@huoyaoyuan I altered your first example to better demonstrate what is going on; switch the platform and results dropdowns to compare differences in the JIT Asm generated;

https://sharplab.io/#v2:C4LghgzgtgPgAgJgIwFgBQcAMACOSB0ASgK4B2wAllAKb4DCA9lAA4UA21ATgMpcBuFAMbUIAbnToA9JOwA5BsGrYAUgEkAKtgCC0bJxHE2wCNjD7swABZKIYGtgBmDTqbZtsAZmwAjamwYA7tgUpNiM5nQAMoTYABzYpIEgUjKCTMxmSsAM2Piy1MDYAGKcdtQBzgDW6Ii4SADs2ADe6Nht2ADaALIFlgwAJqosbAAUPVYDQ8xsAPLMlAykEHkMqqRsISEA5gCUALqt7XgAbLgALNgAqhDbIzvNh+3t0qZwZybeDAAe2z4AnmEAMTYNhgUhbYhgLZKfrUBybBahBgOXA4SrUP4VTj9R5PVHYEZ8MzYQTYAC8CXKYTu9ya2AAvrjGWgnrjur1JsMxhzBsM5ojlvI1htSNt9riTudsAAhb53B4svFtF7hJScMiUGgmMBvHzfX79YhZHJg7AMeZUCgALzAiNxTyJLkECHJlKCdDu4kVSuAnABLW9ePpjhCYDc/vtSoJI1UABEKBBmAxbN4ODtnTt8PHE8nqJ7I21mU8i+02eM+rzptyJpXZhbFoLVutNuDxYHJbrGEtfWAQtR+nQw6NaQXsC8de89T9wf8gSCwRCoTC4QiKIszSjoaQuEISQ2eyFjKOXht0WwAVYlCFty4aDXsNDjMFm9v+rO1OpRCTTb5nw42EapDCG+3gAravoUN4xCKBAx4yAElhCJY2AVIYb5QGA6IWIhJjMFwTicFA2E2GUpgmJe+J8FwNyLKOdAkl4FLbu6+aBk8voRmx7TBvCpBDpxUZ4tmSYQNQg5uFwIyCB4OxeoJJZKnB2BkGkUA0OQvxWAmJKWAuIgqBo2i6OunxWGEzhKFEMRgm+eQAKKaCUZRYtUXHKjI7I1lMozlpy0z8muSwrMKLa7Acbl1KcurCbm4kcJwAA86gAHwjJo/QJiJYCptQ9wIVwSjqCA2BxplybZRw5LJdgGU5imHBZmVomscWEjtkgUUXF0vakPKAaCdctyyaOspfC1UZdhAB6vnF42Ftg6DMjUXhTeqgiFPRxWlXVFXUOg/VHF4h7FBQfj9HJRwXNtWU5Y1dV5vcZLVUUp1sG+FKYF69JAA

The JIT Asm for Core CLR here clearly shows the conversion optimization (all 3 versions are exactly the same Asm), absent in .NET Framework versions along with a few others.

edit:

Adding [MethodImpl(MethodImplOptions.NoInlining)] to C.Dispose() demonstrates that there are still optimizations to the using statement version that are currently not applied when attempting to do the same thing without it.

[siegfriedpammer]

Is this "constrained call avoids boxing for value types" a documented optimization

@colejohnson66 I would say it's documented in the description of the constrained. prefix in ECMA-335, see the citation in my answer.

[colejohnson66]

Yes, it’s documented for constrained. IL prefix, but is it guaranteed even if the prefix is not present?

[timcassell]

Yes, it’s documented for constrained. IL prefix, but is it guaranteed even if the prefix is not present?

No it's not guaranteed. It depends on the JIT/compiler. Old .Net Framework JIT and Unity's IL2CPP compiler does not optimize it.

[siegfriedpammer]

I don't think that boxing even occurs in your introductory example. It is just that SharpLab and ILSpy produce this output, because the original IL cannot be expressed better in C# (see icsharpcode/ILSpy#3089).

In the using statement the call to Dispose is is lowered to a constrained callvirt instruction, which does not box, if the value type implements the method: