Proposal: Allow calling interface methods through 'this'

[gulshan]

In C#, interface methods have to be called through the interface. Previously without default implementations of methods, classes implementing an interface can also call them directly (if not explicitly implemented). Also extension methods to some interface (not implementation class) was/is available to this of the implementation. But now interface methods with default implementations have to be called through the interface, which sometime become very inconvenient. So, proposing here to allow calling interface methods through this (implicit direct call or explicit call through this.). The following snippet is to show the proposal with example code-

interface IFoo { string Foo() => "Foo"; }
interface IBar { void Bar(string bar) { } }
interface IBaz { void Baz(); }

static class IBazExtension
{
    static public void Baz2(this IBaz baz) { }
}

class FooBarBaz : IFoo, IBar, IBaz
{
    public void Baz() { } // Not explicit implementation

    void SomeMethod()
    {
        // what previously was done, without default implementation
        Baz();
        this.Baz2();

        // What we have to currently with default implementation
        var foo1 = ((IFoo)this).Foo();
        (this as IBar).Bar(foo1);
        (this as IBar).Bar(((IFoo)this).Foo());

        // Proposing (only for 'this'), not allowed now
        var foo2 = this.Foo(); // with explicit 'this.'
        Bar(foo2); // without explicit 'this'
        Bar(Foo());
    }
}

[DaZombieKiller]

Not being able to call interface members through this also has the issue of causing boxing allocations with structs. You can work around it, of course (which is the same workaround you can use for explicitly-implemented interface members):

using System;

public interface IHelloWorld
{
    void HelloWorld() => Console.WriteLine("Hello, world");
}

public struct HelloWorldStruct : IHelloWorld
{
    public void DoHelloWorldBoxing()
    {
        ((IHelloWorld)this).HelloWorld();
    }
    
    public void DoHelloWorldNonBoxing()
    {
        CallHelloWorld(ref this);
        
        static void CallHelloWorld<T>(ref T @this)
            where T : struct, IHelloWorld
        {
            @this.HelloWorld();
        }
    }
}

But it'd be a lot nicer to be able to just call it directly.

[HaloFour]

@gulshan

The team already decided on the syntax base(IFoo).Foo() for invoking the default implementations of the interface directly.

[alrz]

@HaloFour doesn't that only point to implementations from base?

[HaloFour]

@DaZombieKiller

Not being able to call interface members through this also has the issue of causing boxing allocations with structs.

Unfortunately that's the case with default implementations regardless of how you call them. The runtime still boxes the receiver and passes as an instance of the interface.

[HaloFour]

@alrz

doesn't that only point to implementations from base?

I don't believe so, reading #2337 it sounds like that syntax would also be used to invoke the default implementation on the interface directly: #2337 (comment)

[alrz]

I mean if we have something like this:

interface I { void M() {} }
class B : I { void I.M() {} }
partial class C : B, I { void I.M() {} }
partial class C { void Test() { base(I).M(); } }

the last line calls to which implementation? what if we want the impl from C? (or any others?)

[HaloFour]

@alrz

the last line calls to which implementation?

IIRC that calls the default implementation defined on I.

what if we want the impl from C? (or any others?)

I don't think that the base syntax is intended to dispatch to explicit implementation on the current or base classes. This proposal discusses DIM specifically, although I can see it applying to explicit implementation, but not to the base class (unless the current class doesn't also explicitly implement the same method on that interface).

Either way I don't think changing the behavior to surface implemented interfaces via this is the appropriate route, especially where explicit implementations are involve. It would be a source breaking change as that method could already be overloaded.

[SilentSin]

Unfortunately that's the case with default implementations regardless of how you call them. The runtime still boxes the receiver and passes as an instance of the interface.

Couldn't the compiler generate a private method for the explicit interface method to call so that any local calls can directly use the private method?

That could even allow other access modifiers. I would love to be able to write protected virtual void IThing.SomeMethod()... instead of needing to manually write the explicit implementation to call the virtual method.

It would be a source breaking change as that method could already be overloaded.

What if you just give explicit implementations lower priority for overload resolution than everything else? Potentially even lower than extension methods if necessary.

