Modifier to mark interface implementation (implement complementing override)

[gatlex]

I suggest to introduce a modifier to mark a method as an implementation of the interface.

DR: It greatly introduces maintainability. It is quite common in large projects and medium-sized refactorings, that a method is removed from an interface - but the (former) implementation remains as dead code.

Edit: Another solution for my goal would be to 'improve' on explicit interface implementation as detailed in this comment.

---

Regarding naming I have no strong opinion. Two options that come to mind:

• Reuse override.
  Pro: Keyword exists.
  Con: Language lawyers will argue that this would not truly reflect the meaning as the method does not actually override but implements the interface method.
• New modifier implement or similar.

[HaloFour]

See also: #7210

For this specific case you could also use a custom attribute with an analyzer to warn/error on annotated methods that don't implicitly implement an interface member. This is kind of how @Override works in Java, the compiler will complain if the member doesn't actually override anything.

[gatlex]

Thank you very much for sharing your insights into the .NET runtime and explaining the connection to the proposal! (+1 now that I got it, btw.) To me it still seems, that the "runtime backend" found its way into the the "language frontend". Maybe the IL code is the same, but conceptually I still don't see the difference in making the "matching" of members explicit (between derived and base class respectively between implementing class and implemented interface).

What explicit implementation syntax do you mean, I'm not aware of anything of the sort? (Maybe its a mitigation in some cases.)

A disadvantage of the analyzer approach then is, that it makes explicit changes to each project necessary (set up the analyzer and add the dependency). While it might be feasible sometimes (and I certainly will use it in selected projects), it's not exactly 'lightweight'.

[CyrusNajmabadi]

What explicit implementation syntax do you mean, I'm not aware of anything of the sort? (Maybe its a mitigation in some cases.)

https://learn.microsoft.com/en-us/dotnet/csharp/programming-guide/interfaces/explicit-interface-implementation

[gatlex]

Ah, that one I actually know and now I think I know what you mean: The method in the example of the page

void IControl.Paint()

becomes in IL a private member with generated name, right?

That would be fine for me - but to use it, one has to upcast to the interface. Probably, that's what you mean by "[...] cannot be referenced from within the current type". I once stumbled over this, because I don't think it's what you would naivly expect (or only when ambiguities exist).

[HaloFour]

Imo, implementing an interface clearly models an 'is a' relation

Or include a bridge method which you can call directly:

void IControl.Paint() => this.Paint();

public void Paint() { ... }

[gatlex]

Or include a bridge method which you can call directly:

I know about this one. Imo its not practical, to laborious and much noise for nothing.

[the-avid-engineer]

You can use explicit interface implementations to get a similar effect

public interface IFoo
{
    void Bar();
}

public class Foo : IFoo
{
    void IFoo.Bar()
    {
        // implementation
    }
}

[CyrusNajmabadi]

I'd put it as more of a 'policitical' issue than a technical.

That's definitely a non-starter for language design. Imagine if every time we designed a feature, we had to duplicate it all over again because some org says they couldn't use it for political reasons.

Such reasons need to be hashed out by that group. The language is not the place to solve organizational dysfunction

[CyrusNajmabadi]

My very personal opinion, apart from that, is that [Implement] is syntactically simply not pretty when compared to public implementation void Bar().

Note: I don't think this language feature could even work.

Consider the following:

//Assembly1
interface I { void M(); }
class C { public void M() {} }

// Assembly2
class D : C, I { }

The compiler has no knowledge of D when compiling the first assembly. So it has no way to validate any sort of keyword.

This would have to be an attribute that could be analyzed with full context of the entirety of downstream dependencies

[the-avid-engineer]

@CyrusNajmabadi If it were a language feature, it would probably be lowered to an attribute much like required

[CyrusNajmabadi]

@CyrusNajmabadi If it were a language feature, it would probably be lowered to an attribute much like required

:-)

My point here is that it can't really be a language feature. Specifically because the analysis and requirements it brings about can't actually be validated by the compiler on its own. You have to know the entire set of downstream dependencies to actually validate things. Which is not something the language knows about or has ever created rules for.

[HaloFour]

@CyrusNajmabadi

Right, an implementation of something like this, whether as a language feature or an analyzer, I think would have to work similarly to Java's @Override annotation. It doesn't prevent implicit implementation, but if you mark a member and the compiler can't verify that the member implements an interface member, that would result in a diagnostic:

interface I {
    void M();
}

class A : I {
    public void M() { } // fine
}

class B : I {
    [Implements] public void M() { } // also fine

    [Implements] public void N() { } // diagnostic, N doesn't implement any interface members
}