async & wait - sondage pour des alternatives [clos]

Maintenant que nous savons ce qui est en réserve pour le c # 5, il y a apparemment encore une ouverture pour nous pour influencer le choix des deux nouveaux mots clés pour ' Asynchrony ' qui ont été annoncés par Anders Heijsberg hier au PDC10 .

async void ArchiveDocuments(List<Url> urls) {
    Task archive = null;
    for(int i = 0; i < urls.Count; ++i) {
        var document = await FetchAsync(urls[i]);
        if (archive != null)
            await archive;
        archive = ArchiveAsync(document);
    }
}

Eric Lippert a une explication du choix des deux mots clés actuels et de la façon dont ils ont été mal compris dans les études d'utilisabilité. Les commentaires ont plusieurs autres propositions.

S'il vous plaît - une suggestion par réponse, les doublons seront supprimés.

Étant donné que je ne suis pas clair sur le sens / la nécessité de async, je ne peux pas vraiment m'y opposer, mais ma meilleure suggestion pour le remplacer awaitest:

yield while (regardez! pas de nouveaux mots-clés)

Notez qu'après y avoir réfléchi un peu plus, je me demande si la réutilisation whilede cette manière est une bonne idée - la tendance naturelle serait d'attendre un booléen après.

(Pense: trouver de bons mots clés, c'est comme trouver de bons noms de domaine :)

Que diriez-vous de ne pas avoir de mot-clé?

J'aimerais que le compilateur se rende compte que, la plupart du temps, lorsque j'appelle une méthode asynchrone, je veux le résultat.

Document doc = DownloadDocumentAsync();

C'est ça. La raison pour laquelle les gens ont du mal à trouver un mot-clé pour cette chose est parce que c'est comme avoir un mot-clé pour "faire ce que vous feriez si les choses étaient parfaitement normales". Cela devrait être la valeur par défaut, pas besoin d'un mot clé.

Mise à jour

J'ai suggéré à l'origine que le compilateur devrait être intelligent avec l'inférence de type pour comprendre quoi faire. En réfléchissant davantage à cela, je garderais l'implémentation existante dans le CTP telle qu'elle est, mais j'y ferais quelques ajouts triviaux, afin de réduire les cas où vous auriez besoin d'utiliser le awaitmot clé explicitement.

Nous inventons un attribut: [AutoAwait]. Cela ne peut être appliqué qu'aux méthodes. Une façon de l'appliquer à votre méthode consiste à la marquer async. Mais vous pouvez également le faire à la main, par exemple:

[AutoAwait]
public Task<Document> DownloadDocumentAsync()

Ensuite, à l'intérieur de n'importe quelle asyncméthode, le compilateur supposera que vous voulez attendre un appel à DownloadDocumentAsync, vous n'avez donc pas besoin de le spécifier. Tout appel à cette méthode l'attendra automatiquement.

Document doc = DownloadDocumentAsync();

Maintenant, si vous voulez "devenir intelligent" et obtenir le Task<Document>, vous utilisez un opérateur start, qui ne peut apparaître qu'avant un appel de méthode:

Task<Document> task = start DownloadDocumentAsync();

Bien, je pense. Maintenant, un appel de méthode simple signifie ce qu'il signifie généralement: attendez que la méthode soit terminée. Et startindique quelque chose de différent: n'attendez pas.

Pour le code qui apparaît en dehors d'une asyncméthode, la seule façon dont vous êtes autorisé à appeler une [AutoAwait]méthode est de la préfixer avec start. Cela vous oblige à écrire du code qui a la même signification, qu'il apparaisse asyncou non dans une méthode.

Ensuite, je commence à devenir gourmand! :)

Tout d'abord, je souhaite asyncappliquer aux méthodes d'interface:

interface IThing
{
    async int GetCount();
} 

Cela signifie essentiellement que la méthode d'implémentation doit retourner Task<int>ou quelque chose de compatible avec await, et les appelants à la méthode obtiendront un [AutoAwait]comportement.

De plus, lorsque j'implémente la méthode ci-dessus, je veux pouvoir écrire:

async int GetCount()

Je n'ai donc pas à mentionner Task<int>comme type de retour.

De plus, je veux asyncm'appliquer aux types de délégués (qui, après tout, sont comme des interfaces avec une méthode). Donc:

public async delegate TResult AsyncFunc<TResult>();

Un asyncdélégué a - vous l'aurez deviné - un [AutoAwait]comportement. À partir d'une asyncméthode, vous pouvez l'appeler et elle sera automatiquement awaitéditée (à moins que vous ne choisissiez de la juste start). Et donc si vous dites:

AsyncFunc<Document> getDoc = DownloadDocumentAsync;

Ça marche. Ce n'est pas un appel de méthode. Aucune tâche n'a encore été lancée - une async delegaten'est pas une tâche. C'est une usine pour faire des tâches. Tu peux dire:

Document doc = getDoc();

Et cela va démarrer une tâche et attendre qu'elle se termine et vous donner le résultat. Ou vous pouvez dire:

Task<Document> t = start getDoc();

Donc, un endroit dans ce domaine où la "plomberie" fuit est que si vous voulez faire un délégué à une asyncméthode, vous devez savoir utiliser un async delegatetype. Donc au lieu de Funcvous devez dire AsyncFunc, et ainsi de suite. Bien qu'un jour ce genre de chose pourrait être corrigé par une inférence de type améliorée.

