-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Umbrella] open issues in default interface method proposal #285
Comments
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 This treatment is also desirable to minimize the break that could be introduced by adding a new default method to an existing interface. |
I have added two open questions to this issue. |
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 The difference between these two samples would be that that instance methods inside both classes and the IB interface could refer to 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();
} |
@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. |
The following should be clarified/described in the default interface implementation proposal:
public
to be used in an interface to make the default access explicit. [YES]internal
members be permitted in an interface? If so, can they be non-virtual? [YES, YES]protected
members be permitted in an interface? If so, what, precisely, would that mean? Can they be abstract? Non-virtual? [YES, open, YES, YES]The text was updated successfully, but these errors were encountered: