J'ai pensé qu'il pourrait être utile d'écrire comment les autres langages gèrent une construction d'attente.

Kotlin

val result = task.await()

C

var result = await task;

F

let! result = task()

Scala

val result = Await.result(task, timeout)

Python

result = await task

JavaScript

let result = await task;

C ++ (Coroutines TR)

auto result = co_await task;

Pirater

$result = await task;

Dard

var result = await task;

Avec tout cela, rappelons-nous que les expressions Rust peuvent résulter en plusieurs méthodes chaînées. La plupart des langues ont tendance à ne pas faire cela.

Avec tout cela, rappelons-nous que les expressions Rust peuvent résulter en plusieurs méthodes chaînées. La plupart des langues ont tendance à ne pas faire cela.

Je dirais que les langages qui prennent en charge les méthodes d'extension ont tendance à en avoir. Ceux-ci incluraient Rust, Kotlin, C # (par exemple, méthode-syntaxe LINQ et divers constructeurs) et F #, bien que ce dernier utilise fortement l'opérateur de tube pour le même effet.

Purement anecdotique de ma part, mais je lance régulièrement une douzaine d'expressions enchaînées de méthodes dans le code Rust dans la nature et cela se lit et fonctionne bien. Je n'ai pas vécu cela ailleurs.

Je voudrais voir que ce problème a été référencé dans le premier post du # 50547 (à côté de la case à cocher "Syntaxe finale pour await").

Kotlin

val result = task.await()

La syntaxe de Kotlin est:

val result = doTask()

Le await est juste un suspendable function , pas une chose de première classe.

Merci de l'avoir mentionné. Kotlin se sent plus implicite parce que les futurs sont impatients par défaut. Cependant, il est toujours courant dans un bloc différé d'utiliser cette méthode pour attendre d'autres blocs différés. Je l'ai certainement fait plusieurs fois.

@cramertj Puisqu'il y a 276 commentaires dans https://github.com/rust-lang/rust/issues/50547 , pourriez-vous résumer les arguments qui y sont présentés pour qu'il soit plus facile de ne pas les répéter ici? (Peut-être les ajouter à l'OP ici?)

Kotlin se sent plus implicite parce que les futurs sont impatients par défaut. Cependant, il est toujours courant dans un bloc différé d'utiliser cette méthode pour attendre d'autres blocs différés. Je l'ai certainement fait plusieurs fois.

peut-être devriez-vous ajouter les deux cas d'utilisation avec un peu de contexte / description.

Qu'en est-il également des autres langages utilisant des attentes implicites, comme go-lang?

Une des raisons d'être en faveur d'une syntaxe post-correction est que du point de vue des appelants, une attente se comporte un peu comme un appel de fonction: vous abandonnez le contrôle de flux et lorsque vous le récupérez, un résultat attend sur votre pile. Dans tous les cas, je préférerais une syntaxe qui embrasse le comportement de type fonction en contenant une paranthèse de fonction. Et il y a de bonnes raisons de vouloir séparer la construction des coroutines à partir de leur première exécution afin que ce comportement soit cohérent entre les blocs de synchronisation et asynchrones.

Mais alors que le style de coroutine implicite a été débattu, et que je suis du côté de l'explicitation, l' appel d'une coroutine ne pourrait-il pas être assez explicite? Cela fonctionne probablement mieux lorsque la coroutine n'est pas directement utilisée lors de sa construction (ou pourrait fonctionner avec des flux). En substance, contrairement à un appel normal, nous nous attendons à ce qu'une coroutine prenne plus de temps que nécessaire dans un ordre d'évaluation plus détendu. Et .await!() est plus ou moins une tentative de différenciation entre les appels normaux et les appels coroutine.

Donc, après avoir, espérons-le, fourni une vision quelque peu nouvelle des raisons pour lesquelles la post-correction pourrait être préférée, une modeste proposition de syntaxe:

• future(?)
• ou future(await) qui vient avec ses propres compromis bien sûr mais semble être accepté comme moins déroutant, voir en bas de l'article.

Adaptation d'un exemple assez populaire d'un autre thread (en supposant que logger.log également une coroutine, pour montrer à quoi ressemble un appel immédiat):

async fn log_service(&self) -> T {
   let service = self.myService.foo(); // Only construction
   self.logger.log("beginning service call")(?);
   let output = service(?); // Actually wait for its result
   self.logger.log("foo executed with result {}.", output)(?);
   output
}

Et avec l'alternative:

async fn log_service(&self) -> T {
   let service = self.myService.foo(); // Only construction
   self.logger.log("beginning service call")(await);
   let output = service(await);
   self.logger.log("foo executed with result {}.", output)(await);
   output
}

Pour éviter le code illisible et pour faciliter l'analyse, n'autorisez que des espaces après le point d'interrogation, pas entre celui-ci et le paran ouvert. Donc future(? ) est bon alors que future( ?) ne le serait pas. Ce problème ne se pose pas dans le cas de future(await) où tous les jetons actuels peuvent être utilisés comme précédemment.

L'interaction avec d'autres opérateurs de post-correction (tels que l'actuel ? -try) est également similaire aux appels de fonction:

async fn try_log(message: String) -> Result<usize, Error> {
    let logger = acquire_lock()(?);
    // Very terse, construct the future, wait on it, branch on its result.
    let length = logger.log_into(message)(?)?;
    logger.timestamp()(?);
    Ok(length)
}

Ou

async fn try_log(message: String) -> Result<usize, Error> {
    let logger = acquire_lock()(await);
    // Very terse, construct the future, wait on it, branch on its result.
    let length = logger.log_into(message)(await)?;
    logger.timestamp()(await);
    Ok(length)
}

Quelques raisons d'aimer ça:

• Comparé à .await!() il ne fait pas allusion à un membre qui pourrait avoir d'autres utilisations.
• Il suit la priorité naturelle des appels, comme le chaînage et l'utilisation de ? . Cela réduit le nombre de classes de priorité et facilite l'apprentissage. Et les appels de fonction ont toujours été quelque peu spéciaux dans le langage (même s'ils ont un trait), de sorte qu'il n'y a aucune attente d'un code utilisateur capable de définir son propre my_await!() qui a une syntaxe et un effet très similaires.
• Cela pourrait se généraliser aux générateurs et aux flux, ainsi qu'aux générateurs qui s'attendent à ce que plus d'arguments soient fournis lors de la reprise. En substance, cela se comporte comme un FnOnce tandis que Streams se comporterait comme un FnMut . Des arguments supplémentaires peuvent également être acceptés facilement.
• Pour ceux qui ont déjà utilisé le Futures actuel, cela montre comment un ? avec Poll aurait dû fonctionner tout au long (séquence de stabilisation malheureuse ici). En tant qu'étape d'apprentissage, cela est également cohérent avec l'attente d'un opérateur basé sur ? pour détourner le flux de contrôle. (await) d'un autre côté ne satisferait pas cela mais après tout la fonction s'attendra toujours à reprendre au point de divergence.
• Il utilise une syntaxe de type fonction, bien que cet argument ne soit valable que si vous êtes d'accord avec moi: smile:

Et des raisons de ne pas aimer ça:

• ? semble être un argument mais il n'est même pas appliqué à une expression. Je crois que cela pourrait être résolu par l'enseignement, car le gage auquel il semble s'appliquer est l'appel de fonction lui-même, qui est la notion quelque peu correcte. Cela signifie également positivement que la syntaxe est sans ambiguïté, j'espère.
• Un mélange plus (et différent) de paranthesis et de ? peut être difficile à analyser. Surtout quand vous avez un futur retournant le résultat d'un autre futur: construct_future()(?)?(?)? . Mais vous pourriez faire le même argument pour pouvoir obtenir un résultat d'un objet fn , conduisant à une expression telle que celle-ci étant autorisée: foobar()?()?()? . Puisque néanmoins je n'ai jamais vu cela utilisé ni plainte, la division en déclarations séparées dans de tels cas semble être assez rarement requise. Ce problème n'existe pas non plus pour construct_future()(await)?(await)? -
• future(?) est mon meilleur coup à une syntaxe laconique et encore un peu concise. Pourtant, son raisonnement est fondé sur les détails d'implémentation dans les coroutines (retour temporaire et envoi à la reprise), ce qui pourrait le rendre inadapté à une abstraction. future(await) serait une alternative qui pourrait encore être expliquée après que await ait été internalisé en tant que mot-clé, mais la position de l'argument est un peu difficile à avaler pour moi. Cela pourrait être bien, et il est certainement plus lisible lorsque la coroutine renvoie un résultat.
• Interférence avec d'autres propositions d'appel de fonction?
• Le tien? Vous n'avez pas besoin de l'aimer, c'était juste un gaspillage de ne pas au moins proposer cette syntaxe de post-correction laconique.

future(?)

Il n'y a rien de spécial à propos de Result : les contrats à terme peuvent renvoyer n'importe quel type de Rust. Il se trouve que certains Futures rapportent Result

Alors, comment cela fonctionnerait-il pour les contrats à terme qui ne rapportent pas Result ?

Il semble que ce que je voulais dire n'était pas clair. future(?) est ce qui a été précédemment décrit comme future.await!() ou similaire. Le branchement sur un futur qui renvoie également un résultat serait future(?)? (deux façons différentes d'abandonner le flux de contrôle tôt). Cela rend le sondage futur (?) et le test des résultats ? orthogonaux. Edit: a ajouté un exemple supplémentaire pour cela.

Le branchement sur un futur qui renvoie également un résultat serait future(?)?

Merci de clarifier. Dans ce cas, je n'en suis certainement pas fan.

Cela signifie que l'appel d'une fonction qui renvoie un Future<Output = Result<_, _>> serait écrit comme foo()(?)?

Il est très syntaxique et utilise ? à deux fins complètement différentes.

Si c'est précisément le conseil à l'opérateur ? qui est lourd, on pourrait bien sûr le remplacer par le mot clé nouvellement réservé. J'avais seulement initialement considéré que cela ressemblait trop à un argument réel de type déroutant, mais le compromis pourrait fonctionner en termes d'aider à analyser mentalement l'énoncé. Ainsi, la même instruction pour impl Future<Output = Result<_,_>> deviendrait:

• foo()(await)?

Le meilleur argument pour lequel ? est approprié est que le mécanisme interne utilisé est quelque peu similaire (sinon nous ne pourrions pas utiliser Poll dans les bibliothèques actuelles) mais cela peut manquer le point d'être une bonne abstraction.

C'est très syntaxique

je pensais que c'était tout l'intérêt des attentes explicites?

il utilise ? à deux fins complètement différentes.

oui, donc la syntaxe foo()(await) serait beaucoup plus agréable.

cette syntaxe est comme appeler une fonction qui renvoie une fermeture puis appeler cette fermeture dans JS.

Ma lecture de "syntax-heavy" était plus proche de "sigil-heavy", voir une séquence de ()(?)? est assez choquant. Cela a été soulevé dans le message d'origine:

Un mélange plus (et différent) de paranthesis et de ? peut être difficile à analyser. Surtout quand vous avez un futur retournant le résultat d'un autre futur: construct_future()(?)?(?)?

Mais vous pourriez faire le même argument pour pouvoir obtenir un résultat d'un objet fn , conduisant à une expression telle que celle-ci étant autorisée: foobar()?()?()? . Puisque néanmoins je n'ai jamais vu cela utilisé ni plainte, la division en déclarations séparées dans de tels cas semble être assez rarement requise.

Je pense que la réfutation ici est: combien de fois avez-vous vu -> impl Fn dans la nature (sans parler de -> Result<impl Fn() -> Result<impl Fn() -> Result<_, _>, _>, _> )? Combien de fois pensez-vous voir -> impl Future<Output = Result<_, _>> dans une base de code asynchrone? Le fait de devoir nommer une valeur de retour rare impl Fn pour rendre le code plus facile à lire est très différent de devoir nommer une fraction significative des valeurs de retour temporaires impl Future .

Le fait de devoir nommer une valeur de retour impl Fn rare pour rendre le code plus facile à lire est très différent de devoir nommer une fraction significative des valeurs de retour impl futures temporaires.

Je ne vois pas comment ce choix de syntaxe a une influence sur le nombre de fois où vous devez nommer explicitement votre type de résultat. Je ne pense pas que cela n'influence pas l'inférence de type différemment de await? future .

Cependant, vous avez tous fait de très bons points ici et plus je crée d'exemples (j'ai édité le message original pour toujours contenir les deux versions de syntaxe), plus je penche vers future(await) moi-même. Il n'est pas déraisonnable de taper et conserve toute la clarté de la syntaxe des appels de fonction que cela était censé évoquer.

Combien de fois vous attendez-vous à voir -> impl Future

> dans une base de code asynchrone?

Je m'attends à voir le type équivalent de celui-ci (un fn asynchrone qui renvoie un résultat) tout le temps , probablement même la majorité de tous les fns asynchrones, car si ce que vous attendez est même un IO, vous lancerez presque certainement Erreurs d'E / S vers le haut.

Lien vers mon article précédent sur le problème du suivi et ajout de quelques réflexions supplémentaires.

Je pense qu'il y a très peu de chances qu'une syntaxe n'incluant pas la chaîne await caractères

• Le préfixe attend avec des délimiteurs obligatoires. Ici, c'est aussi une décision sur les délimiteurs (accolades ou parenthèses ou accepter les deux; tous ont leurs propres avantages et inconvénients). Autrement dit, await(future) ou await { future } . Cela résout complètement les problèmes de précédence, mais est syntaxiquement bruyant et les deux options de délimiteur présentent des sources possibles de confusion.
• Le préfixe attend avec la priorité "utile" concernant ? . (Autrement dit, qui attendent se lie plus étroitement que?). Cela peut surprendre certains utilisateurs qui lisent du code, mais je pense que les fonctions qui renvoient des résultats futurs seront extrêmement plus courantes que les fonctions qui renvoient des résultats futurs.
• Le préfixe attend avec la priorité "évidente" concernant ? . (Autrement dit, cela? Lie plus serré que d'attendre). Sucre de syntaxe supplémentaire await? pour une attente et? opérateur. Je pense que ce sucre de syntaxe est nécessaire pour rendre cet ordre de priorité viable, sinon tout le monde écrira (await future)? tout le temps, ce qui est une pire variante de la première option que j'ai énumérée.
• Postfix attend avec l'espace de syntaxe wait. Cela résout le problème de priorité en ayant un ordre visuel clair entre les deux opérateurs. Je me sens mal à l'aise avec cette solution à bien des égards.

Mon propre classement parmi ces choix change chaque fois que j'examine la question. À partir de ce moment, je pense que l'utilisation de la préséance évidente avec le sucre semble être le meilleur équilibre entre ergonomie, familiarité et compréhension. Mais dans le passé, j'ai privilégié l'une des deux autres syntaxes de préfixe.

Pour des raisons de discussion, je vais donner à ces quatre options ces noms:

Nom | Avenir | Avenir du résultat | Résultat du futur
--- | --- | --- | ---
Délimiteurs obligatoires | await(future) ou await { future } | await(future)? ou await { future }? | await(future?) ou await { future? }
Priorité utile | await future | await future? | await (future?)
Préséance évidente avec sucre | await future | await? future ou (await future)? | await future?
Mot-clé Postfix | future await | future await? | future? await

(J'ai spécifiquement utilisé "postfix keyword" pour distinguer cette option des autres syntaxes postfix comme "postfix macro".)

L'une des lacunes de la `` bénédiction '' await future? dans la préséance utile mais aussi d'autres qui ne fonctionnent pas comme post-correction serait que les modèles habituels de conversion manuelle d'expressions avec ? peuvent ne plus s'appliquer, ou exiger que Future réplique explicitement les méthodes Result d'une manière compatible. Je trouve cela surprenant. S'ils sont répliqués, il devient soudainement aussi déroutant de savoir lesquels des combinateurs travaillent sur un futur retourné et lesquels sont impatients. En d'autres termes, il serait aussi difficile de décider ce que fait réellement un combinateur que dans le cas de l'attente implicite. (Edit: en fait, voir deux commentaires ci-dessous où j'ai une perspective plus technique ce que je veux dire par un remplacement surprenant de ? )

Un exemple où nous pouvons récupérer d'un cas d'erreur:

async fn previously() -> Result<_, lib::Error> {
    let _ = await get_result()?;
}

async fn with_recovery() -> Result<_, lib::Error> {
    // Does `or_recover` return a future or not? Suddenly very important but not visible.
    let _ = await get_result().unwrap_or_else(or_recover);
    // If `or_recover` is sync, this should still work as a pattern of replacing `?` imho.
    // But we also want `or_recover` returning a future to work, as a combinator for futures?

    // Resolving sync like this just feel like wrong precedence in a number of ways
    // Also, conflicts with `Result of future` depending on choice.
    let _ = await get_result()?.unwrap_or_else(or_recover);
}

Ce problème ne se produit pas pour les opérateurs de post-correction réels:

async fn with_recovery() -> Result<_, lib::Error> {
    // Also possible in 'space' delimited post-fix await route, but slightly less clear
    let _ = get_result()(await)
        // Ah, this is sync
        .unwrap_or_else(or_recover);
    // This would be future combinator.
    // let _ = get_result().unwrap_or_else(or_recover)(await);
}

// Obvious precedence syntax
let _ = await get_result().unwrap_or_else(or_recover);

// Post-fix function argument-like syntax
let _ = get_result()(await).unwrap_or_else(or_recover);

Ce sont des expressions différentes, l'opérateur point a une priorité plus élevée que l'opérateur "priorité évidente" await , donc l'équivalent est:

let _ = get_result().unwrap_or_else(or_recover)(await);

Cela a exactement la même ambiguïté quant or_recover savoir si or_recover si pour une raison quelconque vous avez besoin de savoir si cette partie spécifique est asynchrone).

Cela a exactement la même ambiguïté de savoir si or_recover est asynchrone ou non.

Pas exactement pareil. unwrap_or_else doit produire une coroutine car elle est attendue, donc l'ambiguïté est de savoir si get_result est une coroutine (donc un combinateur est construit) ou un Result<impl Future, _> (et Ok contient déjà une coroutine, et Err construit une). Les deux n'ont pas les mêmes préoccupations de pouvoir identifier d'un coup d'œil le gain d'efficacité en déplaçant un point de séquence await vers un join , ce qui est l'une des principales préoccupations de attendre implicite. La raison en est que dans tous les cas, ce calcul intermédiaire doit être sync et doit avoir été appliqué au type avant await et doit avoir abouti à la coroutine attendue. Il y a une autre préoccupation plus grande ici:

Ce sont des expressions différentes, l'opérateur point a une priorité plus élevée que l'opérateur d'attente "priorité évidente", donc l'équivalent est

Cela fait partie de la confusion, le remplacement de ? par une opération de récupération a fondamentalement changé la position de await . Dans le contexte de la syntaxe ? , étant donné une expression partielle expr de type T , j'attends la sémantique suivante d'une transformation (en supposant que T::unwrap_or_else existe) :

• expr? -> expr.unwrap_or_else(or_recover)
• <T as Try>::into_result(expr)? -> T::unwrap_or_else(expr, or_recover)

Cependant, sous 'Priorité utile' et await expr? ( await expr donne T ) nous obtenons à la place

• await expr? -> await expr.unwrap_or_else(or_recover)
• <T as Try>::into-result(await expr) -> await Future::unwrap_or_else(expr, or_recover)

alors que dans une préséance évidente, cette transformation ne s'applique plus du tout sans paranthèse supplémentaire, mais au moins l'intuition fonctionne toujours pour «Résultat du futur».

Et qu'en est-il du cas encore plus intéressant où vous attendez à deux points différents dans une séquence de combinateur? Avec n'importe quelle syntaxe de préfixe, je pense que cela nécessite des paranthèses. Le reste du langage Rust essaie longtemps d'éviter cela pour faire fonctionner les «expressions évaluées de gauche à droite», un exemple de ceci est la magie d'auto-ref.

Exemple pour montrer que cela empire pour les chaînes plus longues avec plusieurs points d'attente / essai / combinaison.

// Chain such that we
// 1. Create a future computing some partial result
// 2. wait for a result 
// 3. then recover to a new future in case of error, 
// 4. then try its awaited result. 
async fn await_chain() -> Result<usize, Error> {
    // Mandatory delimiters
    let _ = await(await(partial_computation()).unwrap_or_else(or_recover))?
    // Useful precedence requires paranthesis nesting afterall
    let _ = await { await partial_computation() }.unwrap_or_else(or_recover)?;
    // Obivious precendence may do slightly better, but I think confusing left-right-jumps after all.
    let _ = await? (await partial_computation()).unwrap_or_else(or_recover);
    // Post-fix
    let _ = partial_computation()(await).unwrap_or_else(or_recover)(await)?;
}

Ce que j'aimerais voir évité, c'est de créer l'analogue Rust de l'analyse de type C où vous sautez entre
côtés gauche et droit de l'expression pour les combinateurs 'pointer' et 'array'.

Entrée de table dans le style de @withoutboats :

| Nom | Avenir | Avenir du résultat | Résultat du futur |
| - | - | - | - |
| Délimiteurs obligatoires | await(future) | await(future)? | await(future?) |
| Priorité utile | await future | await future? | await (future?) |
| Préséance évidente | await future | await? future | await future? |
| Appel Postfix | future(await) | future(await)? | future?(await) |

| Nom | Enchaîné |
| - | - |
| Délimiteurs obligatoires | await(await(foo())?.bar())? |
| Priorité utile | await(await foo()?).bar()? |
| Préséance évidente | await? (await? foo()).bar() |
| Appel Postfix | foo()(await)?.bar()(await) |

Je suis fortement en faveur d'un postfix wait pour diverses raisons mais je n'aime pas la variante montrée par @withoutboats , principalement il semble pour les mêmes raisons. Par exemple. foo await.method() est déroutant.

Regardons d'abord un tableau similaire mais en ajoutant quelques variantes de postfix supplémentaires:

| Nom | Avenir | Avenir du résultat | Résultat du futur |
| ---------------------- | -------------------- | ----- ---------------- | --------------------- |
| Délimiteurs obligatoires | await { future } | await { future }? | await { future? } |
| Priorité utile | await future | await future? | await (future?) |
| Préséance évidente | await future | await? future | await future? |
| Mot-clé Postfix | future await | future await? | future? await |
| Champ Postfix | future.await | future.await? | future?.await |
| Méthode Postfix | future.await() | future.await()? | future?.await() |

Regardons maintenant une expression future chaînée:

| Nom | Futures chaînées des résultats |
| ---------------------- | -------------------------- ----------- |
| Délimiteurs obligatoires | await { await { foo() }?.bar() }? |
| Priorité utile | await (await foo()?).bar()? |
| Préséance évidente | await? (await? foo()).bar() |
| Mot-clé Postfix | foo() await?.bar() await? |
| Champ Postfix | foo().await?.bar().await? |
| Méthode Postfix | foo().await()?.bar().await()? |

Et maintenant, pour un exemple dans le monde réel, à partir de reqwests , où vous voudrez peut-être attendre un futur enchaîné de résultats (en utilisant mon formulaire d'attente préféré).

let res: MyResponse = client.get("https://my_api").send().await?.json().await?;

En fait, je pense que chaque séparateur a l'air bien pour la syntaxe postfix, par exemple:
let res: MyResponse = client.get("https://my_api").send()/await?.json()/await?;
Mais je n'ai pas une forte opinion sur celui à utiliser.

La macro de postfix (ie future.await!() ) pourrait-elle toujours être une option? C'est clair, concis et sans ambiguïté:

| Avenir | Avenir du résultat | Résultat du futur |
| --- | --- | --- |
| future.await! () | future.await! ()? | futur? .await! () |

De plus, la macro postfix nécessite moins d'efforts pour être implémentée, et est facile à comprendre et à utiliser.

De plus, la macro postfix nécessite moins d'efforts pour être implémentée, et est facile à comprendre et à utiliser.

De plus, il utilise simplement une fonctionnalité lang commune (ou du moins cela ressemblerait à une macro de suffixe normale).

Une macro postfix serait bien car elle combine la concision et la chaînabilité de postfix avec les propriétés non magiques et la présence évidente de macros, et s'intégrerait bien avec des macros d'utilisateurs tiers, telles que .await_debug!() , .await_log!(WARN) ou .await_trace!()

Une macro postfix serait bien car elle combine [...] les propriétés non magiques [...] des macros

@novacrazy le problème avec cet argument est que toute macro await! _ serait magique, elle effectue une opération qui n'est pas possible dans le code écrit par l'utilisateur (actuellement, l'implémentation basée sur le générateur sous-jacent est quelque peu exposée, mais je crois comprendre que avant la stabilisation, cela sera complètement caché (et l'interaction avec lui pour le moment nécessite de toute façon d'utiliser des fonctionnalités nocturnes internes de rustc )).

@ Nemo157 Hmm. Je ne savais pas que c'était censé être si opaque.

Est-il trop tard pour reconsidérer l'utilisation d'une macro procédurale comme #[async] pour faire la transformation de la fonction "asynchrone" en fonction du générateur, plutôt qu'un mot clé magique? Il s'agit de trois caractères supplémentaires à taper, et pourraient être marqués dans la documentation de la même manière que #[must_use] ou #[repr(C)] .

Je n'aime vraiment pas l'idée de cacher autant de couches d'abstraction qui contrôlent directement le flux d'exécution. Cela semble contraire à ce qu'est Rust. L'utilisateur doit être en mesure de suivre complètement le code et de comprendre comment tout fonctionne et où va l'exécution. Ils devraient être encouragés à pirater les choses et à tromper les systèmes, et s'ils utilisent Rust sûr, cela devrait être sûr. Cela n'améliore rien si nous perdons le contrôle de bas niveau, et je peux aussi bien m'en tenir à des contrats à terme bruts.

Je crois fermement que Rust, le langage (et non std / core ), devrait fournir des abstractions et une syntaxe uniquement si elles sont impossibles (ou très peu pratiques) à faire par les utilisateurs ou std . Toute cette chose asynchrone est devenue incontrôlable à cet égard. Avons-nous vraiment besoin de quelque chose de plus que l'API pin et les générateurs dans rustc ?

@novacrazy Je suis généralement d'accord avec le sentiment mais pas avec la conclusion.

devrait fournir des abstractions et une syntaxe uniquement si elles sont impossibles (ou très peu pratiques) à faire par les utilisateurs ou std.

Quelle est la raison d'avoir des boucles for dans le langage alors qu'elles pourraient aussi être une macro qui se transforme en loop avec des pauses. Quelle est la raison de || closure quand il pourrait s'agir d'un trait dédié et de constructeurs d'objets. Pourquoi avons-nous introduit ? alors que nous avions déjà try!() . La raison pour laquelle je ne suis pas d’accord avec ces questions et vos conclusions est la cohérence. L'intérêt de ces abstractions n'est pas seulement le comportement qu'elles encapsulent mais aussi l'accessibilité de celui-ci. for -replacement se décompose en mutabilité, chemin de code principal et lisibilité. || -replacement se décompose en verbosité de la déclaration - similaire à Futures actuellement. try!() se décompose dans l'ordre attendu des expressions et de la composabilité.

Considérez que async n'est pas seulement le décorateur d'une fonction, mais qu'il existe d'autres idées pour fournir des modèles supplémentaires par aync-blocks et async || . Puisqu'elle s'applique à différents éléments de langage, la facilité d'utilisation d'une macro semble sous-optimale. Ne même pas penser à la mise en œuvre si elle doit être visible par l'utilisateur alors.

L'utilisateur doit être en mesure de suivre complètement le code et de comprendre comment tout fonctionne et où va l'exécution. Ils devraient être encouragés à pirater les choses et à tromper les systèmes, et s'ils utilisent Rust sûr, cela devrait être sûr.

Je ne pense pas que cet argument s'applique parce que l'implémentation de coroutines utilisant entièrement std api reposerait probablement fortement sur unsafe . Et puis il y a l'argument inverse , car alors qu'il est faisable et vous ne serez pas arrêté même s'il y a moyen syntaxique et sémantique dans la langue de le faire-tout changement va être fortement au risque de rupture des hypothèses faites en unsafe -code. Je soutiens que Rust ne devrait pas donner l'impression qu'il essaie d'offrir une interface standard à l'implémentation de bits qu'il n'a pas l'intention de stabiliser bientôt, y compris les composants internes de Coroutines. Un analogue à cela serait extern "rust-call" qui sert de magie actuelle pour indiquer clairement que les appels de fonction n'ont pas une telle garantie. Nous pourrions vouloir ne jamais avoir à return , même si le sort des coroutines empilées n'a pas encore été décidé. Nous pourrions vouloir accrocher une optimisation plus profondément dans le compilateur.

A part: En parlant de quelle idée, en théorie, pas aussi sérieuse, pourrait-on attendre la coroutine comme un hypothétique extern "await-call" fn () -> T ? Si tel est le cas, cela permettrait en prélude un

trait std::ops::Co<T> {
    extern "rust-await" fn await(self) -> T;
}

impl<T> Co<T> for Future<Output=T> { }

alias. future.await() dans les éléments documentés d'un espace utilisateur. Ou d'ailleurs, une autre syntaxe d'opérateur pourrait également être possible.

@HeroicKatora

Pourquoi avons-nous introduit ? alors que nous avions déjà try!()

Pour être honnête, j'étais également contre cela, même si cela s'est développé sur moi. Ce serait plus acceptable si Try était un jour stabilisé, mais c'est un autre sujet.

Le problème avec les exemples de «sucre» que vous donnez est qu'ils sont du sucre très, très mince. Même impl MyStruct est plus ou moins de sucre pour impl <anonymous trait> for MyStruct . Ce sont des sucres de qualité de vie qui n'ajoutent aucun frais généraux.

En revanche, les générateurs et les fonctions asynchrones ajoutent une surcharge pas tout à fait insignifiante et une surcharge mentale importante. Les générateurs en particulier sont très difficiles à implémenter en tant qu'utilisateur et pourraient être utilisés plus efficacement et plus facilement dans le cadre du langage lui-même, tandis que l'async pourrait être implémenté relativement facilement.

Le point sur les blocs ou fermetures asynchrones est intéressant cependant, et je concède qu'un mot-clé y serait plus utile, mais je m'oppose toujours à l'incapacité d'accéder aux éléments de niveau inférieur si nécessaire.

Idéalement, il serait merveilleux de prendre en charge le mot clé async et une macro d'attribut / procédurale #[async] , la première permettant un accès de bas niveau au générateur généré (sans jeu de mots). Pendant ce temps, yield devrait être interdit dans les blocs ou les fonctions utilisant async comme mot-clé. Je suis sûr qu'ils pourraient même partager le code de mise en œuvre.

Comme pour await , si les deux sont possibles, nous pourrions faire quelque chose de similaire, et limiter le mot-clé await à async fonctions / blocs de mots-clés, et utiliser une sorte de await!() macro dans les fonctions #[async] .

Pseudocode:

// imaginary generator syntax stolen from JavaScript
fn* my_generator() -> T {
    yield some_value;

    // explicit return statements are only included to 
    // make it clear the generator/async functions are finished.
    return another_value;
}

// `await` keyword would not be allowed here, but the `yield` keyword is
#[async]
fn* my_async_generator() -> Result<T, E> {
    let item = some_op().await!()?; // uses the `.await!()` macro
    // which would really just use `yield` internally, but with the pinning API

    yield future::ok(item.clone());

    return Ok(item);
}

// `yield` would not be allowed here, but the `await` keyword is.
async fn regular_async() -> Result<T, E> {
   let some_op = async || { /*...*/ };

   let item = some_op() await?;

   return Ok(item);
}

Le meilleur des deux mondes.

Cela ressemble à une progression plus naturelle de la complexité à présenter à l'utilisateur, et peut être utilisé plus efficacement pour plus d'applications.

N'oubliez pas que ce problème concerne spécifiquement la discussion de la syntaxe de await . D'autres conversations sur la façon dont les fonctions et les blocs async sont implémentés sont hors de portée, sauf dans le but de rappeler aux gens que await! n'est pas quelque chose que vous pouvez ou ne pourrez jamais écrire dans Rust's langue de surface.

Je voudrais pondérer spécifiquement les avantages et les inconvénients de toutes les propositions de syntaxe post-correction. Si l'une des syntaxes se démarque avec un petit nombre d'inconvénients, nous devrions peut-être y aller. Dans le cas contraire, il serait préférable de prendre en charge une syntaxe délimitée par un préfixe de syntaxe qui est compatible avec une post-correction encore à déterminer si le besoin s'en fait sentir. Comme Postfix semble résonner comme étant le plus concis pour quelques membres, il semble pratique de les évaluer fortement avant de passer à d'autres.

La comparaison sera syntax , example (le reqwest de @mehcode ressemble à un benchmark du monde réel utilisable à cet égard), puis un tableau de ( concerns , et facultatif resolution , par exemple s'il est convenu que cela pourrait se résumer à l'enseignement). N'hésitez pas à ajouter de la syntaxe et / ou des préoccupations, je les éditerai dans ce post collectif. Si je comprends bien, toute syntaxe qui n'implique pas await semblera très probablement étrangère aux nouveaux arrivants et aux utilisateurs expérimentés, mais toutes celles actuellement répertoriées l'incluent.

Exemple dans une syntaxe de préfixe pour référence seulement, ne faites pas de bikeshed cette partie s'il vous plaît:

let sent = (await client.get("https://my_api").send())?;
let res: MyResponse = (await sent.json())?;

• Mot-clé Postfix foo() await?
  
  
  
  • Exemple: client.get("https://my_api").send() await?.json() await?
  
  
  • | Préoccupation | Résolution |
    
    | - | - |
    
    | Le chaînage sans ? peut être déroutant ou interdit | |
  
  
• Champ Postfix foo().await?
  
  
  
  • Exemple: client.get("https://my_api").send().await?.json().await?
  
  
  • | Préoccupation | Résolution |
    
    | - | - |
    
    | Ressemble à un champ | |
  
  
• Méthode Postfix foo().await()?
  
  
  
  • Exemple: client.get("https://my_api").send().await()?.json().await()?
  
  
  • | Préoccupation | Résolution |
    
    | - | - |
    
    | Ressemble à une méthode ou à un trait | Il peut être documenté comme ops:: trait? |
    
    | Pas un appel de fonction | |
  
  
• Appel Postfix foo()(await)?
  
  
  
  • Exemple: client.get("https://my_api").send()(await)?.json()(await)?
  
  
  • | Préoccupation | Résolution |
    
    | - | - |
    
    | Peut être confondu avec l'argument réel | mot-clé + mise en évidence + pas de chevauchement |
  
  
• Macro Postfix foo().await!()?
  
  
  
  • Exemple: client.get("https://my_api").send().await!()?.json().await!()?
  
  
  • | Préoccupation | Résolution |
    
    | - | - |
    
    | Ne sera pas réellement une macro… | |
    
    | … Ou, await n'est plus un mot clé | |
  
  

Une réflexion supplémentaire sur le post-correctif vs le préfixe du point de vue de l'incorporation éventuelle de générateurs: compte tenu des valeurs, yield et await occupent deux types d'instructions opposées. Le premier donne une valeur de votre fonction vers l'extérieur, le second accepte une valeur.

Sidenote: Eh bien, Python a des générateurs interactifs où yield peut renvoyer une valeur. Symétriquement, les appels à un tel générateur ou à un flux nécessitent des arguments supplémentaires dans un paramètre de type fortement. N'essayons pas de généraliser trop loin, et nous verrons que l'argument est probablement transféré dans les deux cas.

Ensuite, je soutiens qu'il n'est pas naturel que ces déclarations se ressemblent. Ici, comme pour les expressions d'affectation, nous devrions peut-être nous écarter d'une norme définie par d'autres langages lorsque cette norme est moins cohérente et moins concise pour Rust. Comme exprimé ailleurs, tant que nous incluons await et que des similitudes avec d'autres expressions avec le même ordre d'argumentation existent, il ne devrait y avoir aucun obstacle majeur à la transition même à partir d'un autre modèle.

Depuis implicite semble hors de la table.

En utilisant async / await dans d'autres langages et en regardant les options ici, je n'ai jamais trouvé qu'il était syntaxiquement agréable d'enchaîner les futurs.

Une variante non chaînable est-elle sur la table?

// TODO: Better variable names.
await response = client.get("https://my_api").send();
await response = response?.json();
await response = response?;

J'aime un peu ça, car vous pourriez faire valoir que cela fait partie du modèle.

Le problème avec l'attente d'une reliure est que l'histoire d'erreur est loin d'être agréable.

// Error comes _after_ future is awaited
let await res = client.get("http://my_api").send()?;

// Ok
let await res = client.get("http://my_api").send();
let res = res?;

Nous devons garder à l'esprit que presque tous les futurs disponibles dans la communauté à attendre sont faillibles et doivent être combinés avec ? .

Si nous avons vraiment besoin du sucre de syntaxe:

await? response = client.get("https://my_api").send();
await? response = response.json();

Il faudrait ajouter à la fois await et await? en tant que mots clés ou nous l'étendons également à let , c'est- let? result = 1.divide(0); dire

Compte tenu de la fréquence à laquelle le chaînage est utilisé dans le code Rust, je suis tout à fait d'accord qu'il est important que l'attente chaînée soit aussi claire que possible pour le lecteur. Dans le cas de la variante postfix de await:

client.get("https://my_api").send().await()?.json().await()?;

Cela se comporte généralement de la même manière que je m'attends à ce que le code Rust se comporte. J'ai un problème avec le fait que await() dans ce contexte ressemble à un appel de fonction, mais a un comportement magique (sans fonction) dans le contexte de l'expression.

La version macro de postfix rendrait cela plus clair. Les gens sont habitués aux points d'exclamation en rouille signifiant "il y a de la magie ici" et j'ai certainement une préférence pour cette version pour cette raison.

client.get("https://my_api").send().await!()?.json().await!()?;

Cela dit, cela vaut la peine de considérer que nous avons déjà try!(expr) dans la langue et que c'était notre précurseur pour ? . Ajouter une macro await!(expr) maintenant serait tout à fait cohérent avec la façon dont try!(expr) et ? ont été introduits dans le langage.

Avec la version await!(expr) de await, nous avons la possibilité soit de migrer vers une macro postfixe plus tard , soit d'ajouter un nouvel opérateur de style ? sorte que le chaînage devienne facile. Un exemple similaire à ? mais pour await:

// Not proposing this syntax at the moment. Just an example.
let a = perform()^;

client.get("https://my_api").send()^?.json()^?;

Je pense que nous devrions utiliser await!(expr) ou await!{expr} pour l'instant car c'est à la fois très raisonnable et pragmatique. Nous pouvons alors prévoir de migrer vers une version postfixe de await (ie .await! ou .await!() ) plus tard si / une fois les macros postfix deviennent une chose. (Ou éventuellement en passant par l'ajout d'un opérateur de style ? supplémentaire ... après beaucoup de bikeshedding sur le sujet: P)

FYI, la syntaxe de Scala n'est pas Await.result car c'est un appel bloquant. Les Futures de Scala sont des monades et utilisent donc des appels de méthode normaux ou la compréhension de la monade for :

for {
  result <- future.map(further_computation)
  a = result * 2
  _ <- future_fn2(result)
} yield 123

À la suite de cette horrible notation, une bibliothèque appelée scala-async été créée avec la syntaxe à laquelle je suis le plus favorable, qui est la suivante:

import scala.concurrent.ExecutionContext.Implicits.global
import scala.async.Async.{async, await}

val future = async {
  val f1 = async { ...; true }
  val f2 = async { ...; 42 }
  if (await(f1)) await(f2) else 0
}

Cela reflète fortement ce à quoi je voudrais que le code rust ressemble, avec l'utilisation de délimiteurs obligatoires, et, en tant que tel, je voudrais être d'accord avec les autres pour rester avec la syntaxe actuelle de await!() . Early Rust était lourd de symboles et a été éloigné pour une bonne raison, je suppose. L'utilisation du sucre syntaxique sous la forme d'un opérateur postfix (ou autre) est, comme toujours, rétrocompatible, et la clarté de await!(future) est sans ambiguïté. Cela reflète également la progression que nous avons eue avec try! , comme mentionné précédemment.

L'avantage de le conserver sous forme de macro est qu'il est plus immédiatement évident en un coup d'œil qu'il s'agit d'une fonctionnalité de langage plutôt que d'un appel de fonction normal. Sans l'ajout de ! , la mise en évidence de la syntaxe de l'éditeur / visionneuse serait le meilleur moyen de pouvoir repérer les appels, et je pense que se fier à ces implémentations est un choix plus faible.

Mes deux cents (pas un contributeur régulier, fwiw) Je suis le plus partisan de copier le modèle de try! . Cela a été fait une fois auparavant, cela a bien fonctionné et après qu'il est devenu très populaire, il y avait suffisamment d'utilisateurs pour envisager un opérateur postfix.

Donc mon vote serait: stabiliser avec await!(...) et punt sur un opérateur postfix pour un joli chaînage basé sur un sondage des développeurs Rust. Await est un mot-clé, mais le ! indique que c'est quelque chose de "magique" pour moi et les parenthèses le maintiennent sans ambiguïté.

Aussi une comparaison:

| Postfix | Expression |
| --- | --- |
| .await | client.get("https://my_api").send().await?.json().await? |
| .await! | client.get("https://my_api").send().await!?.json().await!? |
| .await() | client.get("https://my_api").send().await()?.json().await()? |
| ^ | client.get("https://my_api").send()^?.json()^? |
| # | client.get("https://my_api").send()#?.json()#? |
| @ | client.get("https://my_api").send()@?.json()@? |
| $ | client.get("https://my_api").send()$?.json()$? |

Mon troisième centime est que j'aime @ (pour «attendre») et # (pour représenter le multi-threading / concurrence).

J'aime aussi le suffixe @ ! Je pense que ce n'est en fait pas une mauvaise option, même s'il semble que ce n'est pas viable.

• _ @ for await_ est un mnémonique agréable et facile à retenir
• ? et @ seraient très similaires, donc apprendre @ après avoir appris ? ne devrait pas être un tel saut
• Il facilite le balayage d'une chaîne d'expressions de gauche à droite, sans avoir à parcourir en avant pour trouver un délimiteur de fermeture afin de comprendre une expression

Je suis très favorable à la syntaxe await? foo , et je pense qu'elle est similaire à une syntaxe vue en mathématiques, où par exemple. sin² x peut être utilisé pour signifier (sin x) ². Cela semble un peu gênant au début, mais je pense que c'est très facile de s'y habituer.

Comme dit ci-dessus, je suis favorable à l'ajout de await!() tant que macro, tout comme try!() , pour l'instant et finalement à décider comment le postfixer. Si nous pouvons garder à l'esprit le support d'un rustfix qui convertit automatiquement les appels await!() vers le postfix, attend que ce soit encore à décider, encore mieux.

L'option de mot-clé postfix est clairement gagnante pour moi.

• Il n'y a pas de problème de priorité / ordre, mais l'ordre pourrait toujours être rendu explicite avec des parenthèses. Mais surtout pas besoin d'imbrication excessive (argument similaire pour préférer le suffixe «?» Au remplacement de «try ()!»).

• Cela a l'air bien avec le chaînage multiligne (voir le commentaire précédent de @earthengine), et encore une fois, il n'y a aucune confusion concernant la commande ou ce qui est attendu. Et pas d'imbrication / de parenthèses supplémentaires pour les expressions avec de multiples utilisations de await:

let x = x.do_something() await
         .do_another_thing() await;
let x = x.foo(|| ...)
         .bar(|| ...)
         .baz() await;

• Elle se prête à une simple macro await! () (Voir le commentaire précédent de @novacrazy):

macro_rules! await {
    ($e:expr) => {{$e await}}
}

• Même sur une seule ligne, nue (sans le '?'), Le postfix attend le chaînage des mots clés ne me dérange pas car il se lit de gauche à droite et nous attendons le retour d'une valeur sur laquelle la méthode suivante opère alors (même si je voudrais juste préférez le code rustfmt sur plusieurs lignes). L'espace rompt la ligne et est suffisant comme indicateur visuel / signal que l'attente se produit:

client.get("https://my_api").send() await.unwrap().json() await.unwrap()

Pour suggérer un autre candidat que je n'ai pas encore vu mettre en avant (peut-être parce qu'il ne serait pas analysable), qu'en est-il d'un amusant opérateur postfix à double point '..'? Cela me rappelle que nous attendons quelque chose (le résultat!) ...

client.get("https://my_api").send()..?.json()..?

J'aime aussi le suffixe @ ! Je pense que ce n'est en fait pas une mauvaise option, même s'il semble que ce n'est pas viable.

• _ @ for await_ est un mnémonique agréable et facile à retenir
• ? et @ seraient très similaires, donc apprendre @ après avoir appris ? ne devrait pas être un tel saut
• Il facilite le balayage d'une chaîne d'expressions de gauche à droite, sans avoir à parcourir en avant pour trouver un délimiteur de fermeture afin de comprendre une expression

Je ne suis pas fan de l'utilisation de @ pour await. Il est difficile de taper sur un clavier à disposition fin / balayage car je dois appuyer sur alt-gr avec mon pouce droit, puis appuyer sur la touche 2 sur la ligne de numéro. De plus, @ a une signification bien établie (at), donc je ne vois pas pourquoi nous devrions en confondre la signification.

Je préfère de loin taper simplement await , c'est plus rapide car il ne nécessite aucune acrobatie au clavier.

Voici ma propre évaluation, très subjective. J'ai également ajouté future@await , ce qui me semble intéressant.

| syntaxe | notes |
| --- | --- |
| await { f } | fort:

• très simple
• parallèles for , loop , async etc.

• très verbeux (5 lettres, 2 accolades, 3 espaces facultatifs, mais probablement peluchés)
• le chaînage entraîne de nombreuses accolades imbriquées ( await { await { foo() }?.bar() }? )

• parallèles await syntaxe de Python, JS, C # et Dart
• simple, court
• la priorité utile et la priorité évidente se comportent bien avec ? ( await fut? contre await? fut )

• ambiguë: la préséance utile ou évidente doit être apprise
• le chaînage est également très lourd ( await (await foo()?).bar()? vs await? (await? foo()).bar() )

• permet un chaînage très facile
• court
• belle complétion de code

• tromper les utilisateurs en leur faisant croire que c'est un champ / fonction / macro défini quelque part. Edit: Je suis d'accord avec @jplatte que await!() est le moins magique

• permet un chaînage très facile
• court

• tromper les utilisateurs en leur faisant croire qu'il existe une variable await définie quelque part et que les futurs peuvent être appelés comme une fonction

• permet un chaînage très facile
• court

• ne correspond à rien dans la syntaxe de Rust, pas évident
• mon cerveau regroupe les client.get("https://my_api").send() await.unwrap().json() await.unwrap() en client.get("https://my_api").send() , await.unwrap().json() et await.unwrap() (groupés par abord, puis . ) ce qui n'est pas correct
• pour Haskellers: ressemble à du curry mais ne l'est pas

• permet un chaînage très facile
• très court

• semble un peu maladroit (du moins au début)
• consomme @ qui pourrait être mieux adapté à autre chose
• peut être facile à ignorer, en particulier dans les grandes expressions
• utilise @ d'une manière différente de toutes les autres langues

• permet un chaînage très facile
• court
• belle complétion de code
• await n'a pas besoin de devenir un mot clé
• compatible vers l'avant: permet d'ajouter de nouveaux opérateurs de suffixe sous la forme @operator . Par exemple, le ? aurait pu être fait comme @try .
• mon cerveau regroupe les client.get("https://my_api").send()@await.unwrap().json()@await.unwrap() dans les bons groupes (groupés par . abord, puis @ )

• utilise @ d'une manière différente de toutes les autres langues
• pourrait inciter à ajouter trop d'opérateurs postfix inutiles

Mes scores:

• familiarity (fam): à quel point cette syntaxe est-elle proche des syntaxes connues (Rust et autres, comme Python, JS, C #)
• évidence (obv): Si vous deviez lire ceci dans le code de quelqu'un d'autre pour la première fois, seriez-vous capable de deviner la signification, la préséance, etc.?
• verbosité (vrb): combien de caractères il faut pour écrire
• visibilité (vis): à quel point il est facile de repérer (plutôt que d'oublier) dans le code
• chaining (cha): Comme il est facile de l'enchaîner avec . et autres await
• grouping (grp): si mon cerveau regroupe le code dans les bons morceaux
• compatibilité ascendante (fwd): si cela permet d'être ajusté plus tard de manière insécable

| syntaxe | fam | obv | vrb | vis | cha | grp | fwd |
| --------------------- | ----- | ----- | ----- | ----- | --- - | ----- | ----- |
| await!(fut) | ++ | + | - | ++ | - | 0 | ++ |
| await { fut } | ++ | ++ | - | ++ | - | 0 | + |
| await fut | ++ | - | + | ++ | - | 0 | - |
| fut.await | 0 | - | + | ++ | ++ | + | - |
| fut.await() | 0 | - | - | ++ | ++ | + | - |
| fut.await!() | 0 | 0 | - | ++ | ++ | + | - |
| fut(await) | - | - | 0 | ++ | ++ | + | - |
| fut await | - | - | + | ++ | ++ | - | - |
| fut@ | - | - | ++ | - | ++ | ++ | - |
| fut@await | - | 0 | + | ++ | ++ | ++ | 0 |

Il me semble que nous devrions refléter la syntaxe try!() dans la première coupe et obtenir une utilisation réelle de l'utilisation de await!(expr) avant d'introduire une autre syntaxe.

Cependant, si / quand nous construisons une syntaxe alternative.

Je pense que @ air moche, "at" pour "async" ne me semble pas aussi intuitif, et le symbole est déjà utilisé pour la correspondance de motifs.

async préfixe ? (ce qui sera souvent).

Postfix .await!() enchaîne bien, semble assez immédiatement évident dans sa signification, inclut le ! pour me dire qu'il va faire de la magie, et est moins roman syntaxiquement, donc de la "prochaine coupe" approche I personnellement favoriserait celui-ci. Cela dit, pour moi, il reste à voir à quel point cela améliorerait le code réel par rapport à la première coupe await! (expr) .

Je préfère l'opérateur de préfixe pour les cas simples:
let result = await task;
Cela semble beaucoup plus naturel en tenant compte du fait que nous n'écrivons pas le type de résultat, donc attendre aide mentalement lors de la lecture de gauche à droite pour comprendre que le résultat est une tâche avec l'attente.
Imaginez-le comme ceci:
let result = somehowkindoflongtask await;
tant que vous n'atteignez pas la fin de la tâche, vous ne vous rendez pas compte que le type qu'il renvoie doit être attendu. Gardez à l'esprit aussi (bien que cela soit sujet à changement et non directement lié à l'avenir du langage) que les IDE en tant qu'Intellij insèrent le type (sans aucune personnalisation, si cela est même possible) entre le nom et les égaux.
Imaginez-le comme ceci:

Cela ne veut pas dire que mon opinion est à cent pour cent en faveur du préfixe. Je préfère fortement la version postfix de future lorsque les résultats sont impliqués, car cela semble beaucoup plus naturel. Sans aucun contexte, je peux facilement dire lequel de ces mots signifie quoi:
future await?
future? await
Regardez plutôt celui-ci, lequel de ces deux est vrai, du point de vue d'un débutant:
await future? === await (future?)
await future? === (await future)?

Je suis en faveur du mot-clé préfixe: await future .

C'est celui utilisé par la plupart des langages de programmation qui ont async / await, et est donc immédiatement familier aux personnes qui connaissent l'un d'entre eux.

En ce qui concerne la priorité de await future? , quel est le cas courant?

• Une fonction retournant un Result<Future> qui doit être attendu.
• Un futur à attendre qui renvoie un Result : Future<Result> .

Je pense que le deuxième cas est beaucoup plus courant lorsqu'il s'agit de scénarios typiques, car les opérations d'E / S peuvent échouer. Par conséquent:

await future? <=> (await future)?

Dans le premier cas moins courant, il est acceptable d'avoir des parenthèses: await (future?) . Cela pourrait même être une bonne utilisation de la macro try! si elle n'était pas obsolète: await try!(future) . De cette façon, l'opérateur await et le point d'interrogation ne sont pas des côtés différents du futur.

Pourquoi ne pas prendre await comme premier paramètre de fonction async ?

async fn await_chain() -> Result<usize, Error> {
    let _ = partial_computation(await)
        .unwrap_or_else(or_recover)
        .run(await)?;
}

client.get("https://my_api")
    .send(await)?
    .json(await)?

let output = future
    .run(await);

Ici future.run(await) est une alternative à await future .
Il peut s'agir simplement d'une fonction async régulière qui prend le futur et exécute simplement la macro await!() dessus.

C ++ (TR de concurrence)

auto result = co_await task;

C'est dans le Coroutines TS, pas la concurrence.

Une autre option pourrait être d'utiliser le mot clé become au lieu de await :

async fn become_chain() -> Result<usize, Error> {
    let _ = partial_computation_future(become)
        .unwrap_or_else(or_recover_future)
        .start(become)?;
}

client.get("https://my_api")
    .send_future(become)?
    .json_future(become)?

let output = future.start(become);

become pourrait cependant être un mot-clé pour le TCO garanti

Merci @EyeOfPython pour cet [aperçu]. C'est particulièrement utile pour les personnes qui viennent tout juste de rejoindre le hangar à vélos.

Personnellement, j'espère que nous resterons à l'écart de f await , simplement parce que la syntaxe est très peu rustique et que cela semble un peu spécial et magique. Cela deviendrait l'une de ces choses sur lesquelles les utilisateurs novices de Rust seront souvent confus et je pense que cela n'ajoute pas beaucoup de clarté, même aux vétérans de Rust, pour en valoir la peine.

@novacrazy le problème avec cet argument est que toute macro await! _ serait magique, elle effectue une opération qui n'est pas possible dans le code écrit par l'utilisateur

@ Nemo157 Je suis d'accord qu'une macro await! serait magique, mais je dirais que ce n'est pas un problème. Il y a déjà plusieurs macros de ce type dans std , par exemple compile_error! et je n'ai vu personne s'en plaindre. Je pense qu'il est normal d'utiliser une macro en ne comprenant que ce qu'elle fait, pas comment elle le fait.

Je suis d'accord avec les commentateurs précédents que postfix serait le plus ergonomique, mais je préférerais commencer par prefix-macro await!(expr) et potentiellement passer à postfix-macro une fois que c'est une chose plutôt que d'avoir expr.await (champ intégré au compilateur magique) ou expr.await() (méthode intégrée au compilateur magique). Les deux introduiraient une syntaxe complètement nouvelle uniquement pour cette fonctionnalité, et l'OMI qui rendrait le langage incohérent.

@EyeOfPython Voulez- vous ajouter future(await) à vos listes et à votre table? Tous les points positifs de votre évaluation de future.await() semblent se transférer sans la faiblesse

Puisque certains ont soutenu que malgré la coloration syntaxique, foo.await ressemble trop à un accès à un champ, nous pourrions changer le jeton . en # et écrire à la place foo#await . Par exemple:

let foo = alpha()#await?
    .beta#await
    .some_other_stuff()#await?
    .even_more_stuff()#await
    .stuff_and_stuff();

Pour illustrer comment GitHub rendrait cela avec la coloration syntaxique, remplaçons await par match puisqu'ils sont de longueur égale:

let foo = alpha()#match?
    .beta#match
    .some_other_stuff()#match?
    .even_more_stuff()#match
    .stuff_and_stuff();

Cela semble à la fois clair et ergonomique.

La justification de # plutôt qu'un autre jeton n'est pas spécifique, mais le jeton est assez visible, ce qui aide.

Donc, autre concept: si le futur était référence :

async fn log_service(&self) -> T {
   let service = self.myService.foo(); // Only construction
   *self.logger.log("beginning service call");
   let output = *service.exec(); // Actually wait for its result
   *self.logger.log("foo executed with result {}.", output);
   output
}

async fn try_log(message: String) -> Result<usize, Error> {
    let logger = *acquire_lock();
    // Very terse, construct the future, wait on it, branch on its result.
    let length = (*logger.log_into(message))?;
    *logger.timestamp();
    Ok(length)
}

async fn await_chain() -> Result<usize, Error> {
    *(*partial_computation()).unwrap_or_else(or_recover);
}

(*(*client.get("https://my_api").send())?.json())?

let output = *future;

Ce serait vraiment moche et incohérent. Laissez au moins lever l'ambiguïté de cette syntaxe:

async fn log_service(&self) -> T {
   let service = self.myService.foo(); // Only construction
   $self.logger.log("beginning service call");
   let output = $service.exec(); // Actually wait for its result
   $self.logger.log("foo executed with result {}.", output);
   output
}

async fn try_log(message: String) -> Result<usize, Error> {
    let logger = $acquire_lock();
    // Very terse, construct the future, wait on it, branch on its result.
    let length = ($logger.log_into(message))?;
    $logger.timestamp();
    Ok(length)
}

async fn await_chain() -> Result<usize, Error> {
    $($partial_computation()).unwrap_or_else(or_recover);
}

($($client.get("https://my_api").send())?.json())?

let output = $future;

Mieux, mais toujours moche (et pire encore, cela rend la coloration syntaxique de github). Cependant, pour gérer cela, introduisons la possibilité de retarder l'opérateur de préfixe :

async fn log_service(&self) -> T {
   let service = self.myService.foo(); // Only construction
   self.logger.$log("beginning service call");
   let output = service.$exec(); // Actually wait for its result
   self.logger.$log("foo executed with result {}.", output);
   output
}

async fn try_log(message: String) -> Result<usize, Error> {
    let logger = $acquire_lock();
    // Very terse, construct the future, wait on it, branch on its result.
    let length = logger.$log_into(message)?;
    logger.$timestamp();
    Ok(length)
}

async fn await_chain() -> Result<usize, Error> {
    ($partial_computation()).$unwrap_or_else(or_recover);
}

client.get("https://my_api").$send()?.$json()?

let output = $future;

C'est exactement ce que je veux! Non seulement pour await ( $ ) mais aussi pour deref ( * ) et negate ( ! ).

Quelques mises en garde dans cette syntaxe:

1. Priorité des opérateurs: pour moi c'est évident mais pour les autres utilisateurs?
2. Interopérabilité des macros: le symbole $ causerait-il des problèmes ici?
3. Incohérence de l'expression: l'opérateur de préfixe principal s'applique à l'expression entière tandis que l'opérateur de préfixe retardé s'applique uniquement à l'expression délimitée . ( await_chain fn le démontrent), est-ce déroutant?
4. Analyse et implémentation: cette syntaxe est-elle valable du tout?

@Centril
IMO # est trop proche de la syntaxe littérale brute r#"A String with "quotes""#

IMO # est trop proche de la syntaxe littérale brute r#"A String with "quotes""#

Il semble assez clair d'après le contexte quelle est la différence dans ce cas.

@Centril
C'est le cas, mais la syntaxe est également vraiment étrangère au style que Rust utilise à mon humble avis. Il ne ressemble à aucune syntaxe existante avec une fonction similaire.

@Laaas Pas plus que ? lors de son introduction. Je serais ravi de choisir .await ; mais d'autres semblent mécontents de cela, alors j'essaie de trouver autre chose qui fonctionne (c'est-à-dire qui est clair, ergonomique, suffisamment facile à taper, chaînable, a une bonne priorité) et foo#await semble satisfaire tout cela.

? a cependant un tas d'autres bons points, tandis que #await semble plutôt arbitraire. Dans tous les cas, si vous voulez quelque chose comme .await , pourquoi pas .await! ?

@Centril C'était la raison principale derrière future(await) , pour éviter l'accès au champ sans avoir à ajouter d'opérateurs supplémentaires ou de syntaxe étrangère.

tandis que #await semble plutôt arbitraire.

# est arbitraire, oui - est-ce une réussite ou une rupture? Lorsqu'une nouvelle syntaxe est inventée à un moment donné, elle doit être arbitraire parce que quelqu'un a pensé qu'elle avait l'air bien ou avait du sens.

pourquoi pas .await! ?

C'est tout aussi arbitraire, mais je n'y suis pas opposé.

@Centril C'était la raison principale derrière future(await) , pour éviter l'accès au champ sans avoir à ajouter d'opérateurs supplémentaires ou de syntaxe étrangère.

Au lieu de cela, il ressemble à une application de fonction où vous passez await à future ; cela me semble plus déroutant que "l'accès au champ".

Au lieu de cela, il ressemble à une application de fonction où vous passez en attente vers le futur; cela me semble plus déroutant que "l'accès au champ".

Pour moi, cela faisait partie de la concision. Await est dans de nombreux aspects comme un appel de fonction (l'appelé s'exécute entre vous et votre résultat), et le passage d'un mot-clé à cette fonction a clairement indiqué qu'il s'agissait d'un autre type d'appel. Mais je vois comment il pourrait être déroutant que le mot-clé soit similaire à tout autre argument. (Moins la coloration syntaxique et les messages d'erreur du compilateur essayant de renforcer ce message. Futures ne peut pas être appelé autrement que d'être attendu et vice versa).

@Centril

Être arbitraire n'est pas une chose négative , mais avoir une ressemblance avec une syntaxe existante est une chose positive. .await! n'est pas aussi arbitraire, car ce n'est pas une syntaxe entièrement nouvelle; après tout, c'est juste une macro de post-correction nommée await .

Pour clarifier / ajouter au point sur la nouvelle syntaxe spécifiquement pour await , ce que je veux dire par là est l'introduction d'une nouvelle syntaxe qui diffère de la syntaxe existante. Il y a beaucoup de mots-clés préfixes, dont certains ont été ajoutés après Rust 1.0 (par exemple union ), mais AFAIK pas un seul mot-clé suffixe (peu importe s'il est séparé par un espace, un point ou autre chose) . Je ne peux pas non plus penser à une autre langue qui a des mots-clés postfixes.

À mon humble avis, la seule syntaxe postfix qui n'augmente pas considérablement l'étrangeté de Rust est la macro postfix, car elle reflète les appels de méthode mais peut clairement être identifiée comme une macro par quiconque a déjà vu une macro Rust.

J'ai aussi aimé la macro standard await!() . C'est juste clair et simple.
Je préfère qu'un accès de type champ (ou tout autre suffixe) coexiste en tant que awaited .

• Await sent que vous attendez ce qui vient ensuite / juste. Attendu, à ce qui est venu avant / gauche.
• Cohérent à la méthode cloned() sur les itérateurs.

Et j'ai aussi aimé le @? comme du sucre semblable à ? .
C'est personnel, mais je préfère en fait la combinaison &? , car @ tendance à être trop grand et à dépasser la ligne, ce qui est très distrayant. & est également grand (bon) mais ne sous-estime pas (également bon). Malheureusement, & déjà un sens, bien qu'il soit toujours suivi d'un ? .. Je suppose?

Par exemple.

Lorem@?
  .ipsum@?
  .dolor()@?
  .sit()@?
  .amet@?
Lorem@?.ipsum@?.dolor()@?.sit()@?.amet@?

Lorem&?
  .ipsum&?
  .dolor()&?
  .sit()&?
  .amet&?
Lorem&?.ipsum&?.dolor()&?.sit()&?.amet&?

Pour moi, le @ ressemble à un personnage gonflé, distrait le flux de lecture. D'un autre côté, &? est agréable, ne distrait pas (ma) lecture et a un bel espace supérieur entre le & et le ? .

Personnellement, je pense qu'une simple macro await! devrait être utilisée. Si les macros post-correctives entrent dans le langage, alors la macro pourrait simplement être développée, non?

@Laaas Autant que j'aimerais qu'il y en ait, il n'y a pas encore de macros postfix dans Rust, ce sont donc une nouvelle syntaxe. Notez également que foo.await!.bar et foo.await!().bar ne sont pas la même syntaxe de surface. Dans ce dernier cas, il y aurait un suffixe réel et une macro intégrée (ce qui implique de renoncer à await comme mot clé).

@jplatte

Il y a beaucoup de mots-clés préfixes, dont certains ont été ajoutés après Rust 1.0 (par exemple union ),

union n'est pas un opérateur d'expression unaire, il n'est donc pas pertinent dans cette comparaison. Il y a exactement 3 opérateurs de préfixes unaires stables dans Rust ( return , break et continue ) et tous sont tapés à ! .

Hmm ... Avec @ ma proposition précédente est légèrement meilleure:

client.get("https://my_api").@send()?.@json()?

let output = @future;

let foo = (@alpha())?
    .<strong i="8">@beta</strong>
    .@some_other_stuff()?
    .@even_more_stuff()
    .stuff_and_stuff();

@Centril C'est mon point, puisque nous n'avons pas encore de macros de post-correction, cela devrait simplement être await!() . Aussi je voulais dire .await!() FYI. Je ne pense pas que await doive être un mot-clé, bien que vous puissiez le réserver si vous le trouvez problématique.

union n'est pas un opérateur d'expression unaire, il n'est donc pas pertinent dans cette comparaison. Il y a exactement 3 opérateurs de préfixes unaires stables dans Rust ( return , break et continue ) et tous sont tapés à ! .

Cela signifie toujours que la variante préfixe-mot-clé s'inscrit dans le groupe des opérateurs d'expression unaires, même si elle est typée différemment. La variante du mot-clé postfix est une divergence beaucoup plus grande par rapport à la syntaxe existante, trop grande par rapport à l'importance de await dans le langage à mon avis.

Concernant la macro de préfixe et la possibilité de passer à la post-correction: await doit rester un mot-clé pour que cela fonctionne. La macro serait alors un élément de langage spécial où il est permis d'utiliser un mot-clé comme nom sans r# supplémentaire, et r#await!() pourrait mais ne devrait probablement pas invoquer la même macro. À part cela, cela semble être la solution la plus pragmatique pour le rendre disponible.

Autrement dit, conservez await comme mot-clé, mais résolvez await! en une macro lang-item.

@HeroicKatora pourquoi doit-il rester un mot-clé pour que cela fonctionne?

@Laaas Parce que si nous voulons garder la possibilité de transition ouverte, nous devons rester ouverts pour la future syntaxe post-correction qui l'utilise comme mot-clé. Par conséquent, nous devons conserver la réservation de mot-clé afin de ne pas avoir besoin d'une pause d'édition pour la transition.

@Centril

Notez également que foo.await! .Bar et foo.await! (). Bar ne sont pas la même syntaxe de surface. Dans ce dernier cas, il y aurait un suffixe réel et une macro intégrée (ce qui implique de renoncer à wait comme mot clé).

Cela ne pourrait-il pas être résolu en faisant du mot-clé await combiné avec ! résoudre une macro interne (qui ne peut pas être définie par des moyens normaux)? Ensuite, il reste un mot clé mais se résout en une macro dans une syntaxe de macro autrement.

@HeroicKatora Pourquoi await in x.await!() serait-il un mot-clé réservé?

Ce ne serait pas le cas, mais si nous ne résolvons pas la post-correction, ce n'est pas nécessairement la solution à laquelle nous arriverons dans les discussions ultérieures. Si c'était la meilleure possibilité unique convenue, alors nous devrions adopter cette syntaxe de post-correction exacte en premier lieu.

C'est une autre fois que nous rencontrons quelque chose qui fonctionne beaucoup mieux en tant qu'opérateur postfix. Le grand exemple de ceci est try! que nous avons finalement donné son propre symbole ? . Cependant je pense que ce n'est pas la dernière fois où un opérateur postfix est plus optimal et on ne peut pas donner à tout son caractère spécial. Donc je pense que nous ne devrions au moins pas commencer par @ . Ce serait beaucoup mieux si nous avions un moyen de faire ce genre de choses. C'est pourquoi je supporte le style de macro postfix .await!() .

let x = foo().try!();
let y = bar().await!();

Mais pour que cela ait un sens, des macros postfixes elles-mêmes devraient être introduites. Par conséquent, je pense qu'il serait préférable de commencer avec une syntaxe de macro await!(foo) normale. Nous pourrions plus tard étendre cela à foo.await!() ou même foo@ si nous pensons vraiment que c'est assez important pour justifier son propre symbole.
Le fait que cette macro ait besoin d'un peu de magie n'est pas nouveau pour std et pour moi ce n'est pas un gros problème.
Comme le dit @jplatte :

@ Nemo157 Je suis d'accord qu'une macro await! serait magique, mais je dirais que ce n'est pas un problème. Il y a déjà plusieurs macros de ce type dans std , par exemple compile_error! et je n'ai vu personne s'en plaindre. Je pense qu'il est normal d'utiliser une macro en ne comprenant que ce qu'elle fait, pas comment elle le fait.

Un problème récurrent que je vois abordé ici concerne le chaînage et l'utilisation
attendre dans les expressions d'enchaînement. Peut-être qu'il pourrait y avoir une autre solution?

Si nous ne voulons pas utiliser await pour le chaînage et n'utiliser que wait pour
affectations, nous pourrions avoir quelque chose comme simplement remplacer let par await:
await foo = future

Ensuite, pour le chaînage, nous pourrions imaginer une sorte d'opération comme await res = fut1 -> fut2 ou await res = fut1 >>= fut2 .

Le seul cas manquant est l'attente et le retour du résultat, un raccourci
pour await res = fut; res .
Cela pourrait être facilement fait avec un simple await fut

Je ne pense pas avoir vu une autre proposition comme celle-ci (du moins pour le
chaînage), donc en laissant tomber ça ici car je pense que ce serait bien d'utiliser.

@HeroicKatora J'ai ajouté fut(await) à la liste et l'ai classée selon mon opinion.

Si quelqu'un a l'impression que mon score n'est pas correct, dites-le moi!

Au niveau de la syntaxe, je pense que .await!() est propre et permet le chaînage sans ajouter de bizarreries à la syntaxe.

Cependant, si jamais nous obtenons de "vraies" macros postfixes, ce sera un peu bizarre, car vraisemblablement .r#await!() pourrait être masqué, alors que .await!() ne le pourrait pas.

Je suis assez fortement contre l'option "mot-clé postfix" (séparé par un espace comme: foo() await?.bar() await? ), car je trouve que le await est joint à la partie suivante de l'expression, et non la partie sur laquelle il opère. Je préférerais à peu près n'importe quel symbole autre que les espaces ici, et je préférerais même la syntaxe de préfixe à celle-ci malgré ses inconvénients avec les longues chaînes.

Je pense que la "préséance évidente" (avec le await? sucre) est clairement la meilleure option de préfixe, car les délimiteurs obligatoires sont une douleur pour le cas très courant d'attendre une seule instruction, et "précédence utile" n'est pas du tout intuitif, et donc déroutant.

Au niveau de la syntaxe, je pense que .await!() est propre et permet le chaînage sans ajouter de bizarreries à la syntaxe.

Cependant, si jamais nous obtenons de "vraies" macros postfixes, ce sera un peu bizarre, car vraisemblablement .r#await!() pourrait être masqué, alors que .await!() ne le pourrait pas.

Si nous obtenons des macros postfixes et que nous utilisons .await!() nous pouvons annuler la réservation de await comme mot clé et en faire une macro suffixe. L'implémentation de cette macro exigerait encore un peu de magie de courage mais ce serait une vraie macro tout comme compiler_error! est aujourd'hui.

@EyeOfPython Pourriez-vous peut-être expliquer en détail quels changements vous envisagez dans forward-compatibility ? Je ne sais pas de quelle manière fut@await serait supérieur à fut.await!() et await { future } inférieur à await!(future) . La colonne verbosity semble également un peu étrange, certaines expressions sont courtes mais ont une cote inférieure, considère-t-elle les déclarations enchaînées, etc. Tout le reste semble équilibré et ressemble à l'évaluation approfondie la mieux condensée à ce jour.

Après avoir lu cette discussion, il semble que beaucoup de gens souhaitent ajouter une macro await!() normale et découvrir la version postfix plus tard. Cela suppose que nous voulons réellement une version postfixe, ce que je considérerai comme vrai pour le reste de ce commentaire.

Je voudrais donc simplement sonder l'opinion de tout le monde ici: Devrions-nous tous être d'accord sur la syntaxe await!(future) POUR MAINTENANT? Les avantages sont qu'il n'y a aucune ambiguïté d'analyse avec cette syntaxe, et c'est aussi une macro, donc pas de changement de la syntaxe du langage pour prendre en charge ce changement. Les inconvénients sont que cela aura l'air moche pour le chaînage, mais cela n'a pas d'importance car cette syntaxe peut être facilement remplacée par une version postfix automatiquement.

Une fois que nous avons réglé cela et que nous l'avons implémenté dans le langage, nous pouvons continuer la discussion sur la syntaxe d'attente de postfix avec des expériences, des idées et éventuellement d'autres fonctionnalités du compilateur, espérons-le plus matures.

@HeroicKatora Je l'ai noté plus haut car il pourrait libérer await pour être utilisé naturellement comme identifiant ordinaire et cela permettrait d'ajouter d'autres opérateurs de suffixe, alors que je pense que fut.await!() serait mieux si await été réservé. Cependant, je ne suis pas sûr que cela soit raisonnable, il semble également tout à fait valide que fut.await!() pourrait être plus élevé.

Pour await { future } vs await!(future) , ce dernier garde l'option ouverte pour changer à presque toutes les autres options, alors que le premier n'autorise vraiment que l'une des variantes await future ( comme indiqué dans l'entrée de blog @withoutboats ). Donc je pense que ça devrait certainement être fwd(await { future }) < fwd(await!(future)) .

En ce qui concerne la verbosité, vous avez raison, après avoir divisé les cas en sous-groupes, je n'ai pas réévalué la verbosité, qui devrait être la plus objective de toutes.

Je l'éditerai pour prendre en compte vos commentaires, merci!

Stabiliser await!(future) est à peu près la pire option possible que je puisse imaginer:

1. Cela signifie que nous devons annuler la réservation de await ce qui signifie en outre que la conception future du langage devient plus difficile.
2. Il prend sciemment le même chemin qu'avec try!(result) que nous avons déconseillé (et qui nécessite d'écrire r#try!(result) dans Rust 2018).
   
   
   
   • Si nous savons que await!(future) est une mauvaise syntaxe que nous voulons finalement déconseiller, cela crée volontairement une dette technique.
   
   
   • De plus, try!(..) est défini dans Rust alors que await!(future) ne peut pas l'être et serait plutôt la magie du compilateur.
   
   
   • La dépréciation de try!(..) n'a pas été facile et a eu un impact social. Revoir cette épreuve ne semble pas attrayant.
   
   
3. Cela utiliserait une macro syntaxe pour une partie centrale et importante du langage; cela ne semble clairement pas de première classe.
4. await!(future) est bruyant ; contrairement à await future vous devez écrire !( ... ) .
5. Les API Rust, et en particulier la bibliothèque standard, sont centrées sur la syntaxe d'appel de méthode. Par exemple, il est courant de chaîner des méthodes lorsqu'il s'agit de Iterator s. Similaire à await { future } et await future , la syntaxe await!(future) rendra le chaînage de méthode difficile et induira des liaisons temporaires let . C'est mauvais pour l'ergonomie et à mon avis pour la lisibilité.

@Centril J'aimerais être d'accord mais il y a quelques questions ouvertes. Êtes-vous sûr (e) de 1. ? Si nous la rendons «magique», ne pourrions-nous pas la rendre encore plus magique en permettant à cela de faire référence à une macro sans la laisser tomber comme mot-clé?

J'ai rejoint Rust trop tard pour évaluer la perspective sociale de 2. . Répéter une erreur ne semble pas attrayant, mais comme certains codes n'ont toujours pas été convertis à partir de try! il devrait être évident que c'était une solution. Cela soulève la question de savoir si nous avons l'intention d'avoir async/await comme incitation à migrer vers l'édition 2018 ou plutôt d'être patient et de ne pas répéter cela.

Deux autres fonctionnalités centrales (à mon humble avis) comme 3. : vec![] et format! / println! . Le premier parce qu'il n'y a pas d'afaik de construction en boîte stable, le second en raison de la construction de la chaîne de format et de l'absence d'expressions typées de manière dépendante. Je pense que ces comparaisons mettent aussi en partie 4. dans une autre perspective.

Je m'oppose à toute syntaxe qui ne se lit pas un peu comme l'anglais. IE, "wait x" lit quelque chose comme l'anglais. "x # !! @! &" ne le fait pas. "x.await" se lit de manière alléchante comme l'anglais, mais ce ne sera pas le cas lorsque x est une ligne non triviale, comme un appel de fonction membre avec des noms longs, ou un tas de méthodes d'itération chaînées, etc.

Plus précisément, je supporte le "mot-clé x", où le mot-clé est probablement await . Je viens d'utiliser à la fois les coroutines C ++ TS et les coroutines c # unit, qui utilisent toutes deux une syntaxe très similaire à celle-ci. Et après des années à les utiliser dans le code de production, je pense qu'il est absolument essentiel de savoir où se trouvent vos limites d'élasticité . Lorsque vous parcourez la ligne de retrait de votre fonction, vous pouvez sélectionner chaque co_await / yield return dans une fonction de 200 lignes en quelques secondes, sans charge cognitive.

Il n'en est pas de même pour l'opérateur point avec await après, ou pour une autre syntaxe postfixe "pile de symboles".

Je crois que await est une opération fondamentale de flux de contrôle. Il devrait avoir le même niveau de respect que 'if , while , match et return . Imaginez si l'un d'entre eux était des opérateurs postfixes - lire du code Rust serait un cauchemar. Comme avec mon argument pour await, vous pouvez parcourir la ligne de retrait de n'importe quelle fonction Rust et sélectionner immédiatement tout le flux de contrôle. Il y a des exceptions, mais ce sont des exceptions, et ce n'est pas quelque chose que nous devrions rechercher.

Je suis d'accord avec @ejmahler. Nous ne devons pas oublier l'autre aspect du développement - la révision du code. Le fichier avec le code source est beaucoup plus souvent lu puis écrit, donc je pense qu'il devrait être plus facile à lire et à comprendre qu'à écrire. Trouver les points cédants est vraiment important lors de la révision du code. Et personnellement, je voterais pour Useful precedence .
Je crois que ceci:

...
let response = await client.get("https://my_api").send()?;
let body: MyResponse = await response.into_json()?;

est plus facile à comprendre plutôt que ceci:

...
let body: MyResponse = client.get("https://my_api").send().await?.into_json().await?;

@HeroicKatora

@Centril J'aimerais être d'accord mais il y a quelques questions ouvertes. Êtes-vous sûr (e) de 1. ? Si nous la rendons «magique», ne pourrions-nous pas la rendre encore plus magique en permettant à cela de faire référence à une macro sans la laisser tomber comme mot-clé?

Techniquement? Peut-être. Cependant, il devrait y avoir une forte justification pour des cas particuliers et dans ce cas, avoir de la magie sur la magie ne semble pas justifié.

Cela soulève la question de savoir si nous avons l'intention d'avoir async/await comme incitation à migrer vers l'édition 2018 ou plutôt d'être patient et de ne pas répéter cela.

Je ne sais pas si nous avons déjà dit que nous voulions un nouveau système de modules, async / await et try { .. } pour être des incitations; mais quelle que soit notre intention, ils le sont, et je pense que c'est une bonne chose. Nous voulons que les gens commencent à utiliser de nouvelles fonctionnalités de langage pour écrire des bibliothèques meilleures et plus idiomatiques.

Deux autres fonctionnalités centrales (à mon humble avis) comme 3. : vec![] et format! / println! . Le premier beaucoup parce qu'il n'y a pas d'afaik de construction en boîte stable,

Le premier existe, et est écrit vec![1, 2, 3, ..] , pour imiter des expressions littérales de tableau, par exemple [1, 2, 3, ..] .

@ejmahler

"x.await" se lit de manière alléchante comme l'anglais, mais ce ne sera pas le cas lorsque x est une ligne non triviale, comme un appel de fonction membre avec des noms longs, ou un tas de méthodes d'itération chaînées, etc.

Quel est le problème avec un tas de méthodes d'itération chaînées? C'est Rust distinctement idiomatique.
L'outil rustfmt formatera également les chaînes de méthodes sur différentes lignes afin que vous obteniez (à nouveau en utilisant match pour afficher la coloration syntaxique):

let foo = alpha().match?  // or `alpha() match?`, `alpha()#match?`, `alpha().match!()?`
    .beta
    .some_other_stuff().match?
    .even_more_stuff().match
    .stuff_and_stuff();

Si vous lisez .await comme "alors attendez", cela se lit parfaitement, du moins pour moi.

Et après des années à les utiliser dans le code de production, je pense qu'il est absolument essentiel de savoir où se trouvent vos limites d'élasticité .

Je ne vois pas comment le suffixe await annule cela, en particulier dans le formatage rustfmt ci-dessus. De plus, vous pouvez écrire:

let foo = alpha().match?;
let bar = foo.beta.some_other_stuff().match?;
let baz = bar..even_more_stuff().match;
let quux = baz.stuff_and_stuff();

si vous en avez envie.

dans une fonction de 200 lignes en quelques secondes, sans charge cognitive.

Sans trop en savoir sur la fonction particulière, il me semble que 200 LOC viole probablement le principe de responsabilité unique et en fait trop. La solution est de lui faire moins et de le diviser. En fait, je pense que c'est la chose la plus importante pour la maintenabilité et la lisibilité.

Je crois que await est une opération fondamentale de flux de contrôle.

Il en va de même pour ? . En fait, await et ? sont tous deux des opérations de flux de contrôle efficaces qui disent "extraire la valeur hors de son contexte". En d'autres termes, dans le contexte local, vous pouvez imaginer ces opérateurs ayant le type await : impl Future<Output = T> -> T et ? : impl Try<Ok = T> -> T .

Il y a des exceptions, mais ce sont des exceptions, et ce n'est pas quelque chose que nous devrions rechercher.

Et l'exception ici est ? ?

@andreytkachenko

Je suis d'accord avec @ejmahler. Nous ne devons pas oublier l'autre aspect du développement - la révision du code. Le fichier avec le code source est beaucoup plus souvent lu puis écrit, donc je pense qu'il devrait être plus facile à lire et à comprendre qu'à écrire.

Le désaccord porte sur ce qui serait le mieux pour la lisibilité et l'ergonomie.

est plus facile à comprendre plutôt que ceci:

...
let body: MyResponse = client.get("https://my_api").send().await?.into_json().await?;

Ce n'est pas ainsi qu'il serait formaté; l'exécuter via rustfmt vous permet d'obtenir:

let body: MyResponse = client
    .get("https://my_api")
    .send()
    .match?
    .into_json()
    .match?;

@ejmahler @andreytkachenko Je suis d'accord avec @Centril ici, le plus grand changement (certains diront peut-être une amélioration, je ne le ferais pas) que vous gagnez de la syntaxe du préfixe est que les utilisateurs sont incités à diviser leurs déclarations sur plusieurs lignes car tout le reste est illisible. Ce n'est pas Rust-y et les règles de formatage habituelles compensent cela dans la syntaxe post-correction. Je considère également que le point de rendement est plus obscur dans la syntaxe du préfixe car await n'est pas réellement placé au point de code où vous cédez, mais plutôt opposé à celui-ci.

Si vous allez dans cette direction, expérimentons pour le préciser, plutôt avec await en remplacement de let dans l'esprit de l' idée de

await? response = client.get("https://my_api").send();
await? body: MyResponse = response.into_json();

Mais pour aucun de ceux-ci, je vois suffisamment d'avantages pour expliquer leur perte de composabilité et leurs complications dans la grammaire.

Hm ... est-il souhaitable d'avoir à la fois un préfixe et un suffixe en attente? Ou juste la forme de suffixe?

Le chaînage des appels de méthode est idiomatique, en particulier quand on parle de
itérateurs et, dans une bien moindre mesure, des options, mais à part cela, la rouille est
un langage impératif d'abord et un langage fonctionnel ensuite.

Je ne dis pas qu'un suffixe est littéralement incompréhensible, je fais un
argument de charge cognitive qui cache une opération de flux de contrôle de niveau supérieur,
ayant la même importance que le `` retour '', augmente la charge cognitive lorsque
comparé au fait de le mettre aussi près du début de la ligne - et je suis
en faisant cet argument basé sur des années d'expérience de production.

Le sam 19 janvier 2019 à 11 h 59, Mazdak Farrokhzad [email protected]
a écrit:

@HeroicKatora https://github.com/HeroicKatora

@Centril https://github.com/Centril J'aimerais être d'accord mais il y a
quelques questions ouvertes. Etes-vous sûr de 1.? Si nous le faisons, la `` magie '' pourrait
nous ne le rendons pas encore plus magique en permettant à cela de faire référence à une macro sans
le laisser tomber comme mot clé?

Techniquement? Peut-être. Cependant, il devrait y avoir une forte justification pour
cas particuliers et dans ce cas avoir de la magie sur la magie ne semble pas
justifié.

Cela soulève la question de savoir si nous avons l'intention d'avoir async / wait comme
une incitation à migrer vers l'édition 2018 ou plutôt être patient et non
répétez ceci.

Je ne sais pas si nous avons déjà dit que nous voulions un nouveau système de modules, async /
attendez, et essayez {..} d'être des incitations; mais quelle que soit notre intention
ils le sont, et je pense que c'est une bonne chose. Nous voulons que les gens finissent par
commencer à utiliser de nouvelles fonctionnalités de langage pour écrire mieux et plus idiomatique
bibliothèques.

Deux autres fonctionnalités centrales (à mon humble avis) ressemblant beaucoup à 3.: vec! [] Et format! /
println !. Le premier beaucoup car il n'y a pas d'écurie en boîte
construction afaik,

Le premier existe, et s'écrit vec! [1, 2, 3, ..], pour imiter un tableau
expressions littérales, par exemple [1, 2, 3, ..].

@ejmahler https://github.com/ejmahler

"x.await" se lit comme l'anglais, mais ce ne sera pas le cas lorsque x est un
ligne non triviale, comme un appel de fonction membre avec des noms longs, ou un tas
des méthodes d'itération chaînée, etc.

Quel est le problème avec un tas de méthodes d'itération chaînées? C'est distinctement
rouille idiomatique.
L'outil rustfmt formatera également les chaînes de méthodes sur différentes lignes afin que vous
get (à nouveau en utilisant match pour afficher la coloration syntaxique):

laissez toto = alpha (). match? // ou alpha() match? , alpha()#match? , alpha().match!()?
.bêta
.some_other_stuff (). match?
.even_more_stuff (). match
.stuff_and_stuff ();

Si vous lisez .await comme "alors attendez", il se lit parfaitement, du moins pour moi.

Et après des années à les utiliser dans le code de production, je pense que savoiroù se trouvent vos limites de rendement, en un coup d'œil, est absolument critique .

Je ne vois pas comment postfix wait annule cela, en particulier dans le rustfmt
mise en forme ci-dessus. De plus, vous pouvez écrire:

let foo = alpha (). match?; let bar = foo.beta.some_other_stuff (). match?; let baz = bar..even_more_stuff (). match; let quux = baz.stuff_and_stuff ();

si vous en avez envie.

dans une fonction de 200 lignes en quelques secondes, sans charge cognitive.

Sans trop en savoir sur la fonction particulière, il me semble
que 200 LOC viole probablement le principe de responsabilité unique et
trop. La solution est de lui faire moins et de le diviser. En fait, je
pense que c'est la chose la plus importante pour la maintenabilité et la lisibilité.

Je crois qu'attendre est une opération fondamentale de contrôle de flux.

Alors?. En fait, attendez et? sont tous deux des opérations de flux de contrôle efficaces
qui disent «extraire la valeur hors de son contexte». En d'autres termes, dans le local
context, vous pouvez imaginer ces opérateurs ayant le type await: impl
Avenir

-> T et? : impl Essayez-> T.

Il y a des exceptions, mais ce sont des exceptions, et pas quelque chose que nous devrions
lutter pour.

Et l'exception ici est? ?

@andreytkachenko https://github.com/andreytkachenko

Je suis d'accord avec @ejmahler https://github.com/ejmahler . Nous ne devrions pas
oubliez l'autre côté du développement - révision du code. Le fichier avec le code source est
beaucoup plus souvent lu qu'écrit, donc je pense qu'il devrait être plus facile de
lire et comprendre puis écrire.

Le désaccord porte sur ce qui serait le mieux pour la lisibilité et
ergonomie.

est plus facile à comprendre plutôt que ceci:

... let body: MyResponse = client.get ("https: // mon_api") .send (). await? .into_json (). await ?;

Ce n'est pas ainsi qu'il serait formaté; le formatage idiomatique rustfmt
est:

laissez le corps: MyResponse = client
.get ("https: // mon_api")
.envoyer()
.rencontre?
.into_json ()
.rencontre?;

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/rust-lang/rust/issues/57640#issuecomment-455810497 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/ABGmeocFJpPKaypvQHo9LpAniGOUFrmzks5vE3kXgaJpZM4aBlba
.

@ejmahler Nous ne sommes pas d'accord re. "cache"; les mêmes arguments ont été .

L'opérateur ? est très court, et a été critiqué dans le passé pour "cacher" un retour. La plupart du temps, le code est lu et non écrit. Le renommer en ?! le rendra deux fois plus long et donc plus difficile à ignorer.

Néanmoins, nous avons finalement stabilisé ? et depuis, je pense que la prophétie ne s'est pas concrétisée.
Pour moi, le suffixe await suit l'ordre de lecture naturel (au moins pour les locuteurs de langue de gauche à droite). En particulier, il suit l'ordre des flux de données.

Sans parler de la coloration syntaxique: tout ce qui est lié à l'attente peut être mis en évidence avec une couleur vive, afin de pouvoir être trouvé en un coup d'œil. Donc, même si nous avions un symbole au lieu du mot await réel, il serait toujours très lisible et trouvable dans le code syntaxique mis en évidence. Cela dit, je préfère toujours l'utilisation du mot await juste pour des raisons de grepping - il est plus facile de grep le code pour tout ce qui est attendu si nous n'utilisons que le mot await au lieu d'un symbole comme @ ou #, dont la signification dépend de la grammaire.

vous tous, ce n'est pas sorcier

let body: MyResponse = client.get("https://my_api").send()...?.into_json()...?;

postfix ... est extrêmement lisible, difficile à rater en un coup d'œil et super intuitif puisque vous le lisez naturellement comme le code qui se termine en attendant que le résultat du futur soit disponible. aucune manigance de précédence / macro n'est nécessaire et aucun bruit de ligne supplémentaire de sigils inconnus, puisque tout le monde a déjà vu des ellipses.

(excuses à @solson)

@ ben0x539 Cela signifie-t-il que je peux accéder à un membre de mon résultat comme future()....start ? Ou attendre un résultat de plage comme si range()..... ? Et comment vous voulez dire exactement no precedence/macro shenanigans necessary and puisque les points .. suspension actuels

Oui le ? L'opérateur existe. J'ai déjà reconnu qu'il y avait
exceptions. Mais c'est une exception. La grande majorité du flux de contrôle dans tout
Le programme Rust se produit via des mots-clés préfixes.

Le sam 19 janvier 2019 à 13 h 51 Benjamin Herr [email protected]
a écrit:

vous tous, ce n'est pas sorcier

let body: MaResponse = client.get ("https: // mon_api") .send () ...?. into_json () ...?;

postfix ... est extrêmement lisible, difficile à manquer en un coup d'œil et super
intuitif puisque vous le lisez naturellement comme le code qui suit
en attendant que le résultat du futur devienne disponible. non
précédence / macro manigances nécessaires et aucun bruit de ligne supplémentaire de
des signes inconnus, puisque tout le monde a déjà vu des ellipses.

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/rust-lang/rust/issues/57640#issuecomment-455818177 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/ABGmen354fhk7snYsANTfp5oOuDb4OLYks5vE5NSgaJpZM4aBlba
.

@HeroicKatora Cela a l'air un peu artificiel mais oui, bien sûr. Je voulais dire que puisque c'est une opération postfix, comme les autres solutions postfix suggérées, cela évite le besoin d'une priorité contre-intuitive pour await x? , et ce n'est pas une macro.

@ejmahler

Oui le ? L'opérateur existe. J'ai déjà reconnu qu'il y avait des exceptions. Mais c'est une exception.

Il existe deux formes d'expression qui correspondent à keyword expr , à savoir return expr et break expr . Le premier est plus courant que le second. La forme continue 'label ne compte pas vraiment puisque, bien qu'elle soit une expression, elle n'est pas de la forme keyword expr . Vous avez donc maintenant 2 formes d'expression unaire de mot-clé avec préfixe entier et 1 forme d'expression unaire avec suffixe. Avant même de prendre en compte que ? et await sont plus similaires que await et return , j'appellerais à peine return/break expr une règle pour que ? soit une exception contre.

La grande majorité du flux de contrôle dans tout programme Rust se produit via des mots-clés de préfixe.

Comme mentionné ci-dessus, break expr n'est pas si courant ( break; est plus typique et return; sont plus typiques et ce ne sont pas des formes d'expression unaires). Ce qui reste est tôt return expr; s et il ne me semble pas du tout clair que cela soit beaucoup plus courant que match , ? , juste imbriqués if let boucles else s et for . Une fois que try { .. } stabilise, je m'attendrais à ce que ? soit utilisé encore plus.

@ ben0x539 Je pense que nous devrions réserver ... pour les génériques variadiques, une fois que nous sommes prêts à les avoir

J'aime beaucoup l'idée d'innover avec la syntaxe postfix ici. Cela a beaucoup plus de sens avec le flux et je me souviens à quel point le code s'est amélioré lorsque nous sommes passés du préfixe try! au suffixe ? . Je pense qu'il y a beaucoup de gens qui ont fait l'expérience dans la communauté Rust des améliorations apportées au code.

Si nous n'aimons pas l'idée de .await je suis sûr qu'une certaine créativité peut être faite pour trouver un opérateur de suffixe réel. Un exemple pourrait simplement être d'utiliser ++ ou @ pour await.

:( Je ne veux plus attendre.

Tout le monde est à l'aise avec la syntaxe de macro, la plupart des personnes dans ce fil qui commencent par d'autres opinions semblent finir par privilégier la syntaxe de macro.

Bien sûr, ce sera une "macro magique", mais les utilisateurs se soucient rarement de ce à quoi ressemble l'expansion de la macro et pour ceux qui le font, il est assez facile d'expliquer la nuance dans la documentation.

La syntaxe de macro régulière est un peu comme la tarte aux pommes, c'est la deuxième option préférée de tout le monde, mais par conséquent l'option préférée de la famille [0]. Surtout, comme avec try! nous pouvons toujours le changer plus tard. Mais surtout, plus tôt nous pourrons tous être d'accord, plus vite nous pourrons tous commencer à l'utiliser et être productifs!

[0] (Référencé dès la première minute) https://www.ted.com/talks/kenneth_cukier_big_data_is_better_data/transcript?language=en

match, if, if let, while, while let et for sont tous des flux de contrôle omniprésents
qui utilisent des préfixes. Faire semblant de faire une pause et de continuer est le seul flux de contrôle
Les mots-clés induisent en erreur.

Le sam 19 janvier 2019 à 15:37 Yazad Daruvala [email protected]
a écrit:

:( Je ne veux plus attendre.

Tout le monde est à l'aise avec la syntaxe des macros, la plupart des utilisateurs de ce fil
commencer par d'autres opinions semblent finir par privilégier la macro syntaxe.

Bien sûr, ce sera une "macro magique", mais les utilisateurs se soucient rarement de la nature de la macro
l'expansion ressemble et pour ceux qui le font, il est assez facile d'expliquer
nuance dans les documents.

La syntaxe de macro régulière est un peu comme la tarte aux pommes, c'est la deuxième
option préférée mais par conséquent l'option préférée de la famille [0].
Surtout, comme avec try! nous pouvons toujours le changer plus tard. Mais la plupart
surtout, plus tôt nous pourrons tous être d'accord, plus tôt nous pourrons tous commencer
en l'utilisant réellement et soyez productif!

[0] (référencé dans la première minute)
https://www.ted.com/talks/kenneth_cukier_big_data_is_better_data/transcript?language=en

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/rust-lang/rust/issues/57640#issuecomment-455824275 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/ABGmesz5_LfDKdcKn6zMO5uuSJs9lFiYks5vE6wygaJpZM4aBlba
.

@mitsuhiko Je suis d'accord! Postfix semble plus rustique en raison du chaînage. Je pense que la syntaxe fut@await j'ai proposée est une autre option intéressante qui ne semble pas avoir autant d'inconvénients que les autres propositions. Je ne sais pas si c'est trop loin et une version plus terre-à-terre serait préférable.

@ejmahler

match, if, if let, while, while let et for sont tous des flux de contrôle omniprésents qui utilisent des préfixes. Prétendre pause et continuer sont les seuls mots-clés du flux de contrôle est une erreur frustrante.

Ce n'est pas du tout trompeur. La grammaire pertinente pour ces constructions est à peu près:

Expr = kind:ExprKind;
ExprKind =
  | If:{ "if" cond:Cond then:Block { "else" else_expr:ElseExpr }? };
  | Match:{ "match" expr:Expr "{" arms:MatchArm* "}" }
  | While:{ { label:LIFETIME ":" }? "while" cond:Cond body:Block }
  | For:{ { label:LIFETIME ":" }? "for" pat:Pat "in" expr:Expr body:Block }
  ;

Cond =
  | Bool:Expr
  | Let:{ "let" pat:Pat "=" expr:Expr }
  ;

ElseExpr =
  | Block:Block
  | If:If
  ;

MatchArm = pats:Pat+ % "|" { "if" guard:Expr }? "=>" body:Expr ","?;

Ici, les formulaires sont if/while expr block , for pat in expr block et match expr { pat0 => expr0, .., patn => exprn } . Il y a un mot-clé qui précède ce qui suit sous toutes ces formes. Je suppose que c'est ce que vous entendez par "utilise des préfixes". Cependant, ce sont toutes des formes de bloc et non des opérateurs de préfixe unaire. La comparaison avec await expr est donc trompeuse car il n'y a ni cohérence ni règle à proprement parler. Si vous recherchez la cohérence avec les formulaires en bloc, comparez cela avec await block , et non await expr .

@mitsuhiko Je suis d'accord! Postfix semble plus rustique en raison du chaînage.

La rouille est dualiste. Il prend en charge les approches impératives et fonctionnelles. Et je pense que c'est bien, car dans différents cas, chacun d'eux peut être plus adapté.

Je ne sais pas. On dirait que ce serait génial d'avoir les deux:

await foo.bar();
foo.bar().await;

Ayant utilisé Scala pendant un certain temps, j'aimais aussi beaucoup de choses fonctionnant comme ça. Surtout match et if seraient bien d'avoir des positions postfixes dans Rust.

foo.bar().await.match {
   Bar1(x, y) => {x==y},
   Bar2(y) => {y==7},
}.if {
   bazinga();
}

Résumé à ce jour

Matrices d'options:

• sans bateaux
• mehcode
• HeroicKatora
• AaronFriel
• EyeOfPython

Matrice récapitulative des options (en utilisant @ comme sigil, mais peut être n'importe quoi):

| Nom | Future<T> | Future<Result<T, E>> | Result<Future<T>, E> |
| --- | --- | --- | --- |
| PREFIX | - | - | - |
| Macro de mot-clé | await!(fut) | await!(fut)? | await!(fut?) |
| Fonction de mot-clé | await(fut) | await(fut)? | await(fut?) |
| Préséance utile | await fut | await fut? | await (fut?) |
| Préséance évidente | await fut | await? fut | await fut? |
| POSTFIX | - | - | - |
| Fn avec mot-clé | fut(await) | fut(await)? | fut?(await) |
| Champ de mot-clé | fut.await | fut.await? | fut?.await |
| Méthode de mot-clé | fut.await() | fut.await()? | fut?.await() |
| Macro de mot-clé Postfix | fut.await!() | fut.await!()? | fut?.await!() |
| Mot-clé d'espace | fut await | fut await? | fut? await |
| Mot-clé Sigil | fut@await | fut@await? | fut?@await |
| Sigil | fut@ | fut@? | fut?@ |

Le sigil de "Sigil Keyword" _peut_ être # , car alors vous ne pourriez pas le faire avec un futur appelé r . ... car le sigil n'aurait pas à changer de tokenisation comme mon premier souci .

Plus d'utilisation réelle (PM moi d'autres cas d'utilisation _real_ avec plusieurs await sur urlo et je les ajouterai):

| Nom | (reqwest) Client |> Client::get |> RequestBuilder::send |> await |> ? |> Response::json | > ? |
| --- | --- |
| PREFIX | - |
| Macro de mot-clé | await!(client.get("url").send())?.json()? |
| Fonction de mot-clé | await(client.get("url").send())?.json()? |
| Préséance utile | (await client.get("url").send()?).json()? |
| Préséance évidente | (await? client.get("url").send()).json()? |
| POSTFIX | - |
| Fn avec mot-clé | client.get("url").send()(await)?.json()? |
| Champ de mot-clé | client.get("url").send().await?.json()? |
| Méthode de mot-clé | client.get("url").send().await()?.json()? |
| Macro de mot-clé Postfix | client.get("url").send().await!()?.json()? |
| Mot-clé d'espace | client.get("url").send() await?.json()? |
| Mot-clé Sigil | client.get("url").send()@await?.json()? |
| Sigil | client.get("url").send()@?.json()? |

NOTE DE MODIFICATION: On m'a fait remarquer qu'il peut être judicieux pour Response::json de renvoyer également un Future , où send attend l'IO sortant et json (ou autre interprétation du résultat) attend l'IO entrant. Je vais cependant laisser cet exemple tel quel, car je pense qu'il est significatif de montrer que le problème de chaînage s'applique même avec un seul point d'attente d'E / S dans l'expression.

Il semble y avoir un consensus approximatif sur le fait que parmi les options de préfixe, la priorité évidente (avec le sucre await? ) est la plus souhaitable. Cependant, de nombreuses personnes se sont prononcées en faveur d'une solution postfix, afin de faciliter le chaînage comme ci-dessus. Bien que le choix du préfixe fasse l'objet d'un consensus approximatif, il ne semble pas y avoir de consensus sur la meilleure solution postfix. Toutes les options proposées conduisent à une confusion facile (atténuée par la mise en évidence des mots clés):

• Fn With Keyword => appel d'un fn avec un argument appelé await
• Champ de mot-clé => accès au champ
• Keyword Method => appel de méthode
• Macro (préfixe ou suffixe) => await un mot-clé ou non?
• Mot-clé d'espace => rompt le regroupement en une seule ligne (mieux sur plusieurs lignes?)
• Sigil => ajoute de nouveaux sigils à une langue déjà perçue comme lourde de sigils

Autres suggestions plus drastiques:

• Autoriser à la fois le préfixe (priorité évidente) et le suffixe "champ" (cela pourrait être appliqué à plus de mots clés comme match , if , etc. à l'avenir pour en faire un modèle généralisé, mais ce n'est pas nécessaire addendum à ce débat) [[référence] (https://github.com/rust-lang/rust/issues/57640#issuecomment-455827164)]
• await en modèles pour résoudre les futurs (pas de chaînage du tout) [[reference] (https://github.com/rust-lang/rust/issues/57640)]
• Utilisez un opérateur de préfixe mais autorisez le retarder [[reference] (https://github.com/rust-lang/rust/issues/57640#issuecomment-455782394)]

La stabilisation avec une macro de mot-clé await!(fut) est bien sûr compatible pour l'avenir avec pratiquement tout ce qui précède, bien que cela nécessite de faire en sorte que la macro utilise un mot-clé au lieu d'un identifiant régulier.

Si quelqu'un a un exemple d'exemple la plupart du temps réel qui utilise deux await dans une chaîne, j'aimerais le voir; personne n'en a partagé un jusqu'à présent. Cependant, le suffixe await est également utile même si vous n'avez pas besoin de await plus d'une fois dans une chaîne, comme le montre l'exemple reqwest.

Si j'ai manqué quelque chose de notable au-dessus de ce commentaire récapitulatif, envoyez-moi un message sur urlo et j'essaierai de l'ajouter. (Bien que j'exige qu'il ajoute les commentaires de quelqu'un d'autre pour éviter le favoritisme de la voix forte.)

Personnellement, j'ai toujours été en faveur du préfixe mot-clé avec la priorité évidente. Je pense toujours que la stabilisation avec une macro de mot-clé await!(fut) serait utile pour collecter des informations du monde réel sur l'endroit où l'attente se produit dans les cas d'utilisation du monde réel, et nous permettrait toujours d'ajouter un préfixe non macro ou une option de postfix plus tard .

Cependant, en rédigeant le résumé ci-dessus, j'ai commencé à aimer "Keyword Field". "Espace Mot clé" est agréable lorsqu'il est divisé sur plusieurs lignes:

client
    .get("url")
    .send() await?
    .json()?

mais sur une ligne, cela fait une pause maladroite qui regroupe mal l'expression: client.get("url").send() await?.json()? . Cependant, avec le champ de mot-clé, il semble bon dans les deux formes: client.get("url").send().await?.json()?

client
    .get("url")
    .send()
    .await?
    .json()?

bien que je suppose qu'une "méthode de mot-clé" coulerait mieux, car c'est une action. Nous _pouvions_ même en faire une "vraie" méthode sur Future si nous voulions:

trait Future<..> {
    ..
    extern "rust-await" fn r#await(self) -> _;
}

( extern "rust-await" impliquerait bien sûr toute la magie nécessaire pour réellement faire l'attente et ce ne serait pas réellement un vrai fn, il serait principalement là parce que la syntaxe ressemble à une méthode, si un mot-clé méthode est utilisée.)

Autoriser à la fois le préfixe (priorité évidente) et le suffixe "champ" ...

Si une syntaxe postfixe est sélectionnée (peu importe si elle est ensemble ou à la place du préfixe), ce serait certainement un argument pour une discussion future: nous avons maintenant des mots-clés qui fonctionnent à la fois en notation préfixe et postfixe, précisément parce que parfois on est préférable à l'autre, alors peut-être pourrions-nous simplement autoriser les deux là où cela a du sens, et augmenter la flexibilité de la syntaxe, tout en unifiant les règles. C'est peut-être une mauvaise idée, peut-être qu'elle sera rejetée, mais c'est certainement une discussion à avoir dans le futur, si la notation postix est utilisée pour await .

Je pense qu'il y a très peu de chances qu'une syntaxe qui n'inclut pas la chaîne de caractères await soit acceptée pour cette syntaxe.

: +1:

Une pensée aléatoire que j'ai eue après avoir vu un tas d'exemples ici ( comme ceux de @mehcode ): L'une des plaintes dont je me souviens à propos de .await est que c'est trop difficile à voir †, mais étant donné que les choses attendues sont typiquement faillible, le fait qu'il soit souvent .await? permet d'attirer l'attention de toute façon.

† Si vous utilisez quelque chose qui ne met pas en évidence les mots clés

@ejmahler

Je m'oppose à toute syntaxe qui ne se lit pas un peu comme l'anglais

Quelque chose comme request.get().await lit aussi bien que quelque chose comme body.lines().collect() . Dans "un tas de méthodes d'itération enchaînées", je pense que _prefix_ se lit en fait pire, car vous devez vous rappeler qu'ils ont dit "attendez" au début, et ne savez jamais quand vous entendez quelque chose si ça va être ce que vous attendre, un peu comme une phrase de chemin de jardin .

Et après des années à les utiliser dans le code de production, je pense qu'il est absolument essentiel de savoir où se trouvent vos limites d'élasticité. Lorsque vous parcourez la ligne d'indentation de votre fonction, vous pouvez sélectionner chaque retour co_await / yield dans une fonction de 200 lignes en quelques secondes, sans charge cognitive.

Cela implique qu'il n'y en a jamais dans une expression, ce qui est une restriction que je ne prendrais absolument pas en charge, étant donné la nature orientée expression de Rust. Et au moins avec await C #, il est absolument plausible d'avoir CallSomething(argument, await whatever.Foo() .

Étant donné que async _will_ apparaîtra au milieu des expressions, je ne comprends pas pourquoi il est plus facile de voir dans le préfixe que dans le suffixe.

Il devrait recevoir le même niveau de respect que «if, while, match et return. Imaginez si l'un d'entre eux était des opérateurs postfixes - lire du code Rust serait un cauchemar.

return (et continue et break ) et while sont notables comme étant _complètement_ inutiles à enchaîner, car ils renvoient toujours ! et () . Et bien que pour une raison quelconque vous ayez omis for , nous avons vu du code écrit très bien avec .for_each() sans effets négatifs, en particulier en rayon .

Nous devons probablement faire la paix avec le fait que async/await va être une fonctionnalité majeure du langage. Il apparaîtra dans toutes sortes de codes. Il envahira l'écosystème - à certains endroits, il sera aussi courant que ? . Les gens devront l'apprendre.

Par conséquent, nous pourrions vouloir nous concentrer consciemment sur ce que ressentira le choix de syntaxe après l'avoir utilisé pendant une longue période plutôt que sur ce qu'il ressentira au début.

Nous devons également comprendre qu'en ce qui concerne les constructions de flux de contrôle, await est un autre type d'animal. Des constructions comme return , break , continue , et même yield peuvent être comprises intuitivement en termes de jmp . Quand nous les voyons, nos yeux rebondissent sur l'écran parce que le flux de contrôle qui nous tient à cœur se déplace ailleurs. Cependant, alors que await affecte le flux de contrôle de la machine, il ne déplace pas le flux de contrôle qui est important à nos yeux et à notre compréhension intuitive du code.

Nous ne sommes pas tentés d'enchaîner les appels inconditionnels à return ou break car cela n'aurait aucun sens. Pour des raisons similaires, nous ne sommes pas tentés de modifier nos règles de préséance pour les adapter. Ces opérateurs ont une faible priorité. Ils prennent tout à droite et le renvoient quelque part, mettant fin à l'exécution dans cette fonction ou ce bloc. L'opérateur await , cependant, veut être chaîné. C'est une partie intégrante d'une expression, pas la fin.

Après avoir examiné la discussion et les exemples de ce fil, il me reste le sentiment rongeant que nous vivrions pour regretter des règles de préséance surprenantes.

Le candidat cheval de traque semble aller avec await!(expr) pour le moment et espérer que quelque chose de mieux sera résolu plus tard. Avant de lire les remarques de @Centril , j'aurais probablement soutenu cela dans l'intérêt de sortir cette fonctionnalité importante avec presque n'importe quelle syntaxe. Cependant, ses arguments me convainquent que ce ne serait que de la répression. Nous savons que le chaînage des appels de méthode est important dans Rust. Cela a conduit à l'adoption du mot-clé ? , qui est très populaire et très réussi. Utiliser une syntaxe dont nous savons qu'elle nous décevra, c'est en effet simplement ajouter de la dette technique.

Au début de ce fil, @withoutboats a indiqué que seules quatre options existantes semblent viables. Parmi ceux-ci, seule la syntaxe postfix expr await est susceptible de nous rendre heureux à long terme. Cette syntaxe ne crée pas d'étranges surprises de précédence. Cela ne nous oblige pas à créer une version préfixe de l'opérateur ? . Cela fonctionne bien avec le chaînage de méthodes et ne rompt pas le flux de contrôle de gauche à droite. Notre opérateur ? réussi sert de précédent pour un opérateur suffixe, et await ressemble plus à ? en pratique qu'à return , break ou yield . Alors qu'un opérateur non-symbole postfix peut être nouveau dans Rust, l'utilisation de async/await sera suffisamment répandue pour le rendre rapidement familier.

Bien que toutes les options pour une syntaxe postfixe semblent réalisables, expr await présente certains avantages. Cette syntaxe indique clairement que await est un mot-clé, ce qui permet de souligner le flux de contrôle magique. Par rapport à expr.await , expr.await() expr.await! , expr.await!() , etc., cela évite d'avoir à expliquer que cela ressemble à un champ / méthode / macro, mais vraiment n'est pas dans ce cas particulier. Nous nous habituerions tous au séparateur d'espace ici.

Épeler await comme @ ou utiliser un autre symbole qui ne pose pas de problèmes d'analyse est attrayant. C'est certainement un opérateur suffisamment important pour le justifier. Mais si, à la fin, il faut l'épeler await , ce sera très bien. Tant qu'il est en position postfix.

Comme quelqu'un l'a mentionné de vrais exemples ... Je maintiens une base de code de rouille de 23 858 lignes (selon tokei) qui est très fortement asynchrone et utilise des contrats à terme 0,1 await (hautement expérimentaux, je sais). Allons-y (expurgé) spelunking (notez que tout a été exécuté via rustfmt):

// A
if !await!(db.is_trusted_identity(recipient.clone(), message.key.clone()))? {
    info!("recipient: {}", recipient);
}

// B
match await!(db.load(message.key))? {
    Some(key) => key,
    None => {
        return Err(/* [...] */);
    }
};

// C
let mut res = await!(client
    .get(&script_src)
    .header("cookie", self.cookies.read().as_header_value())
    .header("user-agent", USER_AGENT)
    .send())?
.error_for_status()?;

// D
let mut res =
    await!(client.get(inbox_url).headers(inbox_headers).send())?.error_for_status()?;

let mut res: InboxResponse = await!(res.json())?;

// E
let mut res = await!(client
    .post(url)
    .multipart(form)
    .headers(headers.clone())
    .send())?
.error_for_status()?;

let res: Response = await!(res.json())?;

// F
#[async]
fn request_user(self, user_id: String) -> Result<User> {
    let url = format!("users/{}/profile", user_id);
    let (_, mut res) = await!(self.request(url, Method::GET, None, true))?;
    let user = await!(res.json::<UserResponse>())?
        .user
        .into();

    Ok(user)
}

Maintenant, transformons cela en la variante de préfixe la plus populaire, priorité évidente avec le sucre. Pour des raisons évidentes, cela n'a pas été exécuté via rustfmt, alors nous vous prions de nous excuser s'il existe une meilleure façon de l'écrire.

// A
if await? db.is_trusted_identity(recipient.clone(), message.key.clone()) {
    info!("recipient: {}", recipient);
}

// B
match await? db.load(message.key) {
    Some(key) => key,
    None => {
        return Err(/* [...] */);
    }
};

// C
let mut res = (await? client
    .get(&script_src)
    .header("cookie", self.cookies.read().as_header_value())
    .header("user-agent", USER_AGENT)
    .send())
.error_for_status()?;

// D
let mut res =
    (await? client.get(inbox_url).headers(inbox_headers).send()).error_for_status()?;

let mut res: InboxResponse = await? res.json();

// E
let mut res = (await? client
    .post(url)
    .multipart(form)
    .headers(headers.clone())
    .send())
.error_for_status()?;

let res: Response = await? res.json();

// F
async fn request_user(self, user_id: String) -> Result<User> {
    let url = format!("users/{}/profile", user_id);
    let (_, mut res) = await? self.request(url, Method::GET, None, true);
    let user = (await? res.json::<UserResponse>())
        .user
        .into();

    Ok(user)
}

Enfin, transformons ceci en ma variante préférée de postfix, "champ postfix".

// A
if db.is_trusted_identity(recipient.clone(), message.key.clone()).await? {
    info!("recipient: {}", recipient);
}

// B
match db.load(message.key).await? {
    Some(key) => key,
    None => {
        return Err(/* [...] */);
    }
};

// C
let mut res = client.get(&script_src)
    .header("cookie", self.cookies.read().as_header_value())
    .header("user-agent", USER_AGENT)
    .send().await?
    .error_for_status()?;

// D
let mut res: InboxResponse = client.get(inbox_url)
    .headers(inbox_headers)
    .send().await?
    .error_for_status()?
    .json().await?;

// E
let mut res: Response = client.post(url)
    .multipart(form)
    .headers(headers.clone())
    .send().await?
    .error_for_status()?
    .json().await?;

// F
async fn request_user(self, user_id: String) -> Result<User> {
    let url = format!("users/{}/profile", user_id);
    let user = self.request(url, Method::GET, None, true).await?
        .res.json::<UserResponse>().await?
        .user
        .into();

    Ok(user)
}

Après cet exercice, je trouve un certain nombre de choses.

• Je suis maintenant fermement contre await? foo . Il se lit bien pour les expressions simples mais le ? se sent perdu sur les expressions complexes. Si nous devons faire un préfixe, je préfère avoir une priorité "utile".

• L'utilisation de la notation postfix me conduit à joindre des instructions et à réduire les liaisons let inutiles.

• L'utilisation de la notation postfix _field_ me conduit à préférer fortement que .await? apparaisse dans la ligne de l'objet qu'il attend plutôt que sur sa propre ligne dans le jargon rustfmt.

J'apprécie la notation postfixe ellipses "..." ci-dessus, à la fois pour sa concision et symboliquement en langue anglaise représentant une pause en prévision de quelque chose d'autre. (Comme comment fonctionne le comportement asynchrone!), Il s'enchaîne également bien.

let resultValue = doSomethingAndReturnResult()...?;
let resultValue = doSomethingAndReturnResult()...?.doSomethingOnResult()...?;
let value = doSomethingAndReturnValue()....doSomethingOnValue()...;
let arrayOfValues = vec![doSomethingA(),doSomethingB()]...?;
// Showing stacking
let value = doSomethingWithVeryLongFunctionName()...?
                 .doSomethingWithResult()...?;

Je doute que d'autres options soient aussi concises et visuellement significatives.

UNE

let mut res: Response = (await client.post(url)
    .multipart(form)
    .headers(headers.clone())
    .send().await?
    .error_for_status()?
    .json())?;

B

let mut res: Response = await client.post(url)
    .multipart(form)
    .headers(headers.clone())
    .send().await?
    .error_for_status()?
    .json());
let res = res.unwrap();

Doit-il même être considéré comme une bonne forme d'avoir de longues chaînes d'attente?

Pourquoi ne pas simplement utiliser des combinateurs Future normaux?

En fait, certaines expressions ne se traduisent pas bien en chaînes d'attente si vous souhaitez avoir des comportements de sauvegarde en cas d'échec.

Personnellement, je pense ceci:

let value = await some_op()
                 .and_then(|v| v.another_op())
                 .and_then(|v2| v2.final_op())
                 .or_else(|| backup_op());

value.unwrap()

se lit beaucoup plus naturellement que ceci:

let value = match await some_op() {
    Ok(v) => match await v.another_op() {
        Ok(v2) => await v2.final_op(),
        Err(_) => await backup_op(),
    },
    Err(_) => await backup_op(),
};

value.unwrap()

Après tout, nous avons toujours la pleine puissance des contrats à terme à coût zéro entre nos mains.

Considérez cela.

@EyeOfPython Je voudrais @ in future@await . Nous pouvons écrire future~await , où le ~ est travaillé comme un demi-trait d'union, et fonctionnerait pour tous les opérateurs de suffixe possibles.

Le trait d'union - était déjà utilisé comme opérateur moins et opérateur négatif. Ce n'est plus bon. Mais ~ était utilisé pour indiquer des objets de tas dans Rust, et sinon, il n'était guère utilisé dans aucun langage de programmation. Cela donnerait moins de confusion aux personnes d'autres langues.

@earthengine Bonne idée, mais peut-être simplement utiliser future~ ce qui signifie attendre un futur, où le ~ est travaillé comme le mot-clé await (comme le symbole ?

Avenir | Avenir du résultat | Résultat du futur
- | - | -
futur ~ | futur ~? | futur? ~

Également des futurs enchaînés comme:

let res: MyResponse = client.get("https://my_api").send()~?.json()~?;

J'ai regardé comment Go implémente la programmation asynchrone et j'ai trouvé quelque chose d'intéressant. L'alternative la plus proche aux futurs en Go sont les canaux. Et au lieu de await ou d'une autre syntaxe criarde pour attendre les valeurs, les canaux Go fournissent juste l'opérateur <- à cette fin. Pour moi, cela a l'air assez propre et simple. Auparavant, j'ai souvent vu comment les gens louaient Go pour sa syntaxe simple et ses bonnes installations asynchrones, c'est donc une bonne idée d'apprendre quelque chose de son expérience.

Malheureusement, nous ne pouvions pas avoir exactement la même syntaxe car il y a beaucoup plus d'accolades dans le code source de Rust que dans Go, principalement à cause des génériques. Cela rend l'opérateur <- vraiment subtil et pas agréable à travailler. Un autre inconvénient est qu'il pourrait être considéré comme opposé à -> dans la signature de la fonction et il n'y a aucune raison de le considérer comme ça. Et encore un autre inconvénient est que <- sigil était destiné à être implémenté en tant que placement new , de sorte que les gens pourraient mal l'interpréter.

Donc, après quelques expériences avec la syntaxe, je me suis arrêté à <-- sigil:

let output = <-- future;

Dans le contexte async <-- est assez simple, bien que moins de <- . Mais à la place, il offre un gros avantage sur <- ainsi que sur le préfixe await - il joue bien avec l'indentation.

async fn log_service(&self) -> T {
   let service = self.myService.foo();
   <-- self.logger.log("beginning service call");
   let output = <-- service.exec();
   <-- self.logger.log("foo executed with result {}.", output));
   output
}

async fn try_log(message: String) -> Result<usize, Error> {
    let logger = <-- acquire_lock();
    let length = <-- logger.log_into(message)?;
    <-- logger.timestamp();
    Ok(length)
}

async fn await_chain() -> Result<usize, Error> {
    <-- (<-- partial_computation()).unwrap_or_else(or_recover);
}

Pour moi, cet opérateur semble encore plus unique et plus facile à repérer que await (qui ressemble plus à n'importe quel autre mot-clé ou variable dans le contexte du code). Malheureusement, sur Github, cela semble plus mince que dans mon éditeur de code, mais je pense que ce n'est pas fatal et nous pouvons vivre avec cela. Même si quelqu'un se sent mal à l'aise, une coloration syntaxique différente ou une meilleure police (en particulier avec les ligatures) résoudra tous les problèmes.

Une autre raison d'aimer cette syntaxe est qu'elle pourrait conceptuellement être exprimée comme "quelque chose qui n'est pas encore là". La direction de droite à gauche de la flèche est opposée à la direction dans laquelle nous lisons le texte, ce qui nous permet de le décrire comme "chose qui vient du futur". La forme longue de l'opérateur <-- suggère également que "une opération durable commence". Un crochet angulaire et deux traits d'union dirigés à partir de future pourraient symboliser "l'interrogation continue". Et nous sommes toujours capables de le lire comme "attendre" comme avant.
Pas une sorte d'illumination, mais cela pourrait être amusant.

La chose la plus importante dans cette proposition est que l'enchaînement de méthodes ergonomiques serait également possible. L'idée d' opérateur de préfixe retardé que j'ai proposé précédemment convient bien ici. De cette façon, nous aurions le meilleur des deux mondes de la syntaxe du préfixe et du suffixe await . J'espère vraiment qu'il y aurait aussi des extras utiles que je voulais personnellement à de nombreuses reprises auparavant: le déréférencement retardé et la syntaxe de négation retardée .

À travers, je ne suis pas sûr que le mot retardé soit approprié ici, peut-être devrions-nous le nommer différemment.

client.get("https://my_api").<--send()?.<--json()?

let not_empty = some_vec.!is_empty();

let deref = value.*as_ref();

La priorité des opérateurs semble assez évidente: de gauche à droite.

J'espère que cette syntaxe réduira le besoin d'écrire des fonctions is_not_* dont le but est uniquement de nier et de renvoyer une propriété bool . Et les expressions booléennes / de déréférencement dans certains cas seront plus propres lors de leur utilisation.

Enfin, je l'ai appliqué sur des exemples du monde réel publiés par @mehcode et j'aime la façon dont <-- met correctement l'accent sur la fonction async l'intérieur des chaînes d'appels de méthodes. Au contraire, le suffixe await ressemble simplement à un accès au champ normal ou à un appel de fonction (selon la syntaxe) et il est presque impossible de les distinguer sans coloration syntaxique ou mise en forme spéciale.

// A
if db.<--is_trusted_identity(recipient.clone(), message.key.clone())? {
    info!("recipient: {}", recipient);
}

// B
match db.<--load(message.key)? {
    Some(key) => key,
    None => {
        return Err(/* [...] */);
    }
};

// C
let mut res = client.get(&script_src)
    .header("cookie", self.cookies.read().as_header_value())
    .header("user-agent", USER_AGENT)
    .<--send()?
    .error_for_status()?;

// D
let mut res: InboxResponse = client.get(inbox_url)
    .headers(inbox_headers)
    .<--send()?
    .error_for_status()?
    .<--json()?;

// E
let mut res: Response = client.post(url)
    .multipart(form)
    .headers(headers.clone())
    .<--send()?
    .error_for_status()?
    .<--json()?;

// F
async fn request_user(self, user_id: String) -> Result<User> {
    let url = format!("users/{}/profile", user_id);
    let user = self.<--request(url, Method::GET, None, true)?
        .res.<--json::<UserResponse>()?
        .user
        .into();

    Ok(user)
}

Après tout: c'est la syntaxe que je souhaite utiliser.

@novacrazy

Doit-il même être considéré comme une bonne forme d'avoir de longues chaînes d'attente? Pourquoi ne pas simplement utiliser des combinateurs Future réguliers?

Je ne sais pas si je ne vous ai pas mal compris mais ceux-ci ne sont pas exclusifs, vous pouvez toujours utiliser des combinateurs

let value = some_op()
    .and_then(|v| v.another_op())
    .and_then(|v2| v2.final_op())
    .or_else(|| backup_op())
    .await;

Mais pour que cela fonctionne, la clause and_then doit être tapée à FnOnce(T) -> impl Future<_> , pas seulement à FnOnce(T) -> U . Faire des combinateurs enchaînés sur le futur et le résultat ne fonctionne que proprement sans paranthèse dans postfix:

let result = load_local_file()
    .or_else(|_| request_from_server()) // Async combinator
    .await
    .and_then(|body| serde_json::from_str(&body)); // Sync combinator

Dans cet article, je vais me concentrer sur la question de la priorité des

• Appel de méthode ( future.await() )
• Expression de champ ( future.await )
• Appel de fonction ( future(await) )

Les différences de fonctionnalité sont plutôt faibles mais existantes. Notez que j'accepterais tout cela, il s'agit principalement d'un réglage fin. Pour tous les montrer, nous avons besoin de certains types. Veuillez ne pas faire de commentaires sur le caractère artificiel de l'exemple, c'est la version la plus compressée qui montre toutes les différences à la fois.

struct Foo<A, F, S> where A: Future<Output=F>, F: FnOnce(usize) -> S {
    member: A,
}

// What we want to do, in macro syntax:
let foo: Foo<_, _, _> = …;
(await!(foo.member))(42)

• Appel de méthode: foo.member.await()(42)
  Se lie le plus fortement, donc pas de paranthèse du tout
• Membre: (foo.member.await)(42)
  Nécessite une paranthèse autour du résultat attendu quand il s'agit d'un appelable, cela est cohérent avec le fait d'avoir un appelable en tant que membre, sinon confusion avec l'appel à la fonction membre. Cela suggère également que l'on pourrait déstructurer avec des motifs: let … { await: value } = foo.member; value(42) quelque sorte?
• Appel de fonction: (foo.member)(await)(42)
  Nécessite une paranthèse pour la déstructuration (nous déplaçons le membre) car il se comporte comme un appel de fonction.

Tous se ressemblent quand nous ne détruisons pas une structure d'entrée par le déplacement d'un membre, ni n'appelons le résultat comme un appelable puisque ces trois classes de précédence se succèdent directement. Comment voulons-nous que les futurs se comportent?

Le meilleur parallèle à l'appel de méthode devrait être juste un autre appel de méthode prenant self .

Le meilleur parallèle au membre est une structure qui n'a que le membre implicite await et est donc déstructurée en partant de cela, et ce mouvement attend implicitement le futur. Celui-ci semble le moins évident.

Le parallèle à la fonction est l'appel est le comportement des fermetures. Je préférerais cette solution comme l'ajout le plus propre au corpus de langage (car dans la syntaxe correspond le mieux les possibilités du type), mais il y a des points positifs pour l'appel de méthode et .await n'est jamais plus long que les autres.

@HeroicKatora Nous pourrions .await dans libsyntax pour autoriser foo.await(42) mais ce serait incohérent / ad hoc. Cependant, (foo.await)(42) semble utilisable car s'il existe des fermetures à terme, elles ne sont probablement pas si courantes. Ainsi, si nous optimisons pour le cas courant, ne pas avoir à ajouter () à .await emporte probablement sur l'équilibre.

@Centril Je suis d'accord, la cohérence est importante. Quand je vois quelques comportements similaires, j'aimerais en déduire d'autres par synthèse. Mais ici .await semble gênant, surtout avec l'exemple ci-dessus montrant clairement qu'il est parallèle à la déstructuration implicite (à moins que vous ne puissiez trouver une syntaxe différente où ces effets se produisent?). Quand je vois la déstructuration, je me demande instantanément si je peux utiliser cela avec des liaisons let, etc. Ceci, cependant, ne serait pas possible car nous déstructurerions le type d'origine qui n'a pas de tel membre ou surtout quand le type est juste impl Future<Output=F> (Sidenote généralement non pertinente: faire ce travail nous ramènerait à un préfixe alternatif await _ = à la place de let _ = , curieusement¹).

Cela ne nous interdit pas d'utiliser la syntaxe en tant que telle, je pense que je pourrais m'occuper de l'apprendre et si elle s'avère être la dernière, je l'utiliserai avec vigueur, mais cela semble être une faiblesse évidente.

¹ Cela pourrait être cohérent tout en autorisant ? en permettant ? derrière les noms dans un motif

• await value? = failing_future();

pour correspondre à la partie Ok d'un Result . Cela semble intéressant à explorer également dans d'autres contextes, mais plutôt hors sujet. Cela conduirait également à faire correspondre la syntaxe du préfixe et du suffixe pour await en même temps.

Cela ne nous interdit pas d'utiliser la syntaxe en tant que telle, je pense que je pourrais m'occuper de l'apprendre et si elle s'avère être la dernière, je l'utiliserai avec vigueur, mais cela semble être une faiblesse évidente.

Je pense que chaque solution aura un inconvénient dans une certaine dimension ou dans un cas précis. cohérence, ergonomie, chaînabilité, lisibilité, ... Cela en fait une question de degré, d'importance des cas, d'adéquation au code et aux API typiques de Rust, etc.

Dans le cas d'un utilisateur écrivant foo.await(42) ...

struct HasClosure<F: FnOnce(u8)> { closure: F, }
fn _foo() {
    let foo: HasClosure<_> = HasClosure { closure: |x| {} };

    foo.closure(42);
}

... nous fournissons déjà de bons diagnostics:

5 |     foo.closure(42);
  |         ^^^^^^^ field, not a method
  |
  = help: use `(foo.closure)(...)` if you meant to call the function stored in the
          `closure` field

Ajuster cela pour l'adapter à foo.await(42) semble tout à fait réalisable. En fait, pour autant que je sache, nous savons que l'utilisateur a l'intention de (foo.await)(42) quand foo.await(42) est écrit, donc cela peut être cargo fix ed dans un MachineApplicable manière. En effet, si nous stabilisons foo.await mais n'autorisons pas foo.await(42) je crois que nous pouvons même changer la priorité plus tard si nous en avons besoin puisque foo.await(42) ne sera pas légal au début.

D'autres emboîtements fonctionneraient (par exemple, le futur du résultat de la fermeture - non pas que ce soit courant):
`` rouille
struct HasClosure fn _foo () -> Résultat <(), ()> {
laissez toto: HasClosure <_ i = "27"> = HasClosure {fermeture: Ok (| x | {})};

foo.closure?(42);

Ok(())

}

Par exemple, l'avenir du résultat de la fermeture - non pas que ce sera commun

L'opérateur de suffixe supplémentaire ? rend cela sans ambiguïté sans modifications de syntaxe - dans aucun des exemples post-correction. Aucun ajustement nécessaire . Les problèmes sont seulement que .member explicitement un champ et que la déstructuration des mouvements doit s'appliquer en premier. Et je ne veux vraiment pas dire que ce serait difficile à écrire. Je veux surtout dire que cela semble incompatible avec d'autres utilisations de .member qui, par exemple, peuvent être transformées en correspondance. Le message original pesait les points positifs et négatifs à cet égard.

Edit: Ajuster pour ajuster future.await(42) a le risque supplémentaire, probablement involontaire, de rendre ceci a) incompatible avec les fermetures où ce n'est pas le cas en raison des méthodes du même nom que le membre étant autorisées; b) inhiber les développements futurs où nous aimerions donner des arguments à await . Mais, comme vous l'avez mentionné précédemment, ajuster pour Future renvoyer une fermeture ne devrait pas être le problème le plus pressant.

@novacrazy Pourquoi ne pas utiliser simplement des combinateurs Future réguliers?

Je ne suis pas sûr de votre expérience avec Futures 0.3, mais on s'attend généralement à ce que les combinateurs ne soient pas beaucoup utilisés et que l'utilisation principale / idiomatique sera async / await.

Async / await présente plusieurs avantages par rapport aux combinateurs, par exemple, il prend en charge l'emprunt à travers les points de rendement.

Les combinateurs existaient bien avant async / await, mais async / await a quand même été inventé, et pour une bonne raison!

Async / await est là pour rester, ce qui signifie qu'il doit être ergonomique (y compris avec les chaînes de méthodes).

Bien sûr, les gens sont libres d'utiliser les combinateurs s'ils le souhaitent, mais ils ne devraient pas être nécessaires pour obtenir une bonne ergonomie.

Comme @cramertj l'a dit, essayons de garder la discussion concentrée sur async / await, et non sur les alternatives à async / await.

En fait, certaines expressions ne se traduisent pas bien en chaînes d'attente si vous souhaitez avoir des comportements de sauvegarde en cas d'échec.

Votre exemple peut être considérablement simplifié:

let value = try {
    let v = await some_op()?;
    let v2 = await v.another_op()?;
    await v2.final_op()?
};

match value {
    Ok(value) => Ok(value),
    Err(_) => await backup_op(),
}.unwrap()

Cela indique clairement quelles parties gèrent l'erreur et quelles parties sont sur le chemin normal normal.

C'est l'un des avantages de async / await: il fonctionne bien avec d'autres parties du langage, y compris les boucles, les branches, match , ? , try , etc.

En fait, à part await , c'est le même code que vous écririez si vous n'utilisiez pas Futures.

Une autre façon de l'écrire, si vous préférez utiliser le combinateur or_else :

let value = await async {
    try {
        let v = await some_op()?;
        let v2 = await v.another_op()?;
        await v2.final_op()?
    }
}.or_else(|_| backup_op());

value.unwrap()

Et le meilleur de tous est de déplacer le code normal dans une fonction distincte, ce qui rend le code de gestion des erreurs encore plus clair:

async fn doit() -> Result<Foo, Bar> {
    let v = await some_op()?;
    let v2 = await v.another_op()?;
    await v2.final_op()
}

let value = await doit().or_else(|_| backup_op());

value.unwrap()

(Ceci est une réponse au commentaire de

Pour être clair, vous n'êtes pas obligé de mettre entre parenthèses, je l'ai mentionné parce que certaines personnes ont dit que c'était trop difficile à lire sans les parenthèses. Ainsi, les parenthèses sont un choix stylistique

Toutes les syntaxes bénéficient de parenthèses dans certaines situations, aucune des syntaxes n'est parfaite, il s'agit de savoir pour quelles situations nous voulons optimiser.

De plus, après avoir relu votre commentaire, vous pensiez peut-être que je préconisais le préfixe await ? Je ne l'étais pas, mon exemple utilisait le suffixe await . Dans l'ensemble, j'aime postfix await , bien que j'aime aussi certaines des autres syntaxes.

Je commence à être à l'aise avec fut.await , je pense que la réaction initiale des gens sera "Attendez, c'est comme ça que vous attendez? Bizarre." mais plus tard, ils l'adoreraient pour sa commodité. Bien sûr, il en va de même pour @await , qui se démarque beaucoup plus que .await .

Avec cette syntaxe, nous pouvons omettre certains des let dans l'exemple:

let value = try {
    some_op().await?
        .another_op().await?
        .final_op().await?
};

match value {
    Ok(value) => Ok(value),
    Err(_) => backup_op().await,
}.unwrap()

let value = try {
    some_op()@await?
        .another_op()@await?
        .final_op()@await?
};

match value {
    Ok(value) => Ok(value),
    Err(_) => backup_op()<strong i="21">@await</strong>,
}.unwrap()

Cela rend également plus clair ce qui est déballé avec ? , pour await some_op()? , il n'est pas évident de savoir si some_op() est déballé ou le résultat attendu.

@Pauan

Je n'essaye pas de détourner l'attention du sujet ici, j'essaie de souligner qu'il n'existe pas dans une bulle. Nous devons considérer comment les choses fonctionnent ensemble .

Même si la syntaxe idéale était choisie, je voudrais toujours utiliser des futurs et des combinateurs personnalisés dans certaines situations. L'idée que ceux-ci pourraient être légèrement obsolètes me fait remettre en question toute la direction de Rust.

Les exemples que vous donnez semblent toujours terribles par rapport aux combinateurs, et avec la surcharge du générateur, ils seront probablement un peu plus lents et produiront plus de code machine.

En attendant, tout ce bikeshedding préfixe / suffixe sigil / mot-clé est merveilleux, mais peut-être devrions-nous être pragmatiques et choisir l'option la plus simple qui est la plus familière aux utilisateurs venant sur Rust. Ie: mot-clé préfixe

Cette année va passer plus vite qu'on ne le pense. Même janvier est presque terminé. S'il s'avère que les utilisateurs ne sont pas satisfaits d'un mot-clé de préfixe, il peut être modifié dans une édition 2019/2020. Nous pouvons même faire une blague «avec le recul c'est 2020».

@novacrazy

Le consensus général que j'ai vu est que le plus tôt que nous voudrions une troisième édition est 2022. Nous ne voulons certainement pas planifier une autre édition; l'édition 2018 était géniale mais pas sans ses coûts. (Et l'un des points de l'édition 2018 est de rendre async / wait possible, imaginez reprendre cela et dire "non, vous devez passer à l'édition 2020 maintenant!")

En tout cas, je ne pense pas qu'une transition de mot-clé préfixe -> mot-clé postfixe soit possible dans une édition, même si cela serait souhaitable. La règle concernant les éditions est qu'il doit y avoir un moyen d'écrire du code idiomatique dans l'édition X de sorte qu'il compile sans avertissement et fonctionne de la même manière dans l'édition X + 1.

C'est la même raison pour laquelle nous préférons ne pas stabiliser avec une macro de mots clés si nous pouvons générer un consensus sur une solution différente; stabiliser délibérément une solution que nous savons n'est pas souhaitable est en soi problématique.

Je pense que nous avons montré qu'une solution postfix est plus optimale, même pour les expressions avec un seul point d'attente. Mais je doute que l'une des solutions postfix proposées soit évidemment meilleure que toutes les autres.

Juste mes deux cents (je ne suis personne, mais je suis la discussion depuis assez longtemps). Ma solution préférée serait la version postfixe @await . Peut-être pourriez-vous envisager un postfix !await , comme une nouvelle syntaxe de macro postfix?

Exemple:

let mut res: InboxResponse = client.get(inbox_url)
    .headers(inbox_headers)
    .send()!await?
    .error_for_status()?
    .json()!await?;

Après quelques itérations de langage, être capable d'implémenter nos propres macros postfix serait génial.

... toutes les nouvelles propositions de sygils

Rust est déjà lourd de syntaxe / sygil, nous avons le mot clé await réservé, stuff@await (ou tout autre sygil) semble bizarre / moche (subjectif, je sais), et c'est juste une syntaxe ad-hoc qui ne s'intègre à rien d'autre dans la langue qui est un gros drapeau rouge.

Je regarde comment Go met en œuvre
... <- ... proposition

@ I60R : Go a une terrible syntaxe pleine de solutions ad hoc, et est totalement impératif, contrairement à Rust. Cette proposition est encore une fois lourde de syntaxe / syntaxe et totalement ad hoc juste pour cette fonctionnalité particulière.

@ I60R : Go a une syntaxe terrible

Évitons de dénigrer d'autres langues ici. "X a une syntaxe terrible" ne conduit pas à l'illumination et au consensus.

En tant qu'utilisateur Python / JavaScript / Rust et étudiant en informatique, je préfère personnellement que le préfixe await + f.await() soit à la fois dans le langage.

1. Python et JavaScript ont le préfixe await . Je m'attendrais à voir apparaître await au début. Si je dois lire en profondeur pour me rendre compte que c'est du code asynchrone, je me sens très mal à l'aise. Avec la capacité WASM de Rust, il pourrait attirer de nombreux développeurs JS. Je pense que la familiarité et le confort sont vraiment importants, étant donné que Rust a déjà beaucoup d'autres nouveaux concepts.

2. Postfix await semble pratique dans les paramètres de chaînage. Cependant, je n'aime pas les solutions comme .await , @await , f await parce qu'elles ressemblent à une solution ad hoc à la syntaxe await alors qu'il est logique de penser .await() comme appel d'une méthode sur le future .

Rust est déjà un départ de javascript et await n'a rien à voir avec l'appel de fonction (c'est-à-dire que la fonctionnalité ne peut pas être émulée via une fonction) en utilisant des fonctions pour désigner wait rend déroutant les premiers temporisateurs introduits dans async-await. Par conséquent, je pense que la syntaxe devrait être différente.

Je me suis convaincu que .await() est probablement beaucoup plus souhaitable que .await , bien que le reste de cet article couvre un peu cette position.

La raison en est que await!(fut) doit _consumer fut par valeur_. Faire ressembler à un accès à un champ est _bad_, car cela n'a pas la connotation de se déplacer comme le fait un mot-clé de préfixe, ou le potentiel de se déplacer comme une macro ou un appel de méthode.

Fait intéressant, la syntaxe de la méthode par mot-clé la fait presque ressembler à une conception d' attente implicite . Malheureusement, "Explicit Async, Implicit Await" n'est pas possible pour Rust (donc _veuillez_ ne pas le relancer sur ce fil) car nous voulons que async fn() -> T soit utilisé de la même manière que fn() -> Future<T> , plutôt que d'activer un comportement «d'attente implicite».

Le fait qu'une syntaxe .await() _ ressemble_ à un système d'attente implicite (comme Kotlin utilise) pourrait être un détracteur, et donnerait presque l'impression d'un "Async implicite, Attente implicite" en raison de la magie autour du non- vraiment-une-méthode-call .await() syntaxe. Pourriez-vous utiliser cela comme await(fut) avec UFCS? Serait-ce Future::await(fut) pour l'UFCS? Toute syntaxe qui ressemble à une autre dimension du langage pose des problèmes à moins qu'elle ne puisse être quelque peu unifiée avec elle au moins syntaxiquement, même si ce n'est pas fonctionnellement.

Je reste sceptique si les avantages de toute solution de postfix _individuelle_ l'emportent sur les inconvénients de cette même solution, bien que le concept d'une solution de postfix soit plus souhaitable que celui d'un préfixe en général.

Je suis un peu surpris que ce fil soit plein de suggestions qui semblent être faites parce qu'elles sont possibles - et non parce qu'elles semblent apporter des avantages significatifs par rapport aux suggestions initiales.
Pouvons-nous arrêter de parler de $ , # , @ , ! , ~ etc, sans évoquer un argument significatif ce qui ne va pas avec await , qui est bien compris et a fait ses preuves dans divers autres langages de programmation?

Je pense que le post de https://github.com/rust-lang/rust/issues/57640#issuecomment -455361619 a déjà répertorié toutes les bonnes options.

De ceux:

• Délimiteurs obligatoires Les délimiteurs semblent bien, au moins il est évident quelle est la priorité et nous pouvons lire d'autres codes sans plus de clarté. Et taper deux parenthèses n'est pas si mal. Le seul inconvénient est peut-être que cela ressemble à un appel de fonction, même s'il s'agit d'une opération de flux de contrôle différente.
• Une priorité utile pourrait être l'option préférable. Cela semble être la voie empruntée par la plupart des autres langues, c'est donc familier et éprouvé.
• Personnellement, je pense que le mot-clé postfix avec espace blanc semble étrange avec plusieurs attentes dans une seule déclaration:
  client.get("url").send() await?.json()? . Cet espace entre les deux ne semble pas à sa place. Avec les parenthèses, cela aurait un peu plus de sens pour moi: (client.get("url").send() await)?.json()?
  Mais je trouve le flux de contrôle encore plus difficile à suivre qu'avec la variante de préfixe.
• Je n'aime pas le champ postfix. await effectue une opération très complexe - Rust n'a pas de propriétés calculables et l'accès aux champs est par ailleurs une opération très simple. Cela semble donc donner une fausse impression sur la complexité de cette opération.
• La méthode Postfix pourrait être correcte. Cela pourrait encourager certaines personnes à écrire de très longues déclarations avec plusieurs attentes, ce qui pourrait masquer davantage les points de rendement. Cela donne également à nouveau l'apparence d'un appel de méthode, même si c'est quelque chose de différent.

Pour ces raisons, je préfère la "préséance utile" suivie de "délimiteurs obligatoires"

Go a une terrible syntaxe pleine de solutions ad hoc, et est totalement impératif, contrairement à Rust. Cette proposition est encore une fois lourde de syntaxe / syntaxe et totalement ad hoc juste pour cette fonctionnalité particulière.

@dpc , si vous lisez complètement la proposition <-- , vous verrez que cette syntaxe n'est inspirée que par Go, mais est assez différente et utilisable dans un contexte impératif et de chaînage de fonctions. Je ne vois pas non plus en quoi la syntaxe await n'est pas une solution ad hoc, pour moi c'est beaucoup plus spécifique et beaucoup plus maladroit que <-- . C'est similaire d'avoir deref reference / reference.deref / etc au lieu de *reference , ou d'avoir try result / result.try / etc au lieu de result? . Je ne vois aucun avantage à utiliser le mot-clé await autre que la familiarité avec JS / Python / etc qui de toute façon devrait être moins important que d'avoir une syntaxe cohérente et composable. Et je ne vois aucun inconvénient à avoir <-- sigil autre que ce n'est pas un await qui de toute façon n'est pas aussi simple qu'un anglais simple et les utilisateurs devraient comprendre ce qu'il fait en premier.

Edit: cela pourrait également être une bonne réponse au post @ Matthias247 , car il fournit des arguments contre await et propose une alternative possible non affectée par les mêmes problèmes

C'est vraiment intéressant pour moi, à travers, de lire la critique contre la syntaxe <-- , sans arguments qui font appel à des raisons historiques et préjugées.

Mentionnons les spécificités réelles de la priorité:

Le diagramme de préséance tel qu'il se présente aujourd'hui :

Opérateur / Expression | Associativité
- | -
Chemins |
Appels de méthode |
Expressions de champ | de gauche à droite
Appels de fonctions, indexation de tableaux |
? |
Unaire - * ! & &mut |
as | de gauche à droite
* / % | de gauche à droite
+ - | de gauche à droite
<< >> | de gauche à droite
& | de gauche à droite
^ | de gauche à droite
\| | de gauche à droite
== != < > <= >= | Exiger des parenthèses
&& | de gauche à droite
\|\| | de gauche à droite
.. ..= | Exiger des parenthèses
= += -= *= /= %= &= \|= ^= <<= >>= | de droite à gauche
return break fermetures |

La précédence utile place await avant ? afin qu'il se lie plus étroitement que ? . Un ? dans la chaîne lie donc un `await à tout ce qui le précède.

let res = await client
    .get("url")
    .send()?
    .json();

Oui, avec une priorité utile, cela "fonctionne juste". Savez-vous ce que cela fait en un coup d'œil? Est-ce que c'est du mauvais style (probablement)? Si tel est le cas, rustfmt peut-il résoudre ce problème automatiquement?

Une priorité évidente place await _quelque part_ en dessous de ? . Je ne sais pas exactement où, bien que ces détails n'aient probablement pas trop d'importance.

let res = await? (client
    .get("url")
    .send())
    .json();

Savez-vous ce que cela fait en un coup d'œil? Rustfmt peut-il le mettre dans un style utile qui ne gaspille pas automatiquement l'espace vertical et horizontal?

Où se situeraient les mots-clés avec suffixe? Probablement une méthode de mot-clé avec des appels de méthode et un champ de mot-clé avec des expressions de champ, mais je ne sais pas comment les autres doivent se lier. Quelles options conduisent aux configurations les moins possibles où le await reçoit un "argument" surprenant?

Pour cette comparaison, je soupçonne que les "délimiteurs obligatoires" (ce que j'ai appelé la fonction mot-clé dans le résumé ) l'emportent facilement, car cela équivaudrait à un appel de fonction normal.

@ CAD97 Pour être clair, rappelez-vous que .json() est aussi un avenir (au moins en reqwests ).

let res = await await client
    .get("url")
    .send()?
    .json()?;

let res = await? await? (client
    .get("url")
    .send())
    .json();

Plus je joue avec la conversion d'expressions de rouille complexes (même celles qui n'ont besoin que d'une attente, cependant, notez que dans ma future base de code de 20000+, presque chaque expression asynchrone est une attente, directement suivie d'une autre attente), plus je n'aime pas préfixe pour Rust.

C'est _all_ à cause de l'opérateur ? . Aucun autre langage n'a un opérateur de flux de contrôle postfixe _et_ await qui sont essentiellement toujours appariés dans du code réel.

Ma préférence reste le champ postfix . En tant qu'opérateur de contrôle postfix, je pense qu'il a besoin du regroupement visuel serré que future.await fournit sur future await . Et comparé à .await()? , je préfère à quoi .await? ressemble _weird_ donc ce sera _noté_ et les utilisateurs ne supposeront pas que c'est une fonction simple (et ne demanderont donc pas pourquoi UFCS ne fonctionne pas) .

Comme un autre point de données en faveur de postfix, lorsque celui-ci est stabilisé, un rustfix pour passer de await!(...) à ce que nous décidons serait très apprécié. Je ne vois pas comment quoi que ce soit d'autre que la syntaxe de postfix pourrait être traduit sans ambiguïté sans envelopper inutilement des éléments dans ( ... ) .

Je pense que nous devrions d'abord répondre à la question "voulons-nous encourager l'utilisation de await dans des contextes de chaînage?". Je crois que la réponse la plus répandue est "oui", donc cela devient un argument fort pour les variantes de suffixe. Alors que await!(..) sera le plus simple à ajouter, je pense que nous ne devrions pas répéter l'histoire try!(..) . Aussi, personnellement, je ne suis pas d'accord avec l'argument selon lequel "le chaînage cache une opération potentiellement coûteuse", nous avons déjà beaucoup de méthodes de chaînage qui peuvent être très lourdes, donc l'enchaînement n'implique pas de paresse.

Alors que le mot-clé préfixe await sera le plus familier pour les utilisateurs venant d'autres langues, je ne pense pas que nous devrions prendre notre décision en nous basant sur celui-ci et nous devrions plutôt nous concentrer sur le long terme, c'est-à-dire la convivialité, la commodité et la lisibilité. . @withoutboats a parlé de "budget de familiarité", mais je crois fermement que nous ne devrions pas introduire de solutions sous-optimales juste pour des raisons de familiarité.

Maintenant, nous ne voulons probablement pas deux façons de faire la même chose, nous ne devrions donc pas introduire à la fois des variantes de suffixe et de préfixe. Disons donc que nous avons réduit nos options aux variantes de postfix.

Commençons par fut await , je n'aime pas du tout cette variante, car elle dérangera sérieusement la façon dont les humains analysent le code et ce sera une source constante de confusion lors de la lecture du code. (N'oubliez pas que le code est principalement destiné à la lecture)

Suivant fut.await , fut.await() et fut.await!() . Je pense que la variante la plus cohérente et la moins déroutante sera la macro postfix. Je ne pense pas que cela vaille la peine d'introduire une nouvelle entité «fonction de mot-clé» ou «méthode de mot-clé» juste pour enregistrer quelques caractères.

Enfin, les variantes basées sur le sigil: fut@await et fut@ . Je n'aime pas la variante fut@await , si nous introduisons le sceau pourquoi s'embêter avec la partie await ? Avons-nous des plans pour de futures extensions fut@something ? Sinon, cela semble tout simplement redondant. Donc j'aime la variante fut@ , elle résout les problèmes de précédence, le code devient facile à comprendre, à écrire et à lire. Les problèmes de visibilité peuvent être résolus par la mise en évidence du code. Il ne sera pas difficile d'expliquer cette fonctionnalité par "@ for await". Bien sûr, le plus gros inconvénient est que nous paierons cette fonctionnalité avec le "budget sigil" très limité, mais compte tenu de l'importance de la fonctionnalité et de la fréquence à laquelle elle sera utilisée dans les bases de code asynchrones, je pense que cela vaudra la peine à long terme . Et bien sûr, nous pouvons établir certains parallèles avec ? . (Bien que nous devrons être préparés pour les blagues Perl des critiques de Rust)

En conclusion: à mon avis, si nous sommes prêts à alourdir le "budget sigil", nous devrions opter pour fut@ , et sinon avec fut.await!() .

En parlant de familiarité, je ne pense pas que nous devrions trop nous soucier de la familiarité avec JS / Python / C #, car Rust est dans un créneau différent et a déjà un aspect différent dans de nombreux domaines. Fournir une syntaxe similaire à ces langages est un objectif à court terme et à faible récompense. Personne ne sélectionnera Rust uniquement pour utiliser un mot-clé familier lorsque sous le capot, cela fonctionne complètement différent.

Mais la familiarité avec Go compte, car Rust est dans un créneau similaire et même par philosophie, il est plus proche de Go que d'autres langues. Et malgré toute la haine préjugée, l'un des points forts des deux est qu'ils ne copient pas aveuglément des fonctionnalités, mais implémentent plutôt des solutions qui ont vraiment raison.

IMO, dans ce sens, la syntaxe <-- est la plus forte ici

Avec tout cela, rappelons-nous que les expressions Rust peuvent résulter en plusieurs méthodes chaînées. La plupart des langues ont tendance à ne pas faire cela.

Je voudrais rappeler l'expérience de l'équipe de développement C #:

La principale considération par rapport à la syntaxe C # est la priorité des opérateurs wait foo?

C'est quelque chose que je pense pouvoir commenter. Nous avons beaucoup pensé à la préséance avec «wait» et nous avons essayé de nombreuses formes avant de définir la forme que nous voulions. L'une des choses fondamentales que nous avons trouvées était que pour nous, et les clients (internes et externes) qui voulaient utiliser cette fonctionnalité, il était rarement le cas que les gens voulaient vraiment `` enchaîner '' quoi que ce soit après leur appel asynchrone.

La tendance des gens à vouloir «continuer» avec «attendre» à l'intérieur d'une expr était rare. Nous voyons parfois des choses comme (await expr) .M (), mais celles-ci semblent moins courantes et moins souhaitables que le nombre de personnes qui font wait expr.M ().

et

C'est aussi pourquoi nous n'avons utilisé aucune forme «implicite» pour «attendre». Dans la pratique, c'était quelque chose à laquelle les gens voulaient réfléchir très clairement, et qu'ils voulaient au centre de leur code afin d'y prêter attention. Chose intéressante, même des années plus tard, cette tendance est restée. c'est-à-dire que parfois nous regrettons plusieurs années plus tard que quelque chose soit excessivement verbeux. Certaines fonctionnalités sont bonnes de cette manière dès le début, mais une fois que les gens sont à l'aise avec cela, elles sont mieux adaptées à quelque chose de plus terser. Cela n'a pas été le cas avec «attendre». Les gens semblent toujours aimer la nature lourde de ce mot-clé et la priorité que nous avons choisie.

Est un bon point contre sigil au lieu d'un mot (clé) dédié.

https://github.com/rust-lang/rust/issues/50547#issuecomment -388939886

Vous devriez vraiment écouter les gars avec des millions d'utilisateurs.

Donc vous ne voulez rien enchaîner, vous voulez juste avoir plusieurs await , et mon expérience est la même. J'ai écrit du code async/await pendant plus de 6 ans, et je n'ai jamais voulu une telle fonctionnalité. La syntaxe de Postfix semble vraiment étrangère et est considérée comme résolvant une situation qui ne se produira probablement jamais. Async appel

La tendance des gens à vouloir «continuer» avec «attendre» à l'intérieur d'une expr était rare. Nous voyons parfois des choses comme (await expr) .M (), mais celles-ci semblent moins courantes et moins souhaitables que le nombre de personnes qui font wait expr.M ().

Cela ressemble à une analyse a posteriori. Peut-être qu'une des raisons pour lesquelles ils ne continuent pas est qu'il est extrêmement gênant de le faire dans la syntaxe du préfixe (comparable à ne pas vouloir plusieurs fois try! dans une instruction car cela reste lisible via l'opérateur ? ). Ce qui précède considère principalement (pour autant que je sache) la préséance, pas la position. Et je voudrais vous rappeler que C # n'est pas Rust, et que les membres de trait peuvent changer un peu le désir d'appeler des méthodes sur les résultats.

@ I60R ,

1. Je pense que la familiarité est importante. Rust est une langue relativement nouvelle et les gens migreront à partir d'autres langues et si Rust semble familier, il leur sera plus facile de prendre la décision de choisir Rust.
2. Je ne suis pas très amusant des méthodes de chaînage - il est beaucoup plus difficile de déboguer de longues chaînes et je pense que le chaînage ne fait que compliquer la lisibilité du code et ne peut être autorisé qu'en option supplémentaire (comme les macros .await!() ). La forme du préfixe obligera les développeurs à extraire le code dans des méthodes au lieu de le chaîner, comme:

let resp = await client.get("http://api")?;
let body: MyResponse = await resp.into_json()?;

en quelque chose comme ça:

let body: MyResponse = await client.get_json("http://api")?;

Cela ressemble à une analyse a posteriori. Peut-être qu'une des raisons pour lesquelles ils ne continuent pas est qu'il est extrêmement difficile de le faire dans la syntaxe de préfixe. Ce qui précède ne considère que la priorité, pas la position. Et je voudrais vous rappeler que C # n'est pas Rust, et que les membres de trait peuvent changer un peu le désir d'appeler des méthodes sur les résultats.

Non, il s'agit d'expérimentations internes en équipe C # lorsqu'elle avait à la fois des formes préfixe / suffixe / implicite. Et je parle de mon expérience qui n'est pas seulement une habitude où je ne peux pas voir les pros du formulaire postfix.

@mehcode Votre exemple ne me motive pas. reqwest décide consciemment de faire en sorte que le cycle initial de demande / réponse et le traitement ultérieur de la réponse (flux de corps) séparent les processus concurrents, ils devraient donc être attendus deux fois, comme le montre @andreytkachenko .

reqwest pourrait totalement exposer les API suivantes:

let res = await client
    .get("url")
    .json()
    .send();

ou

let res = await client
    .get("url")
    .send()
    .json();

(Ce dernier étant un sucre simple de plus de and_then ).

Je trouve troublant que beaucoup d'exemples de postfix ici utilisent cette chaîne comme exemple, car reqwest s et hyper s est la meilleure décision api de garder ces choses séparées.

Je crois honnêtement que la plupart des exemples de postfix attendent ici devraient être réécrits en utilisant des combinateurs (et du sucre si nécessaire) ou être conservés des opérations similaires et attendus plusieurs fois.

@andreytkachenko

La forme du préfixe obligera les développeurs à extraire le code dans des méthodes au lieu de le chaîner, comme:

Est-ce une bonne ou une mauvaise chose? Pour les cas où il y a N méthodes, chacune pouvant entraîner M suivis, le développeur est censé fournir des méthodes N * M ? Personnellement, j'aime les solutions composables, même si elles sont un peu plus longues.

en quelque chose comme ça:

let body: MyResponse = await client.get_json("http://api")?;

let body: MyResponse = client.get("http://api").await?.into_json().await?;

@Pzixel

Je ne pense pas qu'en C # vous obtiendriez autant de code chaîné / fonctionnel que vous le feriez en Rust. Ou ai-je tort? Cela rend les expériences des développeurs / utilisateurs C # intéressantes, mais pas nécessairement applicables à Rust. Je souhaite que nous puissions contraster avec Ocaml ou Haskell.

Je pense que la cause fondamentale du désaccord est que certains d'entre nous apprécient le style impératif, et d'autres fonctionnels. Et c'est tout. Rust prend en charge les deux, et les deux côtés du débat veulent qu'async s'adapte bien à la manière dont ils écrivent généralement le code.

@dpc

Je ne pense pas qu'en C # vous obtiendriez autant de code chaîné / fonctionnel que vous le feriez en Rust. Ou ai-je tort? Cela rend les expériences des développeurs / utilisateurs C # intéressantes, mais pas nécessairement applicables à Rust. Je souhaite que nous puissions contraster avec Ocaml ou Haskell.

LINQ et le style fonctionnel sont très populaires en C #.

@dpc ,
si vous êtes sur la lisibilité - je pense que le code est explicite - comme meilleur, et mon expérience dit que si les noms des méthodes / fonctions sont bien auto-descriptifs, il n'est pas nécessaire de faire les suivis.

si vous avez des frais généraux - Le compilateur Rust est plutôt intelligent pour les incorporer (de toute façon, nous avons toujours #[inline] ).

@dpc

let body: MyResponse = client.get("http://api").await?.into_json().await?;

Mon sentiment est que cela répète fondamentalement le problème de l'API future: cela facilite le chaînage, mais le type de cette chaîne devient beaucoup plus difficile à pénétrer et à déboguer.

Ce même argument ne s'applique-t-il pas au? opérateur cependant? Cela permet plus de chaînage et rend ainsi le débogage plus difficile. Mais pourquoi avons-nous choisi? essayez! puis? Et pourquoi Rust préfère-t-il les API avec un modèle de générateur? Rust a donc déjà fait un tas de choix favorisant le chaînage dans les API. Et oui, cela peut rendre le débogage plus difficile, mais cela ne devrait-il pas se produire au niveau de la charpie - peut-être une nouvelle charpie pour clippy pour les chaînes trop grandes? Je dois encore voir une motivation suffisante quant à la façon dont l'attente est différente ici.

Est-ce une bonne ou une mauvaise chose? Pour les cas où il y a N méthodes, chacune pouvant entraîner M suivis, le développeur est censé fournir des méthodes N * M ? Personnellement, j'aime les solutions composables, même si elles sont un peu plus longues.

N et M ne sont pas nécessairement grands, et tous ne peuvent pas non plus être intéressants / utiles à extraire.

@andreytkachenko ,

1. Je ne suis pas d'accord, la familiarité est surfaite ici. Lors de la migration à partir d'un autre langage, les premiers utilisateurs rechercheraient la possibilité de faire async-await programmation de style

2. L'incapacité de déboguer de longues chaînes est une limitation des débogueurs et non du style de code. À propos de la lisibilité, je pense que cela dépend, et l'application d'un style impératif est ici inutilement restrictive. Si les appels de fonction async sont toujours des appels de fonction, il est surprenant de ne pas prendre en charge le chaînage. Et de toute façon, <-- est un opérateur de préfixe avec la possibilité de l'utiliser dans les chaînes de fonctions comme option supplémentaire, comme vous l'avez dit

@skade D'accord.

Tous les exemples avec de longues chaînes d'attente sont une odeur de code. Ils pourraient être résolus beaucoup plus élégamment avec des combinateurs ou des API mises à jour, plutôt que de créer ces machines à états génératrices de spaghetti sous le capot. La syntaxe abrégée extrême est une recette pour un débogage encore plus difficile que les futurs actuels.

Je suis toujours un fan des deux préfixe mot - clé await et macro await!(...) / .await!() , en combinaison avec async et #[async] générateur fonctionne , comme décrit dans mon commentaire ici .

Si tout se passe correctement, une seule macro pourrait probablement être créée pour await! pour gérer à la fois le préfixe et le suffixe, et le mot clé await ne serait qu'un mot clé à l'intérieur des fonctions async .

@skade ,
Pour moi, un gros inconvénient de l'utilisation de combinateurs sur future est qu'ils masqueront les appels de fonction async et qu'il serait impossible de les distinguer des fonctions régulières. Je veux voir tous les points suspensibles car il est très probable qu'ils soient utilisés à l'intérieur de chaînes de style constructeur.

@ I60R débogage de longues chaînes d'appels n'est absolument pas un problème de débogage, car le problème avec l'écriture de ces chaînes est d'obtenir une inférence de type correcte. Étant donné que beaucoup de ces méthodes prennent des paramètres génériques et distribuent des paramètres génériques, potentiellement liés à une fermeture, est un problème grave.

Je ne sais pas si rendre tous les points de suspension visibles est un objectif de la fonctionnalité. C'est aux exécutants de décider. Et c'est tout à fait possible avec toutes les versions proposées de la syntaxe await .

@novacrazy bon point, maintenant que vous le mentionnez, en tant qu'ancien javascripter, je n'utilise JAMAIS de chaînes d'attente, j'ai toujours utilisé ensuite des blocs

Je suppose que ça ressemblerait à quelque chose comme

let result = (await doSomethingAsync()
          .then(|result| {
                     match result {
                          Ok(v) => doSomethingAsyncWithFirstResponse(v)
                          Err(e) => Future.Resolve(Err(e))
                      }
            }).then(|result| {
                  Ok(result.unwrap())
            })).unwrap();

dont je ne sais même pas si c'est possible, j'ai besoin de chercher sur l'avenir à Rust

@richardanaya c'est tout à fait possible (syntaxe différente).

Comme la boîte impl:

impl<T> Box<T> {
    #[inline]
    pub fn new(x: T) -> Box<T> {
        box x
    }
    ...
}

Nous pouvons entrer un nouveau mot-clé await et le trait Await avec comme ceci impl:

impl<T> Await for T {
    #[inline]
    pub fn await(self) -> T {
        await self
    }
    ...
}

Et utilisez await comme méthode et comme mot-clé:

let result = await foo();
first().await()?.second().await()?;

@richardanaya D'accord. J'ai été parmi les premiers développeurs à adopter async / await pour mes trucs webdev il y a plusieurs années, et le vrai pouvoir est venu de combiner async / await avec les Promises / Futures existantes. De plus, même votre exemple pourrait probablement être simplifié comme suit:

let result = await doSomethingAsync()
                  .and_then(doSomethingAsyncWithFirstResponse);

let value = result.unwrap();

Si vous avez imbriqué des contrats à terme ou des résultats de contrats à terme ou des contrats à terme de résultats, le combinateur .flatten() peut encore simplifier considérablement cela. Ce serait une mauvaise forme de déballer et d'attendre sur chacun d'eux manuellement.

@XX C'est redondant et invalide. await n'existe que dans les fonctions async , et ne peut fonctionner que sur les types qui implémentent Future / IntoFuture toute façon, il n'y a donc pas besoin d'un nouveau trait.

@novacrazy , @richardanaya

ils pourraient être résolus beaucoup plus élégamment avec des combinateurs ou des API mises à jour, plutôt que de créer ces machines à états spaghetti génératrices sous le capot. La syntaxe abrégée extrême est une recette pour un débogage encore plus difficile que les futurs actuels.

@novacrazy bon point, maintenant que vous le mentionnez, en tant qu'ancien javascripter, je n'utilise JAMAIS de chaînes d'attente, j'ai toujours utilisé ensuite des blocs

Les combinateurs ont des propriétés et des pouvoirs totalement différents dans Rusts async / wait, par exemple en ce qui concerne l'emprunt à travers les points de rendement. Vous ne pouvez pas écrire en toute sécurité des combinateurs qui ont les mêmes capacités que les blocs asynchrones. Laissons la discussion sur les combinateurs en dehors de ce fil, car elle n'est pas utile.

@ I60R

Pour moi, un gros inconvénient de l'utilisation de combinateurs à l'avenir est qu'ils masqueront les appels de fonctions asynchrones et qu'il serait impossible de les distinguer des fonctions régulières. Je veux voir tous les points suspensibles car il est très probable qu'ils soient utilisés à l'intérieur de chaînes de style constructeur.

Vous ne pouvez pas masquer les points de suspension. La seule chose que permettent les combinateurs est de créer d'autres futurs. À un moment donné, ceux-ci doivent être attendus.

Gardez à l'esprit que C # n'a pas le problème où la plupart du code utilisant un préfixe await le combinera avec l'opérateur postfix (déjà existant) ? . En particulier, les questions de préséance et la maladresse générale d'avoir deux «décorateurs» similaires apparaissent sur les côtés opposés d'une expression.

@ Matthias247 Si vous avez besoin d'emprunter des données, bien sûr, n'hésitez pas à utiliser plusieurs instructions await . Cependant, souvent, vous avez simplement besoin de déplacer des données, et les combinateurs sont parfaitement valables pour cela et ont le potentiel de compiler vers un code plus efficace. Parfois optimisé complètement.

Encore une fois, le vrai pouvoir est de combiner les choses ensemble. Il n'y a pas une seule bonne façon de faire les choses aussi compliquées que celle-ci. C'est en partie pourquoi je considère que tout ce bikeshedding syntaxique est exactement cela s'il ne va pas aider les nouveaux utilisateurs venant d'un autre langage et aider à créer un code maintenable, performant et lisible . 80% du temps, je doute que je toucherai même async / await quelle que soit la syntaxe, juste pour fournir les API les plus stables et les plus performantes en utilisant des futurs simples.

À cet égard, le mot-clé préfixe await et / ou la macro mixte await!(...) / .await!() sont les options les plus lisibles, les plus familières et les plus faciles à déboguer.

@andreytkachenko

J'ai vu votre message et je suis tout à fait d'accord, en fait, maintenant que je réfléchis à la «familiarité», je pense qu'il y a deux types de familiarité:

1. Faire ressembler la syntaxe d’attente à des langages similaires qui utilisent beaucoup d’attente. Javascript est assez gros ici, et très pertinent pour nos capacités WASM en tant que communauté.

2. Le deuxième type de familiarité est de rendre le code familier aux développeurs qui ne travaillent qu'avec du code synchrone. Je pense que le plus grand aspect de wait est de rendre le code asynchrone LOOK synchrone. C'est en fait une chose que javascript fait vraiment mal, c'est qu'il est normalisé de longues chaînes qui semblent totalement étrangères aux développeurs principalement synchrones.

Une chose que j'offrirais de mes jours javascript async, ce qui m'a été beaucoup plus utile en tant que développeur rétrospectivement était la possibilité de regrouper les promesses / futurs. Promise.all (p1 (), p2 ()) pour que je puisse facilement mettre en parallèle le travail. Le chaînage d'alors () n'était toujours qu'un écho de la promesse passée de Javascript, mais à peu près archaïque et inutile maintenant que j'y pense.

J'offrirais peut-être cette idée d'attendre. "Essayez de rendre les différences entre le code async et le code de synchronisation aussi minimes que possible"

@novacrazy La fonction async renvoie un type impl Future , non? Qu'est-ce qui nous empêche d'ajouter la méthode await au trait Future ? Comme ça:

pub fn await(self) -> Self::Output {
    await self
}
...

@XX Si je comprends bien, les fonctions async de Rust sont transformées en machines à états à l'aide de générateurs. Cet article est une bonne explication. Donc await besoin d' une fonction async pour travailler, afin que le compilateur puisse les transformer correctement tous les deux. await ne peut pas fonctionner sans la partie async .

Future a un wait méthode, qui est similaire à ce que vous suggérez, mais bloque le thread courant.

@skade ,

Mais comment le style de code peut-il affecter l'inférence de type? Je ne vois pas de différence dans le même code qui est écrit dans un style enchaîné et impératif. Les types doivent être exactement les mêmes. Si le débogueur n'est pas capable de les comprendre, c'est certainement un problème dans le débogueur, pas dans le code.

@skade , @ Matthias247 , @XX

Avec les combinateurs, vous aurez exactement un point suspendu marqué au début de la chaîne de fonctions. Tous les autres seraient implicites à l'intérieur. C'est exactement le même problème qu'avec la prise de mut implicite, ce qui était personnellement pour moi l'un des plus gros points de confusion de Rust. Certaines API renverraient des futures tandis que d'autres renverraient des résultats de futures - je ne veux pas de cela. Les points de suspension devraient être explicites si possible et une syntaxe correctement composable encouragerait

@ I60R let liaisons sont des points de jonction pour l'inférence de type et aident à signaler les erreurs.

@novacrazy

Attendre a donc besoin d'une fonction asynchrone pour fonctionner

Cela peut-il être exprimé en type de retour? Par exemple, que le type de retour est impl Future + Async , au lieu de impl Future .

@skade J'ai toujours pensé que . dans la syntaxe des appels de méthode sert exactement le même objectif

@dpc

Je ne pense pas qu'en C # vous obtiendriez autant de code chaîné / fonctionnel que vous le feriez en Rust. Ou ai-je tort? Cela rend les expériences des développeurs / utilisateurs C # intéressantes, mais pas nécessairement applicables à Rust. Je souhaite que nous puissions contraster avec Ocaml ou Haskell.

vous obtenez autant que Rust. Regardez n'importe quel code LINQ et vous le verrez.

Le code asynchrone typique ressemble à ceci:

async Task<List<IGroping<int, PageMetadata>>> GetPageMetadata(string url, DbSet<Page> pages)
{
    using(var client = new HttpClient())
    using(var r = await client.GetAsync(new Uri(url)))
    {
        var content = await r.Content.ReadAsStringAsync();
                return await pages
                   .Where(x => x.Content == content)
                   .Select(x => x.Metadata)
                   .GroupBy(x => x.Id)
                   .ToListAsync();
    }
}

Ou, plus général

let a = await!(service_a);
let b = await!(some_method_on(a, some, other, params));
let c = await!(combine(somehow, a, b));

Vous n'enchaînez pas les appels, vous l'assignez à une variable et vous l'utilisez d'une manière ou d'une autre. C'est particulièrement vrai lorsque vous traitez avec un emprunteur.

Je peux convenir que vous pouvez enchaîner les futurs dans une seule situation. Lorsque vous souhaitez gérer une erreur pouvant survenir lors de l'appel. par exemple let a = await!(service_a)? . C'est la seule situation où l'alternative à postfix est meilleure. Je pouvais voir que cela profiterait ici, mais je ne pense pas que cela dépasse tous les inconvénients.

Une autre raison: qu'en est-il de impl Add for MyFuture { ... } et let a = await a + b; ?

Je voudrais rappeler la RFC d'assignation de type généralisée dans le contexte du mot-clé d'attente de postfix. Cela permettrait le code suivant:

let x = (0..10)
    .map(some_computation)
    .collect() : Result<Vec<_>, _>
    .unwrap()
    .map(other_computation) : Vec<usize>
    .into() : Rc<[_]>;

Tout à fait comme le mot-clé d'attente de suffixe:

let foo = alpha() await?
    .beta await
    .some_other_stuff() await?
    .even_more_stuff() await
    .stuff_and_stuff();

Avec les mêmes inconvénients lorsqu'il est mal formaté:

foo.iter().map(|x| x.bar()).collect(): Vec<_>.as_ref()

client.get("https://my_api").send() await.unwrap().json() await.unwrap()

Je pense que si nous avalons la pilule du RFC Type Ascription, nous devrions avaler fut await pour plus de cohérence.

BTW, saviez-vous que c'est une syntaxe valide:

fn main() {
    println
    !("Hello, World!");
}

Pourtant, je n'ai vu aucune occurrence de cela dans le code réel.

Permettez-moi de m'écarter un peu. Je pense que nous devrions donner des macros postfixes, comme suggéré par @BenoitZugmeyer , une autre pensée. Celles-ci pourraient être faites soit comme expr!macro ou comme expr@macro , ou peut-être même expr.macro!() . Je pense que la première option serait préférable. Je ne suis pas sûr que ce soit une bonne idée, mais si nous voulons extraire un concept général et non une solution ad-hoc tout en attendant un postfix , nous devrions au moins penser aux macros postfix comme solution potentielle.

Gardez à l'esprit que même si nous devions faire de await une macro de suffixe, ce serait toujours magique (comme compile_error! ). Cependant, @jplatte et d'autres ont déjà établi que ce n'était pas un problème.

Comment je procéderais si nous suivions cette voie, j'établirais d'abord exactement comment les macros postfix fonctionneraient, puis n'autoriserais que await comme macro postfix magique, puis autoriserais plus tard les macros postfix définies.

Lexing

En ce qui concerne le lexing / l'analyse, cela pourrait être un problème. Si nous regardons expr!macro , le compilateur pourrait penser qu'il y a une macro appelée expr! et puis il y a quelques lettres invalides macro après cela. Cependant, expr!macro devrait être possible de lex par un lookahead de un, et quelque chose devient une macro de suffixe quand il y a un expr suivi d'un ! , directement suivi de identifier . Je ne suis pas un développeur de langage et je ne suis pas sûr que cela rende le lexing trop complexe. Je suppose simplement que les macros postfix peuvent prendre la forme de expr!macro .

Les macros postfix seraient-elles utiles?

Sur le dessus de ma tête, j'ai proposé ces autres cas d'utilisation pour les macros postfix. Je ne pense pas que tous puissent être implémentés par des macros personnalisées, donc je ne suis pas sûr que cette liste soit très utile.

• stream!await_all : pour les streams en attente
• option!or_continue : quand option vaut None, continuez la boucle
• monad!bind : pour faire =<< sans le lier à un nom

stream!await_all

Cela nous permet non seulement d'attendre des futurs, mais aussi des flux.

event_stream("ws://some.stock.exchange/usd2eur")
    .and_then(|exchange_response| {
        let exchange_rate = exchange_response.json()?;
        stream::once(UpdateTickerAction::new(exchange_rate.value))
    })

serait équivalent à (dans un bloc async -stream-esque):

let exchange_rate = event_stream("ws://some.stock.exchange/usd2eur")
    !await_all
    .json()?;

UpdateTickerAction::new(exchange_rate.value)

option!or_continue

Cela nous permet de dérouler une option, et si c'est None , continuez la boucle.

loop {
    let event = match engine.event() {
        Some(event) => event,
        None => continue,
    }
    let button = match event.button() {
        Some(button) => button,
        None => continue,
    }
    handle_button_pressed(button);
}

serait équivalent à:

loop {
    handle_button_pressed(
        engine.event()!or_continue
            .button()!or_continue
    );
}

monad!bind

Celui-ci nous permettrait d'obtenir des monades d'une manière assez rustique (c'est-à-dire centrée sur l'expression). Rust n'a pas encore quelque chose comme des monades et je ne suis pas convaincu qu'elles soient ajoutées à Rust. Néanmoins, s'ils devaient être ajoutés, cette syntaxe pourrait être utile.

J'ai pris ce qui suit d' ici .

nameDo :: IO ()
nameDo = do putStr "What is your first name? "
            first <- getLine
            putStr "And your last name? "
            last <- getLine
            let full = first ++ " " ++ last
            putStrLn ("Pleased to meet you, " ++ full ++ "!")

serait équivalent à:

do {
    putStr("What is your first name? ")!bind;
    let first = getLine()!bind;
    putStr("And your last name? ")!bind;
    let last = getLine()!bind;
    let full = first + " " + &last
    putStrLn("Pleased to meet you, " + &full + "!")!bind;
}

Ou, plus intégré, avec moins de let s:

do {
    putStr("What is your first name? ")!bind;
    let first = getLine()!bind;
    putStr("And your last name? ")!bind;
    putStrLn(
        "Pleased to meet you, " + &first + " " + &getLine()!bind + "!"
    )!bind;
}

Évaluation

Je suis très partagé sur ce point. La partie mathématicienne de mon cerveau veut trouver une solution généralisée pour await , et les macros postfixes pourraient être un moyen de les réaliser. La partie pragmatique de mon cerveau pense: Pourquoi se donner la peine de faire un langage dont le macro système déjà personne ne comprend encore plus compliqué.

Cependant, à partir de ? et await , nous avons deux exemples d'opérateurs postfix super utiles. Et si nous en trouvons d'autres que nous voulons ajouter à l'avenir, peut-être similaires à ceux que j'ai mentionnés? Si nous les avons généralisés, nous pouvons les ajouter à Rust naturellement. Si ce n'est pas le cas, nous devrons proposer une autre syntaxe à chaque fois, ce qui gonflera probablement le langage plus que les macros postfix.

Qu'en pensez-vous?

@EyeOfPython

J'ai eu une idée très similaire, et je suis sûr que les macros postfix dans Rust sont une question de temps.
J'y pense à chaque fois lorsque je traite du slicing ndarray :

let view = array.slice(s![.., ..]);

mais beaucoup mieux serait

let view = array.slice![.., ..];
// or like you suggested
let view = array!slice[.., ..];
// or like in PHP
let view = array->slice![.., ..];

et beaucoup de combinateurs peuvent disparaître, comme ceux avec _with ou _else postfixes:

opt!unwrap_or(Error::new("Error!"))?; //equal to .unwrap_or_else(||Error::new("Error!"));

@EyeOfPython @andreytkachenko Les macros postfixes ne sont actuellement pas une fonctionnalité de Rust et IMHO aurait besoin d'une phase complète de mise en œuvre RFC + FCP +.

Ce n'est pas une discussion RFC, mais une discussion d'une RFC acceptée qui doit être implémentée.

Pour cette raison, je ne pense pas qu'il soit pratique de les discuter ici ou de les proposer pour la syntaxe asynchrone. Cela retarderait encore massivement la fonctionnalité.

Pour freiner cette discussion déjà massive, je pense qu'il n'est pas utile de les discuter ici, ils peuvent être considérés comme en dehors de la question discutée.

Juste une réflexion: bien que ce fil soit spécifiquement pour await , je pense que nous aurons la même discussion pour les expressions yield tard, qui pourraient également être chaînées. Dans la mesure où je préférerais voir une syntaxe qui peut être généralisée, quelle que soit son apparence.

Mes raisons de ne pas utiliser de macros ici:

1. Les macros sont fournies pour des éléments spécifiques au domaine et les utiliser de toutes les manières qui modifient le flux de contrôle des programmes ou émulent les fonctionnalités du langage de base est une exagération
2. Les macros Postfix seraient immédiatement utilisées abusivement pour implémenter des opérateurs personnalisés ou d'autres fonctionnalités de langage ésotherique qui conduisent à un mauvais code
3. Ils décourageraient le développement de fonctionnalités de langage appropriées:
   
   
   
   • stream.await_all est un cas d'utilisation parfait pour le combinateur
   
   
   • option.or_continue et le remplacement de _else combinateurs est un cas d'utilisation parfait pour l'opérateur de fusion nul
   
   
   • monad.bind est un cas d'utilisation parfait pour les chaînes if-let
   
   
   • ndarray slicing est un cas d'utilisation parfait pour les génériques const
   
   
4. Ils mettraient en question l'opérateur déjà implémenté ?

@collinanderson

qui pourrait également être enchaîné

Pourquoi diable pensez-vous qu'ils pourraient être enchaînés? zéro occurrence dans le code réel, tout comme l'exemple println ci-dessus.

@Pzixel Il est probable que finalement Generator::resume prendra une valeur, et donc yield expr aura un type non- () .

@vlaff Je ne vois pas clairement voir un argument pour await devant être cohérent avec l'attribution de type. Ce sont des choses très différentes.

En outre, l'attribution de type est une autre de ces fonctionnalités qui sont essayées à plusieurs reprises, il n'y a aucune garantie que _celle_ le fera. Bien que je ne veuille pas m'opposer à cela, TA est une future RFC et il s'agit d'une discussion sur une fonctionnalité acceptée avec une syntaxe déjà proposée.

En lisant les nombreux commentaires, pour ajouter un résumé supplémentaire sur pourquoi attendre! (...) apparaît un chemin très idéal:

1. il semble le plus familier au code existant car les macros sont familières
2. il y a du travail existant qui utilise await! (...) https://github.com/alexcrichton/futures-await et pourrait aider à réduire la réécriture du code
3. puisque les macros de postfix ne sont pas sur la table, peuvent ne jamais faire partie du langage et "attendre!" dans un contexte non standard ne semble pas être même une possibilité selon les RFC
4. cela donne à la communauté plus de temps pour considérer la direction à long terme après une utilisation stable à grande échelle tout en fournissant quelque chose qui n'est pas totalement hors norme (par exemple. try! ())
5. pourrait être utilisé comme un modèle similaire pour le rendement à venir! () jusqu'à ce que nous trouvions un chemin officiel qui pourrait satisfaire wait et yield
6. le chaînage peut ne pas être aussi précieux qu'on l'espère et la clarté sera probablement même améliorée en ayant plusieurs attentes sur plusieurs lignes
7. aucun changement ne devrait se produire pour les surligneurs de syntaxe IDE
8. les personnes d'autres langues ne seront probablement pas ébranlées par une macro d'attente! (...) après avoir vu d'autres usages macro (moins de surcharge cognitive)
9. c'est probablement le chemin d'effort le plus minimal de tous les chemins pour avancer vers la stabilisation

attendre! macro est déjà ici, la question est de chaîner.

Plus j'y pense, plus le suffixe me paraît bien. Par exemple:

let a = foo await;
let b = bar await?;
let c = baz? await;
let d = booz? await?;
let e = kik? + kek? await? + kuk? await?;
// a + b is `impl Add for MyFuture {}` which alises to `a.select(b)`

Permet l'imbrication de tous les niveaux et la lecture du quire. Fonctionne parfaitement avec ? et les futurs opérateurs possibles. Cela semble un peu étranger pour les nouveaux arrivants, mais le profit de la grammaire peut le surpasser.

La raison principale est que await doit être un mot-clé séparé, pas un appel de fonction. C'est trop important pour qu'il ait sa propre mise en évidence et sa propre place dans le texte.

@Pzixel , @HeroicKatora , @skade

Voir par exemple les expressions Python yield et yield from : là, la fonction externe peut fournir une valeur qui deviendra le résultat de yield lorsque le générateur redémarrera. C'est ce que @valff voulait dire et n'a rien à voir avec les attributions de type. Par conséquent, yield aura également un type autre que ! ou () .

Depuis le point de la coroutine, yield et await suspendent et peuvent (éventuellement) renvoyer une valeur. Dans la mesure où ils ne sont que les deux faces d'une même pièce.

Et pour jeter une autre possibilité de syntaxe, _square-brackets-with-keyword_, en partie pour mettre en évidence ceci (en utilisant yield pour la coloration syntaxique):

let body: MyResponse = client.get("http://api").send()[yield]?.into_json()[yield]?

"mot-clé postfix" me semble le plus logique. suffixe avec un caractère autre qu'un espace séparant l'expression future et await également un sens pour moi, mais pas '.' car c'est pour les méthodes et await n'est pas une méthode. Cependant, si vous voulez await comme mot-clé de préfixe, j'aime la suggestion @XX d'un await self pour ceux qui veulent enchaîner un tas de choses ensemble (bien que nous impossible de nommer la méthode await ; juste wait ferait bien que je pense). Personnellement, je finirais probablement par créer une attente par ligne et pas tellement une chaîne parce que je trouve les longues chaînes moins lisibles, donc le préfixe ou le postfixe fonctionneraient pour moi.

[modifier] J'ai oublié que wait existe déjà et bloque le futur, alors grattez cette pensée.

@roland Je fais spécifiquement référence à ceci, qui traite des attributions de type: https://github.com/rust-lang/rust/issues/57640#issuecomment -456023146

@rolandsteiner donc vous écrivez

let body: MyResponse = client.get("http://api").send() await?.into_json() await?;

Quand je l'écrirais comme:

let response = client.get("http://api").send() await?;
let body: MyResponse = response.into_json() await?;

@skade Oh, tu voulais dire un commentaire différent de ce que je pensais, désolé. : stuck_out_tongue:

@Pzixel Il est probable que finalement Generator::resume prendra une valeur, et donc yield expr aura un type non- () .

Par conséquent, yield aura également un type autre que ! ou () .

@valff , @rolandsteiner Je trouve peu probable que yield renvoie la valeur de reprise, difficile à intégrer dans un langage typé statiquement sans rendre la syntaxe et / ou le trait du générateur ennuyeux à utiliser. Le prototype original avec des arguments de reprise utilisait le mot-clé gen arg pour faire référence à cet argument, quelque chose comme celui-ci est beaucoup plus susceptible de bien fonctionner IMO. De ce point de vue, yield retournera toujours () et ne devrait donc pas affecter beaucoup la discussion sur await .

Je pense que await devrait être un opérateur de préfixe, car async est (et je m'attends yield ce que

Cependant, je ne fais pas tourner tout le bikeshedding ici: pourquoi même envisager un mot-clé postfix là où aucun autre de Rust ne l'a? Cela rendrait la langue si bizarre.

Aussi, en enchaînant les futurs, je comprends pourquoi cela pourrait être intéressant. Mais l'enchaînement vous attend? Qu'est-ce que cela signifie même? Un avenir qui renvoie un nouvel avenir? Est-ce vraiment un idiome si commun que nous voulons que Rust ait cet idiome en tant que citoyen de première classe? Si cela nous tient vraiment à cœur, je pense que nous devrions:

1. Optez pour la méthode (ie foo.await() ). Cela n'introduit pas de mot-clé postfix étrange et nous savons tous ce que cela signifie. Nous pouvons également enchaîner avec cela.
2. Si nous voulons vraiment un mot-clé / loloperator, nous pourrons régler cette question plus tard.

Aussi, pour donner mon opinion personnelle, je déteste le await en position de mot-clé postfix.

Le préfixe await est utilisé dans d'autres langues pour une raison - il correspond au langage naturel. Vous ne dites pas "Je vais attendre votre arrivée". Bien qu'ayant écrit JavaScript, je suis peut-être un peu partial.

Je dirai aussi que je considère le await -chaining surfait. La valeur de async/await sur les futurs combinateurs est qu'il permet d'écrire du code asynchrone séquentiellement, en utilisant les constructions de langage standard telles que if , match , et cetera. Vous allez quand même vouloir rompre vos attentes.

N'inventons pas trop de syntaxe magique pour async/await , ce n'est qu'une petite partie du langage. La syntaxe de méthode proposée (ie foo.await() ) est IMO trop orthogonale aux appels de méthode normaux et se révèle trop magique. La machinerie proc-macro est en place, pourquoi ne pas la dissimuler derrière ça?

Que diriez-vous d'utiliser le mot-clé await par opposition à async dans la définition des fonctions? Par exemple:

await fn foo(future: impl Future<Output = i32>) -> i32 {
    future
}

Ce await fn ne peut être appelé que dans le contexte async :

async {
    let n = foo(bar());
}

Et désugaring à let n = (await foo(bar())); .
Ensuite, en plus du mot-clé await , le trait Future pourrait implémenter la méthode await pour utiliser la logique await en position de suffixe, par exemple:

async {
    let n = bar().awaited();
}

Aussi, quelqu'un peut-il m'expliquer la relation avec les générateurs? Je suis surpris que async / await soient implémentés avant que les générateurs ne soient (même stabilisés).

Les générateurs async / await . Il n'y a pas de plans actuels pour les stabiliser, et ils nécessitent toujours un RFC non expérimental avant de pouvoir l'être. (Personnellement, j'adorerais les stabiliser, mais il semble probable qu'ils seront dans au moins un an ou deux, probablement pas RFC avant que async / await soit stable et il y a eu une certaine expérience avec lui).

@XX Je pense que vous async si vous utilisez await dans la définition de fonction. Tenons-nous en aux normes, n'est-ce pas?

@phaazon Pouvez-vous préciser plus en détail comment cela rompt la sémantique de async ?

La plupart des langages utilisent async pour introduire quelque chose qui va être asynchrone et await attend. Donc avoir await au lieu de async est un peu bizarre, pour moi.

@phaazon Non, pas à la place, mais en plus. Exemple complet:

async fn bar() -> i32 {
    5 // will be "converted" to impl Future<Output = i32>
}

await fn foo(future: impl Future<Output = i32>) -> i32 {
    future // will be "converted" to i32 in async context
}

async {
    let a = await bar(); // correct, a == 5
    let b = foo(bar()); // correct, b == 5
}

let c = foo(bar()); // error, can't call desugaring statement `await foo(bar())`

s'il est valide, alors il sera possible d'implémenter la méthode await pour une utilisation dans une chaîne:

async {
    let n = first().awaited()?.second().awaited()?;
    // let n = (await (await first())?.second())?;
}

À mon avis, peu importe si postfix wait "se sent" trop magique et pas familier à la langue. Si nous adoptons la syntaxe .await() la méthode .await!() alors il s'agit juste d'expliquer que Future s ont une méthode .await() ou .await!() que vous pouvez également utiliser pour les attendre dans les cas qui ont du sens. Ce n'est pas si difficile à comprendre si vous passez 5 minutes à y réfléchir, même si vous ne l'avez jamais vu auparavant.

De plus, si nous utilisons le mot-clé prefix, qu'est-ce qui nous empêche d'écrire une caisse avec ce qui suit (pseudocode incomplet car je n'ai pas l'infrastructure pour traiter les détails en ce moment):

trait AwaitChainable {
    fn await(self) -> impl Future;
}

impl<T: Future> AwaitChainable for T {
    fn await(self) -> impl Future {
        await self
    }
}

De cette façon, nous pouvons obtenir le suffixe attendre si nous le voulons. Je veux dire, même si cela n'est pas possible et que nous devons implémenter postfix comme par magie par le compilateur, nous pouvons toujours utiliser quelque chose comme l'exemple ci-dessus pour expliquer comment cela fonctionne principalement. Ce ne serait pas difficile à apprendre.

@ivandardi J'ai pensé à la même chose. Mais cette définition

fn await(self) -> impl Future {
    await self
}

ne dit pas que la fonction peut être appelée dans async -context uniquement.

@XX Ouais, comme je l'ai dit, ignorez le pseudocode cassé: PI n'a actuellement pas l'infrastructure pour rechercher comment la syntaxe et les traits corrects devraient être écrits ici: (Imaginez simplement que j'ai écrit ce qui le rend uniquement appelable en asynchrone contextes.

@XX , @ivandardi Par définition, await ne fonctionne que dans un contexte async . C'est donc illégal:

fn await(self) -> impl Future {
    await self
}

Ce doit être

async fn await(self) -> impl Future {
    await self
}

Qui ne peut être appelé que dans un contexte async comme celui-ci:

await future.await()

Ce qui va à l'encontre de l'objectif général.

La seule façon de faire ce travail est de changer complètement async , ce qui est hors de la table.

@ivandardi Cette évolution de ma version:

fn await(self) -> T { // How to indicate using in async-context only?
    await self
}

`` rouille
wait fn wait (self) -> T {// Parce que async déjà pris
attendez-vous
}

```rust
await fn await(self) -> T {
    self // remove excess await
}

@CryZe @XX Pourquoi me huez -vous? J'ai raison.

@XX Ce que vous essayez de faire est de modifier la signification de async et d'attendre complètement (par exemple, créez un contexte await qui est quelque peu différent d'un contexte async ). Je ne pense pas qu'il obtiendrait beaucoup de soutien de la part des développeurs de langage

@EyeOfPython Cette définition ne fonctionne pas comme prévu:

async fn await(self) -> impl Future {
    await self
}

Plus probable:

#[call_only_in_async_context_with_derived_await_prefix]
fn await(self) -> impl Future {
    self
}

Je vote contre parce que vous avez ignoré qu'il s'agit d'une pseudo syntaxe hypothétique. Essentiellement, leur argument est que Rust pourrait ajouter un trait spécial comme Drop et Copy que le langage comprend, ce qui ajoute la possibilité d'appeler .await () sur le type qui interagit ensuite avec le type comme le ferait un mot-clé await. De plus, le vote est de toute façon considéré comme non pertinent pour les RFC, car il s'agit de trouver une solution objective, et non basée sur des sentiments subjectifs tels que visualisés par des votes positifs / négatifs.

Je ne comprends pas ce que ce code devrait faire. Mais cela n'a rien à voir avec le fonctionnement actuel de l'attente asynchrone. Si cela vous tient à cœur, veuillez le garder en dehors de ce fil et rédigez un RFC dédié pour cela.

@CryZe Ce type est disponible. Il s'appelle Future. Et il a été convenu il y a longtemps que async / await est un mécanisme qui vise UNIQUEMENT à transformer le code async. Il ne s'agit pas d'une notation de liaison générale.

@ivandari votre postfix attend n'attend pas mais crée un nouvel avenir. C'est essentiellement une fonction d'identité. Vous ne pouvez pas attendre implicitement, car ce n'est pas une fonction normale.

@ Matthias247 Ce qu'ils essayaient de suggérer, c'était un moyen pour que postfix wait ait la syntaxe d'un appel de méthode. De cette façon, Rust n'a pas besoin d'introduire de nouveaux symboles arbitraires tels que #, @ ou ... comme nous l'avons fait avec le? opérateur, et ont toujours l'air assez naturel:

let result = some_operation().await()?.some_method().await()?;

L'idée serait donc d'avoir en quelque sorte wait être un type spécial de méthode sur le trait Future que le compilateur voit de la même manière qu'un mot-clé await normal (que vous n'avez pas du tout besoin d'avoir dans ce cas) et de transformer l'async code dans un générateur à partir de là. Ensuite, vous avez le bon flux de contrôle logique de gauche à droite au lieu de gauche droite gauche avec await some_future()? et vous n'avez pas besoin d'introduire de nouveaux symboles étranges.

(Donc tl; dr: cela ressemble à un appel de méthode mais est en fait juste postfix wait)

Quelque chose que je n'ai pas vu mentionné explicitement en considération d'une syntaxe postfix est la prévalence des combinateurs d'erreur et d'options. C'est l'endroit où rust est le plus différent de tous les langages qui attendent - au lieu des retraits automatiques, nous avons .map_err()? .

En particulier des choses comme:

let result = await reqwest::get(..).send();
let response = result.map_err(|e| add_context(e))?;
let parser = await response.json();
let parsed = parser.map_err(|e| add_context(e))?;

est moins lisible que (je me fiche de la syntaxe de postfix considérée):

let parsed = reqwest::get(..)
    .send() await
    .map_err(add_context)?
    .json() await
    .map_err(add_context)?;

_ même si_ ce formatage par défaut a plus de lignes que l'approche à variables multiples. Les expressions qui n'ont pas plusieurs attentes semblent devoir prendre moins d'espace vertical avec postfix-await.

Je n'écris pas de code asynchrone pour le moment, donc je parle par ignorance, désolé d'accumuler - si ce n'est pas un problème dans la pratique, alors c'est excellent. Je ne veux tout simplement pas que la gestion des erreurs appropriée soit rendue moins ergonomique juste pour être plus similaire à d'autres langages qui traitent les erreurs différemment.

Oui, c'est ce que je veux dire. Ce serait le meilleur des deux mondes, permettant aux gens de choisir d'utiliser le préfixe ou le suffixe en fonction de la situation.

@XX Si cela ne peut pas être exprimé dans le code utilisateur, alors nous devrons recourir au compilateur pour implémenter cette fonctionnalité. Mais en termes de compréhension du fonctionnement du suffixe, l'explication que j'ai publiée précédemment fonctionne toujours, même si ce n'est qu'une compréhension superficielle.

@CryZe , @XX ,

À première vue, il se détend, mais ne correspond absolument pas à la philosophie de Rust. Même la méthode sort sur les itérateurs ne retourne pas self et rompt la chaîne d'appels de méthode pour rendre l'allocation explicite. Mais vous vous attendez à ce que quelque chose de non moins impactant soit implémenté de manière complètement implicite, impossible à distinguer des appels de fonction normaux. Il n'y a aucune chance à l'OMI.

Oui, c'est ce que je veux dire. Ce serait le meilleur des deux mondes, permettant aux gens de choisir d'utiliser le préfixe ou le suffixe en fonction de la situation.

Pourquoi cela devrait-il être un objectif? Rust ne prend pas en charge cela pour tous les autres flux de contrôle (par exemple, break , continue , if , etc. Il n'y a pas de raison particulière, à part "cela pourrait paraître plus agréable à son avis particulier.

En général, je voudrais rappeler à tout le monde que await est assez spécial et n'est pas une invocation de méthode normale:

• Les débogueurs peuvent se comporter de manière étrange lorsqu'ils passent au-dessus des attentes, car la pile peut se dérouler et se rétablir. Autant que je me souvienne, il a fallu beaucoup de temps pour que le débogage asynchrone fonctionne en C # et Javascript. Et ceux-ci ont des équipes rémunérées qui travaillent sur des débogueurs!
• Les objets locaux qui ne traversent pas les points d'attente peuvent être stockés sur la vraie pile du système d'exploitation. Ceux qui ne le sont pas doivent être déplacés dans le futur généré, ce qui à la fin fera une différence dans la mémoire de tas requise (c'est là que le futur vivra).
• Les emprunts sur les points d'attente sont la raison pour laquelle les futurs générés doivent être de !Unpin , et causent beaucoup d'inconvénients avec certains des combinateurs et mécanismes existants. Il pourrait être possible de générer des contrats à terme Unpin à partir async méthodes await sont invisibles, cela ne se produira jamais.
• Il peut y avoir d'autres problèmes inattendus de vérification d'emprunt, qui ne sont pas couverts par l'état actuel de async / await.

@Pzixel @lnicola

Les exemples que vous donnez pour C # sont absolument impératifs, et rien de tel que les longues chaînes de style fonctionnel que nous voyons souvent dans Rust. Cette syntaxe LINQ n'est qu'un DSL et ne ressemble en rien à foo().bar().x().wih_boo(x).camboom().space_flight(); J'ai un peu cherché sur Google, et les exemples de code C # semblent 100% impératifs, tout comme la plupart des langages de programmation populaires. C'est pourquoi nous ne pouvons pas simplement prendre ce que la langue X a fait, car ce n'est tout simplement pas la même chose.

La notation de préfixe IMO s'intègre parfaitement dans le style impératif de codage. Mais Rust prend en charge les deux styles.

@skade

Je ne suis pas d'accord avec certains de vos commentaires (et d'autres) sur les problèmes de style fonctionnel. Pour être bref, admettons simplement qu'il y a des gens qui ont une forte préférence pour l'un ou l'autre.

@ Matthias247 Non, il y a une raison particulière autre que sa beauté. C'est parce que Rust encourage le chaînage. Et vous pourriez dire "oh, les autres mécanismes de contrôle de flux n'ont pas de syntaxe postfix, alors pourquoi attendre devrait-il être spécial?". Eh bien, c'est une mauvaise évaluation. Nous avons un flux de contrôle postfix. Ils sont simplement internes aux méthodes que nous appelons. Option::unwrap_or est comme faire une déclaration de correspondance de suffixe. Iterator::filter est comme faire une instruction if avec un suffixe. Ce n'est pas parce que le flux de contrôle ne fait pas partie de la syntaxe de chaînage elle-même que nous n'avons pas déjà de flux de contrôle postfix. De ce point de vue, l'ajout d'un suffixe await serait en fait cohérent avec ce que nous avons. Dans ce cas, nous pourrions même avoir quelque chose de plus similaire au fonctionnement de Iterator et au lieu d'avoir juste un suffixe brut en attente, nous pourrions avoir des combinateurs d'attente, comme Future::await_or . Quoi qu'il en soit, avoir postfix en attente n'est pas qu'une question d'apparence - c'est une question de fonctionnalité et de qualité de vie. Sinon, nous utiliserions toujours la macro try!() , non?

@dpc

Les exemples que vous donnez pour C # sont absolument impératifs, et rien de tel que les longues chaînes de style fonctionnel que nous voyons souvent dans Rust. Cette syntaxe LINQ n'est qu'un DSL et ne ressemble en rien à foo (). Bar (). X (). Wih_boo (x) .camboom (). Space_flight (); J'ai un peu cherché sur Google et les exemples de code C # semblent 100% impératifs, tout comme la plupart des langages de programmation populaires. C'est pourquoi nous ne pouvons pas simplement prendre ce que la langue X a fait, car ce n'est tout simplement pas la même chose.

Ce n'est pas vrai (vous pouvez vérifier n'importe quel framework, par exemple polly ), mais je ne discuterai pas à ce sujet. Je vois autant de code enchaîné dans les deux langues. Cependant, il y a en fait une chose qui rend tout différent. Et ça s'appelle Try trait. C # n'a rien de similaire, donc il ne suppose rien au-delà de await point. Si vous obtenez une exception, elle sera automatiquement encapsulée et déclenchée pour l'appelant.

Ce n'est pas le cas pour Rust, où vous devez utiliser manuellement l'opérateur ? .

Si vous devez avoir quelque chose au-delà du point await , vous devez soit créer un opérateur "combiné" await? , étendre les règles de langage, etc. syntaxe un peu étrangère, mais qui s'en soucie?).

Je vois donc actuellement postfix comme une solution plus viable. La seule suggestion que j'ai ici devrait être un mot-clé dédié séparé par des espaces, et non await() ou await!() .

Je pense que j'ai trouvé une bonne raison justifiant une méthode .await () normale. Si vous y réfléchissez, ce n'est pas différent de toute autre façon de bloquer. Vous appelez la méthode .await (), l'exécution du thread (éventuellement vert) est parquée et à un moment donné, le runtime en cours d'exécution reprend alors l'exécution du thread à un moment donné. Donc, à toutes fins utiles, que vous ayez un canal Mutex ou std comme ceci:

let result = my_channel().recv()?.iter().map(...).collect();

ou un futur comme ça:

let result = my_future().await()?.iter().map(...).collect();

n'est pas différent. Ils bloquent tous les deux l'exécution à leur recv () / await () respectif et ils enchaînent tous les deux de la même manière. La seule différence est que await () s'exécute probablement sur un exécuteur différent qui n'est pas le thread lourd du système d'exploitation (mais cela peut très bien être dans le cas d'un exécuteur à thread unique). Ainsi, le fait de décourager de fortes quantités de chaînage affecte les deux exactement de la même manière et devrait probablement conduire à une véritable peluche coupante.

Cependant, mon point ici est que de la personne qui écrit le point de vue de ce code, il n'y a pas beaucoup de différence entre .recv () ou .await (), les deux sont des méthodes qui bloquent l'exécution et retournent une fois le résultat disponible. . Donc, à toutes fins utiles, cela peut être à peu près une méthode normale et ne nécessite pas un mot-clé complet. Nous n'avons pas non plus de mot clé recv ou lock pour le canal Mutex et std.

Cependant rustc veut évidemment transformer tout le code en générateur. Mais est-ce réellement nécessaire sémantiquement du point de vue du langage? Je suis à peu près sûr que l'on pourrait écrire un compilateur alternatif à rustc qui implémente en attente via le blocage d'un thread OS réel (entrer dans un fn async aurait besoin de générer un thread, puis attendre bloquerait ce thread). Bien que ce soit une implémentation extrêmement naïve et lente, elle se comporterait sémantiquement exactement de la même manière. Donc, le fait que rustc réel se transforme en un générateur n'est pas nécessaire sémantiquement. Donc, je dirais en fait que rustc transformer l'appel à la méthode .await () en un générateur peut être vu comme un détail d'implémentation optimisant de rustc. De cette façon, vous pouvez justifier que .await () soit une méthode complète et non un mot-clé complet, mais aussi que rustc transforme le tout en générateur.

@CryZe contrairement à .recv() nous pouvons interrompre en toute sécurité await depuis n'importe quel autre endroit du programme, puis le code à côté de await ne sera pas exécuté. C'est une grande différence et c'est la raison la plus précieuse pour laquelle nous ne devrions pas faire await implicitement.

@ I60R Ce n'est pas moins explicite qu'attendre comme mot clé. Vous pouvez toujours le mettre en évidence de la même manière dans l'IDE si vous le souhaitez. Il déplace simplement le mot-clé à la position de suffixe, où je dirais qu'il est en fait moins facile à manquer (car il est exactement dans la position où l'exécution s'arrête).

Idée folle: attente implicite . Je suis passé à un fil de discussion séparé, car celui-ci est déjà trop occupé avec la discussion postfix vs préfixe.

@CryZe

Je pense que j'ai trouvé une bonne raison justifiant une méthode .await () normale. Si vous y réfléchissez, ce n'est pas différent de toute autre façon de bloquer.

Veuillez lire à nouveau https://github.com/rust-lang/rust/issues/57640#issuecomment -456147515

@ Matthias247 Ce sont de très bons points, il semble que je les ai manqués.

Tout ce discours sur la transformation de await en une fonction, un membre ou autrement implicite est fondamentalement invalide. Ce n'est pas une action, c'est une transformation.

Le compilateur, à un niveau élevé, que ce soit via un mot-clé ou une macro, transforme les expressions d'attente en expressions de rendement de générateur spéciales, sur place, en tenant compte des emprunts et autres choses en cours de route.

Cela devrait être explicite.

Il doit être soit aussi apparent que possible en tant que mot-clé, soit générer évidemment du code avec une macro.

Les méthodes magiques, les traits, les membres, etc. sont trop faciles à mal interpréter et à mal comprendre, en particulier pour les nouveaux utilisateurs.

Le préfixe mot-clé await ou le préfixe macro await semblent être le moyen le plus acceptable de le faire, ce qui est logique car de nombreux autres langages le font de cette façon. Nous n'avons pas besoin d'être spéciaux pour réussir.

@novacrazy

Les méthodes magiques, les traits, les membres, etc. sont trop faciles à mal interpréter et à mal comprendre, en particulier pour les nouveaux utilisateurs.

Pouvez-vous développer? Plus précisément sur la variante .await!() , si possible.

Avoir un foo.await!() n'est pas difficile à lire, à mon avis, SURTOUT avec une coloration syntaxique appropriée, qui ne devrait pas être ignorée.

Vous en comprenez mal le sens? Ce que cela fait est essentiellement ce qui suit (ignorez les types mystakes):

trait Future {
    fn await!(self) -> Self::Item {
        await self
    }
}

AKA await this_foo et this_foo.await!() sont exactement égaux. Qu'est-ce qui est facile à mal comprendre à ce sujet?

Et sur le thème des nouveaux utilisateurs: de nouveaux utilisateurs vers quoi? Programmation en général, ou nouveaux utilisateurs de Rust en tant que langage mais avec une formation en langage de programmation? Parce que si c'est le premier, je doute qu'ils se lancent directement dans la programmation asynchrone. Et si c'est le dernier, alors il est plus facile d'expliquer la sémantique de postfix wait (comme expliqué ci-dessus) sans confusion.

Alternativement, si seul le préfixe Wait est ajouté, rien de ce que je sache n'interrompt la création d'un programme qui prend en entrée le code Rust de la forme

foo.bar().baz().quux().await!().melo().await!()

et le transforme en

await (await foo.bar().baz().quux()).melo()

@ivandardi

.await!() est bien dans certains cas, et fonctionnerait probablement avec await!(...) comme:

macro_rules! await {
    // prefix
    ($fut:expr) => {...}

    // postfix
    ($self:Self) => { await!($self) }
}

Cependant, les macros de méthode postfix n'existent pas pour le moment et peuvent ne jamais exister.

Si nous pensons que c'est une possibilité dans le futur, nous devrions aller avec la macro await!(...) pour l'instant et simplement ajouter le suffixe dans le futur quand cela sera implémenté.

L'idéal serait d'avoir les deux macros, mais s'il n'y a aucune intention d'implémenter des macros postfixes à l'avenir, le mot-clé préfixe await est probablement le meilleur pari.

@novacrazy Je peux être d'accord avec cela et c'est ma proposition originale. Nous devrions ajouter await!() pour l'instant et trouver un formulaire avec suffixe au fur et à mesure. Discutez aussi potentiellement de la possibilité de macros postfixes, et si nous pouvions ad-hoc un postfix .await!() dans le langage avant d'avoir le support complet des macros postfix dans le langage. Un peu comme ce qui s'est passé avec ? et le trait Try : il a d'abord été ajouté en tant que cas spécial et ensuite il a été étendu à un cas plus général. La seule chose à laquelle nous devons faire attention lorsque nous décidons est à quoi ressemblerait la syntaxe générale des macros postfixes, ce qui pourrait mériter une discussion séparée.

Le préfixe mot-clé await ou le préfixe macro await semblent être le moyen le plus acceptable de le faire, ce qui est logique car de nombreux autres langages le font de cette façon.

C'est évidemment possible, mais je ne me souviens que de deux arguments pour cela, et je ne les trouve pas convaincants:

• C'est comme ça que les autres langues le font
  
  
  
  • C'est bien, mais nous faisons déjà les choses différemment, comme ne pas courir à moins que - poll ed au lieu de courir jusqu'au premier - await , car la rouille est fondamentalement différente Langue
  
  
• Les gens aiment voir await au début de la ligne
  
  
  
  • Mais ce n'est pas toujours là, donc si c'est le seul endroit où l'on regarde on aura des problèmes
  
  
  • Il est tout aussi facile de voir les await s dans foo(aFuture.await, bFuture.await) que s'ils étaient préfixes
  
  
  • Dans rust, on scanne déjà la _end_ de la ligne pour ? si vous regardez le flux de contrôle
  
  

Ai-je oublié quelque chose?

Si le débat était "meh, ils sont tous à peu près pareils", je serais tout à fait d'accord avec "bien, si nous ne nous soucions pas vraiment, nous ferions aussi bien de faire ce que tout le monde fait". Mais je ne pense pas que ce soit là où nous en sommes.

@scottmcm Oui, "meh, ils sont tous à peu près

Nous devrions donc trouver un équilibre décent entre lisibilité, familiarité, maintenabilité et performances. Par conséquent, ma déclaration dans mon dernier commentaire est vraie, avec la macro await!() si nous avons l'intention d'ajouter des macros de méthode postfix ( .await!() ) à l'avenir, ou simplement un mot-clé de préfixe ennuyeux await autrement.

Je dis ennuyeux, car ennuyeux c'est bien. Nous voulons garder notre esprit loin de la syntaxe elle-même lors de l'écriture de code avec ceux-ci.

Si f.await() ne serait pas une bonne idée, alors je préfère la syntaxe du préfixe.

1. En tant qu'utilisateur, j'espère que le langage que j'utilise n'a que quelques règles de syntaxe, et en utilisant ces règles, je peux en déduire de manière fiable ce qu'il pourrait faire. PAS d' exceptions ici et là. Dans Rust, async est au début, await au début ne sera pas une exception. Cependant, f await , le formulaire de mot-clé de publication serait. f.await ressemble à un accès aux champs, une exception . f.await!() macro postfix n'est jamais apparue dans le langage, et je ne sais pas dans quels autres cas elle serait bonne, une exception . Nous n'avons pas de réponse sur la manière dont ces syntaxes deviendraient des règles et non des exceptions ponctuelles .

2. Lorsqu'une exception est faite, j'espère que cela aura un sens intuitif. Prenez ? comme exemple, ce qui peut être considéré comme une exception car peu fréquent dans d'autres langues. f()?.map() lit presque comme compute f () et ce résultat est-il bon? Le ? ici s'explique. Mais pour f await je demande pourquoi c'est postfix ?, pour f.await je demande est await un champ, f.await!() Je demande pourquoi la macro apparaît dans cette position? Ils ne me donnent pas un sens convaincant / intuitif, du moins à première vue.

3. En prolongeant le premier point, Rust aimerait le plus être un langage système. Les principaux acteurs ici, C / C ++ / Go / Java sont tous quelque peu impératifs. Je crois aussi que la plupart des gars commencent leur carrière avec un langage impératif, C / Python / Java et non Haskell, etc. être très fonctionnel mais ne pas avoir un sentiment impératif familier.

4. Je pense qu'il n'y a rien de mal à diviser une chaîne et à l'écrire en plusieurs lignes. Ce ne sera pas verbeux. C'est juste explicite .

En voyant comment la discussion se déplace continuellement d'une direction à l'autre (préfixe vs postfixe), j'ai développé une forte opinion selon laquelle il y a quelque chose qui ne va pas avec le mot clé await et nous devons nous en éloigner complètement. Au lieu de cela, je propose la syntaxe suivante qui, je pense, sera un très bon compromis parmi toutes les opinions publiées dans le fil actuel:

// syntax below is exactly the same as with prefix `await`
let response = go client.get("https://my_api").send();
let body: MyResponse = go response.into_json();

Lors de la première étape, nous l'implémenterions comme un opérateur de préfixe régulier sans aucune erreur de gestion de superstructures spécifiques:

// code below don't compiles because `?` takes precedence over `go`
let response = go client.get("https://my_api").send()?;
let body: MyResponse = go response.into_json()?;

Lors de la deuxième étape, nous implémenterons une syntaxe d'opérateur de préfixe différé qui permettrait également une gestion correcte des erreurs.

// now `go` takes precedence over `?` if present
let response = client.get("https://my_api").go send()?;
let body: MyResponse = response.go into_json()?;

C'est tout.

Voyons maintenant quelques exemples supplémentaires qui fournissent plus de contexte:

// A
if db.go is_trusted_identity(recipient.clone(), message.key.clone())? {
    info!("recipient: {}", recipient);
}

// B
match db.go load(message.key)? {
    Some(key) => key,
    None => {
        return Err(/* [...] */);
    }
};

// C
let mut res = client.get(&script_src)
    .header("cookie", self.cookies.read().as_header_value())
    .header("user-agent", USER_AGENT)
    .go send()?
    .error_for_status()?;

// D
let mut res: InboxResponse = client.get(inbox_url)
    .headers(inbox_headers)
    .go send()?
    .error_for_status()?
    .go json()?;

// E
let mut res: Response = client.post(url)
    .multipart(form)
    .headers(headers.clone())
    .go send()?
    .error_for_status()?
    .go json()?;

// F
async fn request_user(self, user_id: String) -> Result<User> {
    let url = format!("users/{}/profile", user_id);
    let user = self.go request(url, Method::GET, None, true)?
        .res.go json::<UserResponse>()?
        .user
        .into();

    Ok(user)
}

// G
async fn log_service(&self) -> T {
   let service = self.myService.foo();
   go self.logger.log("beginning service call");
   let output = go service.exec();
   go self.logger.log("foo executed with result {}.", output));
   output
}

// H
async fn try_log(message: String) -> Result<usize, Error> {
    let logger = go acquire_lock();
    let length = logger.go log_into(message)?;
    go logger.timestamp();
    Ok(length)
}

// I
async fn await_chain() -> Result<usize, Error> {
    go (go partial_computation()).unwrap_or_else(or_recover);
}

/// J
let res = client.get("https://my_api").go send()?.go json()?;

// A
if db.as is_trusted_identity(recipient.clone(), message.key.clone())? {
    info!("recipient: {}", recipient);
}

// B
match db.as load(message.key)? {
    Some(key) => key,
    None => {
        return Err(/* [...] */);
    }
};

// C
let mut res = client.get(&script_src)
    .header("cookie", self.cookies.read().as_header_value())
    .header("user-agent", USER_AGENT)
    .as send()?
    .error_for_status()?;

// D
let mut res: InboxResponse = client.get(inbox_url)
    .headers(inbox_headers)
    .as send()?
    .error_for_status()?
    .as json()?;

// E
let mut res: Response = client.post(url)
    .multipart(form)
    .headers(headers.clone())
    .as send()?
    .error_for_status()?
    .as json()?;

// F
async fn request_user(self, user_id: String) -> Result<User> {
    let url = format!("users/{}/profile", user_id);
    let user = self.as request(url, Method::GET, None, true)?
        .res.as json::<UserResponse>()?
        .user
        .into();

    Ok(user)
}

// G
async fn log_service(&self) -> T {
   let service = self.myService.foo();
   as self.logger.log("beginning service call");
   let output = as service.exec();
   as self.logger.log("foo executed with result {}.", output));
   output
}

// H
async fn try_log(message: String) -> Result<usize, Error> {
    let logger = as acquire_lock();
    let length = logger.as log_into(message)?;
    as logger.timestamp();
    Ok(length)
}

// I
async fn await_chain() -> Result<usize, Error> {
    as (as partial_computation()).unwrap_or_else(or_recover);
}

/// J
let res = client.get("https://my_api").as send()?.as json()?;

IMO, cette syntaxe est meilleure que les alternatives dans tous les aspects:

✓ Cohérence: semble très organique à l'intérieur du code Rust et ne nécessite pas de style de code de rupture
✓ Composabilité: s'intègre bien avec d'autres fonctionnalités de Rust comme le chaînage et la gestion des erreurs
✓ Simplicité: soit courte, descriptive, facile à comprendre et facile à utiliser
✓ Réutilisabilité: la syntaxe d'opérateur de préfixe différé serait également utile dans d'autres contextes
✓ Documentation: implique que les distributions côté appel circulent quelque part et attendent jusqu'à ce qu'elles reviennent
✓ Familiarité: fournit un modèle déjà familier mais le fait avec moins de compromis
✓ Lisibilité: se lit comme un anglais simple et ne déforme pas le sens des mots
✓ Visibilité: sa position rend très difficile d'être déguisé quelque part dans le code
✓ Accessibilité: pourrait être très facilement recherchée sur Google
✓ Bien testé: le golang est populaire de nos jours avec une syntaxe d'apparence similaire
✓ Surprises: il est difficile de mal comprendre et d'abuser de cette syntaxe
✓ Gratification: après une petite quantité d'apprentissage, chaque utilisateur sera satisfait du résultat

Edit: comme @ivandardi l'a souligné dans le commentaire ci-dessous, certaines choses doivent être clarifiées:

1. Oui, cette syntaxe est un peu difficile à analyser, mais en même temps, il est impossible d'inventer ici une syntaxe qui n'aurait aucun problème de lisibilité. go syntaxe await , et en position différée, l'OMI est plus lisible que postfix await par exemple:

match db.go load(message.key) await {
    Some(key) => key,
    None => {
        return Err(/* [...] */);
    }
};

où pas await semble ambigu et a une associativité différente de celle de tous les mots-clés existants, mais pourrait également devenir un bloqueur si nous décidons d'implémenter des blocs await dans le futur.

2. Il faudra créer un RFC, implémenter et stabiliser la syntaxe "opérateur de préfixe différé". Cette syntaxe ne serait pas spécifique au code asynchrone, mais son utilisation en asynchrone en serait la principale motivation.

3. Dans la syntaxe "opérateur de préfixe différé", le mot-clé est important car:

• Le mot clé long augmenterait l'espace entre la variable et la méthode, ce qui est mauvais pour la lisibilité
• Le mot clé long est un choix étrange pour l'opérateur de préfixe
• Le mot clé long est inutilement détaillé lorsque nous voulons que le code asynchrone ressemble à une synchronisation

Quoi qu'il en soit, il est tout à fait possible de commencer à utiliser await au lieu de go , puis de le renommer dans l'édition 2022. À ce moment-là, il est très probable que différents mots clés ou opérateurs seront inventés. Et nous pouvons même décider qu'aucun changement de nom n'est requis du tout. J'ai trouvé que await était également lisible.

// A
if db.await is_trusted_identity(recipient.clone(), message.key.clone())? {
    info!("recipient: {}", recipient);
}

// B
match db.await load(message.key)? {
    Some(key) => key,
    None => {
        return Err(/* [...] */);
    }
};

// C
let mut res = client.get(&script_src)
    .header("cookie", self.cookies.read().as_header_value())
    .header("user-agent", USER_AGENT)
    .await send()?
    .error_for_status()?;

// D
let mut res: InboxResponse = client.get(inbox_url)
    .headers(inbox_headers)
    .await send()?
    .error_for_status()?
    .await json()?;

// E
let mut res: Response = client.post(url)
    .multipart(form)
    .headers(headers.clone())
    .await send()?
    .error_for_status()?
    .await json()?;

// F
async fn request_user(self, user_id: String) -> Result<User> {
    let url = format!("users/{}/profile", user_id);
    let user = self.await request(url, Method::GET, None, true)?
        .res.await json::<UserResponse>()?
        .user
        .into();

    Ok(user)
}

// G
async fn log_service(&self) -> T {
   let service = self.myService.foo();
   await self.logger.log("beginning service call");
   let output = await service.exec();
   await self.logger.log("foo executed with result {}.", output));
   output
}

// H
async fn try_log(message: String) -> Result<usize, Error> {
    let logger = await acquire_lock();
    let length = logger.await log_into(message)?;
    await logger.timestamp();
    Ok(length)
}

// I
async fn await_chain() -> Result<usize, Error> {
    await (as partial_computation()).unwrap_or_else(or_recover);
}

/// J
let res = client.get("https://my_api").await send()?.await json()?;

Si vous êtes ici pour voter contre, assurez-vous:

• que vous l'avez bien compris, car je ne suis peut-être pas le meilleur orateur pour expliquer de nouvelles choses
• que votre opinion n'est pas biaisée, car il y a beaucoup de préjugés d'où provient cette syntaxe
• que vous mettrez une raison valable ci-dessous, car les votes négatifs silencieux sont extrêmement toxiques
• que votre raison ne concerne pas les sentiments immédiats, puisque j'ai essayé de concevoir une fonctionnalité à long terme ici

@ I60R

J'ai quelques reproches à ce sujet.

match db.go load(message.key)? {
    Some(key) => key,
    None => {
        return Err(/* [...] */);
    }
};

C'est un peu difficile à analyser. À première vue, vous penseriez que nous ferions une correspondance sur db.go , mais il y a quelque chose de plus à cela et vous dites "oooh, ok, load est une méthode de db". OMI cette syntaxe ne fonctionnera principalement pas car les méthodes doivent toujours être proches de l'objet auquel elles appartiennent, sans espace ni interruption de mot-clé entre elles.

Deuxièmement, votre proposition nécessite de définir ce qu'est la "syntaxe d'opérateur de préfixe différé" et éventuellement de la généraliser d'abord dans le langage. Sinon, ce sera quelque chose uniquement utilisé pour le code asynchrone, et nous revenons à la discussion sur "pourquoi pas les macros postfix?" aussi.

Troisièmement, je ne pense pas que le mot-clé compte du tout. Cependant, nous devrions privilégier await car le mot-clé a été réservé pour l'édition 2018, alors que le mot-clé go n'a pas et devrait faire l'objet d'une recherche crates.io plus approfondie avant d'être proposé.

En voyant comment la discussion se déplace continuellement d'une direction à une autre (préfixe vs postfix), j'ai développé une forte opinion selon laquelle il y a quelque chose qui ne va pas avec le mot-clé d'attente et que nous devons nous en éloigner complètement.

Nous pourrions avoir une attente (semi-) implicite et tout irait bien, mais ce sera difficile à vendre dans la communauté Rust, même en dépit du fait que tout l'intérêt des fonctions asynchrones est de cacher les détails de l'implémentation et de leur donner un aspect juste comme bloquer io one.

@dpc Je veux dire, la meilleure façon dont je peux penser que cela fonctionne comme un compromis entre l'attente semi-implicite et le désir d'avoir des sections de code explicitement attendues est quelque chose de similaire à unsafe .

let mut res: Response = await { client.post(url)
    .multipart(form)
    .headers(headers.clone())
    .send()?
    .error_for_status()?
    .json()?
};

Où tout ce qui se trouve à l'intérieur du bloc await serait automatiquement attendu. Cela résout le besoin d'attendre postfix pour le chaînage, puisque vous pouvez simplement attendre la chaîne entière à la place. Mais en même temps, je ne sais pas si cette forme serait souhaitable. Peut-être que quelqu'un d'autre peut trouver une très bonne raison contre cela.

@dpc Le but des fonctions asynchrones n'est pas de cacher les détails, c'est de les rendre plus accessibles et plus faciles à utiliser. Nous ne devons jamais cacher des opérations potentiellement coûteuses et tirer profit des futurs explicites lorsque cela est possible.

Personne ne confond les fonctions asynchrones avec les fonctions synchrones, dans aucune langue. Il s'agit simplement d'organiser des séquences d'opérations sous une forme plus lisible et maintenable, plutôt que d'écrire à la main une machine à états.

De plus, les attentes implicites comme le montre l'exemple de Future combinateurs Future et attendre dessus, ce serait très inefficace.

Explicite, familier, lisible, maintenable et performant: mot-clé préfixe await ou macro await!() , avec potentiellement une macro postfixe .await!() dans le futur.

@novacrazy Même si la syntaxe idéale était choisie, je voudrais toujours utiliser des futurs et des combinateurs personnalisés dans certaines situations. L'idée que ceux-ci pourraient être légèrement obsolètes me fait remettre en question toute la direction de Rust.

Bien sûr, vous pouvez continuer à utiliser des combinateurs, rien n'est obsolète.

C'est la même situation que ? : le nouveau code utilisera généralement ? (car c'est mieux que les combinateurs), mais les combinateurs Option / Résultat peuvent toujours être utilisés (et les plus funk comme or_else sont encore régulièrement utilisés).

En particulier, async / await peut complètement remplacer map et and_then , mais les combinateurs Future plus funk peuvent (et seront) toujours utilisés.

Les exemples que vous donnez paraissent toujours terribles par rapport aux combinateurs,

Je ne pense pas, je pense qu'ils sont beaucoup plus clairs, car ils utilisent les fonctionnalités standard de Rust.

La clarté concerne rarement le nombre de personnages, mais elle a tout à voir avec des concepts mentaux.

Avec le suffixe await c'est encore mieux:

some_op().await?
    .another_op().await?
    .final_op().await

Vous pouvez comparer cela à votre original:

some_op()
    .and_then(|v| v.another_op())
    .and_then(|v2| v2.final_op())

et avec la surcharge du générateur sera probablement un peu plus lent et produira plus de code machine.

Pourquoi prétendez-vous qu'il y aura des frais supplémentaires dus à async / await? Les générateurs et async / await sont spécialement conçus pour être sans coût et fortement optimisés.

En particulier, async / await se compile dans une machine à états fortement optimisée, tout comme les combinateurs Future.

plutôt que de créer ces machines d'état de spaghetti générateur sous le capot.

Les combinateurs du futur créent également une "machine à états spaghetti" sous le capot, ce pour quoi ils ont été conçus.

Ils ne sont pas fondamentalement différents de async / await.

[Les futurs combinateurs] ont le potentiel de compiler vers un code plus efficace.

Veuillez arrêter de diffuser de la désinformation. En particulier, async / await a la possibilité d'être plus rapide que les combinateurs Future.

S'il s'avère que les utilisateurs ne sont pas satisfaits d'un mot-clé de préfixe, il peut être modifié dans une édition 2019/2020.

Comme d'autres l'ont dit, les éditions ne sont pas une chose arbitraire que nous faisons juste quand nous en avons envie, elles sont spécifiquement conçues pour ne se produire que toutes les quelques années (au plus tôt).

Et comme @Centril l'a souligné, trouver une mauvaise syntaxe juste pour la remplacer plus tard est une façon très inefficace de faire les choses.

Le rythme des discussions est assez élevé en ce moment; donc dans un effort pour ralentir les choses et permettre aux gens de se rattraper, j'ai verrouillé le problème temporairement . Il sera déverrouillé dans un délai d'un jour. À ce moment-là, essayez d'être aussi constructif que possible pour aller de l'avant.

Débloquer le problème un jour plus tard ... Veuillez envisager de ne pas faire de remarques déjà faites et de garder les commentaires sur le sujet (par exemple, ce n'est pas le lieu de considérer l'attente implicite ou d'autres choses hors de portée ..).

Comme cela a été un long fil, soulignons certains des commentaires les plus intéressants qui y sont enfouis.

@mehcode nous a fourni un code réel complet avec await dans les positions de préfixe et de suffixe: https://github.com/rust-lang/rust/issues/57640#issuecomment -455846086

@Centril a soutenu de manière convaincante que stabiliser await!(expr) revient à ajouter sciemment de la dette technique: https://github.com/rust-lang/rust/issues/57640#issuecomment -455806584

@valff nous a rappelé que la syntaxe du mot-clé expr await postfix correspondrait le plus parfaitement à l' attribution de type généralisée : https://github.com/rust-lang/rust/issues/57640#issuecomment -456023146

@quodlibetor a souligné que l'effet syntaxique des combinateurs d'erreur et d'option est unique à Rust et plaide en faveur de la syntaxe postfix: https://github.com/rust-lang/rust/issues/57640#issuecomment -456143523

En fin de compte, l'équipe lang va devoir passer un appel ici. Dans l'intérêt d'identifier un terrain d'entente qui pourrait conduire à un consensus, il serait peut-être utile de résumer les positions déclarées des membres de l'équipe lang sur la question clé de la syntaxe postfix:

• @Centril a exprimé son soutien à la syntaxe postfix et a exploré un certain nombre de variations dans ce ticket. Centril ne veut particulièrement await!(expr) .

• @cramertj a exprimé son soutien pour la syntaxe postfix et spécifiquement pour la syntaxe du mot clé expr await postfix.

• @joshtriplett a exprimé son soutien à la syntaxe postfix et a suggéré que nous devrions également fournir une version de préfixe.

• @scottmcm a exprimé son soutien à la syntaxe postfix.

• @withoutboats ne veut pas stabiliser une syntaxe de macro. Tout en étant préoccupé par l'épuisement de notre "budget de non-familiarité", withoutboats considère que la syntaxe du mot-clé expr await postfix a "une vraie chance".

• @aturon , @eddyb , @nikomatsakis et @pnkfelix n'ont encore exprimé aucune position concernant la syntaxe dans les numéros 57640 ou # 50547.

Donc, les choses dont nous avons besoin pour trouver une réponse oui / non:

• Devrions-nous avoir une syntaxe de préfixe?
• Devrions-nous avoir une syntaxe postfix?
• Devrions-nous avoir une syntaxe de préfixe maintenant et comprendre la syntaxe de postfix plus tard?

Si nous choisissons la syntaxe de préfixe, il y a deux principaux prétendants que je pense que les gens acceptent le plus: Utile et Évident, comme on le voit dans ce commentaire . Les arguments contre await!() sont assez forts, donc je considère que cela est exclu. Nous devons donc déterminer si nous voulons une syntaxe utile ou évidente. À mon avis, nous devrions opter pour la syntaxe qui utilise le moins de parenthèses en général.

Et en ce qui concerne la syntaxe postfix, c'est plus compliqué. Il existe également de solides arguments pour le mot-clé postfix await avec espace. Mais cela dépend beaucoup de la façon dont le code est formaté. Si le code est mal formaté, le mot-clé suffixe await avec espace peut sembler vraiment mauvais. Donc, d'abord, nous devrions supposer que tout le code Rust sera formaté correctement avec rustfmt, et que rustfmt divisera toujours les attentes chaînées en différentes lignes, même si elles tiendraient sur une seule ligne. Si nous pouvons faire cela, alors cette syntaxe est très correcte, car elle résout le problème de la lisibilité et de la confusion avec les espaces au milieu d'une chaîne sur une seule ligne.

Et enfin, si nous utilisons à la fois le préfixe et le suffixe, nous devons comprendre et noter la sémantique des deux syntaxes pour voir comment elles interagissent l'une avec l'autre et comment l'une serait convertie en l'autre. Il devrait être possible de le faire, car choisir entre postfix ou prefix await ne devrait pas changer la façon dont le code est exécuté.

Pour clarifier mon processus de pensée, et comment j'aborde et évalue les propositions de syntaxe de surface. await ,
voici les objectifs que j'ai (sans aucun ordre d'importance):

1. await devrait rester un mot-clé pour permettre la conception future du langage.
2. La syntaxe devrait sembler de première classe.
3. L'attente doit être chaînable pour bien composer avec ? et les méthodes en général puisqu'elles sont répandues dans Rust. Il ne faut pas être obligé de créer des liaisons temporaires let qui peuvent ne pas être des subdivisions significatives.
4. Il devrait être facile de grep pour attendre des points.
5. Il devrait être possible de voir les points d'attente en un coup d'œil.
6. La priorité de la syntaxe doit être intuitive.
7. La syntaxe doit bien s'adapter aux IDE et à la mémoire musculaire.
8. La syntaxe doit être facile à apprendre.
9. La syntaxe doit être ergonomique à écrire.

Après avoir défini (et probablement oublié ...) certains de mes objectifs, voici un résumé et mon évaluation de quelques propositions par rapport à ceux-ci:

1. En conservant await comme mot-clé, il est difficile d'utiliser une syntaxe basée sur une macro, que ce soit await!(expr) ou expr.await!() . Pour utiliser une syntaxe de macro, await tant que macro devient soit codé en dur et non intégré à la résolution de nom (c'est- use core::await as foo; dire que await est entièrement abandonné en tant que mot clé.

2. Je crois que les macros ont un sentiment distinctement non de première classe à leur sujet car elles sont destinées à inventer la syntaxe dans l'espace utilisateur. Bien que ce ne soit pas un point technique, l'utilisation de la macro syntaxe dans une telle construction centrale du langage donne une impression impolie. On peut soutenir que les syntaxes .await et .await() ne sont pas non plus les syntaxes de première classe; mais pas aussi de seconde classe que les macros le sentiraient.

3. Le désir de faciliter le chaînage fait que toute syntaxe de préfixe fonctionne mal alors que les syntaxes postfixes composent naturellement avec des chaînes de méthodes et ? en particulier.

4. La grepping est plus facile lorsque le mot-clé await est utilisé, qu'il s'agisse d'un suffixe, d'un préfixe, d'une macro, etc. Lorsqu'une syntaxe basée sur un sigil est utilisée, par exemple # , @ , ~ , le grepping devient plus difficile. La différence n'est pas grande, mais .await est légèrement plus facile à grep pour que await et await car l'un ou l'autre de ces éléments peut être inclus en tant que mots dans les commentaires alors qu'il est plus improbable pour .await .

5. Les sigils sont probablement plus difficiles à repérer en un coup d'œil, tandis que await est plus facile à voir et surtout la syntaxe mise en évidence. Il a été suggéré que .await ou d'autres syntaxes postfixes sont plus difficiles à repérer en un coup d'œil ou que postfix await offre une mauvaise lisibilité. Cependant, à mon avis, @scottmcm note à juste titre que les futurs des résultats sont courants et que .await? aide à attirer davantage l'attention sur lui-même. De plus, Scott note que le préfixe await conduit à des phrases de chemin de jardin et que le préfixe attendre au milieu des expressions n'est pas plus lisible que postfix. Avec l'avènement de l'opérateur ? , les programmeurs Rust ont déjà besoin de scanner la fin des lignes pour rechercher le flux de contrôle .

6. La précédence de .await et .await() est remarquable pour être complètement prévisible; ils fonctionnent comme leurs homologues d'accès sur le terrain et d'appel de méthode. Une macro de suffixe aurait vraisemblablement la même priorité qu'un appel de méthode. Pendant ce temps, le préfixe await a soit une priorité cohérente, prévisible et inutile par rapport à ? (c'est- await (expr?) dire (await expr)? dire ? ).

7. En 2012, @nikomatsakis a noté que Simon Peyton Jones a noté une fois (p. 56) qu'il était envieux de la "puissance du point" et de la façon dont il fournit la magie de l'IDE par lequel vous pouvez restreindre la fonction ou le champ que vous voulez dire. Puisque la puissance du point existe dans de nombreux langages populaires (par exemple Java, C #, C ++, ..), cela a conduit à "atteindre le point" enraciné dans la mémoire musculaire. Pour illustrer la puissance de cette habitude, voici une capture d'écran, due à @scottmcm , de Visual Studio avec Re # er:
   

   C # n'a pas de postfix en attente. Néanmoins, cela est si utile qu'il est affiché dans une liste de saisie semi-automatique sans être une syntaxe valide. Cependant, il peut ne pas arriver à beaucoup, moi y compris, d'essayer .aw quand .await n'est pas la syntaxe de la surface. Considérez les avantages de l'expérience IDE si c'était le cas. Les syntaxes await expr et expr await n'offrent pas cet avantage.

8. Les sigils offriraient probablement une faible familiarité. Le préfixe await a l'avantage d'être familiarisé avec C #, JS, etc. Cependant, ceux-ci ne séparent pas await et ? en opérations distinctes contrairement à Rust. Il n'est pas non plus exagéré de passer de await expr à expr.await - le changement n'est pas aussi radical que d'aller avec un sceau. De plus, en raison de la puissance des points susmentionnée, il est probable que .await sera appris en tapant expr. et en voyant await comme première option dans la fenêtre contextuelle d'auto-complétion.

9. Les sigils sont faciles à écrire et offriraient une bonne ergonomie. Cependant, bien que .await soit plus long à taper, il est également livré avec des pouvoirs de points qui peuvent rendre l'écriture encore meilleure. Le fait de ne pas avoir à pénétrer dans des déclarations let facilite également une meilleure ergonomie. Le préfixe await , ou pire encore await!(..) , manque à la fois de pouvoirs de points et de capacités de chaînage. Quand on compare .await , .await() et .await!() , les premières offres sont les plus concises.

Comme aucune syntaxe n'est la meilleure pour atteindre tous les objectifs simultanément, un compromis doit être fait. Pour moi, la syntaxe avec le plus d'avantages et le moins d'inconvénients est .await . Notamment, il peut être enchaîné, préserve await comme mot-clé, est greppable, a des pouvoirs de points et est donc apprenable et ergonomique, a une priorité évidente et est enfin lisible (surtout avec un bon formatage et mise en évidence).

@Centril Juste pour clarifier quelques questions. Tout d'abord, je voudrais simplement confirmer que vous ne voulez que postfix attendre, non? Deuxièmement, comment aborder la dualité de .await étant un accès de champ? Serait-il correct d'avoir .await comme tel, ou devrait-on privilégier .await() avec les parenthèses de manière à impliquer qu'une sorte d'opération se produit là-bas? Et troisièmement, avec la syntaxe .await , est-ce que Wait serait le mot-clé ou simplement un identifiant "d'accès au champ"?

Tout d'abord, je voudrais simplement confirmer que vous ne voulez que postfix attendre, non?

Oui. Au moins maintenant.

Deuxièmement, comment aborder la dualité de .await étant un accès de champ?

C'est un léger inconvénient; il y a un avantage majeur dans la puissance du point. La distinction est quelque chose que je pense que les utilisateurs apprendront rapidement, d'autant plus qu'il s'agit d'un mot clé mis en évidence et que la construction sera utilisée fréquemment. De plus, comme Scott l'a noté, .await? sera le plus courant, ce qui devrait encore améliorer la situation. Il devrait également être facile d'ajouter une nouvelle entrée de mot-clé pour await dans rustdoc, comme nous l'avons fait pour fn .

Serait-il correct d'avoir .await comme tel, ou devrait-on privilégier .await() avec les parenthèses de manière à impliquer qu'une sorte d'opération se produit là-bas?

Je préfère .await sans queue () ; avoir () à la fin semble être du sel inutile dans la majorité des cas et, je suppose, rendrait les utilisateurs plus enclins à rechercher la méthode.

Et troisièmement, avec la syntaxe .await , est-ce que Wait serait le mot-clé ou juste un identifiant "field access"?

await resterait un mot-clé. Vraisemblablement, vous changeriez libsyntax de manière à ne pas commettre d'erreur lors de la rencontre de await après . , puis le représenteriez différemment dans AST ou lors de la réduction à HIR ... mais c'est surtout un détail d'implémentation .

Merci d'avoir clarifié tout cela! 👍

À ce stade, le problème clé semble être de savoir s'il faut adopter une syntaxe postfixe. Si c'est la direction, alors nous pouvons certainement nous limiter à laquelle. En lisant la salle, la plupart des partisans de la syntaxe postfix accepteraient toute syntaxe postfix raisonnable sur la syntaxe de préfixe.

Entrant dans ce fil, la syntaxe de postfix semblait être l'opprimé. Cependant, il a attiré le soutien clair de quatre membres de l'équipe lang et l'ouverture d'un cinquième (les quatre autres étant restés silencieux jusqu'à présent). De plus, il a attiré un soutien considérable de la part de la communauté plus large qui a commenté ici.

De plus, les partisans de la syntaxe postfix semblent être clairement convaincus que c'est la meilleure voie pour Rust. Il semble qu'un problème profond ou des réfutations convaincantes aux arguments avancés jusqu'à présent seraient nécessaires pour revenir sur ce soutien.

Compte tenu de cela, il semble que nous ayons besoin d'entendre @withoutboats , qui a sûrement suivi ce fil de près, et les quatre autres membres de l'équipe lang. Leurs opinions seront probablement le moteur de ce fil. S'ils ont des préoccupations, en discuter serait la priorité. S'ils sont convaincus du bien-fondé de la syntaxe postfix, alors nous pouvons passer à la recherche d'un consensus pour lequel.

Oups, je viens de remarquer que @Centril avait déjà commenté, alors je vais cacher mon message pour la propreté.

@ivandardi Compte tenu de l'objectif (1) du message, je crois comprendre que await serait toujours un mot-clé, donc ne serait jamais un accès au champ, de la même manière que loop {} n'est jamais une expression littérale struct. Et je m'attendrais à ce qu'il soit mis en évidence pour rendre le plus évident (comme https://github.com/rust-lang/rust-enhanced/issues/333 attend à faire dans Sublime).

Ma seule préoccupation est que faire en sorte que la syntaxe d'attente ressemble à un accès différent pourrait potentiellement causer de la confusion dans une base de code édition 2015 sans s'en rendre compte. (2015 est la valeur par défaut lorsqu'elle n'est pas spécifiée, ouvrant le projet de quelqu'un d'autre, etc.) Tant que l'édition 2015 a une erreur claire lorsqu'il n'y a pas await champ

Oh, et une chose que nous devrions également décider pendant que nous y sommes, c'est comment rustfmt finirait par le formater.

let val = await future;
let val = await returns_future();
let res = client.get("https://my_api").await send()?.await json()?;

1. Utilise await - chèque
2. Première classe - vérifier
3. Chaînage - vérifier
4. Grepping - vérifier
5. Non sigil - chèque
6. Priorité - ¹check
7. Puissance de point - ²check
8. Facile à apprendre - ³check
9. Ergonomique - vérifier

¹Précédence: l'espace après await rend pas évident en position différée. Cependant, c'est exactement la même chose que sur le code suivant: client.get("https://my_api").await_send()?.await_json()? . Pour tous les anglophones, c'est encore plus naturel qu'avec toutes les autres propositions

² Puissance des points: il faudrait un support supplémentaire pour l'EDI pour déplacer await vers la gauche de l'appel de méthode après que . , ? ou ; soit tapé ensuite. Ne semble pas être trop difficile à mettre en œuvre

³Facile à apprendre: en position préfixe, il est déjà familier aux programmeurs. En position différée, ce serait évident après la stabilisation de la syntaxe

Mais le point le plus fort de cette syntaxe est qu'elle sera très cohérente:

• Il ne peut pas être confondu avec l'accès à la propriété
• Il a une priorité évidente avec ?
• Il aura toujours le même formatage
• Cela correspond au langage humain
• Il n'est pas affecté par l'occurrence horizontale variable dans la chaîne d'appels de méthode *

Avec la variante postfixe, il est difficile de prédire quelle fonction est async et où serait la prochaine occurrence de await sur l'axe horizontal:

let res = client.get("https://my_api")
    .very_long_method_name(param, param, param).await?
    .short().await?;

Avec une variante différée, ce serait presque toujours la même chose:

let res = client.get("https://my_api")
    .await very_long_method_name(param, param, param)?
    .await short()?;

N'y aurait-il pas un. entre l'attente et le prochain appel de méthode? Comme
get().await?.json() .

Le mercredi 23 janvier 2019, 05:06 I60R < [email protected] a écrit:

let val = attendre le futur;
let res = client.get ("https: // mon_api") .await send () ?. await json () ?;

1. Les utilisations attendent - vérifier
2. Première classe - vérifier
3. Chaînage - vérifier
4. Grepping - vérifier
5. Non sigil - chèque
6. Priorité - ¹check
7. Puissance de point - ²check
8. Facile à apprendre - ³check
9. Ergonomique - vérifier

---

¹Précédence: l'espace ne le rend pas évident en position différée. Cependant c'est
exactement la même chose que sur le code suivant: client.get ("https: // my_api
") .await_send () ?. await_json () ?. Pour tous les anglophones, c'est encore plus
naturel qu'avec toutes les autres propositions

² Puissance de point: il faudrait un support supplémentaire pour que l'EDI passe à
la gauche de l'appel de méthode après. ou ? est tapé ensuite. Ne semble pas être trop
difficile à mettre en œuvre

³Facile à apprendre: en position préfixe, il est déjà familier aux programmeurs,
et en position différée, il serait évident après que la syntaxe soit

stabilisé

Mais le point le plus fort de cette syntaxe est qu'elle sera très
cohérent:

• Il ne peut pas être confondu avec l'accès à la propriété
• Il a une priorité évidente avec?
• Il aura toujours le même formatage
• Cela correspond au langage humain
• Il n'est pas affecté par l'occurrence horizontale variable dans l'appel de méthode
  chaîne*

* l'explication est cachée sous le spoiler

Avec la variante postfix, il est difficile de prédire quelle fonction est asynchrone et
où serait la prochaine occurrence de wait sur l'axe horizontal:

let res = client.get ("https: // mon_api")

.very_long_method_name(param, param, param).await?

.short().await?;

Avec une variante différée, ce serait presque toujours la même chose:

let res = client.get ("https: // mon_api")

.await very_long_method_name(param, param, param)?

.await short()?;

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/rust-lang/rust/issues/57640#issuecomment-456693759 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AIA8Ogyjc8LW6teZnXyzOCo31-0GPohTks5vGAoDgaJpZM4aBlba
.

nous devrions également décider pendant que nous y sommes, comment rustfmt finirait par le formater

C'est le domaine de https://github.com/rust-dev-tools/fmt-rfcs , donc je dirais que c'est hors sujet pour cette question. Je suis sûr qu'il y aura quelque chose qui sera compatible avec la correction et la priorité choisies.

@ I60R

let res = client.get("https://my_api").await send()?.await json()?;

À quoi cela ressemblerait-il pour les fonctions gratuites? Si je lis bien, c'est en fait un préfixe await .

Je pense que cela montre que nous ne devrions pas être aussi prompts à discréditer l'expérience de l'équipe du langage C #. Microsoft réfléchit beaucoup aux études d'utilisabilité, et nous prenons ici une décision basée sur une seule ligne de code et sur le principe que Rust est suffisamment spécial pour avoir une syntaxe différente de celle de tous les autres langages. Je ne suis pas d'accord avec cette prémisse - j'ai mentionné ci-dessus LINQ et les méthodes d'extension étant omniprésentes en C #.

Cependant, il peut ne pas arriver à beaucoup, moi y compris, d'essayer .aw quand .await n'est pas la syntaxe de la surface.

~ Je ne pense pas que cela arrivera à quelqu'un qui connaît les autres langues. ~ Cela mis à part, vous attendriez-vous à ce que la fenêtre contextuelle de complétion inclue à la fois les méthodes await et Future ?

[...] et nous prenons ici une décision basée sur une seule ligne de code et sur le principe que Rust est suffisamment spécial pour avoir une syntaxe différente de celle de tous les autres langages. Je ne suis pas d'accord avec cette prémisse [...]

@lnicola Je veux juste le signaler au cas où vous et d'autres l'auriez manqué (il est facile de le rater dans le déluge de commentaires): https://github.com/rust-lang/rust/issues/57640#issuecomment -455846086

Plusieurs exemples réels tirés du code de production réel.

Compte tenu du commentaire de @Centril ci - expr await et la syntaxe du champ expr.await postfix (et peut-être que la syntaxe de la méthode postfix n'est pas encore disponible).

Comparé au mot clé postfix, @Centril soutient que le champ postfix bénéficie de "la puissance du point" - que les IDE peuvent être mieux en mesure de le suggérer comme une autocomplétion - et que les instances de son utilisation peuvent être plus faciles à trouver avec grep car le point de tête fournit une clarification de l'utilisation du mot dans les commentaires.

Inversement, @cramertj a plaidé en faveur de la syntaxe des mots-clés postfix au motif qu'une telle syntaxe indique clairement qu'il ne s'agit pas d'un appel de méthode ou d'un accès à un champ. @withoutboats a soutenu que le mot-clé postfix est la plus familière des options de postfix.

En ce qui concerne "la puissance du point", nous devons considérer qu'un IDE pourrait toujours offrir await comme complétion après un point et ensuite simplement supprimer le point lorsque la complétion est sélectionnée. Un IDE suffisamment intelligent (par exemple avec RLS) pourrait même remarquer le futur et offrir await après un espace.

Le champ postfix et les options de méthode semblent offrir la plus grande surface pour les objections, en raison de l'ambiguïté, par rapport au mot clé postfix. Comme une partie de la prise en charge du champ / méthode postfix sur le mot clé postfix semble provenir d'un léger malaise avec la présence de l'espace dans le chaînage de méthodes, nous devrions examiner et nous engager avec l' observation de @valff selon laquelle le mot clé postfix ( foo.bar() await ) n'aura pas l'air plus surprenant que l'attribution de type généralisée ( foo.bar() : Result<Vec<_>, _> ). Pour les deux, le chaînage se poursuit après cet interlude séparé par des espaces.

@ivandardi , @lnicola ,

J'ai mis à jour mon commentaire récent avec un exemple manquant pour un appel de fonction gratuit. Si vous voulez plus d'exemples, vous pouvez vous référer au dernier spoiler dans mon commentaire précédent

Dans l'intérêt de débattre future.await? vs future await? ...

Quelque chose qui n'est pas trop discuté est le regroupement visuel ou la grepping d'une chaîne de méthodes.

consider ( match au lieu de await pour la coloration syntaxique)

post(url).multipart(form).send().match?.error_for_status()?.json().match?

par rapport à

post(url).multipart(form).send() match?.error_for_status()?.json() match?

Quand je scanne visuellement la première chaîne pour await j'identifie clairement et rapidement send().await? et je vois que nous attendons le résultat du send() .

Cependant, lorsque je scanne visuellement la deuxième chaîne pour await , je commence par voir await?.error_for_status() et je dois aller, non, sauvegarder, puis connecter send() await ensemble.

Oui, certains de ces mêmes arguments s'appliquent à l'attribution de type généralisée, mais ce n'est pas encore une fonctionnalité acceptée. Bien que j'aime l'attribution de type dans un sens, je pense que dans un contexte d'expression _general_ (vague, je sais), il devrait être exigé d'être enveloppé de parens. Tout cela est hors sujet pour cette discussion. Gardez également à l'esprit que le montant de await dans une base de code a un changement important en étant significativement plus élevé que le montant de l'attribution de type.

L'attribution de type généralisée lie également le type à l'expression attribuée via l'utilisation d'un opérateur distinct : . Tout comme tout autre opérateur binaire, sa lecture montre (visuellement) clairement que les deux expressions sont un seul arbre. Alors que future await n'a pas d'opérateur et pourrait facilement être confondu avec future_await par habitude de voir rarement deux noms non séparés par un opérateur sauf si le premier est un mot-clé (des exceptions s'appliquent, ce n'est pas dire que je préfère la syntaxe de préfixe, je ne le fais pas).

Comparez cela à l'anglais si vous voulez, où un trait d'union ( - ) est utilisé pour regrouper visuellement des mots qui autrement seraient facilement interprétés comme séparés.

Je pense que cela montre que nous ne devrions pas être aussi prompts à discréditer l'expérience de l'équipe du langage C #.

Je ne pense pas que «si vite» et «discréditer» soient justes ici. Je pense que la même chose se produit ici qui s'est produite dans le RFC async / wait lui-même: examiner attentivement pourquoi cela a été fait dans un sens, et déterminer si l'équilibre sort de la même manière pour nous. L'équipe C # est même mentionnée explicitement dans un:

• 2394-async_await.md # polymorphic-return-a-non-factor-for-us
• 2394-async_await.md # hot-async-functions

Je pensais que l'idée de await était que vous vouliez réellement le résultat, pas l'avenir
alors peut-être que la syntaxe d'attente devrait être plus comme la syntaxe 'ref'

let future = task()
mais
let await result = task()

donc pour enchaîner vous devriez faire soit

task().chained_method(|future| { /* do something with future */ })

mais

task().chained_method(|await result| { /* I've got the result */ })

- foo.await             // NOT a real field
- foo.await()           // NOT a real method
- foo.await!()          // NOT a real macro

Ils fonctionnent tous bien avec le chaînage, et tous ont des inconvénients qui ne sont pas de vrais champs / méthodes / macro.
Mais puisque await , en tant que mot-clé, est déjà une chose spéciale, nous n'avons pas besoin de le rendre plus spécial.
Nous devrions simplement sélectionner le plus simple, foo.await . () et !() sont redondants ici.

@liigo

- foo await        // IS neither field/method/macro, 
                   // and clearly seen as awaited thing. May be easily chained. 
                   // Allow you to easily spot all async spots.

@mehcode

Lorsque je scanne visuellement la première chaîne pour wait, j'identifie clairement et rapidement send (). et voyez que nous attendons le résultat de send ().

J'aime plus la version espacée, car il est beaucoup plus facile de voir où se construit l'avenir et où il est attendu. Il est beaucoup plus facile de voir ce qui se passe, à mon humble avis

Avec la séparation par points, cela ressemble beaucoup à un appel de méthode. La mise en évidence du code n'aidera pas beaucoup et elle n'est pas toujours disponible.

Enfin, je pense que le chaînage n'est pas le cas d'utilisation principal (sauf pour ? , mais foo await? est aussi clair que possible), et avec l'attente simple, cela devient

post(url).multipart(form).send().match?

contre

post(url).multipart(form).send() match?

Où ce dernier a l'air beaucoup plus maigre imo.

Donc, si nous avons réduit à future await et future.await , pouvons-nous simplement rendre le "point" magique facultatif? Pour que les gens puissent choisir celui qu'ils veulent et, surtout, arrêter les disputes et aller de l'avant!

Il n'est pas dangereux d'avoir une syntaxe facultative, Rust en a beaucoup d'exemples. le plus connu est le dernier sperator ( ; ou , ou autre, après le dernier élément, comme dans (A,B,) ) sont pour la plupart facultatifs. Je n'ai pas vu de raison valable pour laquelle nous ne pouvons pas rendre le point facultatif.

Je pense que ce serait le bon moment pour faire cela dans Nightly et laisser l'écosystème décider lequel est le meilleur pour eux. Nous pouvons avoir des lints pour appliquer le style préféré, le rend personnalisable.

Ensuite, avant d'atterrir chez Stable, nous examinons l'utilisation de la communauté et décidons si nous devons en choisir un ou simplement laisser les deux.

Je ne suis pas du tout d'accord avec l'idée que les macros ne se sentiraient pas assez de première classe pour cette fonctionnalité (je ne la considérerais pas comme une fonctionnalité essentielle en premier lieu) et je voudrais souligner à nouveau mon commentaire précédent sur await!() (peu importe si le préfixe ou le suffixe) n'est pas une "vraie macro", mais je suppose qu'à la fin, trop de gens veulent que cette fonctionnalité soit stabilisée dès que possible, plutôt que de bloquer cela sur les macros postfix et le préfixe wait n'est vraiment pas un bon ajustement pour Rust.

Dans tous les cas, verrouiller ce fil pendant une journée n'a beaucoup aidé et je vais me désabonner maintenant. N'hésitez pas à me mentionner si vous répondez directement à l'un de mes points.

Mon argument contre la syntaxe avec . est que await n'est pas un champ et donc il ne devrait pas ressembler à un champ. Même avec la coloration syntaxique et la police en gras, cela ressemblera à un champ en quelque sorte . suivi d'un mot est fortement associé à l'accès au champ.

Il n'y a aucune raison d'utiliser la syntaxe avec . pour une meilleure intégration IDE non plus, car nous serions en mesure d'autoriser n'importe quelle syntaxe différente avec l'achèvement . en utilisant quelque chose comme la fonction d'achèvement postfixe disponible dans Intellij IDEA.

Nous devons percevoir await comme un mot clé de flux de contrôle. Si nous décidons fortement d'opter pour postfix await , alors nous devrions envisager une variante sans . et je propose d'utiliser le formatage suivant pour mieux souligner les points de blocage avec une interruption possible:

async fn request_user(self, user_id: String) -> Result<User> {
    let url = format!("users/{}/profile", user_id);
    let user = self.request(url, Method::GET, None, true)
        await?.res.json::<UserResponse>()
        await?.user
        .into();
    Ok(user)
}

// A
if db.is_trusted_identity(recipient.clone(), message.key.clone()) 
    await? {
    info!("recipient: {}", recipient);
}

// B
match db.load(message.key)
    await? {
    Some(key) => key,
    None => {
        return Err(/* [...] */);
    }
};

// C
let mut res = client.get(&script_src)
    .header("cookie", self.cookies.read().as_header_value())
    .header("user-agent", USER_AGENT)
    .send()
    await?.error_for_status()?;

// D
let mut res: InboxResponse = client.get(inbox_url)
    .headers(inbox_headers)
    .send()
    await?.error_for_status()?
    .json()
    await?;

// E
let mut res: Response = client.post(url)
    .multipart(form)
    .headers(headers.clone())
    .send()
    await?.error_for_status()?
    .json()
    await?;

async fn request_user(self, user_id: String) -> Result<User> {
    let url = format!("users/{}/profile", user_id);
    let user = self.request(url, Method::GET, None, true)
        yield?.res.json::<UserResponse>()
        yield?.user
        .into();
    Ok(user)
}

// A
if db.is_trusted_identity(recipient.clone(), message.key.clone()) 
    yield? {
    info!("recipient: {}", recipient);
}

// B
match db.load(message.key)
    yield? {
    Some(key) => key,
    None => {
        return Err(/* [...] */);
    }
};

// C
let mut res = client.get(&script_src)
    .header("cookie", self.cookies.read().as_header_value())
    .header("user-agent", USER_AGENT)
    .send()
    yield?.error_for_status()?;

// D
let mut res: InboxResponse = client.get(inbox_url)
    .headers(inbox_headers)
    .send()
    yield?.error_for_status()?
    .json()
    yield?;

// E
let mut res: Response = client.post(url)
    .multipart(form)
    .headers(headers.clone())
    .send()
    yield?.error_for_status()?
    .json()
    yield?;

Cela pourrait également être une réponse au point @ivandardi sur le formatage

Je trouve que tous ces exemples pour postfix attendent d'être plus contre cela que pour cela. Les longues chaînes d'attente se sentent mal, et l'enchaînement devrait être réservé aux futurs combinateurs.

Comparez (avec la chose match as await pour la coloration syntaxique):

post(url)?.multipart(form).send()?.match?.error_for_status()?.json().match?

à

let value = await post(url)?.multipart(form).send()?.error_for_status()
                 .and_then(|resp| resp.json()) // and then parse JSON

// now handle errors

Remarquez le manque d'attente au milieu? Parce que le chaînage peut généralement être résolu par une meilleure conception d'API. Si send() retourne un futur personnalisé avec des méthodes supplémentaires, par exemple pour convertir des messages d'état non 200 en erreurs matérielles, alors il n'y a pas besoin d'attentes supplémentaires. À l'heure actuelle, en reqwest au moins, il semble fonctionner sur place et produire un simple Result plutôt qu'un nouvel avenir, d'où vient le problème.

Le chaînage attend est une forte odeur de code à mon avis, et .await ou .await() confondra tellement de nouveaux utilisateurs que ce n'est même pas drôle. .await ressemble particulièrement à quelque chose de Python ou PHP, où les accès aux membres variables peuvent par magie avoir un comportement spécial.

await devrait être une évidence, comme si on disait: "avant de continuer, nous attendons ce" non "et ensuite, nous attendons cela". Ce dernier est littéralement le combinateur and_then .

Une autre façon potentielle d'y penser est de considérer les expressions et les futurs async / await comme des itérateurs. Ils sont tous les deux paresseux, peuvent avoir de nombreux états et peuvent être terminés par la syntaxe ( for-in pour les itérateurs, await pour les futures). Nous ne proposerions pas une extension de syntaxe pour les itérateurs pour les enchaîner en tant qu'expressions régulières comme nous le sommes ici, non? Ils utilisent des combinateurs pour le chaînage, et les opérations / futures asynchrones devraient faire de même, ne se terminant qu'une seule fois. Cela fonctionne plutôt bien.

Enfin, et surtout, je veux pouvoir parcourir verticalement les premiers tirets d'une fonction et voir clairement où les opérations asynchrones se produisent. Ma vision n'est pas si belle, et avoir des attentes à la fin de la ligne ou coincé au milieu rendrait les choses tellement plus difficiles que je pourrais simplement rester avec des futurs bruts.

Tout le monde s'il vous plaît lire ce billet de blog avant de commenter.

Async / await n'est pas une question de commodité. Il ne s'agit

Il s'agit de permettre de nouvelles choses qui ne peuvent pas être faites avec des combinateurs.

Ainsi, toute suggestion de "utilisons plutôt des combinateurs" est hors sujet et devrait être discutée ailleurs.

Remarquez le manque d'attente au milieu? Parce que le chaînage peut généralement être résolu par une meilleure conception d'API.

Vous n'obtiendrez pas une jolie chaîne dans un vrai exemple asynchrone. Exemple réel:

req.into_body().concat2().and_then(move |chunk| {
    from_slice::<Update>(chunk.as_ref())
        .into_future()
        .map_err(|_| {
            ...
        })
        .and_then(|update| {
            ...
        })
        .and_then(move |(user, file_id, chat_id, message_id)| {
            do_thing(&file_id)
                .and_then(move |file| {
                    if some_cond {
                        Either::A(do_yet_another-thing.and_then(move |bytes| {
                            ...

                            if another_cond {
                                ...
                                Either::A(
                                    do_other_thing()
                                        .then(move |res| {
                                            ...
                                        }),
                                )
                            } else {
                                Either::B(future::ok(()))
                            }
                        }))
                    } else {
                        Either::B(future::ok(()))
                    }
                })
                .map_err(|e| {
                    ...
                })
        })
        // ...and here we unify both paths
        .map(|_| {
            Response::new(Body::empty())
        })
        .or_else(Ok)
})

Les combinateurs n'aident pas ici. L'imbrication peut être supprimée, mais ce n'est pas facile (j'ai essayé deux fois et j'ai échoué). Vous avez des tonnes de Either:A(Either:A(Either:A(...))) à la fin.

OTOH c'est facilement résolu avec async / await .

@Pauan l' a écrit avant que je termine mon message. Ainsi soit-il. Ne mentionnez pas les combinateurs, async/await ne devrait pas se ressembler. C'est bien si c'est le cas, il y a des choses plus importantes à considérer.

Le vote négatif de mon commentaire ne rendra pas les combinateurs plus pratiques.

En lisant le commentaire d'attribution de type , je me demandais à quoi cela ressemblerait combiné avec await . Compte tenu de la réservation que certaines personnes ont avec .await ou .await() comme champs de membre / accès aux méthodes déroutants, je me demande si une syntaxe générale d '"attribution" pourrait être une option, (c'est-à-dire, "donnez-moi ce que await renvoie ").

Utilisation de yield pour await pour la coloration syntaxique

let result = connection.fetch("url"):yield?.collect_async():yield?;

Combiné avec l'attribution de type, par exemple:

let result = connection.fetch("url") : yield?
    .collect_async() : yield Vec<u64>?;

Avantages: toujours joli (IMHO), syntaxe différente de l'accès champ / méthode.
Inconvénients: conflits potentiels avec l'attribution de type (?), Plusieurs attributions théoriquement possibles:

foo():yield:yield

Edit: Il m'est venu à l'esprit que l'utilisation de 2 attributions serait plus logique dans l'exemple combiné:

let result = connection.fetch("url") : yield?
    .collect_async() : yield : Vec<u64>?;

@Pauan, il serait inapproprié de surappliquer ce billet de blog. Les combinateurs peuvent être appliqués en conjonction avec la syntaxe d'attente pour éviter les problèmes décrits.

Le problème central a toujours été qu'un futur engendrable devait être 'static , mais si vous capturiez des variables par référence dans ces combinateurs, vous vous retrouviez avec un futur qui n'était pas 'static . Mais attendre un futur non- 'static ne rend pas le fn asynchrone dans lequel vous êtes pas 'static . Vous pouvez donc faire des choses comme ceci:

`` rouille
// tranche: & [T]

let x = attendre le futur.et_alors (| i | si la tranche.contains (i) {async_fn (tranche)});

Donc, je prévoyais de ne pas commenter du tout, mais je voulais ajouter quelques notes de quelqu'un qui n'écrit pas beaucoup de code asynchrone, mais qui devra quand même le lire:

• Le préfixe await est beaucoup plus facile à remarquer. C'est à la fois lorsque vous l'attendez (à l'intérieur d'un async fn) ou à l'extérieur (dans l'expression d'un corps de macro).
• Postfix await étant un mot-clé peut bien se démarquer dans les chaînes avec peu ou pas d'autres mots-clés. Mais dès que vous avez des fermetures ou similaires avec d'autres structures de contrôle, votre awaits deviendra beaucoup moins visible et plus facile à oublier.
• Je trouve que .await comme pseudo champ est très étrange. Ce n'est pas comme n'importe quel autre domaine qui m'importe.
• Je ne sais pas si le recours à la détection IDE et à la coloration syntaxique est une bonne idée. Il est utile de faciliter la lisibilité lorsqu'aucune coloration syntaxique n'est disponible. De plus, avec les discussions récentes sur la complication de la grammaire et les problèmes que cela entraînera pour l'outillage, ce n'est peut-être pas une bonne idée de compter sur les IDE / éditeurs pour faire les choses correctement.

Je ne partage pas le sentiment que await!() tant que macro "ne se sent pas de première classe". Les macros sont un citoyen de première classe dans Rust. Ils ne sont pas non plus là uniquement pour «inventer la syntaxe dans le code utilisateur». De nombreuses macros "intégrées" ne sont format!() est là pour donner au compilateur la puissance de la vérification de type statique des chaînes de format. include_bytes!() n'est pas non plus défini par l'utilisateur et n'est pas là pour de simples raisons syntaxiques, c'est une macro car il doit s'agir d'une extension de syntaxe car, encore une fois, il fait des choses spéciales à l'intérieur du compilateur et il ne pourrait pas raisonnablement être écrit d'une autre manière sans l'ajouter en tant que fonctionnalité de langage de base.

Et c'est un peu mon argument: les macros sont un moyen idéal pour introduire et masquer la magie du compilateur d'une manière uniforme et sans surprise. Await est un bon exemple de ceci: il nécessite une manipulation spéciale, mais son entrée n'est qu'une expression, et en tant que tel, il convient parfaitement à la réalisation à l'aide d'une macro.

Donc, je ne vois pas vraiment la nécessité d'un mot-clé spécial. Cela dit, si cela doit être un mot-clé, alors ce devrait être juste cela, un simple mot-clé - je ne comprends pas vraiment la motivation de le déguiser en champ. Cela semble juste faux, ce n'est pas un accès au champ, ce n'est même pas à distance comme un accès au champ (contrairement, par exemple, aux méthodes getter / setter avec du sucre), donc le traiter comme un est incompatible avec la façon dont les champs fonctionnent aujourd'hui dans la langue.

@ H2CO3 await! macro est bon dans tous les cas, sauf pour deux propriétés:

1. Les accolades supplémentaires sont vraiment ennuyeuses lorsque vous écrivez encore un millier d'attentes. Rust a supprimé les accolades des blocs if/while/... pour (je crois) la même raison. Cela peut sembler sans importance, mais c'est vraiment le cas
2. Asymétrie avec async étant un mot-clé. Async devrait faire quelque chose de plus grand que d'autoriser une seule macro dans le corps de la méthode. Sinon, il pourrait simplement s'agir #[async] attribut mot-clé await . Cette attente peut être causée par l'expérience dans d'autres langues, qui sait, mais je crois fermement qu'elle existe. Il peut ne pas être résolu, mais il doit être pris en considération.

Sinon, il pourrait simplement s'agir #[async] attribut

Cela faisait longtemps, et je suis désolé de le voir disparaître. Nous introduisons un autre mot-clé alors que l'attribut #[async] fonctionnait parfaitement bien, et maintenant avec des macros procédurales de type attribut stables, il serait même cohérent avec le reste du langage à la fois syntaxiquement et sémantiquement, même s'il était toujours connu (et géré spécialement) par le compilateur.

@ H2CO3 quel est le but ou l'avantage d'avoir await comme macro du point de vue de l'utilisateur ? Existe-t-il des macros intégrées qui modifient le flux de contrôle des programmes sous le capot?

@ I60R L'avantage est l'uniformité avec le reste du langage, et donc de ne pas avoir à se soucier encore d'un autre mot-clé, avec tout le bagage qu'il apporterait avec lui-même - par exemple, la priorité et le regroupement sont évidents dans une invocation de macro.

Je ne vois pas pourquoi la deuxième partie est pertinente - ne peut-il pas y avoir une macro intégrée qui fait quelque chose de nouveau? En fait, je pense que pratiquement toutes les macros intégrées font quelque chose de "bizarre" qui ne peut pas (raisonnablement / efficacement / etc.) Être réalisé sans le support du compilateur. await!() ne serait pas un nouvel intrus à cet égard.

J'ai déjà suggéré une attente implicite , et plus récemment suggéré une attente non chaînable .

La communauté semble très fortement en faveur de l'attente explicite (j'aimerais que cela change, mais…). Cependant, la granularité de l'explicitation est ce qui crée le passe-partout (c'est-à-dire en avoir besoin plusieurs fois dans la même expression semble créer du passe-partout).

[ Attention : la suggestion suivante sera controversée, mais veuillez lui donner une chance sincère]

Je suis curieux de savoir si la plupart des membres de la communauté feraient des compromis et permettraient une «attente partielle-implicite»? Peut-être que lire attendre une fois par chaîne d'expression est assez explicite?

await response = client.get("https://my_api").send()?.json()?;

C'est quelque chose qui s'apparente à la déstructuration de la valeur, que j'appelle la déstructuration de l'expression.

// Value de-structuring
let (a, b, c) = ...;

// De-sugars to:
let _abc = ...;
let a = _abc.0;
let b = _abc.1;
let c = _abc.2;

// Expression de-structuring
await response = client.get("https://my_api").send()?.json()?;

// De-sugards to:
// Using: prefix await with explicit precedence
// Since send() and json() return impl Future but ? does not expect a Future, de-structure the expression between those sub-expressions.
let response = await (client.get("https://my_api").send());
let response = await (response?.json());
let response = response?;



md5-eeacf588eb86592ac280cf8c372ef434



```rust
// If needed, given that the compiler knows these expressions creating a, b are independent,
// each of the expressions would be de-structured independently.
await (a, b) = (
    client.get("https://my_api_a").send()?.json()?,
    client.get("https://my_api_b").send()?.json()?,
);
// De-sugars to:
// Not using await syntax like the other examples since await can't currently let us do concurrent polling.
let a: impl Future = client.get("https://my_api_a").send();
let b: impl Future = client.get("https://my_api_b").send();
let (a, b) = (a.poll(), b.poll());
// return if either a or b is NotReady;

let a: impl Future = a?.json();
let b: impl Future = b?.json();
let (a, b) = (a.poll(), b.poll());
// return if either a or b is NotReady;
let (a, b) = (a?, b?);

Je serais également satisfait des autres implémentations de l'idée de base, "lire attendre une fois par chaîne d'expression est probablement assez explicite". Parce que cela réduit le passe-partout, mais aussi cela rend le chaînage possible avec une syntaxe basée sur le préfixe qui est la plus familière à tout le monde.

@yazaddaruvala Il y avait un avertissement ci-dessus, alors soyez prudent.

Je suis curieux de savoir si la plupart des membres de la communauté feraient des compromis et permettraient une «attente partielle-implicite»? Peut-être que lire attendre une fois par chaîne d'expression est assez explicite?

1. Je ne pense pas que la plupart des communautés veulent quelque chose de partiel-implicite. L'approche native de Rust ressemble plus à "tout explicite". Même les lancers u8 -> u32 sont faits explicitement.
2. Cela ne fonctionne pas bien pour des scénarios plus compliqués. Que doit faire le compilateur avec Vec<Future> ?

await response = client.get("https://my_api").send()?.json()?.parse_as::<Vec<String>>()?.map(|x| client.get(x))?;

Doit-on effectuer await pour chaque appel imbriqué? Ok, nous pouvons probablement faire fonctionner wait pour une ligne de code (donc mapFunc imbriqués ne sera pas attendu), mais il est trop facile de briser ce comportement. Si wait fonctionne pour une ligne de code, tout refactoring comme "extraire la valeur" la rompt.

@yazaddaruvala

Dois-je comprendre que vous corrigez dans ce que vous proposez est le préfixe await qui a priorité sur ? avec la possibilité supplémentaire d'utiliser await à la place du mot-clé let pour changer le contexte pour saupoudrer tout impl Future <_ i = "7"> retourne avec wait?

Ce qui signifie que ces trois déclarations ci-dessous sont équivalentes:

// foo.bar() -> Result<impl Future<_>, _>>
let a = await foo.bar()?;
let a = await (foo.bar()?);
await a = foo.bar()?;

Et ces deux déclarations ci-dessous sont équivalentes:

// foo.bar() -> impl Future<Result<_, _>>
await a = foo.bar()?;
let a = await (foo.bar())?;

Je ne suis pas sûr que la syntaxe soit idéale, mais peut-être que le fait d'avoir un mot-clé qui se transforme en «attendre le contexte implicite» rend les problèmes du mot-clé de préfixe moins problématiques. Et en même temps, permettant d'utiliser un contrôle plus fin sur l'endroit où wait est utilisé en cas de besoin.

À mon avis, pour les courts métrages, le préfixe wait a l'avantage d'être similaire à de nombreux autres langages de programmation et de nombreux langages humains . Si à la fin il est décidé qu'attendre ne devrait être qu'un suffixe, je pense que je finirai parfois par utiliser une macro Await!() (ou toute autre forme similaire qui n'entre pas en conflit avec les mots-clés), quand je pense que cela s'appuie sur une connaissance approfondie de la structure des phrases en anglais aidera à réduire la surcharge mentale de lecture / écriture de code. Il y a une valeur certaine dans les formes de suffixe pour des expressions enchaînées plus longues, mais mon point de vue explicitement non basé sur des faits objectifs est que, avec la complexité humaine du préfixe en attente subventionné par la langue parlée, l'avantage de la simplicité de n'avoir qu'une seule forme ne l'emporte pas clairement sur la clarté potentielle du code d'avoir les deux. En supposant que vous faites confiance au programmeur pour choisir celui qui est le plus approprié pour le morceau de code actuel, au moins.

@Pzixel

Je ne pense pas que la plupart des communautés veulent quelque chose de partiel-implicite. L'approche native de Rust ressemble plus à "tout explicite".

Je ne vois pas les choses de la même manière. Je vois qu'il s'agit toujours d'un compromis entre explicite et implicite. Par exemple:

• Les types de variables sont requis dans la portée de la fonction
  
  
  
  • Les types de variables peuvent être implicites dans une portée locale.
  
  
  • Les contextes de fermeture sont implicites
  
  
  • Étant donné que nous pouvons déjà raisonner sur les variables locales.
  
  
• Des durées de vie sont nécessaires pour aider le vérificateur d'emprunt.
  
  
  
  • Mais dans une portée locale, ils peuvent être déduits.
  
  
  • Au niveau de la fonction, les durées de vie n'ont pas besoin d'être explicites, lorsqu'elles ont toutes la même valeur.
  
  
• Je suis sûr qu'il y en a d'autres.

Utiliser await une seule fois par expression / instruction, avec tous les avantages du chaînage, est un compromis très raisonnable entre explicite et réducteur standard.

Cela ne fonctionne pas bien pour des scénarios plus compliqués. Que doit faire le compilateur avec Vec?

await response = client.get("https://my_api").send()?.json()?.parse_as::<Vec<String>>()?.map(|x| client.get(x))?;

Je dirais que le compilateur devrait faire une erreur. Il existe une énorme différence de type qui ne peut être déduite. Pendant ce temps, l'exemple avec Vec<impl Future> n'est résolu par aucune des syntaxes de ce thread.

// Given that json() returns a Vec<imple Future>,
// do I use .await on the `Vec`? That seems odd.
// Given that the client.get() returns an `impl Future`,
// do I .await inside the .map? That wont work, given Iterator methods are not `async`
client.get("https://my_api").send().await?.json()[UNCLEAR]?.parse_as::<Vec<String>>()?.map(|x| client.get(x)[UNCLEAR])?;

Je dirais que le Vec<impl Future> est un mauvais exemple, ou nous devrions maintenir chaque syntaxe proposée au même standard. Pendant ce temps, la syntaxe "attente partielle-implicite" que j'ai proposée fonctionne mieux que les propositions actuelles pour des scénarios plus compliqués comme await (a, b) = (client.get("a")?, client.get("b")?); utilisant un suffixe normal ou un préfixe attendant let (a, b) = (client.get("a") await?, client.get("b") await?); résultats -La version implicite peut être exécutée simultanément par le compilateur désugardant de manière appropriée (comme je l'ai montré dans mon message d'origine).

En 2011, lorsque la fonctionnalité async en C # était encore en test, j'ai demandé que await était un opérateur de préfixe et j'ai obtenu une réponse du PM du langage C #. Puisqu'il y a une discussion sur la question de savoir si Rust devrait utiliser un opérateur de préfixe, j'ai pensé qu'il pourrait être utile de publier cette réponse ici. From Pourquoi 'await' est-il un opérateur préfixe au lieu d'un opérateur postfix? :

Comme vous pouvez l'imaginer, la syntaxe des expressions await a été un énorme point de discussion avant de nous décider sur ce qui est maintenant disponible :-). Cependant, nous n'avons pas beaucoup considéré les opérateurs postfix. Il y a juste quelque chose à propos de postfix (cf. les calculateurs HP et le langage de programmation Forth) qui rend les choses plus simples en principe et moins accessibles ou lisibles en pratique. C'est peut-être juste la façon dont la notation mathématique nous lave le cerveau en tant qu'enfants ...

Nous avons définitivement trouvé que l'opérateur de préfixe (avec sa saveur littéralement impérative - "fais ceci!") Était de loin le plus intuitif. La plupart de nos opérateurs unaires sont déjà préfixes, et await semble correspondre à cela. Oui, il se noie dans les expressions complexes, mais il en va de même pour l'ordre d'évaluation en général, en raison du fait que, par exemple, l'application de fonction n'est pas non plus un suffixe. Vous évaluez d'abord les arguments (qui sont sur la droite) puis appelez la fonction (qui est sur la gauche). Oui, il y a une différence dans cette syntaxe d'application de fonction en C # avec des parenthèses déjà intégrées, alors que pour await, vous pouvez généralement les supprimer.

Ce que je vois au sens large (et que j'ai moi-même adopté) autour de await, c'est un style qui utilise beaucoup de variables temporaires. J'ai tendance à préférer

var bResult = await A().BAsync();
var dResult = await bResult.C().DAsync();
dResult.E()

ou quelque chose comme ça. En général, j'éviterais généralement d'avoir plus d'une attente en tout, sauf les expressions les plus simples (c'est-à-dire qu'ils sont tous des arguments pour la même fonction ou opérateur; ce sont probablement bien) et j'éviterais de mettre entre parenthèses les expressions d'attente, préférant utiliser des locals supplémentaires pour les deux emplois .

Ça a du sens?

Mads Torgersen, PM du langage C #

Mon expérience personnelle en tant que développeur C # est que la syntaxe me pousse à utiliser ce style d'instructions multiples, et que cela rend le code asynchrone beaucoup plus difficile à lire et à écrire que l'équivalent synchrone.

@yazaddaruvala

Je ne vois pas les choses de la même manière. Je vois que c'est toujours un compromis entre explicite et implicite

C'est toujours explicite. Je peux lier un bon article sur le sujet btw .

Je dirais que le compilateur devrait faire une erreur. Il existe une énorme différence de type qui ne peut être déduite. Pendant ce temps, l'exemple avec Vecn'est résolu par aucune des syntaxes de ce fil.

Pourquoi est-ce une erreur? Je suis content d'avoir Vec<impl future> , que je pourrais ensuite rejoindre. Vous proposez des limitations supplémentaires sans raison.

Je dirais que le Vecest un mauvais exemple, ou nous devrions maintenir chaque syntaxe proposée au même standard.

Nous devrions examiner chaque cas. Nous ne pouvons pas simplement ignorer les cas extrêmes parce que "moi, vous savez, personne n'écrit ça de toute façon". La conception du langage concerne principalement les cas de bord.

@chescock Je suis d'accord avec vous, mais étant dit avant, Rust a une très grande différence avec C # ici: en C #, vous n'écrivez jamais (await FooAsync()).Bar() . Mais dans Rust, c'est le cas. Et je parle de ? . En C #, vous avez une exception implicite qui se propage via des appels asynchrones. Mais dans rust, vous devez être explicite et écrire ? sur le résultat de la fonction après l'attente.

Bien sûr, vous pouvez demander aux utilisateurs d'écrire

let foo = await bar();
let bar = await foo?.baz();
let bar = bar?;

mais c'est beaucoup plus étrange que

let foo = await? bar();
let bar = await? foo.baz();

Cela semble beaucoup mieux, mais cela nécessite l'introduction d'une nouvelle combinaison de await et ? doint (await expr)? . De plus, si nous avons d'autres opérateurs, nous pourrions écrire await?&@# et faire fonctionner toutes les combinaisons ... Cela semble un peu compliqué.

Mais alors nous pouvons simplement placer await comme un suffixe et il s'intégrera naturellement dans la langue actuelle:

let foo = bar() await?;
let bar = foo.baz() await?;

maintenant await? est deux jetons séparés, mais ils fonctionnent tout à fait. Vous pouvez avoir await?&@# et vous ne vous soucierez pas de le pirater dans le compilateur lui-même.

Bien sûr, cela semble un peu plus étrange que le préfixe, mais étant dit, tout dépend de la différence Rust / C #. Nous pouvons utiliser l'expérience C # pour être sûr que nous avons besoin d'une syntaxe d'attente explicite qui est susceptible d'avoir un mot-clé séparé, mais nous ne devons pas suivre aveuglément la même manière et ignorer les différences Rust / C #.

J'étais un partisan du préfixe await moi-même pendant longtemps et j'ai même invité des développeurs de langage C # dans le sujet (nous avons donc des informations plus récentes que celles de 2011 😄), mais maintenant je pense que postfix await mot clé

N'oubliez pas qu'il y a une soirée, donc nous pouvons la retravailler plus tard si nous trouvons un meilleur moyen.

Il m'est venu à l'esprit que nous pourrions peut-être tirer le meilleur parti des deux mondes avec une combinaison de:

• un préfixe async mot-clé
• une fonction de macro postfix générale

Ce qui, ensemble, permettrait à une macro de suffixe .await!() d'être implémentée sans la magie du compilateur.

À l'heure actuelle, une macro postfix .await!() nécessiterait la magie du compilateur. Cependant, si une variante de préfixe du mot-clé await était stabilisée, alors ce ne serait plus vrai: la macro postfix .await!() pourrait être implémentée de manière triviale comme une macro qui préfixe son argument (une expression) avec le mot-clé await et tout entre parenthèses.

Avantages de cette approche:

• Le mot-clé préfixe await est disponible et accessible aux utilisateurs familiers avec cette construction à partir d'autres langages.
• Le mot-clé prefix async peut être utilisé là où il est souhaitable de faire ressortir la nature asynchrone d'une expression.
• Il y aurait une variante de suffixe .await!() , qui pourrait être utilisée dans des situations de chaînage, ou dans toute autre situation où la syntaxe du préfixe est maladroite.
• Il n'y aurait pas besoin de magie du compilateur (potentiellement inattendue) pour la variante postfix (comme cela serait autrement un problème pour le champ, la méthode ou les options macro de postfix).
• Les macros Postfix seraient également disponibles pour d'autres situations (comme .or_else!(continue) ), qui nécessitent par ailleurs la syntaxe de macro postfix pour des raisons similaires (elles nécessitent sinon que l'expression précédente soit encapsulée d'une manière maladroite et illisible).
• Le mot-clé préfixe await pourrait être stabilisé relativement rapidement (permettant à l'écosystème de se développer) sans que nous ayons à attendre l'implémentation des macros postfixes. Mais à moyen et long terme, nous laisserions encore ouverte la possibilité d'une syntaxe postfixe pour l'attente.

@nicoburns , @ H2CO3 ,

Nous ne devrions pas implémenter des opérateurs de flux de contrôle comme await!() et .or_else!(continue) tant que macros, car du point de vue de l'utilisateur, il n'y a aucune raison valable de le faire. Quoi qu'il en soit, sous les deux formes, les utilisateurs auraient exactement les mêmes fonctionnalités et devraient les apprendre tous les deux, mais si ces fonctionnalités étaient implémentées sous forme de macros, les utilisateurs se demanderaient en outre pourquoi exactement elles sont implémentées de cette manière. Il est impossible de ne pas le remarquer, car il y aurait simplement une différence bizarre et artificielle entre les opérateurs réguliers de première classe et les opérateurs réguliers implémentés sous forme de macros (car en elles-mêmes, les macros sont de première classe, mais ce qu'elles implémentent ne le sont pas).

C'est exactement la même réponse que pour . avant await : nous n'en avons pas besoin. Les macros ne peuvent pas imiter un flux de contrôle de première classe: elles ont une forme différente, elles ont des cas d'utilisation différents, elles ont une mise en évidence différente, elles fonctionnent de manière différente et elles sont perçues complètement différemment.

Pour les fonctionnalités .await!() et .or_else!(continue) , il existe des solutions appropriées et ergonomiques avec de belles syntaxes: await mot-clé et none -coalescing opérateur. Nous devrions préférer les implémenter au lieu de quelque chose de générique, rarement utilisé et qui ressemble à des macros postfix.

Il n'y a aucune raison d'utiliser des macros, puisqu'il n'y a pas quelque chose de compliqué comme format!() , il n'y a pas quelque chose de rarement utilisé comme include_bytes!() , il n'y a pas de DSL personnalisé, il n'y a pas de suppression de la duplication dans le code utilisateur, il y a pas nécessaire une syntaxe de type vararg, il n'y a pas besoin de quelque chose qui ressemble différemment, et nous ne pouvons pas utiliser cette façon simplement parce que c'est possible.

Nous ne devrions pas implémenter les opérateurs de flux de contrôle sous forme de macros car du point de vue de l'utilisateur, il n'y a aucune raison valable de le faire.

try!() été implémenté en tant que macro. Il y avait une très bonne raison à cela.

J'ai déjà décrit la raison pour laquelle await serait une macro - il n'y a pas besoin d'un nouvel élément de langage si une fonctionnalité existante peut également atteindre l'objectif.

il n'y a pas quelque chose de compliqué comme format!()

Je ne suis pas d' format!() :

En passant, je n'ai pas suggéré que ce devrait être une macro postfix. (Je pense que ça ne devrait pas.)

Pour les deux fonctionnalités, il existe des solutions appropriées et ergonomiques avec de belles syntaxes

Nous ne devrions pas donner à chaque appel de fonction, expression de contrôle de flux ou fonctionnalité mineure de commodité sa propre syntaxe très spéciale. Il en résulte seulement un langage gonflé, plein de syntaxe sans raison, et c'est exactement le contraire de «beau».

(J'ai dit ce que je pouvais; je ne vais plus répondre à cet aspect de la question.)

@nicoburns

Il m'est venu à l'esprit que nous pourrions peut-être tirer le meilleur parti des deux mondes avec une combinaison de:

• un préfixe await mot-clé
• une fonction de macro postfix générale

Cela implique de faire de await un mot clé contextuel par opposition au mot clé réel qu'il est actuellement. Je ne pense pas que nous devrions faire ça.

Ce qui, ensemble, permettrait à une macro de postfix .await!() d'être implémentée sans la magie du compilateur.

Il s'agit d'une implémentation de solution plus complexe que foo await ou foo.await (en particulier cette dernière). Il y a toujours de la «magie», tout autant; vous venez de faire une manœuvre comptable .

Avantages de cette approche:

• Le mot clé préfixe await est disponible et accessible aux utilisateurs familiers avec cette construction à partir d'autres langages.

Si nous ajoutons .await!() plus tard, nous donnons simplement aux utilisateurs plus à apprendre (à la fois await foo et foo.await!() ) et maintenant les utilisateurs demanderont "lequel dois-je utiliser quand..". Cela semble utiliser plus du budget de la complexité que foo await ou foo.await comme le feraient des solutions uniques.

• Les macros Postfix seraient également disponibles pour d'autres situations (comme .or_else!(continue) ), qui nécessitent par ailleurs la syntaxe de macro postfix pour des raisons similaires (elles nécessitent sinon que l'expression précédente soit encapsulée d'une manière maladroite et illisible).

Je pense que les macros postfix ont de la valeur et devraient être ajoutées au langage. Cela ne signifie cependant pas qu'ils doivent être utilisés pour await ing; Comme vous l'avez mentionné, il y a .or_else!(continue) et de nombreux autres endroits où les macros postfix seraient utiles.

• Le mot clé préfixe await pourrait être stabilisé relativement rapidement (permettant à l'écosystème de se développer) sans que nous ayons à attendre la mise en œuvre des macros postfixes. Mais à moyen et long terme, nous laisserions encore ouverte la possibilité d'une syntaxe postfixe pour l'attente.

Je ne vois aucune valeur à «laisser des possibilités ouvertes»; la valeur de postfix pour la composition, l'expérience IDE, etc. est connue aujourd'hui. Je ne suis pas intéressé par "stabiliser await foo aujourd'hui et j'espère que nous pourrons parvenir à un consensus sur foo.await!() demain".

@ H2CO3

try!() été implémenté en tant que macro. Il y avait une très bonne raison à cela.

try!(..) était obsolète, ce qui signifie que nous l'avons jugé impropre à la langue, en particulier parce qu'il n'était pas un suffixe. L'utiliser comme argument - autre que pour ce que nous ne devrions try!(..) est défini sans aucun support du compilateur .

En passant, je n'ai pas suggéré que ce devrait être une macro postfix. (Je pense que ça ne devrait pas.)

await n'est pas "chaque simple .." - en particulier, ce n'est pas une fonction de commodité mineure ; c'est plutôt une fonctionnalité de langage majeure qui est ajoutée.

@phaylon

De plus, avec les discussions récentes sur la complication de la grammaire et les problèmes que cela entraînera pour l'outillage, ce n'est peut-être pas une bonne idée de compter sur les IDE / éditeurs pour faire les choses correctement.

La syntaxe foo.await est destinée à réduire les problèmes d'outillage car tout éditeur avec un semblant de bon support pour Rust comprendra déjà le formulaire .ident . L'éditeur doit simplement ajouter await à la liste des mots-clés. De plus, les bons IDE ont déjà une complétion de code basée sur . - il semble donc plus simple d'étendre RLS (ou équivalents ...) pour fournir await comme première suggestion lorsque l'utilisateur tape . après my_future .

Pour ce qui est de compliquer la grammaire, .await est en fait le moins susceptible de compliquer la grammaire étant donné que prendre en charge .await dans la syntaxe consiste essentiellement à analyser .$ident et à ne pas se tromper sur ident == keywords::Await.name() .

La syntaxe foo.await est destinée à réduire les problèmes d'outillage car tout éditeur avec un semblant de bon support pour Rust comprendra déjà la forme .ident. Ce que l'éditeur doit faire, c'est simplement ajouter await à la liste des mots-clés. De plus, les bons IDE ont déjà la complétion de code basée sur. - il semble donc plus simple d'étendre RLS (ou équivalents ...) pour fournir wait comme première suggestion lorsque l'utilisateur tape. après mon_futur.

Je trouve simplement cela en contradiction avec la discussion de grammaire. Et le problème n'est pas seulement maintenant, mais dans 5, 10, 20 ans plus tard, après quelques éditions. Mais comme j'espère que vous l'avez remarqué, je mentionne également que même si un mot-clé est mis en surbrillance, les points d'attente peuvent passer inaperçus si d'autres mots-clés sont impliqués.

Quant à compliquer la grammaire, .await est en fait le moins susceptible de compliquer la grammaire étant donné que la prise en charge de .await dans la syntaxe consiste essentiellement à analyser. $ Ident et à ne pas se tromper sur ident == keywords :: Await.name ().

Je pense que l'honneur appartient à await!(future) , car il est déjà entièrement pris en charge par la grammaire.

@Centril try! finalement devenu redondant car l'opérateur ? peut faire strictement plus. Ce n'est pas «impropre à la langue». Cela ne vous plaira peut-être pas, ce que j'accepte. Mais pour moi, c'est en fait l'une des meilleures choses que Rust a inventées, et c'était l'un des arguments de vente. Et je sais qu'il est implémenté sans le support du compilateur - mais je ne vois pas en quoi cela est pertinent lorsque je discute si oui ou non il effectue un flux de contrôle. C'est vrai, peu importe.

attendre n'est pas "tout le monde .."

Mais d'autres mentionnés ici (par exemple or_else ) le sont, et mon point s'applique toujours aux fonctionnalités majeures de toute façon. Ajouter de la syntaxe juste pour ajouter de la syntaxe n'est pas un avantage, donc chaque fois qu'il y a quelque chose qui fonctionne déjà dans un cas plus général, il devrait être préféré à l'invention d'une nouvelle notation. (Je sais que l'autre argument contre les macros est qu '"elles ne sont pas postfixes". Je ne pense tout simplement pas que les avantages d'attendre d'être son propre opérateur postfix soient suffisamment élevés pour justifier le coût. Nous avons survécu aux appels de fonctions imbriquées. Nous sera tout aussi bien après avoir écrit quelques macros imbriquées.)

Le mercredi 23 janvier 2019 à 09:59:36 +0000, Mazdak Farrokhzad a écrit:

• Les macros Postfix seraient également disponibles pour d'autres situations (comme .or_else!(continue) ), qui nécessitent par ailleurs la syntaxe de macro postfix pour des raisons similaires (elles nécessitent sinon que l'expression précédente soit enveloppée d'une manière maladroite et illisible).

Je pense que les macros postfix ont de la valeur et devraient être ajoutées au langage. Cela ne signifie cependant pas qu'ils doivent être utilisés pour await ing; Comme vous l'avez mentionné, il y a .or_else!(continue) et de nombreux autres endroits où les macros postfix seraient utiles.

La principale raison d'utiliser .await!() est que l'apparence d'une macro rend
il est clair que cela peut affecter le flux de contrôle.

.await ressemble à un accès de champ, .await() ressemble à une fonction
appel, et ni les accès aux champs ni les appels de fonction ne peuvent affecter le contrôle
couler. .await!() ressemble à une macro et les macros peuvent affecter le contrôle
couler.

@joshtriplett I n'affecte pas le flux de contrôle au sens standard. Ceci est le fait de base pour justifier que le vérificateur d'emprunt devrait fonctionner à terme tel que défini (et la broche est le raisonnement comment). Du point de vue de l'exécution de la fonction locale, l'exécution de await est comme la plupart des autres appels de fonction. Vous continuez là où vous vous êtes arrêté et avez une valeur de retour sur la pile.

Je trouve simplement cela en contradiction avec la discussion de grammaire. Et le problème n'est pas seulement maintenant, mais dans 5, 10, 20 ans plus tard, après quelques éditions.

Je n'ai aucune idée de ce que vous entendez par là.

Je pense que l'honneur appartient à await!(future) , car il est déjà entièrement pris en charge par la grammaire.

Je comprends, mais à ce stade, en raison des nombreux autres inconvénients de cette syntaxe, je pense qu'elle est effectivement exclue.

@Centril try! finalement devenu redondant car l'opérateur ? peut faire strictement plus. Ce n'est pas «impropre à la langue». Vous pourriez ne pas l'aimer, cependant, ce que j'accepte.

Il est explicitement obsolète et de plus une erreur difficile d'écrire try!(expr) sur Rust 2018. Nous avons décidé collectivement de le faire ainsi et il a donc été jugé inapte.

La principale raison d'utiliser .await!() est que ressembler à une macro indique clairement qu'elle peut affecter le flux de contrôle.

.await ressemble à un accès au champ, .await() ressemble à un appel de fonction, et ni les accès aux champs ni les appels de fonction ne peuvent affecter le flux de contrôle.

Je pense que la distinction est quelque chose que les utilisateurs apprendront relativement facilement, d'autant plus que .await sera généralement suivi de ? (qui est le flux de contrôle local de la fonction). En ce qui concerne les appels de fonction, et comme mentionné ci-dessus, je pense qu'il est juste de dire que les méthodes d'itération sont une forme de flux de contrôle. De plus, ce n'est pas parce qu'une macro peut affecter le flux de contrôle qu'elle le fera . De nombreuses macros ne le font pas (par exemple dbg! , format! , ...). La compréhension que .await!() ou .await affectera le flux de contrôle (bien que dans un sens beaucoup plus faible que ? , selon la note de @HeroicKatora ) découle du mot await lui-même.

@Centril

Cela implique de faire attendre un mot-clé contextuel par opposition au mot-clé réel qu'il est actuellement. Je ne pense pas que nous devrions faire ça.

Eek. C'est un peu douloureux. Peut-être que la macro pourrait avoir un nom différent comme .wait!() ou .awaited!() (ce dernier est assez agréable car il indique clairement que cela s'applique à l'expression précédente).

"Ce qui, ensemble, permettrait à une macro postfix .await! () D'être implémentée sans la magie du compilateur."
Il s'agit d'une implémentation de solution plus complexe que foo await ou foo.await (en particulier cette dernière). Il y a toujours de la «magie», tout autant; vous venez de faire une manœuvre comptable.

De plus, try! (..) est défini sans aucun support du compilateur.

Et si nous avions un préfixe await mot-clé et des macros de suffixe, alors .await!() (peut-être avec un nom différent) pourrait également être implémenté sans le support du compilateur, non? Bien sûr, le mot-clé await lui-même impliquerait toujours une quantité importante de magie du compilateur, mais cela serait simplement appliqué au résultat d'une macro, et n'est pas différent de la relation de try!() avec le return mot-clé.

Si nous allons ajouter .await! () Plus tard, nous donnons simplement aux utilisateurs plus à apprendre (les deux attendent foo et foo.await! ()) Et maintenant les utilisateurs demanderont "lequel dois-je utiliser quand ..". Cela semble utiliser plus du budget de complexité que foo await ou foo.await comme le feraient des solutions uniques.

Je pense que la complexité que cela ajoute à l'utilisateur est minime (la complexité de la mise en œuvre peut être une autre affaire, mais si nous voulons quand même des macros postfixes ...). Les deux formes se lisent intuitivement, de sorte que lors de la lecture de l'une ou de l'autre, ce qui se passe devrait être évident. Quant à savoir lequel choisir lors de l'écriture du code, la documentation pourrait simplement dire quelque chose comme:

"Il y a deux façons d'attendre un avenir dans Rust: await foo.bar(); et foo.bar().await!() . Laquelle utiliser est une préférence stylistique et ne fait aucune différence pour le déroulement de l'exécution"

Je ne vois aucune valeur à «laisser des possibilités ouvertes»; la valeur de postfix pour la composition, l'expérience IDE, etc. est connue aujourd'hui.

C'est vrai. Je suppose que dans mon esprit, il s'agit davantage de faire en sorte que notre mise en œuvre ne ferme pas la possibilité d'avoir un langage plus unifié à l'avenir.

Je n'ai aucune idée de ce que vous entendez par là.

Peu importe. Mais en général, je le préfère aussi lorsque la syntaxe est évidente sans une bonne mise en évidence. Ainsi, les choses se démarquent dans git diff et d'autres contextes similaires.

En théorie oui, et pour les programmes triviaux oui, mais en réalité les programmeurs
besoin de savoir où se trouvent leurs points de suspension.

Pour un exemple simple, vous pouvez maintenir une RefCell sur un point de suspension, et
le comportement de votre programme sera différent que si le RefCell était
libéré avant le point de suspension. Dans les grands programmes, il y aura
d'innombrables subtilités comme celle-ci, où le fait que la fonction actuelle
suspend est une information importante.

Le mercredi 23 janvier 2019 à 14:21, HeroicKatora [email protected]
a écrit:

@joshtriplett https://github.com/joshtriplett Je n'affecte pas le contrôle
flux au sens standard. C'est le fait fondamental pour justifier que le
Le vérificateur d'emprunt devrait fonctionner dans les contrats à terme tels que définis. Du point de vue de la
l'exécution d'une fonction locale, l'exécution de wait est comme tout autre appel de fonction.

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/rust-lang/rust/issues/57640#issuecomment-456989262 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/ABGmeqcr2g4olxQhH9Fb9r6g3XRaFUu2ks5vGOBkgaJpZM4aBlba
.

Le mercredi 23 janvier 2019 à 14:26:07 -0800, Mazdak Farrokhzad a écrit:

La principale raison d'utiliser .await!() est que ressembler à une macro indique clairement qu'elle peut affecter le flux de contrôle.

.await ressemble à un accès de champ, .await() ressemble à un appel de fonction, et ni les accès aux champs ni les appels de fonction ne peuvent affecter le flux de contrôle.

Je pense que la distinction est quelque chose que les utilisateurs apprendront relativement facilement

Pourquoi devraient-ils le faire?

Je pense que la distinction est quelque chose que les utilisateurs apprendront relativement facilement, d'autant plus que .await sera généralement suivi de? (qui est le flux de contrôle local de la fonction).

Souvent oui, mais pas toujours, et la syntaxe devrait certainement fonctionner dans les cas où ce n'est pas le cas.

En ce qui concerne les appels de fonction, et comme mentionné ci-dessus, je pense qu'il est juste de dire que les méthodes d'itération sont une forme de flux de contrôle.

Pas de la même manière que return ou ? (ou même break ). Il serait très surprenant qu'un appel de fonction puisse renvoyer deux niveaux de la fonction qui l'a appelé (l'une des raisons pour lesquelles Rust n'a pas d'exceptions est précisément parce que cela est surprenant), ou sortir d'une boucle dans l'appel fonction.

De plus, ce n'est pas parce qu'une macro peut affecter le flux de contrôle qu'elle le fera. De nombreuses macros ne le font pas (par exemple, dbg !, format !, ...). La compréhension que .await! () Ou .await affectera le flux de contrôle (bien que dans un sens beaucoup plus faible que?, Selon la note de wait ".

Je n'aime pas du tout ça. Effectuer le flux de contrôle est un effet secondaire très important . Il doit avoir une forme syntaxique différente de celle des constructions qui ne peuvent normalement pas faire cela. Les constructions qui peuvent faire cela dans Rust sont: les mots-clés ( return , break , continue ), les opérateurs ( ? ) et les macros (en évaluant à un des autres formes). Pourquoi brouiller les eaux en ajoutant une exception?

@ejmahler Je ne vois pas en quoi la tenue d'un RefCell est différente pour la comparaison avec un appel de fonction normal. Il se peut également que la fonction interne veuille acquérir la même RefCell. Mais personne ne semble avoir de problème majeur à ne pas saisir immédiatement le graphe d'appel potentiel complet. De même, les problèmes d'épuisement de la pile ne sont pas particulièrement préoccupés par la nécessité d'annoter l'espace de pile fourni. Ici la comparaison serait favorable pour les coroutines! Devrions-nous rendre les appels de fonction normaux plus visibles s'ils ne sont pas en ligne? Avons-nous besoin d'appels de queue explicites pour s'attaquer à ce problème de plus en plus difficile avec les bibliothèques?

La réponse est, à mon humble avis, que le plus grand risque lors de l'utilisation de RefCell et d'attente est la méconnaissance. Lorsque les autres problèmes ci-dessus peuvent être résumés du matériel, je pense qu'en tant que programmeurs, nous pouvons également apprendre à ne pas nous accrocher à RefCell, etc.

Le mercredi 23 janvier 2019 à 22:30:10 +0000, Elliott Mahler a écrit:

En théorie oui, et pour les programmes triviaux oui, mais en réalité les programmeurs
besoin de savoir où se trouvent leurs points de suspension.

: +1:

@HeroicKatora

Une différence critique est la quantité de code que vous devez inspecter, combien
possibilités dont vous devez tenir compte. Les programmeurs sont déjà habitués à
s'assurer que rien qu'ils appellent n'utilise également une RefCell qu'ils ont vérifiée
en dehors. Mais avec await, au lieu d'inspecter une seule pile d'appels, nous n'avons pas
contrôle sur ce qui est exécuté pendant l’attente - littéralement n’importe quelle ligne du
programme peut être exécuté. Mon intuition me dit que le programmeur moyen est
beaucoup moins équipés pour faire face à cette explosion de possibilités, car ils
doivent y faire face beaucoup moins fréquemment.

Pour un autre exemple de points de suspension étant des informations critiques, dans le jeu
programmation, nous écrivons généralement des coroutines destinées à être reprises
une fois par image, et nous changeons l'état du jeu à chaque reprise. Si nous oublions un
point de suspension dans l'une de ces coroutines, nous pouvons quitter le jeu dans un
état pour plusieurs cadres.

Tous ces problèmes peuvent être résolus en disant «soyez plus intelligent et gagnez moins
erreurs »bien sûr, mais cette approche ne fonctionne pas historiquement.

Le mercredi 23 janvier 2019 à 14:44 Josh Triplett [email protected]
a écrit:

Le mercredi 23 janvier 2019 à 22:30:10 +0000, Elliott Mahler a écrit:

En théorie oui, et pour les programmes triviaux oui, mais en réalité les programmeurs
besoin de savoir où se trouvent leurs points de suspension.

: +1:

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/rust-lang/rust/issues/57640#issuecomment-456995913 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/ABGmep05nhZizdE5xil4FsnpONJCxqn-ks5vGOXhgaJpZM4aBlba
.

Pour un autre exemple de points de suspension qui sont des informations critiques, dans la programmation de jeu, nous écrivons généralement des coroutines qui sont destinées à être reprises une fois par image, et nous changeons l'état du jeu à chaque reprise. Si nous oublions un point de suspension dans l'une de ces coroutines, nous pouvons laisser le jeu dans un état cassé pendant plusieurs images.

Si vous déposez la clé dans un SlotMap, vous perdez de la mémoire. La langue elle-même ne vous aide pas en soi. Ce que je veux dire, c'est que vos exemples de la façon dont await n'est vaguement pas assez visible (tant qu'il s'agit d'un mot clé, son occurrence sera unique) ne semblent pas se généraliser à des problèmes qui ne se sont pas produits pour d'autres fonctionnalités. Je pense que vous devriez évaluer attendre moins sur les fonctionnalités que le langage vous offre immédiatement et plus sur la façon dont il vous permet d'exprimer vos propres fonctionnalités. Évaluez vos outils puis appliquez-les. Suggérer une solution pour l'état du jeu, et comment cela est résolu assez bien: écrivez un wrapper qui affirme en retour que l'état du jeu a en fait coché le montant requis, async vous permet d'emprunter votre propre état pour cette cause. Interdire les autres attend dans ce code compartimenté.

L'explosion d'état dans RefCell ne vient pas de vous ne vérifiant pas qu'il n'est pas utilisé ailleurs, mais d'autres points de code ne sachant pas que vous vous êtes appuyé sur cet invariant et l'ajoute silencieusement. Ceux-ci sont traités de la même manière, documentation, commentaires, emballage correct.

Tenir RefCell n'est pas très différent de hodling Mutex en bloquant io. Vous pouvez obtenir une impasse, ce qui est pire et plus difficile à déboguer qu'une panique. Et pourtant, nous n'annotons pas les opérations de blocage avec le mot clé explicite block . :).

Le partage de RefCell entre des fonctions asynchrones limitera considérablement leur utilisation générale ( !Send ), donc je ne pense pas que ce sera courant. Et RefCell doit généralement être évité, et lorsqu'il est utilisé, emprunté pour le moins de temps possible.

Donc, je ne pense pas que hodling RefCell accidentellement au-dessus d'un seuil

Si nous oublions un point de suspension dans l'une de ces coroutines, nous pouvons laisser le jeu dans un état cassé pendant plusieurs images.

Les coroutines et les fonctions asynchrones sont une chose différente. Nous n'essayons pas de rendre yield implicite.

À quiconque est en faveur de la syntaxe de macro au lieu de la syntaxe de mot-clé ici: Veuillez décrire de quoi il s'agit await qui signifie que cela devrait être une macro et en quoi c'est différent de, disons, while , ce qui _pourrait_ avoir juste été une macro while! ( même en utilisant juste macro_rules! ; pas de casse spéciale du tout).

Edit: Ce n'est pas de la rhétorique. Je suis vraiment intéressé par une telle chose, de la même manière que je pensais que je voulais courir à la première attente (comme C #) mais la RFC m'a convaincu du contraire.

À quiconque est en faveur de la syntaxe de macro au lieu de la syntaxe de mot-clé ici: Veuillez décrire de quoi il s'agit, wait, cela signifie que cela devrait être une macro et en quoi c'est différent de, disons, while, qui aurait pu durer un moment! macro (même en utilisant uniquement des macro_rules !; pas de casse spéciale du tout).

Je suis généralement d'accord avec ce raisonnement, et je souhaite utiliser un mot-clé pour la syntaxe de préfixe.

Cependant, comme indiqué ci-dessus (https://github.com/rust-lang/rust/issues/57640#issuecomment-456990831), je suis en faveur d'avoir également une macro postfix pour la syntaxe postfix (peut-être .awaited!() pour éviter les conflits de nom avec le mot-clé prefix). Mon raisonnement étant en partie que cela simplifie les choses d'avoir un mot-clé qui ne peut être utilisé que d'une seule manière, et d'enregistrer d'autres variantes pour les macros, mais étant principalement que pour autant que je sache, personne n'a été en mesure de trouver un suffixe syntaxe de mot-clé que je considérerais comme acceptable:

• foo.bar().await et foo.bar().await() seraient techniquement des mots-clés, mais ils ressemblent à un accès de champ ou à un appel de méthode, et je ne pense pas qu'une telle construction de modification de flux de contrôle devrait être cachée comme ça.
• foo.bar() await est juste déroutant, surtout avec un chaînage supplémentaire tel que foo.bar() await.qux() . Je n'ai jamais vu un mot-clé utilisé comme suffixe comme celui-là (je suis sûr qu'ils existent, mais je ne peux pas penser à un seul exemple dans aucune langue que je connaisse de mots-clés qui fonctionnent comme ça). Et je pense que cela est très déroutant, comme si l'attente s'appliquait au qux() non au foo.bar() .
• foo.bar()@await ou une autre ponctuation pourrait fonctionner. Mais ce n'est pas particulièrement agréable et cela semble assez ponctuel. En fait, je ne pense pas qu'il y ait de problèmes significatifs avec cette syntaxe (contrairement aux options ci-dessus). J'ai juste l'impression qu'une fois que nous avons commencé à ajouter des sigils, la balance commence à pencher vers l'abandon de la syntaxe personnalisée et vers le fait que ce soit une macro.

Je vais réitérer une idée antérieure une fois de plus, bien que modifiée avec de nouvelles pensées et considérations, puis essayer de garder le silence.

await tant que mot clé n'est valide que dans une fonction async , nous devrions donc autoriser l'identifiant await ailleurs. Si une variable est nommée await dans une portée externe, elle ne peut pas être accédée depuis un bloc async sauf si elle est utilisée comme identifiant brut. Ou, par exemple, la macro await! .

De plus, adapter le mot-clé comme ça permettrait de faire mon point principal: nous devrions permettre le mélange et la mise en correspondance des générateurs et des fonctions asynchrones, comme ceci:

// imaginary generator syntax stolen from JavaScript
fn* my_generator() -> T {
    yield some_value;

    // explicit return statements are only included to 
    // make it clear the generator/async functions are finished.
    return another_value;
}

// `await` keyword would not be allowed here, but the `yield` keyword is
#[async]
fn* my_async_generator() -> Result<T, E> {
    let item = some_op().await!()?; // uses the `.await!()` macro
    // which would really just use `yield` internally, but with the pinning API
    // same as the current nightly macro.

    yield future::ok(item.clone());

    return Ok(item);
}

// `yield` would not be allowed here, but the `await` keyword is.
async fn regular_async() -> Result<T, E> {
   let some_op = async || { /*...*/ };

   let item = await? some_op();

   return Ok(item);
}

Je pense que cela est suffisamment transparent pour les utilisateurs extrêmement avancés qui souhaitent faire des choses géniales, mais permet aux utilisateurs nouveaux et modérés d'utiliser uniquement ce qui est nécessaire. 2 et 3, s'ils sont utilisés sans aucune instruction yield , sont en fait identiques.

Je pense aussi que le préfixe await? est un excellent raccourci pour ajouter ? au résultat de l'opération asynchrone, mais ce n'est pas strictement nécessaire.

Si les macros postfix deviennent une chose officielle (ce que j'espère en quelque sorte), les deux await!(...) et .await!() pourraient exister ensemble, permettant trois façons équivalentes de faire des waits, pour des cas d'utilisation et des styles spécifiques . Je ne pense pas que cela ajouterait des frais généraux cognitifs, mais permettrait une plus grande flexibilité.

Idéalement, async fn et #[async] fn* pourraient même partager le code d'implémentation pour transformer le générateur sous-jacent en une machine à états asynchrone.

Ces problèmes ont montré qu'il n'y a pas de véritable style préféré, donc le mieux que je puisse espérer est de fournir des niveaux de complexité propres, flexibles, lisibles et faciles à approcher. Je pense que le schéma ci-dessus est un bon compromis pour l’avenir.

await tant que mot clé n'est valide que dans une fonction async , nous devrions donc permettre à l'identifiant d'attendre ailleurs.

Je ne sais pas si c'est pratique dans Rust, étant donné les macros hygiéniques. Si j'appelle foo!(x.await) ou foo!(await { x }) quand il veut un expr , je pense qu'il devrait être sans ambiguïté que le mot clé await est recherché - pas le await ou l'expression littérale await struct avec un raccourci de champ init - même dans une méthode synchrone.

permettant trois façons de faire équivalentes attend

Je t'en prie, non. (Au moins en core . Évidemment, les gens peuvent créer des macros dans leur propre code. S'ils le souhaitent)

À l'heure actuelle, une macro postfix .await! () Nécessiterait la magie du compilateur. Cependant, si une variante de préfixe du mot-clé await était stabilisée, cela ne serait plus vrai: la macro postfix .await! () Pourrait être implémentée de manière triviale comme une macro qui préfixe son argument (une expression) avec le mot-clé await et encapsule tout entre parenthèses.

Je noterai que c'est tout aussi vrai - mais plus simple! - dans l'autre sens: si nous stabilisons la syntaxe du mot-clé .await , les gens peuvent déjà créer une macro de préfixe awaited!() s'ils n'aiment pas assez le suffixe.

Je n'aime pas l'idée d'ajouter plusieurs variantes autorisées (comme le préfixe et le suffixe) mais pour une raison légèrement différente de celle que les utilisateurs demanderont. Je travaille dans une entreprise assez grande et les disputes sur le style de code sont réelles. J'aimerais n'avoir qu'une seule forme évidente et correcte à utiliser. Après tout, le zen de python pourrait avoir raison sur ce point.

Je n'aime pas l'idée d'ajouter plusieurs variantes autorisées (comme le préfixe et le suffixe) mais pour une raison légèrement différente de celle que les utilisateurs demanderont. Je travaille dans une entreprise assez grande et les disputes sur le style de code sont réelles. J'aimerais n'avoir qu'une seule forme évidente et correcte à utiliser. Après tout, le zen de python pourrait avoir raison sur ce point.

Je vois ce que tu veux dire. Cependant, il n'y a aucun moyen d'empêcher les programmeurs de définir leurs propres macros en faisant des choses comme await!() . Les structures similaires seront toujours possibles. Il y aura donc vraiment différentes variantes de toute façon.

Eh bien, pas au moins await!(...) car ce serait une erreur; mais si un utilisateur définit macro_rules! wait { ($e:expr) => { e.await }; } et l'utilise ensuite comme wait!(expr) alors il semblera distinctement unidiomatique et deviendra probablement rapidement démodé. Cela réduit considérablement la probabilité de variation dans l'écosystème et permet aux utilisateurs d'apprendre moins de styles. Ainsi, je pense que le point de

@Centril Si quelqu'un veut faire de mauvaises choses, il est difficile de l'arrêter. Qu'en est-il de _await!() ou awai!() ?

ou, lorsque l'identifiant Unicode est activé, quelque chose comme àwait!() .

...

@earthengine Le but est de fixer des normes communautaires (similaires à ce que nous faisons avec les styles lints et rustfmt ), pas pour empêcher diverses personnes de faire des choses bizarres exprès. Nous traitons ici de probabilités , pas de garanties absolues de ne pas voir _await!() .

Résumons et passons en revue les arguments de chaque syntaxe de postfix:

• __ expr await (mot-clé postfix) __: La syntaxe du mot-clé Postfix utilise le mot-clé await nous avons déjà réservé. Attendre est une transformation magique, et l'utilisation d'un mot-clé permet de se démarquer de manière appropriée. Cela ne ressemble pas à un accès à un champ, à une méthode ou à un appel de macro, et nous n'aurons pas à l'expliquer comme une exception. Il correspond bien aux règles d'analyse actuelles et à l'opérateur ? . L'espace dans le chaînage de méthodes n'est sans doute pas pire qu'avec Generalized Type Ascription , une RFC qui semble susceptible d'être acceptée sous une forme ou une autre. En revanche, les IDE devront peut-être faire plus de magie pour fournir une saisie semi-automatique pour await . Les gens peuvent trouver l'espace dans le chaînage de méthodes trop gênant (bien que @withoutboats ait soutenu que cela pourrait être un avantage), en particulier si le code n'est pas formaté de telle sorte que await termine chaque ligne. Il utilise un mot-clé que nous pourrions peut-être éviter d'utiliser si nous adoptions une autre approche.

• __ expr.await (champ postfix) __: La syntaxe du champ Postfix exploite la "puissance du point" - cela semble naturel dans le chaînage et permet aux IDE de compléter automatiquement await sans effectuer d'autres opérations comme supprimant automatiquement le point ). C'est tout aussi concis que le mot-clé postfix. Le point devant await peut en faciliter la recherche d'instances avec grep. En revanche, cela ressemble à un accès sur le terrain. En tant qu'accès au champ apparent, il n'y a aucun indice visuel indiquant que «cela fait quelque chose».

• __ expr.await() (méthode postfix) __: La syntaxe de la méthode Postfix est similaire au champ postfix. Du côté positif, la syntaxe d'appel () indique au lecteur, "cela fait quelque chose". Vu localement, cela a presque du sens de la même manière qu'un appel à une méthode de blocage donnerait une exécution dans un programme multi-thread. En revanche, c'est un peu plus long et plus bruyant, et déguiser le comportement magique de await en une méthode peut s'avérer déroutant. On peut dire que await est une méthode dans le même sens limité que call/cc dans Scheme est une fonction. En tant que méthode, nous aurions besoin de déterminer si Future::await(expr) devrait fonctionner de manière cohérente avec UFCS .

• __ expr.await!() (macro postfix) __: La syntaxe des macros Postfix exploite de la même manière la "puissance du point". La macro ! bang indique "cela pourrait faire quelque chose de magique". En revanche, c'est encore plus bruyant, et bien que les macros fassent de la magie, elles ne font généralement pas de magie au code environnant comme le fait await . Également à la baisse, en supposant que nous normalisions une syntaxe de macro postfix à usage général , il peut y avoir des problèmes pour continuer à traiter await comme un mot clé.

• __ expr@ , expr# , expr~ , et d'autres symboles à un seul caractère__: L'utilisation d'un seul caractère comme nous le faisons avec ? maximise la concision et peut-être rend la syntaxe postfixe semblent plus naturels. Comme pour ? , nous pouvons constater que nous apprécions cette concision si await commence à envahir notre code. En revanche, tant que la douleur d'avoir notre code jonché de await devient pas un problème, il est difficile de voir un consensus se former autour des compromis inhérents à l'adoption d'une telle syntaxe.

Je voulais prendre un post pour dire merci à @traviscross pour ces articles de synthèse! Ils ont toujours été bien écrits et bien réticulés. C'est très apprécié. :cœur:

J'ai une idée qu'en ajoutant des "opérateurs de pipe" comme F #, les utilisateurs peuvent utiliser soit le préfixe soit le suffixe (avec une différence de syntaxe explicite).

// use `|>` for instance, Rust can choose other sigils if there are conflicts with current syntax
await expr
expr |> await

// and we can use this operator on normal function calls too
f(g(h(x))) 
x |> h |> g |> f
// this is more convenient than "postfix macro"
x.h!().g!().f!()