Please Consider to Simplify the Keyword of "await"!

[juepiezhongren]

Async is now everywhere, but "await" is always not that convenient, I think 2 things are making trouble:

• - 1. await is a bit LONG, especially when a lot of async functions are consequently called, and not forget async using and async stream in C# 8, in which "await" is making cumbersome;

• - 2. await is on the LEFT! Considerring how many javaers envy the Extending Method, which is the same troubling when you going to do chaining async function calls with so many "()".

• First Proposition: underline to simplify "await":

Thanks to @HaloFour , as underline could be use as variable and member names, it is invalid in regard to properties' await behavior, so it is Not Perfect.

        async Task<string> NormalAsync() {
            await aAsync();
            await Task.Delay(1000);
            await Task.Run(async () => {
                await Task.Delay(1000);
                ,,,,,,
            });
            if((await getIdentityAsync()).Substring(0,2)=="aa")
                return null;
            if((await "aa".Trans().getIdentityAsync())==null)
                throw new Exception("");
            var str = (await (await (await 5.AAsync()).BAsync()).CAsync());
            return str;
        }

       async Task<string> SimplifiedAsync() {}

        _ Task<string> SimplifiedAsync() {
            aAsync()_;
            Task.Run(_() => {
                Task.Delay(1000)_;
                ,,,,,,
            })_;
            if(getIdentityAsync()_.Substring(0,2)=="aa")
                return null;
            if("aa".Trans().getIdentityAsync()_==null)
                throw new Exception("");
            Task.Delay(1000)_;
            var str = 5.AAsync()_.BAsync()_.CAsync()_;
            return str;
        }

• Second Proposition: ! to simplify "await":

Athough it looks pretty good, but thanks to @eyalsk, "damnit" operator is going to be used for the non-nullable reference types, so............

       async Task<string> SimplifiedAsync() {}

        ! Task<string> SimplifiedAsync() {
            aAsync()!;
            Task.Run(!() => {
                Task.Delay(1000)!;
                ,,,,,,
            })!;
            if(getIdentityAsync()!.Substring(0,2)=="aa")
                return null;
            if("aa".Trans().getIdentityAsync()!==null)
                throw new Exception("");
            Task.Delay(1000)!;
            var str = 5.AAsync()!.BAsync()!.CAsync()!;
            return str;
        }

• Third Proposition: ..(double dots) to simplify "await":
  thanks to @birbilis , this seems to be a good solution, esp when dot is easy to use than most other punctuation marks.

        async Task<string> SimplifiedAsync() {}

        .. Task<string> SimplifiedAsync() {
            aAsync()..;
            Task.Run(..() => {
                Task.Delay(1000)..;
                ,,,,,,
            })..;
            if(getIdentityAsync()...Substring(0,2)=="aa")
                return null;
            if("aa".Trans().getIdentityAsync()..==null)
                throw new Exception("");
            Task.Delay(1000)..;
            var str = 5.AAsync()...BAsync()...CAsync()..;
            return str;
        }

• Fourth Proposition: "<" to simplify "async", ">" to simplify "await":
  thanks to @gwhzh21, this is best at match the pair.

       async Task<string> SimplifiedAsync() {}

        < Task<string> SimplifiedAsync() {
            aAsync()>;
            Task.Run(<() => {
                Task.Delay(1000)>;
                ,,,,,,
            })>;
            if(getIdentityAsync()>.Substring(0,2)=="aa")
                return null;
            if("aa".Trans().getIdentityAsync()>==null)
                throw new Exception("");
            Task.Delay(1000)>;
            var str = 5.AAsync()>.BAsync()>.CAsync()>;
            return str;
        }

• Fifth Proposition: pipe "|>" or extension method:
  thanks to @birbilis @HaloFour ,pipe is sure a solution but, but we shall never forget the keyword of "delegate" and "=>", less always made things more gracefull.

    static async Task<string> NormalAsync() =>
       await Foo("a") |> await Foo()  |> await Foo()  |> await Foo();

    static .. Task<string> NormalAsync() => Foo("a").. |> Foo().. |> Foo().. |> Foo()..;

