[Umbrella] open issues in default interface method proposal

[gafter]

The following should be clarified/described in the default interface implementation proposal:

• The spec should allow the modifier public to be used in an interface to make the default access explicit. [YES]
• The spec should describe the runtime method resolution algorithm in the face of interface default methods. (Now noted as an open issue in the spec)
• Should (explicitly implemented) event accessors be permitted in an interface? [YES]
• Should internal members be permitted in an interface? If so, can they be non-virtual? [YES, YES]
• Should protected members be permitted in an interface? If so, what, precisely, would that mean? Can they be abstract? Non-virtual? [YES, open, YES, YES]
• Which interfaces are searched (by spec, the most specific override rule searches both direct and indirect interfaces)
• Diamond Inheritance between Class and Interface (moved to Issues in Default Interface Methods #406)

[gafter]

The draft spec suggests that the following should be legal (because every concrete class declaration contains a most specific implementation for every interface method):

interface IA
{
    void M() {}
}
class Derived: IA
{
    private void M() { }
}

I asked @MadsTorgersen to check on what his LDM notes and memory say about this situation. Mads said that he does not recall it being discussed, and his LDM notes do not show it being discussed. However, he believes it should behave the same way that this behaves:

interface IA
{
    void M();
}
class Base: IA
{
    void IA.M() { }
}
class Derived: Base, IA
{
    private void M() { }
}

I agree with that: in either case Derived has a most specific implementation of IA.M, and so IA is fully implemented by Derived. The method Derived.M is simply not a candidate to implement IA.M and is unrelated to it. This agrees with the draft specification.

This treatment is also desirable to minimize the break that could be introduced by adding a new default method to an existing interface.

[gafter]

I have added two open questions to this issue.

[bbarry]

interface IA { int M() => 1; }
interface IB: IA { override int M() => 2; }
class Base : IB { }
class Derived : Base, IA { }

should behave like this:

interface IA { int M() }
interface IB: IA { int M(); }

class Base: IB
{
    public virtual int M() => 2;
}
class Derived: Base, IA
{
}

under a rule that class inheritance takes precedence over interface inheritance and that once a class implements an interface, all interface implementations would resolve as if they are class implementations from the perspective of inheriting classes.

The difference between these two samples would be that that instance methods inside both classes and the IB interface could refer to base.IA.M() or some similar syntax to call that specific implementation. The former for example could become:

interface IA { int M() => 1; }
interface IB: IA { override int M() => 2; }
class Base : IB { }
class Derived : Base, IA { 
    public override int M() => base.IA.M();
}

[gafter]

@bbarry The spec has been modified to give classes priority over interfaces. Moreover, the most specific override rule (also added to the spec) now answers this question the same way.

All of the issues here have been answered or moved to another issue, so I'm closing this. See #406 for issues to be taken up by the LDM.