Stealing cycles from the UI thread isn't a big deal for the scenarios that await is designed for. For example, downloading a file, or waiting for a DB connection to return results. I agree 100% that it's a bad idea for CPU bound items, in which case you are recreating the problem that asynchronous operations are trying to avoid (responsive UI).
Also, when you get to Silverlight, async stuff is mandatory in a lot of circumstances, so await is a much easier way of dealing with it. Await is much more useful to the Silverlight developer (or WPF developer trying to keep their code SL compatible) than the WinForms developer.
J.Ja
Discussion on:
Message 3 of 5

































