Protected interface methods

[bernd5]

I posted last year the following issue dotnet/roslyn#43680

With the following content:

Protected interface members seem to prohibit members in implementing types with the same name and non explicit interface implementations.

Consider the following code:

using System;

namespace ProtectedInterfaceMember
{
    interface ISomething
    {
        protected void DoInternal()
        {
            Console.WriteLine("This the default impl. for ISomething.DoInternal()");
        }

        void Do()
        {
            DoInternal();
        }
    }

    public class App : ISomething
    {
        public void DoInternal()
        {
            Console.WriteLine("This has nothing to do with ISomething");
        }

        public static void Main()
        {
            ISomething app = new App();
            app.Do();
        }
    }
}

If you compile it with roslyn you get error "CS8704", which says you can't override / implement the protected interface member implicitly. If you want to do this it must be done explicit.

I think this should be just a warning or completely removed. If you extend an interface with such protected methods you may break existing code.

In the spec I couldn't find a reason why this situation should cause an error.

---

This situation makes the usage of protected interface members very difficult. Is this a roslyn bug or is it intended?

[AlekseyTs]

This is by design, see section https://github.com/dotnet/csharplang/blob/main/proposals/csharp-8.0/default-interface-methods.md#overrides-in-interfaces: "members that are not public may only be implemented in a class or struct explicitly (not implicitly)."

If you extend an interface with such protected methods you may break existing code.

Adding an abstract API to an existing interface has always been a breaking change. I really do not see non-public accessibility making it any worse than it always was.

[bernd5]

My problem is that this DoInternal() method of the class (which is no explicit interface implementation) is not ignored.
Why does it cause an error? It has nothing to do with the interface as far as I understand the spec:

Closed Issue: How does one implement a non-public interface member in a class?
Decision: You can only implement non-public interface members explicitly

I would be okay with a warning - to make it more clear that this is not an interface implementation. But currently it is an error!

Assume you had a class which has such a method, and the interface is extended with such a protected method to define a default implementation with a customization point (which should not be called directly from interface users).
Now the method in the class (which has by accident the same name) causes a compile error...

[jnm2]

@AlekseyTs The code example shows that we're not talking about adding an abstract API to an existing interface but rather a member with a default implementation, right? The reason for the existence of the DIM feature was to add new members to interfaces without breaking implementors.

[bernd5]

To make it more clear, assume the following situation:

using System;
using System.Collections;
using System.Collections.Generic;

interface ICollectionX<T> : IEnumerable<T> 
{
    public void Add(T t);
    public void Remove(T t);
}

public class ComplexCollection<T> : ICollectionX<T>
{
    public int Count() => 42; 
    
    //assume implemented..
    public void Remove(T t) => throw new NotImplementedException();
    public void Add(T t) => throw new NotImplementedException();
    IEnumerator IEnumerable.GetEnumerator() => throw new NotImplementedException();
    IEnumerator<T> IEnumerable<T>.GetEnumerator() => throw new NotImplementedException();
}

This is now extended with a protected Count() method for use in other interface methods:

using System;
using System.Collections;
using System.Collections.Generic;

interface ICollectionX<T> : IEnumerable<T> 
{
    public void Add(T t);
    public void Remove(T t);
    
    protected int Count(){
        int cnt = 0;
        foreach(var _ in this) ++cnt;
        return cnt;
    }
}

public class ComplexCollection<T> : ICollectionX<T>
{
    public int Count() => 42; 
    
    //assume implemented..
    public void Remove(T t) => throw new NotImplementedException();
    public void Add(T t) => throw new NotImplementedException();
    IEnumerator IEnumerable.GetEnumerator() => throw new NotImplementedException();
    IEnumerator<T> IEnumerable<T>.GetEnumerator() => throw new NotImplementedException();
}

Now it does not compile anymore. Roslyn says:

error CS8704: 'ComplexCollection' does not implement interface member 'ICollectionX.Count()'. 'ComplexCollection.Count()' cannot implicitly implement a non-public member.

[CyrusNajmabadi]

This does seem like an issue for me. Tagging @MadsTorgersen . The error is particularly strange:

error CS8704: 'ComplexCollection' does not implement interface member 'ICollectionX.Count()'. 'ComplexCollection.Count()' cannot implicitly implement a non-public member.

First, ComplexCollection does implement htat interface member. It does definitionally as this is a DIM, so the implementation is already there.

Second: "ComplexCollection.Count()' cannot implicitly implement a non-public member." Why are we error'ing there? Why are we trying to implicitly impl a non-public DIM member in the first place?

[CyrusNajmabadi]

I'm also worried about the source-breaking change aspect here. Adding a DIM and causing an error that an existing type will no longer build because it happens to have the same name seems just...wrong.

[AlekseyTs]

Thank you for clarifications. If I remember correctly, the motivation behind the error is to guard a user against falling into the muscle memory "trap" by using an implicit implementation to implement non-public APIs. This is not just about protected, but about any non-public APIs. The error is reported because it looks like the intent might be to actually implement the API rather than rely on possible default implementation or implementation from a base class. The error is reported only when the signature fully match, etc. I.e. only when accessibility is the only reason to "ignore" the API as an implementation. Certainly, this behavior can cause some inconvenience as you demonstrated. It might be worth considering removal of the error, since DIM feature is no longer new.

[bernd5]

Without the removal any larger framework can't use protected interface members at all.
Imagine we would add a protected interface member to IEnumerable<T> or IDisposable - the chance to break something is high.
For private interface members there is no warning or error emitted - just for protected ones.

[MgSam]

I think this situation is related and I find the result extremely confusing.

public interface IFoo
{
    public string Bar { get; internal set; }
}

public class Foo : IFoo
{
    public string Bar { get; internal set; } //Error - Non-public accessor "Bar.set" cannot implement accessor from interface IFoo
}

Why is this code invalid? And even if there is a good reason, the error given is not very good.