Proposal: sequential and concurrent keywords for asynchronous code

[RuslanLa]

The current async-wait based implementation of asynchronous flows creates some complexity in awaiting of several tasks. For example, to run several operations and to wait until all are done, we should do something like that:

var tasks = new List<Task>()
for(var i=0; i<100; i++){
    tasks.Add(MakeAsync(i));
}
await Task.WhenAll(tasks);

This implementation creates some overhead and decreases the code readability. I saw a lot of code where operations didn’t depend on each other and could be awaited non-sequential, but programmers didn't use the pattern above. I guess it says about the complexity of the pattern, especially for newcomers.
The proposal is to create new keywords, for example, the code above could be replaced with:

concurrent {
    for(var i=0; i<100; i++){
      MakeAsync(i);
    }
}

or

concurrent {
    OperationOneAsync();
    OperationTwoAsync();
} 

Another asynchronous blocks, which could be created is sequential await for dependent operations. For example the code:

var result1 = await OperationOneAsync();
await OperationTwoAsync(result1);

Could be replaced with:

sequential {
    var result1 = OperationOneAsync();
    OperationTwoAsync(result1);
}

Also, there could be nested blocks:

concurrent {
    OperationOneAsync();
    sequential {
        var result1 = OperationOneAsync();
        OperationTwoAsync(result1);
    }
} 

Sequential and concurrent methods:

concurrent int DeferredOperation() {
    var firstResult = OperationOneAsync();
    var secondResult = OperationTwoAsync(); 
    return SyncOperation(firstResult, secondResult);
} 

which will become:

async Task<int> DeferredOperation() {
    var firstTask = OperationOneAsync();
    var secondTask = OperationTwoAsync();
    await Task.WhenAll(firstTask, secondTask);
    return SyncOperation(firstTask.Result, secondTask.Result); 
} 

Concurrent, sequential blocks/methods could be run only from async methods or other concurrent, sequential.

[svick]

My main problem with this proposal is that it makes it much harder to understand what is actually happening in your code. If you have something like sequential { A(B(C())); }, where exactly are awaits inserted? Especially consider that the methods in question might be overloaded, including overloads that take Tasks.

This is even worse for concurrent. For example, what will the following code do?

concurrent {
    OperationOneAsync();
    SyncOperation();
    OperationTwoAsync();
}

Or is that forbidden? If it is, how exactly does the for example work?

Some other points:

• For libraries, you're currently pretty much required to write await task.ConfigureAwait(false). Changing that to task.ConfigureAwait(false) does not help that much.

• The for example can be simplified using LINQ to:

  await Task.WhenAll(Enumerable.Range(0, 100).Select(i => MakeAsync(i)));

  In light of this, I think the concurrent syntax is not as useful.

• You claim that the for example has unnecessary overhead, but I don't see anything here that would help with that.

[RuslanLa]

This is even worse for concurrent. For example, what will the following code do?

concurrent {
    OperationOneAsync();
    SyncOperation();
    OperationTwoAsync();
}

Or is that forbidden? If it is, how exactly does the for example work?
It will be replaced with the:

var firstTask =  OperationOneAsync();
SyncOperation();
var secondTask = OperationTwoAsync();
Task.WhenAll(firstTask, secondTask);

The idea is to make forbidden dependencies on the tasks result, when another method call with IAwaitable is above in the block.

For example:

concurrent {
    var result1 = OperationOneAsync();
    SyncOperation(result1);
    OperationTwoAsync();
}

will be forbidden.
But

concurrent {
    var result1 = OperationOneAsync();
    OperationTwoAsync();
    SyncOperation(result1);
}

is ok.

[RuslanLa]

• The for example can be simplified using LINQ to:

  await Task.WhenAll(Enumerable.Range(0, 100).Select(i => MakeAsync(i)));

It was the example, that I thought to use as a opposite, but I found it the least readable, and therefore used await and creation of list. The reason is that the main idea of the code is to call MakeAsync, but the complexity related to Enumerables hides the initial idea and makes the enumeration as the main idea. But for loop is one of the most common construct in the programming languages, and it doesn't take away the attention from the main operation, from my perspective.
The another example:

concurrent {
     for(var i = 0; i < 100; i++) {
         MakeAsync(i);
     }
     AndSomethingElseOne();
     AndSomethingElseTwo();
} 

It will look more complex with Linq.

[RuslanLa]

• For libraries, you're currently pretty much required to write await task.ConfigureAwait(false). Changing that to task.ConfigureAwait(false) does not help that much.

The regular async/await will be still available for these cases.

[marksmeltzer]

I think this is not good. Does it save keystrokes? Yes. Does it make the code clearer? No. In fact, it hides useful details. Do I wish that C# async had been implemented differently using the lessons learned F# and C++? Of course. But unless we bite the bullet and add something like a new keyword async2 (or whatever), or simply change the implementation going forward and potentially introduce a keyword async_v1 for forced backwards compatibility, obscuring the details of the current async plumbing only serves to further entrench the legacy C# async design decisions. Burying those details behind more succinct keywords without improving the fundamentals doesn't provide any great, worthwhile benefit. Regards,

[svick]

The another example: […] It will look more complex with Linq.

Not by much:

var tasks = Enumerable.Range(0, 100).Select(i => MakeAsync(i))
    .Append(AndSomethingElseOne())
    .Append(AndSomethingElseTwo());
await Task.WhenAll(tasks);

[RuslanLa]

Not by much:

I see. Thank you for example! For now, it looks like, the most preferable way. So, furthermore, readability of code could be increased by hiding the creation of the enumerable after a method without additional keywords:

var task = MakeAsyncForRange(0, 100)
await Task.WhenAll(task, AndSomethingElseOne(), AndSomethingElseTwo())

Maybe it would be a little little bit more readable if there was GetAwaiter on the tuple of tasks:
await (task, AndSomethingElseOne(), AndSomethingElseTwo())
, but it's not related to the current discussion.

[svick]

Maybe it would be a little little bit more readable if there was GetAwaiter on the tuple of tasks:

That's #380 and it already exists as an external library.

[RuslanLa]

Maybe it would be a little little bit more readable if there was GetAwaiter on the tuple of tasks:

That's #380 and it already exists as an external library.

Great! Thank you!