Async generic delegate in C# 5.0

Question

With Iterators, the following generic delegate is possible:

public delegate IEnumerable<TOut> MyDelegate<TIn>(TIn param1);

With the new async/await in C# 5.0 CTP, I expect to be able to create the analogous delegate as follows:

public delegate async TOut MyDelegate<TIn>(TIn param1);

I can't find the C# 5.0 spec or any help in this regard. Anyone know how this can be written or if it can't be written and why?

Thanks!

Penates

Answer 1

async is an implementation detail, not an interface specification. An async delegate doesn't make sense.

Any method that returns an "awaitable" (such as Task or Task<T>) can be used with await.

So an "asynchronous delegate" would be any delegate type that returns Task or Task<T> (or any other kind of awaitable). In your case:

public delegate Task<TOut> MyDelegate<TIn, TOut>(TIn param1);

Pulling

Ok, I considered that Task<> was analogous to IEnumerable<>. I guess I'm just surprised that Task<> isn't an interface rather than a class. I am now able to find this in the documentation. Thanks! – Penates

An interface would be nice (in particular, it would allow variance), but it has some disadvantages, too. The await keyword right now uses pattern matching, rather than being dependent on the Task type. This allows other awaitables, such as the WinRT asynchronous operations in Windows 8, which may be purely unmanaged code. If there was a managed interface ITask<T>, then the unmanaged code would have to implement the managed interface, which is messy. – Pulling

@uosɐſ note also that you can similarly use foreach on any type with a GetEnumerator method that in turn returns a type with a bool-returning MoveNext method and a Current property. In other words, just as foreach is not dependent on IEnumerable, so await is not dependent on any specific type. – Lithia

@StephenCleary this is more usually called duck typing rather than pattern matching. – Lithia

@Lithia I usually use the term "duck typing" only when it is a language feature where I can supply my own type, such as C++ templates; and I use the term "pattern matching" when the language only supports a specific pre-defined pattern, such as await. I believe this is how Eric Lippert uses the terms. – Pulling

But in that piece he calls it "a fairly strong form of duck typing". He also uses the term "pattern matching" once, and the term "pattern-based approach" several times. I have read that article a couple of times already, and it always seemed to me that the "pattern" in "pattern-based approach" had more to do with "design patterns" than "pattern matching" – Lithia

@StephenCleary You guys should really consider adding an interface. Not having a variant ITask<T> practically makes C#4 and C#5 incompatible! The variance added in 4 is now unusable with the features from 5! – Reboant

@MgSam: When I was new to the async keyword, I felt a variant Task<T> would be nice. These days I find that async methods remove much of the need for a variant Task<T>. P.S. I don't work for Microsoft, so I have little say in it either way. :) – Pulling

Why would async methods remove the need for a variant Task<T>? Synchronicity has nothing to do with generic types. If I have a variant generic interface and I now want it to support being async, I have no (good) option other than to remove the variance, which is not acceptable. – Glottal

@jam40jeff: Have you considered IObservable<T> instead of Task<T>? – Pulling

@StephenCleary: Yes, but IObservable<T> doesn't provide the good API and compiler support for the pattern TAP was designed for. Namely, there are no single return value semantics and compiler support for continuations (async and await). Yes, it could be made to work, but a return type of IObservable<T> doesn't express what ITask<T> could. – Glottal

@jam40jeff: Observables are the only awaitable I'm aware of that are also covariant. – Pulling

Well, this discussion prompted me to create an ITask<out T> implementation. It's usage isn't too bad: github.com/jam40jeff/ITask – Glottal