Inconsistent use of keywords between classes and interfaces

[panagiotidisc]

It is a reasonable assumption to make that interfaces work like abstract classes that provide only methods, and don't have their own storage (fields). It logically follows from that assumption that access modifiers (public, private, protected, internal and static) and inheritance keywords (virtual, abstract, sealed, and override) behave the same as with classes. However, usage of these keyword, as well as compiler messages (or lack thereof) can very easily lead to nonsense and bug-prone code.

I will present several scenarios that illustrate the poor design of interfaces:

Topic 1: protected is not respected

Currently the following is perfectly valid code and compiles with no issues:

C asClass = new C();
I asI = asClass;
Console.WriteLine(asI.MyString);
asClass.MyString = "NO!";
Console.WriteLine(asI.MyString);

public interface I
{
	public string MyString { get; protected set; }
}

public class C : I
{
	public string MyString { get; set; } = "protected from set?";
}

output:

protected from set?
NO!

The compiler has allowed C to implement MyString+get, and has silently made a new public MyString+set method, different from the protected I.MyString+set, and has not given us a CS0108 warning.
Even stranger is that the following is allowed, and again does not give a CS0108 warning or an error:

public interface I
{
	protected string MyString { get; }
}

public class C : I
{
	public string MyString { get; set; }
}

This looks like the compiler is generating the backing field for C.MyString, and then implicitly implements I.MyString.
Additionally, explicitly implementing I.MyString causes even more issues.
The following is ok:

public interface I
{
	public string MyString { get; set; }
}
public class C : I
{
	string I.MyString { get; set; }

	string foo()
	{
		//return MyString; compiler error
		return (this as I).MyString; // too verbose if there is no ambiguity
	}
}

But if we change the setter to protected we suddenly cannot use the setter!

public interface I
{
	public string MyString { get; protected set; }
}
public class C : I
{
	string I.MyString { get; set; } //what even is this setter?

	string foo()
	{
		//(this as I).MyString = "foo"; //we get CS1540 which makes no sense
		return (this as I).MyString; //public getter so we are good
	}
}

Ok getters and setters are weird, but what about normal methods? They don't make sense either:

public interface I
{
	protected void Foo();
	protected void Bar() { //... }
}
public class C : I
{
	protected void Foo() { //... } //no CS0108 warning
	void I.Foo() //protected access keyword not allowed
	{
		(this as I).Bar(); //once again nonsense CS1540
	}
}

Unlike the auto-implemented protected set, it is mandatory to implement the purely virtual I.Foo method, but once again we cannot access protected interface methods.

I am aware that the above errors wouldn't appear if C was an interface instead of a class, but given that interfaces HAVE to be implemented by a class eventually, this weird inheritance model is... convoluted to say the least, especially to a newcomer to c#.
Combined with the following issues, I believe making a library with a lot of interfaces and implementor classes becomes an exercise in madness

Topic 2: default implementations are implicitly virtual for implementor classes, and hidden by deriving interfaces

I think this is a very peculiar feature(?) Consider the following code:

C c = new();
c.Foo();
(c as I).Foo();
(c as I2).Foo();
//c.Bar(); //compiler error
(c as I).Bar(); //verbose

public interface I
{
	public void Foo()
	{
		Console.WriteLine("I::Foo");
	}
	public virtual void Bar() //virtual keyword is legal, but does nothing
	{
		Console.WriteLine("I::Bar");
	}
}

public interface I2 : I
{
	public void Foo() //CS0108 hiding inherited member
	{
		Console.WriteLine("I2::Foo");
	}
	//public override void Bar() //CS0106 override keyword is invalid
	//{
	//	Console.WriteLine("I2::Bar");
	//}
}
public class C :  I, I2
{
	public void Foo()
	{
		Console.WriteLine("C::Foo");
	}

	/* override */void I.Bar() //CS0106 override keyword is invalid
	{
		Console.WriteLine("C::Bar");
	}
}

output:

C::Foo
C::Foo
C::Foo
C::Bar

The virtual keyword serves no purpose. You either override implicitly in the case of classes, or hide in the case of interfaces.
Furthermore, both I and I2's Foo have been overridden by C's Foo. The compiler has solved the diamond problem for us. Did we mean for it to do it? Maybe.
Would it be easy for a developer to do this by accident? Absolutely.
If during development the author chooses to seal I2.Foo without being aware that C is implicitly overridding it, then other code will potentially misbehave.
It also doesn't help that when a coder wants to be explicit about what he is implementing (void I.Bar() { //... }) to avoid such an issue, that now a consumer of the class must always cast C to I before calling I.Bar, even when there is no ambiguity.

The following scenario illustrates another "quirk" of default interface implementations:

C1 c1 = new C1();
(c1 as I).Foo();
C2 c2 = new C2();
(c2 as I).Foo();

public interface I
{
	public void Foo()
	{
		Console.WriteLine("I");
	}
}

public class C1 : I
{
	public virtual void Foo()
	{
		Console.WriteLine("C1");
	}
}

public class C2 : C1
{
	public override void Foo()
	{
		Console.WriteLine("C2");
	}
}

output:

C1
C2

It would be easy to forget that I.Foo can be overridden, and not only are we overridding it, but we are also allowing it to be overridden by derived classes too!
Moreover, if no virtual or abstract keyword is applied by the base class C1, it is as if it implicitly adds the sealed keyword to the Foo, and the one writing the C2 may become perplexed as to why they can't override I's Foo.

For classes the sealed keyword can only be applied to virtual members, as such I think default interface implementations should be implicitly sealed, the virtual and abstract keywords should be applied explicitly, and implementors must apply the override and/or sealed keywords explicitly.

Topic 3: static operators

Building on 4436's proposal for mandatory operators, I think we should be able to apply or relax more restrictions. Suppose we want to define an interface for a commutative operation:

public interface ICommutative
{
	public int Number { get; }
	static int operator +(ICommutative t1, ICommutative t2)
	{
		return t1.Number + t2.Number;
	}
	static int One => 1;
}

It is trivial to prove ICommutative's + operator is actually not commutative.

C1 c1 = new C1();
C2 c2 = new C2();
Console.WriteLine(c1 + c2);
Console.WriteLine(c2 + c1);
Console.WriteLine((C1)c2 + c1);

public class C1 : ICommutative
{
	public int Number => throw new NotImplementedException();