thanks to @yaakov-h @eyalsk, extension could make async chain happen. But i have doubts about its performance, considering more Task wraps compared with a struct stateMachine .Besides, there is not a interface which Task and ValueTask both implement and could result in Roslyn creating stateMachine code, because GetAwaiter COMES FROM NO INTERFACE! Extenstion code is not a general solution for all promise-like class and structs.

        public static Task<T2> FAsync<T1, T2>(this Task<T1> objT, Func<T1, Task<T2>> funcAsync) 
            =>return objT.ContinueWith(t1 => funcAsync(t1.Result)).Unwrap();
        
        public static T2 F<T1, T2>(this T1 obj, Func<T1, T2> Func) => Func(obj);

        await "a".F(s=>Foo(s)).FAsync(s=>Foo(s)).FAsync(s=>Foo(s))

[HaloFour]

I think a postfix _ operator is very difficult to see and does not fit well within the rest of the structure of the C# language. Not to mention it will create ambiguity as an underscore may appear within any legal identifier. You're not limited to awaiting the result of methods.

[juepiezhongren]

@HaloFour underscore may not be good enough, may be ! should be another option , just like fsharp, but please put it on the right!

        async Task<string> SimplifiedAsync() {
            aAsync()!;
            bAsync()!;
            cAsync()!;
            Task.Delay(1000)!;
            var str = 5.AAsync()!.BAsync()!.CAsync()!;
            return str;
        }

[iam3yal]

@juepiezhongren ! or the "damnit" operator is going to be used for the non-nullable reference types.

[juepiezhongren]

@eyalsk just got known that, so get back to underscore

[iam3yal]

@juepiezhongren Just a side note, there are some characters or whatever in your post that might make your post unreadable for some people, you may want to edit it. :)

[juepiezhongren]

@eyalsk
delete them all, though i wish more people to know this, forget it

[stuartstein777]

Underscore looks far too difficult to see at a quick glance. Also I like the grammer of await something.

something await doesn't make as much sense to me.

[juepiezhongren]

@stuartstein777 please try to consider that u have a function with more than 50 await, with chains, with if, with using, with lock, with everything being muted with await. The codes are really not graceful as C# always should look like. Underscore may not be a good one, but async-programming needs to be as graceful as sync-one.

further, simplified is just an option, just like var, just like var out, it makes things easy and elegant but just
an option.

[ghost]

can we add a key word "awaiting ",then translate this:
awaiting
{
var xx = AsyncMethod1().AsyncMethod2().AsyncMethod3().AsyncMethod4();
}
to :
var xx = await (await (await ((await AsyncMethod1()).AsyncMethod2())).AsyncMethod3()).AsyncMethod4();

[juepiezhongren]

@zhangasyncjun property, indexer, function should be equally treated, besides, in this scope, sync functions have to be banned.

[cherepets]

My suggestion is second pair of ().
So

AsyncMethod()()

should be equivalent to

await AsyncMethod()

Examples:

var a = AsyncMethod1()().AsyncMethod2()().AsyncMethod3()()?.AsyncMethod4()() ?? true;

using (var q = MyFactory.CreateDisposableAsync()())
q.DoSomething()();

[juepiezhongren]

double() is surely unacceptable, considering a function's result is a delegate

[cherepets]

It shouldn't break anything. In case you are returning delegate (like async Task<Func> AsyncMethod()), you'll just write
var result = AsyncMethod()()();

[stuartstein777]

SomeAsyncMethod()()() is absurd.

[juepiezhongren]

@cherepets thanks all the same.,u got my point

[birbilis]

Btw, some inlining hint would help for the last suggestion (and would be even better if there was an inline keyword)
https://stackoverflow.com/questions/473782/inline-functions-in-c

[Thaina]

In the meantime I take an idea like @eyalsk as this

public static async Task<V> Then<T,V>(this Task<T> obj,Func<T,V> func)
{
	return func(await obj);
}
public static async Task<V> Then<T,V>(this Task<T> obj,Func<T,Task<V>> func)
{
	return await func(await obj);
}

var taskValue = await task.Then((item) => item.Value);

Because I don't know why you use ContinueWith and UnWrap instead of await

Would you pleased to explain?

[iam3yal]

@Thaina Well, because I was providing an example to the OP that posted the following:

    public static Task<T2> FAsync<T1, T2>(this Task<T1> objT, Func<T1, Task<T2>> funcAsync) {
        return objT.ContinueWith(t1 => {
            var t2R = funcAsync(t1.Result).Result;//It blocks current thread!!!!
            return t2R;
        });
    }

