proposal: async mode

[darrenoakey]

this is suggestion that may leave you convinced of my lack of sanity - but I'm actually serious - I'd love this.

Essentially a mode, at the project level (like nullable) - that says "everything is async".
Because bottom line - once you start going async, you sort of have to have most stuff async anyway, and it becomes "work" to decide at each point. More than that - the syntax is very heavy. And of course, it's completely trivial to turn any "sync" call into an async function with Task.FromResult - so the idea would be - you turn on async at the project level - and instead of writing:

     public async Task<String> Hello() 
     {
           await Task.CompletedTask;
           return "hello";
     }

    public async Task<string> CallHello()
    { 
           return await Hello();
    }

you could just write:

    public String Hello()
    { 
           return "hello";
    }

    public String CallHello()
    {
         return await Hello();
     } 

which would be completely equivalent to the previous one. You'd probably still need "await" - (although I reckon even that could disappear, as the compiler could see whether you later passed the result to something that took a task explicitly - I think it would be valid to assume that any invocation should be awaited before use if and only if you don't pass the result to some helper function that does things with tasks (and you could make a DontAwait helper :))). - and you could definitely know for sure (with some ide support) if someone called properties that exist on the result - as opposed to the Task<?> - then you know they meant it to be awaited.

Anyway - the point is - at the moment there's quite a big impedance mismatch between the sync and async world - it would collapse to a much simpler picture if we just had a project where every function was intrinsically async, without all the noise of "async" and "task" that normally come with it.

For really cool extra points, you could also implicitly pass a cancellation token to every method - and check it at the start of the method, and inside any loops - because even people who have fully embraced async often don't bother plumbing through cancellation.

And while 1.0 would be just a naive rewrite - you could almost do it at the code level with roslyn - or hey... generators... - if people bought into the concept, there's obviously massive potential to optimise a lot of the overhead out automatically.

[canton7]

If nothing else, this would create a dialect of C# (since you've have a change in syntax based on some switch), which the LDM team is against.

[svick]

For better or worse, async-await as implemented in C# does require you to think about it. My problem with this proposal is that it doesn't change that, but it pretends that it does. For example, you will still need to write await File.ReadAllTextAsync(path).ConfigureAwait(false) instead of File.ReadAllText(path). But this proposal would make it seem like just turning the option on does make your code properly async, which is not true.

Some other points to consider:

• Dialects of C# are considered a bad thing, because they mean you can't understand the code just by looking at it. Nullable reference types get away with it by solving one of the biggest issues in C#, and even then, it doesn't change the behavior of any existing code. This proposal would cause a much larger disruption, for much smaller gain.
• Not every method needs to be async, which means this option would have a serious negative effect on performance.
• Also related to performance: ValueTask is becoming increasingly common and this option would not give you the choice to use that.

[darrenoakey]

valid points all.

I guess though, I'm finding that I sort of have sync libraries and async libraries - and in the async libraries, essentially everything is async. I code as functionally as possible - all immutable objects etc - and normally the thing at the bottom of the tree is the async bit, so the entire tree ends up being async. my average function length is 1.4 lines, so between them the words "Task" and "async" actually form a significant percentage of the entire codebase :(

[GeraudFabien]

And of course, it's completely trivial to turn any "sync" call into an async function with Task.FromResult

... No Task.FromResult is a syncronous api.

I don't agree with you're code since code and you're idea for two reason. Async is done for performance it can bring a lot of bug and complexity to debug. With you're solution we cannot control anythinks.
But still i have somethinks i don't understand about you're sample

     public async Task<String> Hello() 
     {
           await Task.CompletedTask; // This line if we supposed another Task is what make this code block truly async
           return "hello";
     }

And on you're final code you're write

    public String Hello()
    {
          // Where is the fake task ???? 
           return "hello";
    }

I'm not sure but my theorie is that you don't have understand what is a task and you added await Task.CompletedTask; to make the warning disappear. Otherwise you're exemple would be more like this

     public async Task<String> Hello() 
     {
           await Task.Run(()=>...)
           //// or await MyMethod()
           //// or ...
           return "hello";
     }

And on you're final code you're write

    public String Hello()
    {
           ...
           return "hello";
    }

so the entire tree ends up being async

Yes and no. For long operation or web and UI you have async for anythinks else isnt'. Async does 'pollute' you're caller but does not polute the method you call...

Async is slower than normal method call because the return must be encapsulated inside a Task... (CF. https://devblogs.microsoft.com/dotnet/understanding-the-whys-whats-and-whens-of-valuetask/ , https://devblogs.microsoft.com/dotnet/async-valuetask-pooling-in-net-5/)

You'd probably still need "await" - (although I reckon even that could disappear,

Why would you remove await. And what if i want to start multiple task and wait them later. It's a big lost just to earn one keyword in the code.

[arnonax-tr]

I like the idea a lot (in fact I got to it because I thought about something similar myself). With that said, I also get the objections regarding creating a new dialect of C#.
All in all, I think that the pain is real and I'd like to see a solution for reducing most of the ceremony around async/await.

In addition, I'd like to point another problem with the way things currently work: often when you start creating something simple you can get pretty well with synchronous code, but then if at some point you realize that you need to change the implementation to be asynchronous, it means that you must change your API and break backward compatibility. This is especially relevant to interfaces which can have different implementations, where the simpler one can provide information directly from memory (synchronous) and more complex ones provide the same information from disk or over the network (async). To make this point even stronger, when you do TDD, as you typically start with the simplest case (sync) and then gradually grow and refactor. But because of the impedance mismatch between sync and async, the refactoring is becomes too complex and also requires to break the interfaces.
If everything would be async by default, then simple implementation will also act as async even if not needed, but the interfaces wouldn't need to break at any point.