Is it possible to make Expiclit Interfaces Protected instead of Private?

[malylemire1]

This would allow override of base classes implementing an explicit interface.

See this post for details :

http://stackoverflow.com/questions/5976216/how-to-call-an-explicitly-implemented-interface-method-on-the-base-class.

[HaloFour]

This is legal in the CLR. As long as the signature matches a virtual method may be overridden by a method with any name or accessibility. VB.NET does allow this now:

Public Class Foo
    Implements IDisposable

    Protected Sub Close() Implements IDisposable.Dispose
        ' dispose here
    End Sub
End Class

[malylemire1]

The problem I see for now is with existing code base.
It's assumed that explicit interfaces with no access modifier are private.
They should be kept private by default.

[KrisVandermotten]

As @malylemire1 pointed out, explicit interface implementations should be private by default. So the question is to be interpreted as: can we have syntax to make them protected?

But then, if you can make them protected, can you also make them internal? Or protected internal? Or even public? Public obviously makes no sense, and even the others don't feel right. In any case, it would be inconsistent that something that can be declared protected cannot be declared public.

There is an easy workaround available today: just have the explicitly implemented interface method call a protected helper method, virtual or not as needed. That leeds to a design pattern where an interface is not re-implemented in a derived class, which is a lot cleaner anyway.

[miloush]

@KrisVandermotten I don't see why making them public (or any other accessibility) makes no sense.
(I consider the explicit interface implementations in C# to be actually public members anyway, or of the visibility of the interface itself.)

Another way to solve this issue would be to allow (IInterface)base but if VB already features modifiers for interface members, it sounds like a reasonable way, should this be common enough scenario (or feature-parity between C# and VB was desired).

[gafter]

We are now taking language feature discussion in other repositories:

• https://github.com/dotnet/csharplang for C# specific issues
• https://github.com/dotnet/vblang for VB-specific features
• https://github.com/dotnet/csharplang for features that affect both languages

Features that are under active design or development, or which are "championed" by someone on the language design team, have already been moved either as issues or as checked-in design documents. For example, the proposal in this repo "Proposal: Partial interface implementation a.k.a. Traits" (issue 16139 and a few other issues that request the same thing) are now tracked by the language team at issue 52 in https://github.com/dotnet/csharplang/issues, and there is a draft spec at https://github.com/dotnet/csharplang/blob/master/proposals/default-interface-methods.md and further discussion at issue 288 in https://github.com/dotnet/csharplang/issues. Prototyping of the compiler portion of language features is still tracked here; see, for example, https://github.com/dotnet/roslyn/tree/features/DefaultInterfaceImplementation and issue 17952.

In order to facilitate that transition, we have started closing language design discussions from the roslyn repo with a note briefly explaining why. When we are aware of an existing discussion for the feature already in the new repo, we are adding a link to that. But we're not adding new issues to the new repos for existing discussions in this repo that the language design team does not currently envision taking on. Our intent is to eventually close the language design issues in the Roslyn repo and encourage discussion in one of the new repos instead.

Our intent is not to shut down discussion on language design - you can still continue discussion on the closed issues if you want - but rather we would like to encourage people to move discussion to where we are more likely to be paying attention (the new repo), or to abandon discussions that are no longer of interest to you.

If you happen to notice that one of the closed issues has a relevant issue in the new repo, and we have not added a link to the new issue, we would appreciate you providing a link from the old to the new discussion. That way people who are still interested in the discussion can start paying attention to the new issue.

Also, we'd welcome any ideas you might have on how we could better manage the transition. Comments and discussion about closing and/or moving issues should be directed to #18002. Comments and discussion about this issue can take place here or on an issue in the relevant repo.

---

I have not moved this feature request to the csharplang repo because I don't believe it would ever rise in priority over other requests to be something we would ever do in any particular release, in part because of the limited improvement in expressiveness (as @KrisVandermotten pointed out, there is a straightforward way to get the desired effect today). However, you are welcome to move discussion to the new repo if this still interests you.