[Proposal] Implicit return Task.CompletedTask

[damianh]

For methods that...

1. return a Task
2. do NOT use the await modifier
3. do not explcitly return a Task.CompletedTask

...a Task.CompletedTask is implicitly returned.

For example this...

public Task LogAsync(ILogMessage message)
{
    Log(message);
    return Task.CompletedTask;
}

...could be this with implicit return Task.CompleteTask;

public Task LogAsync(ILogMessage message)
{
    Log(message);
}

And futher shortened to:

public Task LogAsync(ILogMessage message) => Log(message);

[koszeggy]

And futher shortened to:

public Task LogAsync(ILogMessage message) => Log(message);

Today this is completely legal if Log(message) also returns a Task. To me it would cause some confusion because I couldn't be sure (without checking the signature of Log) whether I return a "real" task here or just an implicit Task.CompletedTask.

Additionally, I would hesitate to encourage fake-async implementations by a dedicated syntax, even though sometimes you are forced to this, eg. when you have to implement async interface methods without any actual async operation.

[damianh]

In the case of Log returning a task, then that should be returned instead of implicit Task.CompletedTask

Am trying to consider any potential trap with such ... 🤔

Implementing async interface with non-async operation appears to be a fairly common scenario (though obviously not all usages in these search results apply).

[HaloFour]

Done:

public async Task LogAsync(ILogMessage message) => Log(message);

[siegfriedpammer]

Doesn't this produce a warning and/or inefficient code due to a state machine being emitted unnecessarily? See for example https://sharplab.io/#v2:EYLgZgpghgLgrgJwgZwLQIPYBsUBoYgCWWAPgAIBMAjALABQZADAARlUCsA3PfWQMysKzAMLMA3vWZTWAsgA5WANmYA5ABQBKZgF4AfMwCym7nWnNJ0/qwAshzeItSAvvSdA

I don't think it would be a good idea to encourage people to do it like that. I don't like the idea of implicit returns, but I think there should be something that creates a "pit of success".

[HaloFour]

It does produce a warning because the compiler assumes that an async method without an await is a mistake on the part of the developer. However, if it is not a mistake, you, as the developer, are free to silence the warning. There's a little bit of additional overhead due to the state machine, but that should be pretty minimal. The behavior of exceptions is also affected, in that if Log throws, the returned Task is in a faulted state, which is the behavior you'd expect from a Task-returning method.

IMO, shorthand here isn't necessary. These cases shouldn't be common enough that the burden of manually returning a completed task is onerous, and the language shouldn't encourage it as an idiomatic pattern. Even for a library author, it feels like the kind of thing that would be written quite infrequently and only at a specific abstraction.