[HaloFour]

@SilentSin

Couldn't the compiler generate a private method for the explicit interface method to call so that any local calls can directly use the private method?

Yes. The C# compiler goes out of its way to make the method uncallable. That was an explicit design decision. You can write your own private method and have the explicit implementation call that.

.NET doesn't care what the accessibility level or the name is of the overriding method, as long as the signature matches. That's why you can do this in VB.NET:

Public Class Foo : Implements IDisposable
    Private Sub Close() Implements IDisposable.Dispose
    End Sub
End Class

[SilentSin]

@HaloFour

The C# compiler goes out of its way to make the method uncallable. That was an explicit design decision. You can write your own private method and have the explicit implementation call that.

But why?

It doesn't even give a warning for giving a regular method the same name as an explicit one so it obviously can't be that bad of a design decision, yet it "goes out of its way" in a way that actually costs runtime performance to prevent a slightly less verbose implementation of the exact same behaviour.

[HaloFour]

@SilentSin

It doesn't even give a warning for giving a regular method the same name as an explicit one

Because the regular method doesn't have the same name.

yet it "goes out of its way" in a way that actually costs runtime performance to prevent a slightly less verbose implementation of the exact same behaviour.

How often do you really want to call an explicit implementation from within the class? The language shouldn't optimize for the unlikely.

[theunrepentantgeek]

But why?

If the C# compiler used a callable name (sometimes referred to as a "speakable" name) for an explict interface implementation, there's a significant probability that it would collide with a method name already in use. Making the method uncallable (by giving it an "unspeakable" name) prevents these collisions.

[SilentSin]

@HaloFour

Because the regular method doesn't have the same name.

It might not compile to the same name, but it sure does have the same name in the source code. My point is that if that was actually a bad pattern worth preventing, then there should be a warning for it.

How often do you really want to call an explicit implementation from within the class?

From a private context within the class itself: not too often.

But from a protected virtual and/or internal context: quite often. internal interfaces are very convenient for standardising functionality without necessarily exposing it publicly.

[HaloFour]

@SilentSin

It might not compile to the same name, but it sure does have the same name in the source code. My point is that if that was actually a bad pattern worth preventing, then there should be a warning for it.

No it doesn't. The name in source code includes the interface name, just as it does in IL. Having another method with the same name isn't considered a bad pattern. It's fairly normal, especially where the names collide between two interfaces and you need to explicitly implement one or the other, like with IEnumerable<T>.GetEnumerator and IEnumerator<T>.Current.

[SilentSin]

@HaloFour

Having another method with the same name isn't considered a bad pattern.

I agree, but I got the impression you felt differently because you said:

The C# compiler goes out of its way to make the method uncallable. That was an explicit design decision.

If it's not bad, then why explicitly go out of your way to prevent a simpler implementation?

[HaloFour]

@SilentSin

Making the explicit implementation uncallable enables implementing two interfaces that share a method that differs only by return type.

[gulshan]

@HaloFour

The team already decided on the syntax base(IFoo).Foo() for invoking the default implementations of the interface directly.

I think this proposal is valid as long as this is not proposing a breaking change. Also, I have found the concept of "Most specific override rule" here- https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/proposals/csharp-8.0/default-interface-methods#the-most-specific-override-rule . If I am not wrong, according to this rule, even with default implementations, there will always be exactly one "most specific" implementation (either default implementation from interface or an implementation in the implementing class) for any interface member. And this proposal is about calling that single most specific implementation of some interface member through this (implicitly or explicitly).

Please correct me if I'm wrong.

[SilentSin]

@HaloFour

If the mere possibility of ambiguity was enough to prevent a feature from being implemented, then we wouldn't have method overloads at all. I can't help but feel that you're being deliberately obtuse given how obvious the solution is: allow it if there is no ambiguity or give an error if there is any, just like with other method overloads.

[HaloFour]

@SilentSin

If the mere possibility of ambiguity was enough to prevent a feature from being implemented, then we wouldn't have method overloads at all.

If C# were being designed today you'd probably have a number of proponents of that theory. Method overloading represents probably the most complicated part of the C# compiler.

