Why must async methods return Task?

re: Why must async methods return Task?

Lucian Wischik, MSFT — Sat, 24 Nov 2012 01:58:09 GMT

@Stefan - thanks for the serialization scenario. We'd discussed serialization in our design meetings. It's a big topic, so I wrote a separate blog article with a possible implementation of serialization. (Sorry for the missing spaces... this blog platform doesn't let me past code with syntax highlighting unless I go via raw HTML markup, which is losing spaces!)

How would I expect a solution to generalize to Yield? Here are some examples. (I also count f3 and f4 as the interesting examples that I might want to return).

Sub f1(lambda As IAsyncAction) ...

Sub f2(Of T)(lambda As IAsyncOperation(Of TR)) ...

Sub f3(Of T,U)(lambda As IAsyncOperationWithProgress(Of TR,TP)) ...

Sub f4(Of T)(lambda As IObservable(Of T))

Sub f5(Of T)(lambda As IAsyncEnumerable(Of T))

f1(... : Return : ...)

f2(... : Return 15 : ...) ' infers TR=integer

f3(... : Yield 12 : ... : Return "hello") ' infers TR=string, TP=integer

f4(... : Return 7 : Return 15 : Return 12 : Return ) ' infers T=integer

f5(... : If b Then Return : ... : Yield 15) ' infers T=integer

In f5 the Yield statement implies that the first generic parameter is the dominant type of all yield expressions, but in f3 it implies that the SECOND generic parameter is the dominant type of all yield expressions.

In f1/f5 the Return operand must be void, but in f2/f3 the dominant type of return operands is taken as the first generic parameter. And in f4 we use multiple returns for a function with multiple return-values, or a void return to indicate the end of the sequence.

I'll grant you that multi-return f4 might be trying to be too clever for its own good. But even just the fact that Yield sometimes binds to the first generic parameter and sometimes to the second is too ugly.

re: Why must async methods return Task?

Lucian Wischik, MSFT — Sat, 24 Nov 2012 01:46:33 GMT

@Stephen Clearly -- good point. Yes covariance would be a reason for ITask(Of T).

re: Why must async methods return Task?

Stefan Wenig — Thu, 22 Nov 2012 18:55:33 GMT

(cont'd)

You gave three reasons for not doing this. I’d like to ask you to elaborate on the first two:

- How would you expect a solution to generalize to Yield? (Btw, we can easily do our trick using iterators, we just need to install a reflection-based serialization surrogate, which works as long as all your local variables are serializable. But the syntax is awkward, e.g. instead of calling await EditObject, we’d have to do foreach (var x in EditObject) yield return x; plus there are no return values.)

- What interesting return types would it not work with? (If you think about IAsyncOperation<IEnumerable<T>>, a possible workaround may be an interface IAsyncEnuerableOperation<T> deriving from the former. This might not resolve every problem, but there have always been border cases in C# that the type system just won’t let you do. And there have been solutions, like dynamic interface proxies.)

On the third reason, I disagree strongly. You write “this kind of complex and arbitrary restriction is unprecedented and ugly”. C# already has some features that use behind-the-scene transformation, like foreach (for .Dispose()) and LINQ query expressions. Providing any unresolvable overloads for Select(), or using type parameters that cannot be inferred, will result in compilation errors. Frankly, I don’t see a real difference here. On the other hand, no single feature in C# today relies on such a complex framework type. All other dependencies of C# are a) implicit (the type does not usually show in the source code) and b) use very primitive types, like Object, ValueType or MulticastDelegate. Linking a compiler feature to a complex type that is not serializable is what is unprecedented.

We discussed this at some length and think that solution #1 would be a very useful addition that does not really bring unprecedented, unexpected or ugly behavior to C#.

We’d love to see you pick up this idea again for some hypothetical future version of C# ;-)

Thanks for listening!

Cheers, Stefan

PS: sorry for all the curly braces on your VB blog, but I assume you and most of your readers read C# fluently, and I can hardly read, let alone write VB. Just figuring out what that AsyncFunction() is took me some time (the missing space didn't help).

re: Why must async methods return Task?

Stefan Wenig — Thu, 22 Nov 2012 18:55:07 GMT

Hi Lucian,

I’m working with Michael who asked about serialization above. I’d like to elaborate a bit. What we’re trying to do is creating a way to create request-spanning methods for ASP.NET using continuation-passing style.

Here’s some simple pseudo code (not intended to show the potential of CPS web programming, just how it could work):

async Task<string> GetInput (string msg) {…}

async Task<bool> Confirm (string msg) {…}

async Task<void> EditObject (MyObject obj)

{

await ShowWebForm (“EditObject.aspx”, obj);

}

async Task CreateObject ()

{

int name = await GetInput (“object name”);

var obj = MyObject (name);

await EditObject (obj);

if (await Confirm (“do you want to keep this?”))

Repository.Add (obj);

}

The system could execute until a call to ShowWebForm occurs, which could somehow pass the parameters it receives and call a page using Server.Transfer. The current thread then ends. At the next request, execution would continue right after this call to ShowWebForm. Our problem however is that Task<T> and Task are such awfully complex and tangled objects that we don’t see a way to safely serialize and deserialize them, so this would not work with state servers.

This is our priority, so if the problem of serializing Tasks is solved, everything else is just of theoretical interest to us. But still, here it is:

Replacing Task<T> with MyTask<T> could solve the problem by using a simpler structure that serializes easily. Your solution #1 would solve this beautifully. (There should be a non-generic type corresponding to Task, i.e. Task<void>, though).

(to be continued)

re: Why must async methods return Task?

Michael — Thu, 22 Nov 2012 07:34:11 GMT

Thanks for the lengthy explanation. Enjoyed reading it :) Since I (well, the team I work in) are one of the Scenario #3 proponents, I have a follow up: We didn't want to replace Task to substitute an arbitrary adapter to our own framework but so we can replace Task with a (lightweight) implementation that is serializable. Do you have any design suggestions along the lines of what you proposed for Scenario #3

Regards, Michael

re: Why must async methods return Task?

Stephen Cleary — Thu, 22 Nov 2012 02:05:39 GMT

Enjoyed your post!

With my work in async, I have on a few occasions wished for ITask<T> - not so I can return my own implementation, but so I could use generic variance. There are a few situations where that would be really useful. Well, maybe someday generic variance will be extended to classes... :)