Coffeehouse Thread

32 posts

Forum Read Only

This forum has been made read only by the site admins. No new threads or comments can be added.

Why is the "async" keyword needed?

Back to Forum: Coffeehouse
  • User profile image
    androidi

    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.

  • User profile image
    DCMonkey

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

  • User profile image
    androidi

    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.

  • User profile image
    spivonious

    @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?

  • User profile image
    vesuvius

    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.

  • User profile image
    Blue Ink

    @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).

  • User profile image
    Maddus Mattus

    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?

     

  • User profile image
    contextfree`

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

  • User profile image
    magicalclick

    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.

    Leaving WM on 5/2018 if no apps, no dedicated billboards where I drive, no Store name.
    Last modified
  • User profile image
    felix9

    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

    Generic Forum Image

    and for Rx, page 74:

    Generic Forum Image

    and for Erik Meijer, page 77

    Generic Forum Image

    Generic Forum Image

  • User profile image
    Charles

     

    , Maddus Mattus wrote

    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?

     

    This is simpler than Rx (also different and not a replacement or competing mechanism - Async is about IEnumerable and Rx is about IObservable). You should watch the C9 Live segments with the Async folks and also the one with Erik and Wolfram...

    Erik was an advisor/reviewer on the Async working group.....

    C

  • User profile image
    androidi

    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.

     

  • User profile image
    Blue Ink

    @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();

    Smiley

  • User profile image
    Maddus Mattus

    @Charles: I will, thanks Smiley

  • User profile image
    joechung

    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.

  • User profile image
    MathNerd

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

  • User profile image
    Adam​Speight2008

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

  • User profile image
    wkempf

    @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.

Conversation locked

This conversation has been locked by the site admins. No new comments can be made.