which doesn't make use of async/await, I thought to simplify it enough so he/she would understand what's going on and build on that.

p.s. Updated my post with the async/await version.

[slaneyrw]

I'm finding a lot of (await ...).Property now starting to proliferate in my codebases now, especially with ASP.NET Core.

i.e.
var principal = (await HttpContext.AuthenticateAsync("scheme")).Principal

I'm writing a lot of extensions methods for specific Task-Of-T to make the code cleaner

public static async Task<ClaimsPrincipal> PrincipalAsync(this Task<AuthenticateResult> result)
{
    return ( await result ).Principal;
}

var principal = await this.HttpContext.AuthenticateAsync("scheme").PrincipalAsync();

How about using "*" suffix. The compiler can easily work out whether to use * operator or await keyword - Task and Task<T> don't override the * operator.

var principal = HttpContext.AuthenticateAsync("scheme")*.Principal

[theunrepentantgeek]

The compiler works in multiple passes - at the point where it needs to decide whether the suffix * is an operator or something else, it's only looking at syntax; it doesn't have access to the definitions of Task or Task<T> to inspect. That information only becomes available in later passes.

Moreover, the await operator works with anything that is awaitable - which includes Task and Task<T> but also includes ValueTask, ValueTask<T> as well as anything you write yourself.

IIRC, if you dig back into the history of the design of async and await they considered using an operator and decided against it.

[slaneyrw]

Just because a decision was made in the past doesn't mean that it's set in stone... look at how the syntax for anonymous delegates was made better by lambda expressions, or Tuples and deconstructors.

I'm not advocating for a complete replacement - that's not possible - just a shortcut to allow us to avoid plastering nested awaits in brackets all over our code base.

And, yes, I'm aware the rules regarding the use of the await keyword... but 99.999% of the code that uses await is programming against Task, Task<T>, ValueTask, or ValueTask<T>.

I'm pretty sure the compiler team can work out when to use an operator or rewrite to await, after all they managed it for "?" with nullable reference types and Nullable<T>

[CyrusNajmabadi]

And, yes, I'm aware the rules regarding the use of the await keyword... but 99.999% of the code that uses await is programming against Task

I disagree with that statement. Most of the time (in libraries at least) await is used against a ConfiguredTaskAwaitable.

[Mike-E-angelo]

I think this is an issue that is asking for improved asynchronous handling? That's how I read it. Seems like everyone is patting themselves on the back for doing such a great job for the .NET asynchronous model. Don't get me wrong, while the current implementation is an improvement over previous models, when other languages mimic you it is not the time to get stale and self-congratulatory.

We should continue to innovate and lead the way, right?

The sentiment is out there in the wild. Consider:

Top-rated vote that was fourth in feature requests, amassing 44 votes, until it was shut down and told to move it to this repository, even though this issue spans way more than the C# language.
https://developercommunity.visualstudio.com/idea/583945/improve-asynchronous-programming-model.html

Nice little discussion that triggered me nicely today, started by @dotMorten:

Why is async/await and the TPL so freakin‘ hard to use right in C# and .NET? Is it because it was retrofitted into a fairly old language and runtime? I see these kind of discussions all the time and it makes me sad.
Source

And it’s not just devs new to the platform getting onboarded or anything, these “what’s the right/best way?” questions routinely come up from the most experienced among us. Somehow async/await missed the pit of success that I think characterizes most of the rest of the language.
Source

And from @dotMorten himself:

I’ve always said async/await makes writing multi threaded apps easy, but it doesn’t make multi threading easy
Source

That entire thread in its own right is also very telling. There seem to be dozens of replies to the question, with each of them having their own take.

Anyways, it would be nice to capture this somewhere in a more formal manner, and I would like some assistance in doing so if at all possible.

Or is there perhaps a better issue on here that captures this sentiment? I find it interesting that this issue is still open after nearly 3 years despite having so many downvotes. Almost as interesting as shutting down a feature request on a feature request forum and telling us to use GitHub instead.

[HaloFour]

@Mike-E-wins

Short of having a concrete way of making it better I don't know what else there is to really do here. Most of the issues that pop up appear to be minor syntactic tweaks. Those that are trying to make await flow better in expressions I can understand as the precedence of the operator can make it a little unwieldy, but a lot of issues just seem to want to "hide" the asynchrony or make it automagick both of which are dangerous, IMO.

