Unexpected behaviour mixing default interface methods, generics, and value types

[SamPruden]

I'm using default interface methods for the first time and just encountered some unexpected behaviour.

var foo = new Foo();
GenericallyIncrement(ref foo);
Console.WriteLine(foo.Bar); // Not actually incremented!!!

void GenericallyIncrement<T>(ref T foo) where T : IFoo => foo.IncrementThroughInterface();

interface IFoo
{
    int Bar { get; set; }
    void IncrementThroughInterface() => this.Bar++;
}

struct Foo : IFoo
{
    public int Bar { get; set; }
}

SharpLab

When passing the reference through the generic method, it seems that there's a value copy happening somewhere and eating the increment.

The boxed version works as expected.

IFoo foo = new Foo();
foo.IncrementThroughInterface();
Console.WriteLine(foo.Bar); // Successfully incremented

SharpLab

I find it particularly strange that this behaves differently from calling a non DIM interface member.

var foo = new Foo();
GenericallyIncrement(ref foo);
Console.WriteLine(foo.Bar); // Prints 1

void GenericallyIncrement<T>(ref T foo) where T : IFoo => foo.Increment();

interface IFoo
{
    void Increment();
}

struct Foo : IFoo
{
    public int Bar { get; set; }
    public void Increment() => this.Bar++;
}

SharpLab

I assume that this is intended behaviour, but it's not very intuitive and quite unhelpful. I had expected that the generics would allow me to call the interface method without boxing, but while it does get called, it's only on a copy.

Thinking through the consequences of this, I suppose that it means that any generic method that calls a DIM is required to put a class constraint on it in order to get the expected behaviour, right? Otherwise, it could be called with a value type and appear to be working but silently fail. The issue I see with that is that adding a DIM to an interface may require adding a class constraint to an existing API method, which would be a breaking change. One of the main goals of DIMs was to allow adding interface members without it being a breaking change.

Is there a way to get the behaviour that I expected without boxing?

What's the design reason behind this behaviour? I tried to find documentation on DIMs that would clarify this but haven't been able to find anything substantial, and I couldn't see this question of value types addressed when I skimmed the various discussions on here. Is there an up to date language specification somewhere? The only thing that I can find is a C#6 Draft... which obviously doesn't address DIM behaviour at all.

Is there any point in proposing a change to this? I assume not because that would break backwards compatibility.

I think there should at least be an analyzer warning here somewhere!

[CyrusNajmabadi]

This is the intended and supported behavior of hte runtime as i understand it. DIM will call through a boxed (as the interface) copy of the struct. So when teh interface method runs it mutates that copy, and the original does not see it.

An analyzer seems fine here. Requests for that would go to dotnet/roslyn-analyzers

What's the design reason behind this behaviour?

First, it's more that there was no other way to implement it. In the interface 'this' isn't some value type that the runtime can then go mutate. It's not a constrained generic type parameter either. So there's no way for the original value to get mutated in the case of value types. Known limitation of hte runtime which the language has a correspondence with.

Second, this is well outside the bounds of what DIM was intended for. Adding default behavior for mutable structs was definitely not something we felt was very important to make work. The primary use case was to be able to version interfaces in a compatible fashion without having an ABI break.

[HaloFour]

Having trouble finding the original discussions. As I recall a few potential solutions were looked at to avoid the boxing of this but they were all really complicated for both the runtime and the language (which would then have to treat this as a generic type parameter effectively) and considered not worth the effort.

[SamPruden]

That's good to know, thanks. I had assumed that they would be implemented something like static generic methods, but I understand that if that's now how they work then this is practically unsolvable. I assume there was good reason for not going down that route.

Perhaps I was abusing DIMs. I've got mutable ref structs for performance reasons and I was experimenting with using DIMs to specify default behaviours that those structs could override, much like classical inheritance. This seems like a natural way to use them and something suggested by their name, but I understand if that's not what they were intended for. I do find it a bit unfortunate that we now have language features that don't quite do the intuitive thing when put together, though. There are quite a number of additional ways this feature could be useful, but they're limited by this.

I'll try to get an issue filed in dotnet/roslyn-analyzers, but I don't think that I've thought about this quite enough for a detailed proposal yet.

[phizch]

Extension methods also "work", though they need struct or class constraints.

SharpLab

I think an analyzer would be a good idea. Not sure how the logic would go either :-)

[SamPruden]

Thanks for prompting me on this @phizch. I've put together an analyzers issue.

It's a little verbose I'm afraid - what's that old quote about "I would have written half as many words if only I had the time?"

Feel free to chime in there.