Zeph (./281) :
Je sais bien que les Tasks ne proposent pas de choses complètement inutiles, forcément si tu regardes les fonctionnalités séparément une à une elles ont du sens. Ce que je leur reproche, c'est de proposer tout *à la fois*, c'est à dire d'être un mélange d'à peu près tous les paradigmes asynchrones qui existent.

C'est pas exactement un mélange… Tout est défini autour de la même fonctionnalité: Un état x représentant la fin d'exécution (erreur ou réussite) de y, déclenche un événement z. C'est simple: (Résultat + )Signal.

Si je veux fournir une API asynchrone dans laquelle je ne veux pas exposer de "Wait()" (parce que je considère que ça serait un risque de bloquer un thread pour tel ou tel évènement), je ne vais pas pouvoir utiliser Task.

Sauf que si ton API asynchrone ne doit pas bloquer sur un Wait(), sinon c'est un bug. Si tu implémentes une API sans interface (ce qui est presque toujours le cas ?), tu ne dois pas être lié à un contexte de synchronisation. Autrement dit, ton code doit s'exécuter, et s'exécutera sur le ThreadPool par défaut, donc Wait() ne posera pas de problème. (cf. ici)
En revanche, si tu as une application console dont le seul but est d'exécuter une commande qui est implémentée de manière asynchrone, ben le Wait() sera ton meilleur ami. (Exemple pas pris au hasard, c'est juste… Super fréquent)

Je suis assez d'accord avec ce que raconte ce mec sur la séparation claire des APIs synchrones et asynchrones, donc un petit lien plutôt que de tout recopier ici :
http://blog.ometer.com/2011/07/24/callbacks-synchronous-and-asynchronous/

Ben ouais mais du coup tu mélanges tout là, ça n'a absolument aucun rapport avec le schmilblick :/
Les Task ne sont pas des Callbacks (l'intérêt étant justement d'inverser ce paradigme), et en dehors du Wait() (sans rapport avec de quelconques callbacks), il n'y a absolument rien de synchrone sur les Tasks. Si on faisait le parallèle avec ce que le mec raconte, les task tombent à 100% dans le cas asynchrone, ce qui est normal, puisque c'est leur but… (i.e. La continuation est toujours exécuté après la fin d'exécution de la tâche.)
Après, en tant que développeur tu es libre de faire ta propre bidouille (e.g. avec TaskCompletionSource<T>, ou avec ManualResetEventSlim…) et de te tirer une balle dans le pieds, mais c'est quand même pas si facile que ça.