I can't help but feel that you're being deliberately obtuse given how obvious the solution is: allow it if there is no ambiguity or give an error if there is any, just like with other method overloads.

That would immediately break a lot of existing code. Given how IEnumerable<T> and IEnumerator<T> interfaces extend from IEnumerable and IEnumerator respectfully every single implementation of those interfaces is required to disambiguate through explicit implementation and relies on the compiler not consider the explicit implementation to be an invocable member.

I wasn't there 20 years ago when this was being designed. I doubt the current team members have the context that went into the decision. The CLR provides a fairly flexible method for overriding members (both for interfaces and base classes), C# chose one design and VB.NET chose a different design. Neither design prevents developers from accomplishing anything. C#'s syntax optimizes for the common case whereas VB.NET's flexibility comes with a lot of verbosity in all cases.

I'm not opposed to having syntax for invoking the most specific override of a given interface member, I just don't think that those members should appear to be automatically "inherited" into the current class, either publicly or via this. If base(T).M doesn't offer that facility I'd suggest bringing it up as a part of that proposal so that it can be considered.

[Joe4evr]

I wonder if one could convince the language team to consider this(T) invocation in addition to base(T), so that the syntax itself is clearly unambiguous and it's guaranteed you're calling the member defined on the class rather than a potentially default-implemented version. 🤔

[CyrusNajmabadi]

I doubt the current team members have the context that went into the decision.

I've got some context here (though i was an intern at the time :)). What is it you'd like to know? I think the issue here has gone over the topic space pretty well afaict.

[HaloFour]

@CyrusNajmabadi

What is it you'd like to know?

I'd be curious as to the design process that led to explicit implementation of interface members. It's not something born of the legacy of C++ or Java. It's quite a different from the approach taken by the VB.NET team, which wasn't inherited from VB either. Given the flexibility provided by the CLR it's interesting to hear why the languages chose to surface that functionality differently.

[CyrusNajmabadi]

my recllection is that these methods were truly thought of us bridges from the interface into functionality provided by the class. it was not felt that they were something expected to be exported from teh class itself as part of its surface. After all, ignoring renaming, there would be no way to export multiple interface methods with the same sig (which was hte prime case for explicit interface impl).

So the general feeling at the time was:

1. you would define your public surface area of your class. And you'd provide methods like string BankAccount() { } string UserAccount { }.
2. you would then implement your interfaces, like IProvidesBankAccount { string Account { get; } } IProvidesUserAccount { string Account { get; } }, and you'd use the explicit impl to dispatch to whatever class surface shape you wanted.

The idea of having the class itself want to defer to the interface didn't every really seem important. why would it need to since it had full access to its full surface area?

I can't say as to why VB did what it did. My guess is that they just found it easier or more cohesive to just have the methods be normal speakable methods and not have to have the indirection of the explicit one calling the actual class method. So they merged it into a single concept where you could directly provide the redirected name.

[CyrusNajmabadi]

Another way to think about it: explicit interface impl was expected to be the rare case. i.e. you'd normally just implement the methods implicitly and be good and done with things. C# even goes extra far to make that easy. for example:

class C
{
    public void Foo() { }
}

interface IFooable { void Foo(); }

class D : C, IFooable { }

In this case, C# will ensure that instances of D will see C.Foo as their impl of IFooable.Foo. This is unlike VB where you would actually have to provide a truly explicit method that says it impls IFooable.Foo.

So, in essence C# heavily weights toward making implicit impl easy and the norm. And explicit-impl exists primarily for collisions (i.e. times when you can't be implicit). VB heavily weights toward making everything explicit.

Tihs has led to where we are now where calling through the interface method was never felt to be something that important. But dim changes that equation (significantly) IMO.

[SilentSin]

That would immediately break a lot of existing code. Given how IEnumerable and IEnumerator interfaces extend from IEnumerable and IEnumerator respectfully every single implementation of those interfaces is required to disambiguate through explicit implementation and relies on the compiler not consider the explicit implementation to be an invocable member.

I can see 3 general possibilities:

1

