[Proposal] Add an [AutoAwaitAttribute] so compiler will auto-add "await" to async methods

[ritchiecarroll]

Suggest a compiler operation that would take async/await heavy code and automatically add await where needed to improve code readability when it encounters an attribute like AutoAwaitAttribute.

For example, the following simplified code:

            [AutoAwait]
            async Task<bool> IsEmptyAsync()
            {
                using SqliteConnection connection = ConnectionFactory();
                connection.OpenAsync(cancellationToken);
                CreateTableAsync(connection, cancellationToken);

                using SqliteCommand command = connection.CreateCommand();
                command.CommandText = "SELECT COUNT(*) FROM WaveformCache";

                using SqliteDataReader reader = command.ExecuteReaderAsync(cancellationToken);

                return
                    reader.ReadAsync(cancellationToken) &&
                    !reader.IsDBNullAsync(0, cancellationToken) &&
                    (reader.GetInt32(0) == 0);
            }

Would become the following behind the scenes where compiler adds await everywhere practical:

            [AutoAwait]
            async Task<bool> IsEmptyAsync()
            {
                await using SqliteConnection connection = ConnectionFactory();
                await connection.OpenAsync(cancellationToken);
                await CreateTableAsync(connection, cancellationToken);

                await using SqliteCommand command = connection.CreateCommand();
                command.CommandText = "SELECT COUNT(*) FROM WaveformCache";

                await using SqliteDataReader reader = await command.ExecuteReaderAsync(cancellationToken);

                return
                    await reader.ReadAsync(cancellationToken) &&
                    !await reader.IsDBNullAsync(0, cancellationToken) &&
                    (reader.GetInt32(0) == 0);
            }

[HaloFour]

I disagree that making await implicit improves readability. It hides one of the most important aspects of the async method. Also, await doesn't just apply to Task<T> or task-like types. Quite literally any type can be "awaitable" by adhering to the awaitable pattern, which can be satisfied through extension methods.

[ritchiecarroll]

Doesn't the extension method need to marked as async though? This would be a signature detectable by the compiler.

I can't help but think the simplified function is "so" much easier to read, especially when the asynchronous function names already include an Async suffix.

That said, consider the inferred use of DisposeAsync by adding await to a using - the compiler doesn't even warn you here when it's not added (perhaps this needs to be a Roslyn proposal). I'll bet this one is missed often.

Anyway, there may be various technical reasons why this would be complex to implement, but it "feels" like something that could be added.

[HaloFour]

@ritchiecarroll

Doesn't the extension method need to marked as async though?

No. The extension method needs to be called GetAwaiter and return a type that adhere to the awaiter pattern. The compiler can definitely detect this, but I severely doubt you would want to have the compiler automatically emit an await anytime it detects a type within an expression that just happens to fit this pattern. Adding a NuGet package or adding using statements could drastically change the meaning of your code. await TimeSpan.Infinity would be a terrible thing to happen accidentally.

I can't help but think the simplified function is "so" much easier to read, especially when the asynchronous function names already include an Async suffix.

The suffix is meaningless. It's the use of await that is important. It's that operator that defines the seam in the coroutine, not the method call.

Anyway, there may be various technical reasons why this complex to implement, but it "feels" like something that could be added.

It's not a matter of being complex to implement. The team has been pretty clear that asynchrony is something that the developer should explicitly opt-into and not be something that just kind of happens automagickally.

[ritchiecarroll]

Yeah was unaware of the duck-typed GetAwaiter extension - that usage would definitely not be a good candidate for auto-application of await, but seems easy enough to detect.

The suffix may be meaningless, but it always there in MS functions out of convention - and I think a recommended naming pattern. Your right, it's not required, but still, it's usually there - so again, from a "readability" perspective...

Sorry, I'm not familiar with what the team has or hasn't been clear on here, do you know if there's a place I should go to read on these types of opt-in policies?

[HaloFour]

but seems easy enough to detect.

The compiler always follows the "awaitable" pattern. It has no special knowledge of Task<T> or ValueTask<T>, they just happen to be two types that adhere to that pattern.

[brabebhin]

You don't always want to await on the spot. You sometimes can start tasks and then perform other things while the task is running and only await later on.

Such an attribute can affect this situation in unforseen ways.

[jnm2]

Also, don't forget about Task.Yield() which returns YieldAwaitable and .ConfigureAwait(false) which returns ConfiguredTaskAwaitable. All is certainly not Task and ValueTask.

[CyrusNajmabadi]

FWIW, this:

and automatically add await where needed to improve code readability when it encounters an attribute like AutoAwaitAttribute.

Would actually vastly decrease readability for me. I actively prefer an async model where awaiting points are actively visible and understandable in code. Having that be implicit would be a net negative for me.

That said, i'm not opposed to other visible approaches that might have better ergonomics than the full await keyword.

[LeonG-ZA]

I don't like this. I usually scan through other's code to make sure that there aren't any non-async long running synchronous code hiding inside an async method. You would be surprised how many people do this.
With this feature it would be difficult to quickly glance over the code to find these "errors".