Question: Why was await named await instead of wait? Is it really async + wait?

[ncaq]

I became interested in controversy from tweet. https://twitter.com/public_ai000ya/status/949948053103853573

I concluded that await comes from natural language await. https://twitter.com/ncaq/status/949961647803650048

However, it was pointed out by others that C# specifications are written as async + wait. I certainly confirmed that it was written. https://twitter.com/bagatela_8zu/status/949967049794535424

Asynchronously wait for x to complete

csharplang/introduction.md at cc435ac889996d6661a43a772085b98e410a2dc1 · dotnet/csharplang

Is await really coined by C#? Is not it related to natural language await at all?

If await is really async + wait, I think that it is irrational to take out the meaning of a and put it on wait. However, since it is so written in the actual standard, I want to know the intention of the nominator.

As far as I looked it was C# that introduced the await keyword for the first time in the programming language.

[HaloFour]

First I've heard of this.

I don't think that await actually stands for "asynchronously wait". Wouldn't make sense to invent a combined keyword like that given that there is no precedence of any other keyword like it in the C# language, and that the English word "await" already exists and has a meaning that perfectly fits. It does make sense that the team might want to avoid the word "wait" which already has meaning in various programming languages (and in BCL methods) as being a blocking operation. As for the spec, it's certainly not appropriate for the definition of a word to actually contain that word, so it does make sense to more explicitly state that "await" means to "asynchronously wait".

And ultimately, does it really matter?

[HaloFour]

I'll note that anytime I've heard anyone from Microsoft describe the feature/keyword they've pronounced the await keyword as the English word "await", not like "a"-"wait".

[Joe4evr]

The way I see it, wait rather implies that you're waiting synchronously, at which point you wouldn't be working asynchronously at all. It's like you want to bake a cake, and once you put the batter in the oven, you're just gonna sit there and do nothing for 2 hours.

[ufcpp]

from thesaurus:

• wait → interval, downtime, halt, hold
• await → anticipate, hope, ready for, look for

The latter is better to describe what an async method does.

[ncaq]

Thank you for your comment.

I don't think that await actually stands for "asynchronously wait".

I thought that I was not async + wait either. However, as a description of await in the spec, "Asynchronously wait for x to complete" was written, so I thought that another person's argument might be correct.

It does make sense that the team might want to avoid the word "wait" which already has meaning in various programming languages (and in BCL methods) as being a blocking operation.

The other point was also pointed out for compatibility, for code using the wait keyword.

As for the spec, it's certainly not appropriate for the definition of a word to actually contain that word, so it does make sense to more explicitly state that "await" means to "asynchronously wait".

Is not the spec "Asynchronously wait" written confusing?

And ultimately, does it really matter?

I was worried and there was no choice. I think that await is derived from natural language in myself so it is still more.

I'll note that anytime I've heard anyone from Microsoft describe the feature/keyword they've pronounced the await keyword as the English word "await", not like "a"-"wait".

It is that derived from natural language again.

The way I see it, wait rather implies that you're waiting synchronously, at which point you wouldn't be working asynchronously at all. It's like you want to bake a cake, and once you put the batter in the oven, you're just gonna sit there and do nothing for 2 hours.

There was one who insisted that it was abbreviation for async + wait.

The latter is better to describe what an async method does.

Certainly wait has a similar meaning to sleep.

[alrz]

https://blogs.msdn.microsoft.com/ericlippert/2010/10/29/asynchronous-programming-in-c-5-0-part-two-whence-await/

[benaadams]

Its serendipity 😄

[GeirGrusom]

hearken unto FetchAsync(…)

:heart:

[hiroshi-manabe]

At least Stephen Cleary translated it to "asynchronous wait" in his head.

And ultimately, does it really matter?

No, it didn't, at first.

But I saw someone went so far as to call it "urban legend", that the keyword "await" was named for "asynchronous wait". So it does matter now. It is not acceptable to let someone who did not coin the word tell the history.

[ncaq]

I write related links of discussion.

• asyncとawaitの由来を調べたところ,asyncとawaitのaは関係なかったことがわかりました,英語はクソ - ncaq
• await って言う単語 | ++C++; // 未確認飛行 C ブログ
• Etymology of C#'s "await" - Microsoft Community

[HaloFour]

The fact that some people have so little to do as they have to start and continue a trivial Internet debate on the subject does not make it matter.

The English definition of the word accurately describes what it does. The English pronunciation of the keyword by any team member presenting on the subject matches that of the English word (əˈwāt), not that of a combination of the English letter with the English word "wait" (eyˈwāt). If the concept of "asynchronous"+"wait" made the team chuckle enough to allow that contender to win, then the answer of serendipity seems appropriate. I'd say that there are probably significantly more amusing (and debatable) conversations that happen behind closed doors as the sausage is being made.

[hiroshi-manabe]

Of course it doesn't matter to everyone - I think it matters because it is about forging the history. But if someone thinks it doesn't matter, why does he/she bother commenting?

The English pronunciation of the keyword by any team member presenting on the subject matches that of the English word (əˈwāt), not that of a combination of the English letter with the English word "wait" (eyˈwāt).

It doesn't prove anything. Not more than the fact many people pronounce "enum" as "ee-num" doesn't prove it is named for "E-number" or something like that.

