In your DoSomething
example, the compiler is not complaining because the type of your MyAwaitable's GetResult
method has nothing to do with THuh
. The statement that relates to THuh
is return null;
. The null literal is implicitly convertible to THuh
, so all is well.
The IEnumerable
keyword that is analogous to await
is foreach
. await
requires a type that fits a certain pattern, and so does foreach
. One is a mechanism for consuming awaitable types, the other for consuming enumerable types.
On the other hand, iterator blocks (yield return
and yield break
) are mechanisms for defining enumerable types (by writing a method rather than explicitly declaring the type). The analogy here is the async
keyword.
To elaborate on the analogy between async
and yield return
, note that an iterator block that returns IEnumerable<int>
can contain the statement yield return 42;
similarly, an async method that returns Task<int>
can contain the statement yield return 42;
. Note how in both cases, the type of the return expression is not the return type of the method, but rather the type argument of the method's return type.
If you haven't done so yet, you really ought to read Eric Lippert's blog on these topics:
http://blogs.msdn.com/b/ericlippert/archive/tags/Async/
http://blogs.msdn.com/b/ericlippert/archive/tags/Iterators/
Also, posts on on continuation-passing style other than the ones in the Async series can be useful if the concept is new to you (as it was to me):
http://blogs.msdn.com/b/ericlippert/archive/tags/continuation+passing+style/
Finally, for examples, see Eric's blog post linking to his MSDN article and related articles in the same issue and the follow-up article by Bill Wagner at http://msdn.microsoft.com/en-us/vstudio/hh533273
EDIT
I see some samples that do not seem to follow this rule - the return value seems reachable and the value is non-default. Is this value inaccessible? If so, why the awkward inaccessible return statement?
The phrase "the endpoint of the body must be unreachable" means that you must have a return statement. The endpoint of the body comes after the return statement, and is made unreachable by the return statement. Example using a normal int-returning method:
public int Main()
{
Console.WriteLine("X");
//after this comment is the reachable end point of the body; this method therefore won't compile.
}
public int Main()
{
Console.WriteLine("X");
return 0;
//anything after the return statement is unreachable, including the end point of the body; this method therefore will compile.
}
EDIT 2
Here is a short, trivial example of an awaiter that calculates the last half of a string. The example passes a continuation that prints the result to the console. It's not thread safe!
public static class StringExtensions
{
public static SubstringAwaiter GetAwaiter(this string s)
{
return new SubstringAwaiter(s, s.Length / 2, s.Length - s.Length / 2);
}
}
public class SubstringAwaiter
{
private readonly string _value;
private readonly int _start;
private readonly int _length;
private string _result;
private Action _continuation;
public SubstringAwaiter(string value, int start, int length)
{
_value = value;
_start = start;
_length = length;
}
public bool IsCompleted { get; private set; }
public void OnCompleted(Action callback)
{
if (callback == null)
return;
_continuation += callback;
}
public string GetResult()
{
if (!IsCompleted)
throw new InvalidOperationException();
return _result;
}
public void Execute()
{
_result = _value.Substring(_start, _length);
IsCompleted = true;
if (_continuation != null)
_continuation();
}
}
public class Program
{
public static void Main()
{
var awaiter = "HelloWorld".GetAwaiter();
awaiter.OnCompleted(() => Console.WriteLine(awaiter.GetResult()));
awaiter.Execute();
}
}
IsComplete
and I call any continuations registered by the Framework withOnComplete(Action)
inMyAwaiter.SetOutcome()
. I can use a customTaskScheduler
to write a deterministic, single-file (single-threaded?) scheduling policy. 2 (Where) How easy is it to abandon a tree of continuations (when idle)? I guess the customTaskScheduler
can just choose NOT to schedule any more. Any consequences? – Berglund