F u n c < T > valueSelector, T a s kMa n a g e r t a s kMa n a g e r , T a s k C reationOp t i o n s options );

There isn't much to a F ut u re < T > besides what it inherits from the Ta s k base class I t has some constructors (which look a lot like T a s k's ) , and there are a lot of new static factory methods The primary difference is that instead of Ac t i o n delegates, these accept F u n c < T > delegates: this is typed as returning a value of type T There is also a non generic F ut u re class to make type inference based creation easier For example, in C# 30 and beyond you can create a new F u t u r e < T > without having to explicitly state the type argument for T

var my F ut u re = F ut u re C reat e ) => int Ma xVa l u e ) ;

In the above snippet, the my F ut u re variable ends up correctly typed as a F u t u r e < i nt > When a F u t u r e < T > finishes, the value returned from its delegate ends up accessible from the Va l u e property Any accesses to retrieve this value will block waiting for it to be bound (if it hasn't been already) and then return the value Much like the W a i t API, any unhandled exceptions will be repropagated during accesses to Va l u e You may have noticed a few strange things here: there i s a constructor (and corresponding Sta rtNew overloads) that doesn't accept any F u n c < T > Moreover, the E x c e pt i o n and Va l u e properties have public set methods This is a feature often called a promise style future, because the future itself is a promise for a value, but there is no tie-in to the scheduler itself You cannot St a rt such a future Some thread must later explicitly set the appropriate property ( E x c e pt i o n if something wrong happens, or Va l u e otherwise), and i t will behave just as i f the scheduler were responsible for doing so In other words, task state transitions will occur as expected, threads waiting for results will be awaken, and so forth

Continuations The Cont i n u eWi th methods on Ta s k and F u t u r e < T > are meant to offer an alternative to waiting Instead of waiting (which can block a thread), you can

instead register an action to be performed once the target task enters a final state This "promise" to invoke an action later on itself manifests as yet another task, meaning you can wait on it and so on This task is not neces sarily started when returned, however; the TPL continuation implementation will call Sta rt on it sometime later (Cont i n u eWi th handles the race condition in which a task completed before the call to Cont i n ueWi th; in this case, it is possible for the continuation task to have already been started, or even begun running, before it is returned) A wonderful thing about this is that you can create a string of continuations that are dependent on one another, and at the end of doing so you will have a single Ta s k handle to the whole chain The relatively obscure parameter exec uteSy n c h ronou s ly controls whether the continuation should be run asynchronously in the scheduler (the default) or synchronously whenever the task completes The only purpose for this is to avoid overhead when the continuation is a very quick action, like setting a flag or event, for instance By default, a task's continuation will fire no matter the final state of the task You can, however, specify a Ta s kCont i n u a t i on K i n d flags enum value to limit the final states in which the continuation will become active: O n R a n To Complet ion , OnCa n c e led, or On F a u l e d (The default i s equivalent to O n R a n ToCompletion I OnC a n c e l e d I On F a u lted ) If the task eventually transitions into a final state that wasn't part of the continuation's activation criteria, the continuation Ta s k object will be canceled This may cause continuations of that continuation (registered with OnCa n c eled ) to fire, and so on The F u t u r e < T > class also provides some unique overloads of Cont i n u e