It is not for you - of course, not for me, either - to decide what "await" is named for. The answer is only in the original namer's/namers' mind. If you are not interested and you are not the original namer (which I guess is the case), you are free to leave this issue and do something you think is more important.

[CyrusNajmabadi]

I was one of the original namers.

Why was await named await instead of wait?

"wait" would not have been appropriate. As 'wait' has a lot of historical precedence in computing to indicate that you are synchronously blocked while you 'wait' for the work to be done. We did not want the keyword to imply synchronous blocking at all. While async/await has become commonplace, and fairly intuitive to most users now, at the time it was very new and we anticipated there being a lot of confusion around the feature. This was borne out by how much we saw people on our own team get confused by things (including all the subtleties around concurrency, asynchrony and the like). As such, we wanted to avoid words we though would definitely lead people down the wrong path.

Is it really async + wait

I can't recall a single person ever proposing or defending 'await' for that reason. Though i can't confirm that absolutely no one thought that. The real reason it was picked was:

1. the english term had reasonably close semantics to what we wanted. i.e.: to wait for something, but with the implication that you can go do other things while waiting for that thing to happen. i.e. "they were awaiting the birth of their first child."
2. it was short. "Foo() continue with" or "Foo() continue after" would have likely been the most consistent with how this is translated, but it felt too long and clunky for our tastes. Specifically, we wanted to avoid the 'mistake' made with "yield return"**
3. it wasn't terrible. Seriously, we had a bunch of options. Some awful, some meh, some ok. Nothing stood out as 'wow, this is perfect and amazing and awesome'. So we simply picked something we felt was ok, and which didn't bug as as we used the original prototypes.

That's it. A fairly ho hum decision in language design. We knew the semantics we wanted, and we went with syntax we felt was acceptable.

--

**

Basically, we had previously added 'word' operators in C# by adding more syntax to ensure there would be no overlapping with existing code. i.e. we couldn't just add yield expr as the iterator syntax as that would allow yield(expr) which already could have existing meaning in code. So we went with the more-of-a-mouthful yield return approach. While this has worked out acceptably for us with iterators, we felt it would be inappropriate for async. For the very simple reason that async would outweigh iterators by a factor of 1000:1 at least. So it was paramount that there be a simple way to express the operator. We knew we wanted a single word, but no existing keyword would do. Hence, why we added the 'async' pseudo-interior-modifier. That modifier actually has no impact on external code consumers (like virtually every other modifier). Instead, it literally serves only to tell the parser "hey... when parsing this code await(expr), it should be treated as the new operator, and not as a method call". It was an ungainly approach to solve a hairy syntactic problem of the time.

[HaloFour]

@CyrusNajmabadi

Must be a little humbling to see how far those keywords have been adopted into other languages/frameworks that are adopting the same functionality as C#, from EcmaScript to C++.

[hiroshi-manabe]

I was one of the original namers.

Thank you for commenting on this issue, and sorry for taking your time.

I know this really is a trivial question, but like all trivial questions, it can cause a controversy. Now we have something to refer to.

I'm happy to know the real story behind "async" - I didn't doubt it being named for "asynchronous wait".

[CyrusNajmabadi]

Must be a little humbling to see how far those keywords have been adopted into other languages/frameworks that are adopting the same functionality as C#, from EcmaScript to C++.

It feels very gratifying. I had a concern at the time that this would be akin to 'anonymous delegates'. i.e. solving the right problem, but in the wrong way. I was worried we were going to create something that we'd then have to revise and have a v2 version of (like we had with lambdas the next release after anony-delegates**). But it turned out to work out very well, and I think it's great to see it being adopted in so many areas.

I do want us to improve certain areas that are still clunky. For example, the pain around .ConfigureAwait, as well as how chaining of long async sequences is not very pleasant. However, by and large, things turned out really good, and i'm glad my concerns turned out to be unwarranted, and very insightful team members made this all work out really well.

--

Or, in other words: "it's the syntax, stupid." Syntax matters, and it's important to sweat it when you're adding something you think could legitimately be used as commonly in a codebase as lambdas/queries/etc.

[CyrusNajmabadi]

and sorry for taking your time.

Nothing to be sorry about. :)

[iam3yal]

@CyrusNajmabadi

As such, we wanted to avoid words we though would definitely lead people down the wrong path.

And here we are, many years later, people's creativity exceeds boundaries.

[iam3yal]

@CyrusNajmabadi

I do want us to improve certain areas that are still clunky. For example, the pain around .ConfigureAwait

I really hope that you will address this at some point "soon", I know that there are proposals about it but nothing is championed yet, I think.

[vladd]

@eyalsk @CyrusNajmabadi For the mitigation of ConfigureAwait pain I'd propose to consider returning back await everything-style await ThreadPoolEx.SwitchTo();. It can be used everywhere instead of ConfigureAwait(false), but (1) is guaranteed to escape the UI thread and (2) doesn't need to be repeated.

The points against this approach are listed here, but doesn't the same problem exist for ConfigureAwait?

[gafter]

I was also involved, and I confirm @CyrusNajmabadi's recollection. Also await just felt right.

[IS4Code]

Interesting, I have never observed the a in await as asynchronous. I guess I know English.

[ncaq]

Thank you. I am honored to have the comments from the nominees. It was confirmed that await is derived from natural language. This issue is closed.