Added: C# Language Design Notes for Apr 18, 2017

[MadsTorgersen]

C# Language Design Notes for Apr 18, 2017

1. Default implementations for event accessors in interfaces
2. Reabstraction in a class of default-implemented member
3. sealed override with default implementations
4. Use of sealed keyword for non-virtual interface members
5. Implementing inaccessible interface members
6. Implicitly implementing non-public interface members
7. Not quite implementing a member
8. asynchronous Main

Please discuss.

[svick]

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[.]

Another option would be to generate code that effectively performs the workaround automatically. So this code:

static MyTask Main() { … }

would compiled into:

static void Main() => MainTask().GetAwaiter().GetResult();

static async Task MainTask() => await MainMyTask();

static MyTask MainMyTask() { … }

This way, the generated code does not rely on some unknown GetResult() to block, it only relies on TaskAwaiter.GetResult().

Let's stick with the name Main instead of MainAsync for now.

What is the reasoning for this? I think I don't like it, since it trains people that they shouldn't follow the TAP naming convention.

[jnm2]

since it trains people that they shouldn't follow the TAP naming convention.

I have somewhat strong opinions on interfaces where every method name ends in Async. 😈
That convention was only ever because we don't have return value overloading and you might need to have an async and non-async method side by side. However, you'll never have two Main methods.

[paulomorgado]

Implementing inaccessible interface members

That might be useful in designing interfaces where there's a public and a protected contract.

Today we need to use abstract classes with protected abstract members for that.