Nobody is standing back and saying that async/await makes multithreading easy, or that it's the best possible solution, but it certainly makes writing code that does multithreading easier compared to the predecessors, and it's much less effort than trying to retrofit fibers/green-threads throughout the ecosystem where accidentally blocking an OS thread is a real threat.

As for issues that sit for long periods of time, that describes most of the repo. There's an unfortunately wide gulf between issues that are so good that they get LDM attention and championed and issues that are so bad that they're quickly closed, and that backlog limbo is many, many years long. To be fair there's way too many good-enough ideas out there and even out of the issues that the LDM is actively pursuing they probably have more than a decade of work. I'm not sure that there's much more that can be done short of having more community involvement in terms of forking and prototyping ideas out to demonstrate their feasibility and value. That'll never be a guarantee of acceptance, but might lower that bar.

That's my opinion, anyway.

[Mike-E-angelo]

As for issues that sit for long periods of time, that describes most of the repo.

Yeah that is why I was bummed about having the vote dismissed and told to submit it here. You basically summarized my own understanding of what to expect by posting something here.

The problem is that I am not an asynchronous wizard/expert and am in no capacity equipped to provide any sort of design/specifications that could be legitimately used.

However, I am an end-user of the product, and combined with a lot of other end-users of the product, we're all pointing to pretty much the same pain points.

I guess it's a matter of simply being aware of it until there's a legitimate push to make a vNext (if there is one).

In the meantime, I continue to be open to feedback for any other next steps that arise here. I am not exactly wanting to open a new issue until I have a sponsor of some sort that could help guide me through.

I will also try to work on not getting so triggered on Twitter every time I see the word "async." 😆

[CyrusNajmabadi]

However, I am an end-user of the product, and combined with a lot of other end-users of the product, we're all pointing to pretty much the same pain points.

Ok :) But what is a good solution whose benefits outweigh its own cons? There hasn't been progress here because the domain is complex and challenging, and there's no clear ways that have been proposed to truly make things better.

The problem is that I am not an asynchronous wizard/expert

Consider that asynchrony is inherently complex (same as concurrency, same as locking, etc. etc.). There isn't some magic bullet to change that. There are just tools that can be provided to help people wrangle it a bit better than before.

THere were several quotes from dotMorten listed and i agree with them all. For example:

Why is async/await and the TPL so freakin‘ hard to use right in C# and .NET? Is it because it was retrofitted into a fairly old language and runtime?

Yes. And also because asynchrony is hard.

MS, and the LDM, woudl love it if computers advanced to the poitn where you didn't have to think about it. But the reverse happened. Asynchrony became hugely important, which necessitated developers having to build up their skills in this complex space.

I’ve always said async/await makes writing multi threaded apps easy, but it doesn’t make multi threading easy

Correct. And it wasn't meant to. Async/await is about asynchrony. Multithreading is about concurrency. Fortunately, these things can work together. For example, i can easily get massive speedup, with good program behavior by utilizing TPL, the threadpool, and using tasks+async/await to wrangle all that. Is it trivial? Definitely not. But these are extremely complex areas. And even making that extreme complexity "medium" complexity instead of "easy" complexity is a great step.

[HaloFour]

Just for an interesting exercise in comparative design, Java has decided to take a different tack to trying to solve asynchrony. They plan on adding a form of "virtual thread" which is basically a green-thread and blurring the distinction of whether you're running on them vs. OS threads.

http://cr.openjdk.java.net/~rpressler/loom/loom/sol1_part1.html

They even call out the approach of using coroutines by C# and Kotlin as leading to the two "colored functions" world.

It's an interesting approach and I'm curious as to whether or not they'll be successful. They'll need to update a lot of the JRE to correctly handle blocking when running on a virtual thread so to not block the OS thread, and there's always the threat that third-party code and native code will cause blocking. Blocking an OS thread could block all or a large percentage of the virtual threads.

They also appear to be adding continuations to the JVM which should make it simple to build coroutine primitives.

[Mike-E-angelo]

Thank you @CyrusNajmabadi and @HaloFour. I guess having some reassurance that there is awareness around this issue is what I am after here, and you have provided it.

👍

