Should an abstract class be allowed to implicitly implement an interface member with an abstract member, even when the interface member has a default implementation?
## Conclusion
Yes, of course. Adding a body to an interface member declaration shouldn't ever break an implementing class.
Should it be allowed? would it prevent overrides in *classes* or only in *interfaces*?
It seems odd to prevent either. Also, it is weird in connection with diamond inheritance: what if one branch is sealed?
## Conclusion
Let's not allowed `sealed` on overrides in interfaces. The only use of `sealed` on interface members is to make them non-virtual in their initial declaration.
The way the runtime works today, a class member can happily implement an interface member that isn't accessible! That's not likely to be depended on today (no language will generate that interface), but we need to decide what semantics to have here.
We could continue to only have *public* members in interfaces be virtual. But if we want protected, internal and private, we should probably have it so they can only be implemented by classes that can see them. But this means that interfaces can *prevent* other assemblies from implementing them! This may be a nice feature - it allows closed sets of implementations.
## Conclusion
This is still open, but our current stake in the ground is we should *allow* non-public virtual interface members, but *disallow* overriding or implementing them in places where they are not accessible.
# Implicitly implementing non-public interface members
Would we allow non-public interface members to be implemented implicitly? If so, what is required of the accessibility of the implementing method? Some options:
For now, let's simply not allow it. Only public interface members can be implicitly implemented (and only by public members). We can relax as we think through it.
# Not quite implementing a member
You have a member and you implement an interface. The interface adds a new member with a default implementation, that looks like your method but doesn't *quite* make it an implementation. Bug? Intentional? We can't provide a warning, because it would assume it was a bug.
We've decided to allow a `Main` method that returns `Task` and `Task<int>`. Whether it's `async` or not is completely optional, and an implementation detail of the method.
This feature relies on the pattern of calling `GetAwaiter().GetResult()` on the returned task, and on an expectation that this call blocks until the task is complete. That is the case for the framework's implementations of `Task` and `Task<T>`.
What about other awaitable types? Should they be allowed? This would be easy enough to implement; the concern is whether it is reasonable to expect their `GetResult()` method to block? After all, the compiler has not previously relied on this in its use of `GetResult()` on awaitable types, so one would assume that no particular effort has been put into ensuring it in the implementation of those types.