public IEnumerator<T> GetEnumerator()...
IEnumerator IEnumerable.GetEnumerator()...
...
this.GetEnumerator();// Calls the top one because it's not an explicit interface method.

2

IEnumerator<T> IEnumerable<T>.GetEnumerator()...
IEnumerator IEnumerable.GetEnumerator()...
...
this.GetEnumerator();// Ambiguity error.
// Not a breaking change because it wouldn't currently compile anyway.

3

IEnumerator IEnumerable.GetEnumerator()...
...
this.GetEnumerator();// Calls the method.
// Not a breaking change because it wouldn't currently compile.

So where's the use case that you think would cause a breaking change?

[HaloFour]

@CyrusNajmabadi

Tihs has led to where we are now where calling through the interface method was never felt to be something that important. But dim changes that equation (significantly) IMO.

Mind expanding on this?

I didn't see DIM as being much more than an addendum to the contract between the interface and the consumer of that interface. The implementer isn't really involved unless it implements those defaulted members. In that case it makes sense to want to invoke the default implementation, like a override of a virtual member might want to call the base member. But beyond that I don't see it that necessary to invoke the default implementations (or the most specific override). DIM doesn't feel like traits or a way to compose common behavior to types given that the defaulted members are not "inherited" by the implementer, which, IMO, is slightly unfortunate.

[CyrusNajmabadi]

Mind expanding on this?

DIM provides actual functionality that a class may want to use. Very specifically, it is different from before since previously the class would only have been able to use functionality that it itself created (and thus would have access to). In the non-DIM world, i see little need for a class to call through the interface methods of itself (instead it could just call into the real code that those interface methods just ended up using). But now, the "real code" lives in the interface portion itself.

In this regard DIM interfaces straddle the line between being an interface for a class that they implement, and being an abstract base class that they inherit. In the latter view, you would def expect to be able to easily get at this functionality as if it was just in a subclass.

Note: i don't feel strongly about this. :)

[GeeLaw]

Instead of restricting it to only work with this, I propose a syntax that allows calling interface method on any expression.

Let expr be an expression of primary operation or a variable (this means expr.Foo will be resolved as member Foo of expr, which is not true for a + b.Foo). The syntax expr.(interface).member can be used to access the member member of interface interface. Some other possibilities and refutation:

• expr.(interface)member feels like casting member (though there is no syntactical ambiguity).
• expr(interface).member confuses with invoking delegate then accessing member of return value if interface is color-color.
• expr(interface)member does not have . to represent member access (though there is no syntactical ambiguity).
• expr.interface.member is hard to parse since interface itself might contain . and confuses with multi-level member access.

The run-time behaviour should be identical to the trick to access interface member with generics:

• For reference-typed expressions, it always calls the most derived implementation of the interface member.
• For value-typed expressions, if the struct implements the member, no boxing should happen and the mutation should reflect in the variable if the expression is a variable. Otherwise, the interface member uses the default implementation, thus whatever applies to default implementation applies here (e.g., boxing).

For example,

interface I { void Foo() { } }
struct Struct : I, IDisposable
{
  void IDisposable.Dispose() { }
  // No boxing.
  public void Close() { this.(IDisposable).Dispose(); }
  // Boxing.
  public void Bar() { this.(I).Foo(); }
}
// No boxing.
new Struct().(IDisposable).Dispose();
// Boxing.
new Struct().(I).Foo();

Given the new syntax, base(interface). would be obsolete.

---

@SilentSin

Unfortunately that's the case with default implementations regardless of how you call them. The runtime still boxes the receiver and passes as an instance of the interface.

Couldn't the compiler generate a private method for the explicit interface method to call so that any local calls can directly use the private method?

Did you mean "generate a private method for the default interface member implementation"? This will not help in avoiding boxing, because all the compiler can do is to call the default implementation in the private method, and it's the action of calling the default implementation that causes boxing. (More generally, calling a method not implemented by the value type itself requires boxing. So the DIMI is like ToString, GetHashCode, and Equals of System.ValueType.)

The compiler cannot copy the code of the default implementation, since the interface might be in another assembly and should be able to be replaced without having to recompile the struct.