Honestly, I feel sheepish here because a mere month ago I promised myself to never EVER post anything ever again around this topic again (after the vote on developercommunity was closed -- seriously, that sucked!) but here we are. 😆😞

But in any case, thank you for your feedback and for taking the time to provide your thoughts around the matter. I continue to be open to suggestions on how to proceed, or if that is even possible. I am not looking for anything for "right now," but perhaps in the future if/when inspiration strikes. If you do think of something, please consider this thread and let me others know. I know I can try giving my thoughts/feedback as well and providing any support if I can assemble it accordingly.

[Mike-E-angelo]

Prompted by this discussion:

https://twitter.com/cezary_piatek/status/1356149993124614144

What about something like this:

public interface IMyInterface
{
    ValueTask<string> GetValue();
}

class MyClass
{
    readonly IMyInterface dependency;
    public MyClass(IMyInterface dependency) => this.dependency = dependency;

    public string@ HelloWorld()
    {
        var message = dependency.GetValue();
        var result = $"Hello World: {message}";
        return result;
    }
}

Where string@ is syntactic sugar for async ValueTask<string> and denotes that all asynchronous calls within should assume to be awaited.

To account for ConfigureAwait(true) and ConfigureAwait(false), @+ and @- could be used, respectively:

    public string@- HelloWorld()
    {
        var message = dependency.GetValue(); // equivalent to await dependency.GetValue().ConfigureAwait(false)
        var result = $"Hello World: {message}";
        return result;
    }

Or if you have multiple calls, you can override with explicit control:

    public string@ HelloWorld()
    {
        var first = dependency.GetValue(); // equivalent to await dependency.GetValue().ConfigureAwait(true)
        var second = @- dependency.GetValue(); // equivalent to await dependency.GetValue().ConfigureAwait(false)
        var result = $"Hello World: {second}";
        return result;
    }

Taken further, an assembly-level attribute can be applied for default await configuration:

[AttributeUsage(AttributeTargets.Assembly)]
public class ConfigureAwaitAttribute
{
    public ConfigureAwaitAttribute(bool continueOnCapturedContext) => ContinueOnCapturedContext = continueOnCapturedContext;
    public bool ContinueOnCapturedContext { get; }
}

Then:

[assembly: ConfigureAwait(true)] // For client-based/presentation assemblies

    public string@ HelloWorld()
    {
        var message = dependency.GetValue(); // equivalent to await dependency.GetValue().ConfigureAwait(true)
        var result = $"Hello World: {message}";
        return result;
    }

Or:

[assembly: ConfigureAwait(false)] // For non-presentation-based assemblies

    public string@ HelloWorld()
    {
        var message = dependency.GetValue(); // equivalent to await dependency.GetValue().ConfigureAwait(false)
        var result = $"Hello World: {message}";
        return result;
    }

[HaloFour]

@jnm2

From that blog post it still sounds experimental and unproven outside of microbenchmarks. That blog post also succinctly states why ValueTask/ValueTask<T> aren't a replacement for Task/Task<T> and that pooling only compounds the issues with them if you stray at all from the happy path.

[jnm2]

@HaloFour Does that apply less to methods that use IValueTaskSource manually?

[HaloFour]

@jnm2

Not at all, but presumably if you're going to that trouble you should have an understanding of the ramifications. A syntax that encourages the use of ValueTask<T> across the board coupled with potential automagick pooling sounds ripe for disaster.

[CyrusNajmabadi]

Where string@ is syntactic sugar for async ValueTask<string>

Just wanted to weigh in on this. First, as mentioned above, the language is highly unlikely to bless any particular Task-like implementation. Second, if it were to bless one, it would not be ValueTask. That impl is quite complex and niche. It's for a very particular audience with very explicit needs who are willing to use this more complex type and understand the issues around it in order to benefit their use cases.

[CyrusNajmabadi]

My opinion is that trying to handwave away asynchrony is a horrendously spectacularly bad idea. I don't have the vocabulary to properly and perspicuously express just how bad I think it is.

I wanted to weigh in on this as well. While opinions are all over the place on if this is a good or bad thing, i can say without question that the direction that C# has taken here is absolutely an intentional one. The view when creating this feature (which hasn't really changed much in the years that follows) is that asynchrony points should be clear and explicit in code. We did not want, and still do not want an approach more in line with Java's Loom approach. It was and remains a goal of ours for this feature as we believe the benefits of this explicitness outweigh the negatives. It is highly unlikely we will change that.

