Default interface methods

[stakx]

The upcoming .NET Core 3.0 along with C# 8 will support default interface methods.

It is likely that DynamicProxy won't support those properly (e.g., Proceed?) without some changes. This is a reminder to look into this.

[thomaslevesque]

I just looked into it. Proceed indeed doesn't work:

NotImplementedException: This is a DynamicProxy2 error: The interceptor attempted to 'Proceed' for method 'Int32 get_Area()' which has no target. When calling method without target there is no implementation to 'proceed' to and it is the responsibility of the interceptor to mimic the implementation (set return value, out arguments etc)

(which makes sense, since default implementations aren't actually inherited by the implementing class)

Interface methods with default implementation have IsAbstract == false

[thomaslevesque]

The only workaround I found so far for FakeItEasy is to call the default interface method non-virtually, by emitting IL with a call opcode instead of callvirt.
https://gist.github.com/thomaslevesque/a4310070de3d44f81144aafd136bea7c
Hopefully it can be done in a cleaner fashion in Castle.Core...

[stakx]

@thomaslevesque, I've wanted to look into this earlier in the past week, now that .NET Core 3 and .NET Standard 2.1 have been released. Unfortunately, I realised quickly that VS2019 as an IDE isn't up to the task: Compilation is very unreliable and haphazard, I get different compilation errors (often bogus ones, too) on every single build. That makes it difficult to properly develop and test against .NET Core 3. I'll see if I'm more lucky with Rider IDE. Otherwise, it'll be the command line, or another wait until VS2019 is actually usable. 😞

[thomaslevesque]

Unfortunately, I realised quickly that VS2019 as an IDE isn't up to the task: Compilation is very unreliable and haphazard, I get different compilation errors (often bogus ones, too) on every single build.

Really? It seems to be working fine for me. Have you tried cleaning everything (bin/obj/.vs) and killing the build server processes?

[thomaslevesque]

Anyway, I wonder what the correct behavior should be...
Should Proceed call the default implementation automatically? Or should it be explicit?
I'm leaning toward the former, but it might have side effects that I'm not seeing...

[stakx]

outdated

Have you tried cleaning everything (bin/obj/.vs) and killing the build server processes?

Several times, yes. Even reinstalled the whole thing on several occasions, with no better luck on subsequent tries. There's no way on Earth that I am going to do these contortions every time I need to use VS. I'd rather stay with VS1017. 😆

Should Proceed call the default implementation automatically? Or should it be explicit?

I would also prefer the former, but implicit Proceed-ing might not always be possible: One of the more difficult problems the C# language design team had to solve with default interface implementations revolved around the case where the same interface method can have different default implementations (think diamond-shaped / multiple inheritance). IIRC, they resolved it with a new, parameterized form of the base keyword. (Edit: That seems to have been resolved differently in the final released product.) I'll need to study that in more detail, but I suspect the implications of that are that Proceed might not always be able to figure out by itself which base implementation to call, and you'd have to provide explicit disambiguation.

[stakx]

This may be much easier to implement than I had previously assumed.

Up until now, I was mostly thinking about how to implement Proceed for interface methods having a default implementation. This would be akin to class override methods invoking the base class' overridden method. However, base support for default interface methods was dropped for C# 8 and, AFAIK, hasn't been added since.

This reduces the problem to ensuring two things:

1. DynamicProxy should be prepared to find some new constructs in interfaces, e.g. sealed methods (Fix MissingMethodException when proxying interfaces containing sealed methods #621) and static or non-public members. The adjustments necessary to support those probably aren't too tough.

2. When one chooses (via IProxyGenerationHook) not to intercept an interface method that has a default implementation, DynamicProxy should forward to the latter. We've probably laid the mental groundwork for this already in Forward non-intercepted methods on class proxies to target #571, and we might be able to simply leverage MetaMethod.Ignore to tell DynamicProxy not to create an override for the default implementation.

I'll give this a try later today.

[andreminelli]

This may be much easier to implement than I had previously assumed.

Up until now, I was mostly thinking about how to implement Proceed for interface methods having a default implementation. This would be akin to class override methods invoking the base class' overridden method. However, base support for default interface methods was dropped for C# 8 and, AFAIK, hasn't been added since.

This reduces the problem to ensuring two things:

1. DynamicProxy should be prepared to find some new constructs in interfaces, e.g. sealed methods (Fix MissingMethodException when proxying interfaces containing sealed methods #621) and static or non-public members. The adjustments necessary to support those probably aren't too tough.
2. When one chooses (via IProxyGenerationHook) not to intercept an interface method that has a default implementation, DynamicProxy should forward to the latter. We've probably laid the mental groundwork for this already in Forward non-intercepted methods on class proxies to target #571, and we might be able to simply leverage MetaMethod.Ignore to tell DynamicProxy not to create an override for the default implementation.

I'll give this a try later today.

Hi, @stakx
Have you tried that at all?
I am trying to help on an issue in NSubstitute where this support would make thinks easier for sure.