4 ms·
Exception propagation is one area I have to agree. Still, there was no reason to invent whole new language semantics for that. As far as simple flows, I'll di
by jasallen 12y ago
Exception propagation is one area I have to agree. Still, there was no reason to invent whole new language semantics for that. As far as simple flows, I'll disagree. The Task Library allows for normal workflow operations and your decisions are much more (to me) explicit when you see "WaitAll", "WaitAny" chaining things together.
- contextfree 12y agoawait isn't an alternative to TPL/Tasks, it's a feature that improves a certain common use case of TPL/Tasks. "await foo" means (roughly[1]) "yield and schedule the current continuation to be run on completion of foo". What really requires language support is the "current continuation" bit, which starts to become tricky/convoluted to express directly once control flow comes in. For any use case other than this there are other tools, such as WaitAll/WaitAny as you say. [1] http://stackoverflow.com/questions/4070237/how-could-the-new-async-feature-in-c-sharp-5-0-be-implemented-with-call-cc/4071015#4071015 http://stackoverflow.com/questions/4070237/how-could-the-new...
- jasallen 12y agoNoone suggested it was not built on top of Tasks. I make it a rule never to question Eric Lippert, and I won't do so here. That said, right, the current continuation bit requires IL foo, but as the ones writing the code, there is always a way besides needing the current continuation bit. And if you're going between languages much at all, Tasks are a lot more like promises and other paradigms in other languages. Whereas the whole await business is just... weird.
- reubenbond 12y ago"WaitAll" and "WaitAny" have their non-blocking counterparts, "WhenAll" and WhenAny", which allow you to express the same logic/structure without blocking a thread. Nesting callbacks (ContinueWith) gets messy very quickly, and then your program structure and semantics are hidden behind masses of arcane ceremony. Performing async calls dependent on previous async calls is hard enough to do correctly using ContinueWith, but try using it in a loop.