Une autre question est de savoir ce qui devrait arriver si vous dites commencer par une méthode ordinaire (non asynchrone). De toute évidence, une erreur de compilation serait l'option sûre. Mais il y a d'autres possibilités.

hearken unto AsyncFetch(…)

(si vous ne l'obtenez pas, lisez l' entrée de blog d'Eric . Au moins c'est mieux que for sooth Romeo wherefore art thou AsyncFetch(…))

Je pense que ça asyncva, mais c'est peut-être parce que je l'associe aux pages asynchrones ASP.NET - même idée.

Pour le awaitmot - clé que je préfère continue afterou resume after.

Je ne suis pas comme yieldou l' une de ses variantes, parce que la sémantique sont telles que la méthode peut donner jamais réellement l' exécution; cela dépend de l'état de la tâche.

J'ai également ajouté des commentaires sur le blog d'Eric, je ne vois aucun problème avec l'utilisation du même mot clé async

var data = async DownloadFileAsync(url);

J'exprime juste que je veux télécharger le fichier de manière asynchrone. Il y a un peu de redondance ici, "async" apparaît deux fois, car c'est aussi dans le nom de la méthode. Le compilateur pourrait être très intelligent et détecter la convention selon laquelle les méthodes se terminant par "Async" sont en fait des méthodes async, et ajouter cela pour nous dans le code compilé. Au lieu de cela, vous voudrez peut-être juste appeler

var data = async DownloadFile(url);

au lieu d'appeler le synchrone

var data = DownloadFile(url);

Heck, nous devrions également être en mesure de les définir de la même manière, puisque le mot-clé async est là dans notre déclaration, pourquoi devons-nous ajouter manuellement "Async" à chaque nom de méthode - le compilateur peut le faire pour nous.

async = task - Il s'agit de modifier une fonction pour renvoyer une tâche, alors pourquoi ne pas utiliser le mot-clé "task"?

wait = finish - Nous n'avons pas nécessairement besoin d'attendre, mais la tâche doit "terminer" avant d'utiliser le résultat.

J'aime yield until. yield while, déjà suggéré, est génial et n'introduit pas de nouveaux mots clés, mais je pense que "jusqu'à" capture un peu mieux le comportement.

Je pense que yield <something>c'est une excellente idée, car le rendement capture déjà l'idée de faire si bien le reste de la méthode. Peut-être que quelqu'un peut penser à un meilleur mot que «jusqu'à».

Je veux simplement enregistrer mon vote pour la suggestion d'Aaron G comefrom- la première utilisation appropriée que j'ai vue de la déclaration COMCFROM d'INTERCAL . L'idée est que c'est en quelque sorte l'opposé de GOTO (sauter de l'instruction GOTO) en ce sens qu'il fait de la place dans votre code pour passer à l'instruction COMEFROM.

Puisque nous avons affaire à Task<T>s, que diriez-vous d'utiliser startcomme mot-clé précédant l'instruction, comme dans:

start var document = FetchAsync(urls[i]);

Il est à noter que F # utilise également le async mot clé dans ses flux de travail asynchrones, ce qui est à peu près la même chose que la nouvelle fonctionnalité asynchrone en C # 5. Par conséquent, je garderais celui-là même

Pour le awaitmot clé en F #, ils utilisent simplement let!au lieu de let. C # n'a pas la même syntaxe d'affectation, ils ont donc besoin de quelque chose sur le côté droit du =signe. Comme l'a dit Benjol, il fonctionne de la même manière yieldque ce devrait donc être presque une variante de cela.

yield async FetchAsync(..)

Cela va parfaitement avec le asyncmodificateur que vous devez appliquer à la méthode que vous invoquez. Et aussi la sémantique du courant yield returnqui est, vous revenez et donne l'exécution au code énumérateur tandis que dans ce cas, vous cédez votre exécution à la méthode asynchrone.

Imaginez si à l'avenir il y aurait d'autres utilisations yield, nous pourrions ajouter un yield xoù x est la nouvelle fonctionnalité brillante au lieu d'avoir tous ces mots clés différents pour faire la plupart du temps la même chose, donner l'exécution.

Franchement, je ne comprends pas très bien l'argument «ne pas céder l'exécution». Après tout, l'intérêt d'appeler une autre méthode n'est-il pas déjà de «céder l'exécution» à cette méthode? Qu'il soit asynchrone ou non? Je manque quelque chose ici?

Et bon pour vous si le async retourne de manière synchrone mais en ayant le mot-clé là, cela signifie qu'il y a une chance probable que la méthode s'exécute de manière asynchrone et que vous céderez l'exécution à une autre méthode. Votre méthode doit en tenir compte, qu'elle effectue ou non des appels asynchrones.

OMI Je pense que les différents cas «sans céder» sont un détail de mise en œuvre. Je préfère garantir la cohérence de la langue (c'est-à-dire la réutilisation yield).

Que diriez-vous complete, comme dans "Je veux que la tâche soit terminée"?

Task<byte[]> downloadTask = DownloadFileAsync(url);
byte[] data = complete downloadTask;

task(pour la déclaration de méthode) et async(dans le corps de la méthode)