Intended behavior of explicit IDisposable.Dispose implementations in ref structs.

[aloraman]

Disclaimer: Originally posted at runtime repo, as I was not sure if it was intended language design, a compiler bug, or a general compatibility-driven decision.

One of C# 13 features announced in What's new in C# 13 is to enable ref structs to implement interfaces. It allows ref structs to implement IDisposable interface, moreover it allows them to implement IDisposable explicitly. Currently, when implemented both implicitly and explicitly, ref structs behave differently to other types, e.g. consider the following example:

using System;

TestClass(new FooClass()); // Explicit
TestStruct(new FooStruct()); // Explicit
TestRefStruct(new FooRefStruct()); // Implicit!

void TestClass(FooClass target) {using(target){}}
void TestStruct(FooStruct target) {using(target){}}
void TestRefStruct(FooRefStruct target) {using(target){}}


public class FooClass: IDisposable
{
  public void Dispose() => Console.WriteLine("Implicit");
  void IDisposable.Dispose() => Console.WriteLine("Explicit");
}

public struct FooStruct: IDisposable
{
  public void Dispose() => Console.WriteLine("Implicit");
  void IDisposable.Dispose() => Console.WriteLine("Explicit");
}

public ref struct FooRefStruct: IDisposable
{
  public void Dispose() => Console.WriteLine("Implicit");
  void IDisposable.Dispose() => Console.WriteLine("Explicit");
}

Run at Sharplab

That is, ref structs prefer implicit* Dispose implementation, while every other type prefers explicit Dispose implementation, conforming to ECMA-334 spec.

*Colloquially called implicit, in other words - not explicit. For ref structs it means choosing a specific method by matching public void Dispose() signature, i.e. duck typing.

Is this intended design or a bug? If former, would it be possible to reconsider this? Now, it creates a weird behavior, the only purpose of which is to be a nasty puzzler for a programmer interview. If changed, it would be a breaking change, but a very minor one.
To observe such a breaking change, you'll need to explicitly add an IDisposable implementation to an existing ref struct with implicit Dispose method - which is somewhat of a breaking change in itself. Now, if such a struct is used in a Dispose statement - different overload will be called, so it is a source level breaking change, but it's no different from adding explicit Dispose implementation to any regular disposable type anyway. As far as I understand, this is not a binary breaking change - existing binaries that utilize ref struct Disposal have a direct call to implicit Dispose method on IL level anyway - so they will continue to call implicit implementations.

NB
As far as I understand how consistent the behavior is with allow ref struct feature (I don't have NET 9.0 version locally with this feature enabled), in generic code an explicit implementation will be used (even though JIT could've replaced callvirt IDisposable.Dispose to call Dispose due to per-concrete type reification for structs):

TestGeneric(new FooClass()); // Explicit
TestGeneric(new FooStruct()); // Explicit
TestGeneric(new FooRefStruct()); // Explicit (!)

void TestGeneric<T>(T target) where T:IDisposable, allow ref struct => {using(target){}}

Which makes non-generic case even more inconsistent.

[HaloFour]

Before interfaces were supported on ref structs the C# language allowed you to use using with those types as long as they had an accessible Dispose method on them. The compiler still prefers that pattern for the sake of backward compatibility and explicitly emits a call to that Dispose method without even checking to see if the type implements IDisposable. Whether or not the compiler should continue to do that is probably a conversation worth having.

using System;

var target = new FooRefStruct();
using (target) { };

public ref struct FooRefStruct
{
  public void Dispose() => Console.WriteLine("Implicit");
}

[CyrusNajmabadi]

Personally, if you have a ref struct with that would behave differently, then I think that's a bad thing. So I would just stick with our current behavior and not change it. In practice it should not matter. And if it does, meh :-)

[333fred]

Agreed with Cyrus. The behavior is a fallout of the rules exactly as written; while we could change it, it really doesn't seem necessary to me. The only reason that struct and class don't behave the same way is because we're too afraid of making the breaking change to have them work this way. When we did using for ref structs, we actually tried to extend pattern-based using to all types, but it caused breaking changes that we didn't want to take. ref structs actually work the way we'd want any type to work in an ideal world.

[aloraman]

@CyrusNajmabadi Still, the preference of choosing IDisposable.Dispose (without boxing) made it into ECMA-334. I'd prefer ref structs to behave the same way as the other types - for the sake of consistency. Fewer language quirks, fewer brainteaser questions for an interview. Also, if ref struct could have interface implementation feature in the same language release as disposal feature - there would be no need for Dispose-like method matching in compiler, so I'd argue for changing current situation to get rid of obsolete intermediary step.

[CyrusNajmabadi]

fewer brainteaser questions for an interview.

Honestly, I could not care less. :-)

so I'd argue for changing current situation to get rid of obsolete intermediary step.

I'd be fine with a larger, holistic, improvement to the whole disposal area. However, it would only be through that that I would change this here. I would never touch this up front, thinking that we might do the other stuff later.

[jnm2]

fewer brainteaser questions for an interview.

Potentially serving as a way to filter out interviewers :D

[colejohnson66]

I'd argue that explicit interface implementations on ref structs don't make sense and should be prohibited.
After all, you and the compiler can't reach them (they require boxing).

[jnm2]

They can be reached without boxing (using the .constrained IL prefix for the callvirt) via:

void M<T>(T disposable) where T : IDisposable, allows ref struct
{
    disposable.Dispose();
}

[aloraman]

Also, disposal of other types does not involve boxing, even though the IDisposable.Dispose() is prefered - as specified in ECMA-334 (once for using block, and once for foreach block again)

[jnm2]

Oh I see, that is also a constrained call!