	public static int operator +(C1 c1, C1 c2)
	{
		return 0;
	}
}

public class C2 : C1
{
	public static int operator +(C2 c1, C1 c2)
	{
		return 1;
	}
}

output:

0
1
0

C1 and C2 define their own + operators, and completely ignore ICommutative's + operator. As operators are static members, no hiding warnings are issued. I believe there is merit to allowing the abstract, virtual, override, and sealed keywords to static members of both classes and interfaces.

Bonus Topic 4: variant classes

Due to all the weird quirks with the interactions between classes and interfaces, I see merit to allowing variant classes.
From a language design perspective, the only extra restriction that classes would have would be to not allow covariant and contravariant generic parameters as Fields. Properties on the other hand can be covariant if they are get-only

[HaloFour]

Interfaces have evolved substantially since their initial design in C# 1.0, which is where I believe the majority (if not all) of these warts originate. If interfaces were to be redesigned today they would likely adopt different syntax.

What is the intent of this discussion? To suggest changing interface syntax or improve diagnostics? It would be exceptionally difficult to do anything meaningful to the syntax without the potential for massive breaking changes.

[CyrusNajmabadi]

Warning can be added without breaking changes.

They also cause breaks.

As far as I know, the CLR has no concept of public, private,

It very much does have these concepts:-)

[CyrusNajmabadi]

But if we change the setter to protected we suddenly cannot use the setter!

Correct. C is an implementation of the interface. It does not inherit it. Protected applies to types in the inheritance hierarchy of the original type.

[CyrusNajmabadi]

The virtual keyword serves no purpose

Originally, everything was abstract in an interface. Later in c# we started allowing non-abstract members. So we added the ability to be explicit for the abstracts so you could easily distinguish them if you wanted. But we have to maintain compat with c#1. So they are optional.

[CyrusNajmabadi]

as such I think default interface implementations should be implicitly sealed,

This goes against the primary purpose of DIMs, which is to provide a simple impl of an interface, while ensuring that implementations can change that impl.

DIMs intentionally work just like normal interface members (and are effectively invisible at the consumption point). All they do is impact the impl side by making some of the members optional to implement.

and implementors must apply the override

The impls are not overrides. As a clear example of this, you cannot use base. within them. There is no inheritance relationship here. Just an implementation relationship. The impl class provides the impl method, and this is all compiled such that the entry for the interface member slot points at that class member (or sometimes a bridge member).

Interfaces are not abstract classes. From the impl side, they're just a contract to implement, nothing more.

[CyrusNajmabadi]

(this as I).Bar(); //once again nonsense CS1540

Why would C be able to access arbitrary protected members of the interface. We don't allow that with normal protected inheritance. If the above was allowed, then C could cast any other impl of I to I and get access to protecteds, when would violate access rules.

The point of explicit impl is to hide from your public surface area. Once you hide, yes, you possibly do not have access yourself anymore. That's been the intent and how things have worked with interfaces in .net since 1.0 :-)

If you want the never to be visible to yourself, define a member with the accessibility you want.

[HaloFour]

As for the accessibility modifiers on the interface, there is nothing that stipulates that the class must match them. The contract is between the interface and the consumer, not the implementer. As such, the interface stipulates the accessibility modifiers of the members exposed to consumers of that interface. The class is free to implement the interface as it sees fit, though. Explicit implementation is always private, for instance, and that's been true since C# 1.0.

[panagiotidisc]

Explicit implementation being private is easily worked around by (this as I), so I see no reason for it to be the case.
As for classes, being mandated to implement pure virtual protected interface members, but not being able to access them seems very contradictive.

[HaloFour]

As for classes, being mandated to implement pure virtual protected interface members, but not being able to access them seems very contradictive.

The interface only dictates the contract with the consumer, not the class. A member being available and accessible on the interface doesn't dictate how that member is available or accessible on the class, or even if it exists at all. That's always been the case, and the CLR is actually a lot more flexible in how interface implementations can be provided than even C# is.

For example, VB.NET exposes some more of the features provided by the CLR here, in that you can completely rename the member or use a different accessibility modifier:

Public Interface IFoo
    Sub M
End Interface

Public Class Foo : Implements IFoo
    Friend Sub N() Implements IFoo.M ' implements the interface member with a different name and accessibility level
    End Sub

    Sub OtherMethod
        Me.M() ' error BC30456: 'M' is not a member of 'Foo'.
    End Sub
End Class

[CyrusNajmabadi]

Explicit implementation being private

Explicit impls are not private. They legit don't have accessibility as far as the language is concerned. You'll see this if you try to even use private (as we'll disallow it).

The explicit impl member is effectively a hidden, unspeakable, member which implements that interface member. That's how it's been since 1.0.

Not necessarily being able to ever access it (the casting approach will often not get you it) is very much intentional and a core part of the design here for c#.