This was an interesting Stack Overflow question from last week. At first glance it seems to be impossible, but if you think about what
yield return actually does, an answer presents itself.
await facility in the C# 5 CTP is mightly reminiscent of the iterator methods (
yield return) added in C# 2. So much so that it is irresistable (to someone like me, anyway) to see if I can reinvent one using the other.
For many years now people have already been implementing something a lot like
yield return, and I’ve blogged about that before. It’s quite possible to write a simple library such that
yield return can play much the same role as
await, except for some irritating limitations.
But can we go the other way, and write a library that provides the capability of
yield return using only the new
Short answer: yes.
Long answer: (now read on…)
One of the great things in C# is
yield return. It’s a form of continuation implemented atop the CLR in an ingeniously lightweight way, purely by transforming the body of an ordinary method into a state machine class.
ssuming you’d have a lot of these objects building up in the GC, it might prove important to reduce the number of ancillary allocations going on, so it may be better to avoid creating a list of the properties in every single instance.
C# has the yield return feature, which makes it easy to write state machines as if they were plain old methods:
The idea of returning functions via yield return to simply asynchronous IO programming has a precedent in Microsoft’s Concurrency and Coordination Runtime:
Although they are yielding interfaces, really they are yielding functions:
The ITask interface has only one really important method: Execute, which means that really it’s a function (a delegate in C# terms). I think the functional style makes the whole thing cleaner, but the point is that the idea was already in use in the Microsoft’s CCR, perhaps as long ago as 2005 (although that’s difficult to verify).
If you do asynchronous programming (or have been put off it in the past by the complexity) and you haven’t already looked at this, then you really should:
I blogged yesterday about an idea for doing the same kind of thing but using lambdas to encapsulate the last remaining bit of complexity. Today I’ve applied the same idea, but with the goal of providing a thin layer that works along with Jeffrey Richter’s AsyncEnumerator class, essentially providing an optional new way of working with it. As I am not especially familiar with the asynchronous APIs, it would be especially stupid for me to try and reinvent the wheel instead of building on the work Jeffrey has already done.
Update: More in-depth stuff about this
I just watched this video of Jeffrey Richter demonstrating his AsyncEnumerator class:
The key idea is the realisation that yield return takes care of turning a single function into a continuation that can be resumed under the control of some other code, but still provides a natural way to write procedurally. This is just what is needed to manage asynchronous communication. Great stuff.
There was a brief flurry of excitement about the fancy yield return syntax when the C# 2.0 specification was first published some years ago, and the idea of it being used for creating coroutines.
This quickly died down, as far as I can see anyway. Either people forgot the idea, or it became such boringly standard practice that no one ever thinks to discuss it anymore. I don’t know which, but I think it deserves more attention either way.
There were a few people at the time saying that it was a shame that C# appeared to only support coroutines in a special case where the function returns some weird IEnumerable<T> thing, and wouldn’t it have been better if it was more general?