[KPixel]

I think that this is a very difficult problem to solve correctly due to the way that async was added to C#. And I don't think that it is such a huge problem to require introducing a lot of new concepts.

My suggestion would be to add one feature that would make async a lot less verbose:
What if we could implement extension methods that can turn an async call into a "sync"-looking one?

That way, await Task.Delay(1000).ConfigureAwait(false); can become Task.Delay(1000).A(); thanks to the following extension:

public static async-to-sync-like void A(this System.Threading.Tasks.Task task)
    => await task.ConfigureAwait(false);

public static async-to-sync-like T A<T>(this System.Threading.Tasks.Task<T> task)
    => await task.ConfigureAwait(false);

I used async-to-sync-like as the keyword to let the compiler know what to do here. It is a placeholder.

Then:

var str = await (await (await 5.AAsync().ConfigureAwait(false)).BAsync().ConfigureAwait(false)).CAsync().ConfigureAwait(false);

Becomes:

var str = name.AAsync().A().BAsync().A().CAsync().A();

With this approach, we retain all the flexibility of the async model: It will work with Task and ValueTask. It handles ConfigureAwait() and developers can choose when to use.

The main concern that I have is that we lose the visual hint that we are making async calls. So, a developer reading an unfamiliar code will not know what A() does...

Edit: Wow, I just realized that I wrote something similar three years ago :)

[HaloFour]

@KPixel

The main concern that I have is that we lose the visual hint that we are making async calls. So, a developer reading an unfamiliar code will not know what A() does...

That's why the await is required. You can write an extension method today that would handle Task<...> and ValueTask<...> types and automatically call ConfigureAwait on them, but you can't avoid the await, and that is intentional. Otherwise it looks like a blocking call and there is no indication that the async machinery is kicking in or that the current method must also be async.

[KPixel]

Indeed.

This discussion started over three years ago and hasn't made any progress because we can't find a perfect solution. So, either we settle for an imperfect one, or we leave it as-is.

And note that C# already has plenty of imperfect features, including nullable ref types (that I like overall).

[Duranom]

Why is there always a lot of discussion on having shorter or different keywords/syntax for something that works properly but when done wrong can really go bad.

Took years for people to properly understand and do right async/await, asynchronous, multi-threading, the differences and how they work (together)... And there are still to this day .NET meetings/conventions with these topis coming up with a lot of new and old developers attending,.. And still things go wrong from time to time resulting in a lot of time spend fixing issues or making workarounds because of a library not doing things proper.

Yes, when making a lot (mainly) libraries/UI apps you need to apply ConfigureAwait(false) and it can be annoying, as you have to take into account that it can be run in an environment where synchronization context is required. But if you don't or make libraries only for (company) internal with like ASP.NET Core or a Console than you hardly ever need to add it.
I think there was another discussion about Configureawait somewhere else, and I think having a property in project files like there is for NRT Nullable to choose the default compilation behavior to Configureawait(true) or Configureawait(true) if not set postfixed could be handy... but different discussion and topic.

I really find that the async/await keywords are really friendly to help make code understandable and helps to explain what is going on to people, especially to some more inexperienced developers or those less associated to the language. I know a lot of developers find that a moot thing, but by gods it is handy to have language features that are not only to be understood by developers.
The more obscure the hint of await becomes the more misreading will occur, harder to explain to people and harder the language becomes to understand over time... And something we all don't want but might happen in far future is that it will be harder to port to another language when it is time to put C# to rest.

The hint/warning keyword that something happens differently from the standard way of working, is a real big handy thing. And yes more code is become async/await fully as it works a bit like a zombie virus, but until C# and .NET are purely asynchronous from top to bottom then it is really good to have that syntax that is clear on what is going on.
I always tell new people to compare the keywords as if you are driving in a car. You should know the rules, what to do and when what to do, but you still need/want the damn traffic boards and you want them as clear as possible. On some places there can be a lot of them and then it is time to have them refactored to be more clear, maybe clean up some that are obsolete, but you don't want them made in to obscure little traffics boards that you will not notice until it is too late.
You don't want to end up Paris when you are going to Köln or people driving into your house with their cars.