Why is the "async" keyword needed?

Looking at one of the bit less trivial samples included, the (C# Xpert) CancellationAndProgress, it seems nearly every method has the new async keyword.

Is this keyword only meant to highlight that the method has the new "asyncness" in the control flow? I'm thinking, if this is the case, wouldn't it be better to use the IDE graphical capabilities to make the dev aware that there's funky things going on if it really is that big deal. Or is the mainstream still coding in notepad so its important that you can easily from notepad tell this matter.

I think the IDE should provide capabilities similar to modern disassemblers, that is, insert graphical arrows to the left of the code that show what is going on incase there's something less obvious going on. Of course to improve scrolling performance those should only be visible when you hover to the outline strip which causes the outline to be highlighted. Or simply allow user to pick say a different background color for the particular line that has unusual flow / compiler magic.

Now if the keyword actually serves some purpose beyond enabling await to work in the method, then that's another matter but I didn't really get this from what I saw so far?

I just have a feeling I'm going to see async keyword glued to every method in my code and then if the purpose was to highlight something it's going to be pretty pointless.

So how are you going to tell the IDE where to insert graphical arrows?

OK of course it can't in every case use arrows to point at something, the point was about highlighting rather that adding a new keyword in the language for that purpose, if that's the case here.

@androidi: I agree. It seems like async is required on every method that uses await. If this is really true, couldn't the compiler just infer this?

No it isn't. I am an expert on Begin and End asychronous .NET code, with monitors and mutexes. It makes me feel very bright, now everyone will be able to write async code...darn!

I have recently been witnessing some graduates get up to speed with Automatic Properties, Anonymous methods and Lambda expressions, and it really has not been a pretty sight. Abstractions are good as starting blocks, but at some stage they will need to understand what is actually going on underneath the covers.

@spivonious: well, yes, the compiler could infer this, but I presume it's the easiest way to determine if a method is asynchronous or not without looking at the source code, even because we don't always have access to it.

As to sticking the "async" in front of every method, I think that one of the demos showed in passing that the compliler will complain about that (you get a squiggly green line, I believe).

This just screams Rx Framework!

I can't wrap my head around it.

The clean beautifull way that Rx is implented, versus this new keyword,..

I don't know,..

What would Erik say?

strictly speaking, it's definitely not required - it could be inferred from the return type and the presence of one or more "awaits".

I don't know much about it, but, I like how C# force me to add ref and out in the method parameter. Sure, it is a bit tedious, but, the code is also slaping me face with what I should know right there at method call level. And yes, I like to get slap by editors to make sure my tiny brain didn't ignores something important.

Page 70 of Lucian Wischik's presentation:
http://blogs.msdn.com/b/lucian/archive/2010/10/29/a-technical-walk-through-all-of-the-async-ctp.aspx

and for Rx, page 74:

and for Erik Meijer, page 77

I can't recall seeing  an example in c# where "await" would collide with some existing identifier like those slides mention.

Sometimes I wish there was some way to allow breaking changes while making it minimal effort to convert to the "C# next generation" with those changes. There's tools to convert very large code base from C# to C++/Java and back within hours so converting from C# 4 to C# 5 doesn't seem a big deal unless the team goes really wild with things.  And if something is still broken after conversion - well you have your unit tests and the conversion tool can add warning comment to the code for things that may need checking and testing.

edit:

I now watched

http://channel9.msdn.com/Blogs/Charles/Visual-Studio-Async-Meet-the-team

and it was stated that C# doesn't need the keyword, it's only required for VB. It was stated it makes sense to add it to C# also but why wasn't clarified. Let the speculation ensue: Maybe it's purely for "language parity" reasons... But I think feature parity is one thing, this async would be the case of making C# look like VB just because. Don't like that thought at all.

@androidi: I think a possible conflict could come from code like this:

Task bar;

void Foo () {
  ...
  await bar;
  ...
}

we could be either using the await contextual keyword or attempting to declare a variable of type await. Both are equally likely, so the compiler would end up breaking on old code.

The presence of async tips the compiler that we do mean the contextual keyword and not the type.

Again, this is just speculation on my part... Eric Lippert has been on a roll about continuation and async, and he promised an explanation about why async is needed.

Incidentally: The same post also mentions a few alternatives that were considered, mostly using composed keywords (which I believe would have solved this particular ambiguity). My favorite is:

for sooth Romeo wherefore art thou FetchAsync();

@Charles: I will, thanks

I really like the new async/await syntax.  It makes a lot of sense if you do a lot of asynchronous programming and have come to hate callbacks and having to roll your own exception handling recovery and cancellation mechanisms.

@Blue Ink:This shouldn't conflict because I belive async should only apply to function calls not types.

@felix9: Erik's picture would allow speculative execution to run in parallel, I think.

@MathNerd: It does conflict. His example isn't applied to a type, but to an Task instance, and that must be something allowed in order to handle more complex scenarios such as WaitAll and WaitAny. While I believe it's a very unlikely scenario that somone has a type named "await", especially if they care at all about C# coding conventions, it's still something that a language designer must consider.