Quote of the Day: "I don't want to require MainAsync
. It sounds like mayonnaise-ink!"
- Default implementations for event accessors in interfaces
- Reabstraction in a class of default-implemented member
sealed override
with default implementations- Use of
sealed
keyword for non-virtual interface members - Implementing inaccessible interface members
- Implicitly implementing non-public interface members
- Not quite implementing a member
- asynchronous
Main
Today, syntactically, either both or neither accessor can have an implementation.
Should we allow just one to be specified? Overridden?
If you have only one, you probably have a bug. Let's not allow it for now.
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?
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?
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.
Some folks find it a weird use of sealed
, and that they look too much like things that can be implemented in classes.
We think non-virtual members in interfaces are going to be useful, but will come back to the syntax. This is a mental model tripping block.
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.
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.
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:
- Must be public
- Must be the exact same accessibility
- Must be at least as accessible
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.
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.
Can't do anything about this.
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 if someone uses an alternative implementation? We can't prevent that. They either know what they are doing, or they are asking for it.
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.
If we don't allow other awaitables in Main
directly, folks can easily work around it just by having an async Task Main
that awaits it:
static MyTask MyMain() { ... }
static async Task Main() => await MyMain(); // problem solved
Let's still keep the async
keyword optional.
Let's stick with the name Main
instead of MainAsync
for now.
Let's stick to Task
and Task<T>
, but refine the rule:
- Look for
Main()
orMain(string[] args)
- Does exactly one return
void
orint
? If one, use that. If more, error. - Otherwise, look for
Task
andTask<T>
, where the return type ofGetAwaiter().GetResult()
isint
orvoid
.