他の言語がawait構造をどのように処理するかを書くことは役に立つかもしれないと思いました。

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 ++（コルーチンTR）

auto result = co_await task;

ハック

$result = await task;

ダート

var result = await task;

それでも、Rust式はいくつかの連鎖メソッドになる可能性があることを忘れないでください。 ほとんどの言語はそうしない傾向があります。

それでも、Rust式はいくつかの連鎖メソッドになる可能性があることを忘れないでください。 ほとんどの言語はそうしない傾向があります。

拡張メソッドをサポートする言語は拡張メソッドを持っている傾向があると思います。 これらには、Rust、Kotlin、C＃（たとえば、メソッド構文LINQおよびさまざまなビルダー）およびF＃が含まれますが、後者は同じ効果のためにパイプ演算子を多用します。

私の側では純粋に逸話的ですが、私は定期的にRustコードで数十以上のメソッド連鎖式に遭遇し、それを読み取って正常に実行します。 私は他の場所でこれを経験したことがありません。

この問題は、＃50547の一番上の投稿（[待機の最終構文]チェックボックスの横）で参照されていることを確認したいと思います。

Kotlin

val result = task.await()

Kotlinの構文は次のとおりです。

val result = doTask()

awaitは単なるsuspendable functionであり、一流のものではありません。

言及していただきありがとうございます。 先物はデフォルトで熱心であるため、Kotlinはより暗黙的に感じます。 ただし、そのメソッドを使用して他の遅延ブロックを待機することは、遅延ブロックでは依然として一般的なパターンです。 私は確かにそれを数回しました。

@cramertj https://github.com/rust-lang/rust/issues/50547に276のコメントがあるので、ここで繰り返さないようにするために、そこで行われた引数を要約できますか？ （たぶんここでそれらをOPに追加しますか？）

先物はデフォルトで熱心であるため、Kotlinはより暗黙的に感じます。 ただし、そのメソッドを使用して他の遅延ブロックを待機することは、遅延ブロックでは依然として一般的なパターンです。 私は確かにそれを数回しました。

多分あなたは少しの文脈/説明で両方のユースケースを追加するべきです。

また、go-langのように、暗黙の待機を使用する他のlangとは何ですか？

修正後の構文を支持する理由の1つは、呼び出し元の観点から、awaitが関数呼び出しのように動作することです。フロー制御を放棄し、それを取り戻すと、結果がスタックで待機します。 いずれにせよ、function-paranthesisを含めることで、関数のような動作を取り入れた構文をお勧めします。 また、コルーチンの構築を最初の実行から分割して、この動作が同期ブロックと非同期ブロックの間で一貫するようにするのには十分な理由があります。

しかし、暗黙のコルーチンスタイルが議論されており、私は明示性の側にいますが、コルーチンを呼び出すことは十分に明示的ではないでしょうか？ これはおそらく、コルーチンが構築された場所で直接使用されていない場合（またはストリームで機能する可能性がある場合）に最適に機能します。 本質的に、通常の呼び出しとは対照的に、よりリラックスした評価順序では、コルーチンに必要以上に時間がかかると予想されます。 そして、 .await!()は、多かれ少なかれ、通常の通話とコルーチン通話を区別する試みです。

それで、うまくいけば、ポストフィックスが好まれる理由についていくらか新しい見解を提供した後、構文の謙虚な提案：

• future(?)
• またはfuture(await)はもちろん独自のトレードオフがありますが、混乱が少ないと認められているようです。投稿の下部を参照してください。

他のスレッドからのかなり人気のある例を適応させる（ logger.logもコルーチンであると仮定して、すぐに呼び出すことがどのように見えるかを示します）：

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
}

そして代替案：

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
}

判読不能なコードを回避し、構文解析を支援するために、疑問符とオープンパランの間ではなく、疑問符の後にスペースを入れてください。 したがって、 future(? )は適切ですが、 future( ?)は適切ではありません。 この問題は、現在のすべてのトークンを以前のように使用できるfuture(await)の場合には発生しません。

他の修正後の演算子（現在の? -tryなど）との相互作用も、関数呼び出しの場合と同じです。

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 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)
}

これを好きになるいくつかの理由：

• .await!()と比較して、他の用途を持つ可能性のあるメンバーを暗示していません。
• これは、チェーンや?使用など、呼び出しの自然な優先順位に従います。 これにより、優先クラスの数が少なくなり、学習に役立ちます。 また、関数呼び出しは常に言語でいくらか特殊であるため（特性はありますが）、ユーザーコードが非常に類似した構文と効果を持つ独自のmy_await!()を定義できることは期待できません。
• これは、ジェネレーターとストリーム、および再開時に提供される引数が増えることを期待するジェネレーターに一般化できます。 本質的に、これはFnOnceとして動作しますが、 StreamsはFnMutように動作します。 追加の議論も簡単に受け入れることができます。
• 以前に現在のFuturesを使用したことがある人のために、これはPollを含む?がずっと機能するはずだった方法をキャプチャします（ここでは残念な安定化シーケンス）。 学習ステップとして、 ?ベースのオペレーターが制御フローを迂回させることを期待することとも一致します。 (await)はこれを満たしませんが、結局のところ、関数は常に分岐点で再開することを期待します。
• 関数のような構文を使用しますが、この引数は、私に同意する場合にのみ有効です：smile：

そしてこれを好まない理由：

• ?は引数のように見えますが、式には適用されていません。 適用されているように見えるトークンは関数呼び出し自体であるため、これは教えることで解決できると思います。これはやや正しい概念です。 これはまた、構文が明確であることを明確に意味します。
• 構文解析と?より多くの（そして異なる）組み合わせは、解析が難しい場合があります。 特に、ある未来が別の未来の結果を返す場合： construct_future()(?)?(?)? 。 ただし、 fnオブジェクトの結果を取得できるようにするために同じ引数を作成して、次のような式を許可することもできます： foobar()?()?()? 。 それにもかかわらず、私はこれが使用されたり苦情があったりするのを見たことがないので、そのような場合に別々のステートメントに分割することが十分に必要になることはめったにないようです。 この問題はconstruct_future()(await)?(await)?も存在しません-
• future(?)は、簡潔でありながら構文がやや簡潔な私のベストショットです。 それでも、その理由はコルーチンでの実装の詳細（一時的に戻って再開時にディスパッチする）に基づいているため、抽象化には適さない可能性があります。 future(await)は、 awaitがキーワードとして内部化された後でも説明できる代替手段ですが、引数の位置を飲み込むのは少し難しいです。 それは問題ないかもしれません、そしてコルーチンが結果を返すとき、それは確かにより読みやすくなります。
• 他の関数呼び出しの提案への干渉？
• あなた自身の？ あなたはそれを好きである必要はありません、少なくともこの簡潔な修正後の構文を提案しないのは無駄のように感じました。

future(?)

Resultについて特別なこと任意のRustタイプを返すことができます。 一部の先物がResult返すのはたまたまです

では、 Result返さない先物ではどのように機能するのでしょうか。

私が何を意味するのかはっきりしていなかったようです。 future(?)は、以前にfuture.await!()または同様のものとして説明されていたものです。 結果も返す未来に分岐すると、 future(?)? （制御フローを早期に放棄する2つの異なる方法）。 これにより、将来のポーリング(?)と結果のテスト?直交します。 編集：このための追加の例を追加しました。

同様に結果を返す未来への分岐はfuture(?)?

明確にしていただきありがとうございます。 その場合、私は間違いなくそれのファンではありません。

つまり、 Future<Output = Result<_, _>>を返す関数を呼び出すと、 foo()(?)?ように記述されます。

これは構文が非常に多く、2つのまったく異なる目的で?を使用します。

特に、重い演算子?へのヒントである場合は、もちろん、新しく予約されたキーワードに置き換えることができます。 私は当初、これは不可解なタイプの実際の議論に非常に似ていると考えていましたが、そのトレードオフは、ステートメントを精神的に解析するのに役立つという点で機能する可能性があります。 したがって、 impl Future<Output = Result<_,_>>の同じステートメントは次のようになります。

• foo()(await)?

?が適切である理由の最良の議論は、使用される内部メカニズムがいくぶん似ているということです（そうでなければ、現在のライブラリではPollを使用できません

構文が非常に多い

私はそれが明示的な待機の要点だと思いましたか？

それは使用しています ？ 2つの完全に異なる目的のために。

ええ、だからfoo()(await)構文はもっといいでしょう。

この構文は、クロージャを返す関数を呼び出してから、JSでそのクロージャを呼び出すようなものです。

「syntax-heavy」の私の読みは「sigil-heavy」に近く、 ()(?)?シーケンスを見るとかなり耳障りです。 これは元の投稿で取り上げられました：

構文解析と?より多くの（そして異なる）組み合わせは、解析が難しい場合があります。 特に、ある未来が別の未来の結果を返す場合： construct_future()(?)?(?)?

ただし、 fnオブジェクトの結果を取得できるようにするために同じ引数を作成して、次のような式を許可することもできます： foobar()?()?()? 。 それにもかかわらず、私はこれが使用されたり苦情があったりするのを見たことがないので、そのような場合に別々のステートメントに分割することが十分に必要になることはめったにないようです。

ここでの反論は次のとおりだと思います。野生で-> impl Fnを見たことがありますか（ -> Result<impl Fn() -> Result<impl Fn() -> Result<_, _>, _>, _>ません）。 非同期コードベースで-> impl Future<Output = Result<_, _>>が表示されると予想される回数は？ コードを読みやすくするためにまれなimpl Fn戻り値に名前を付ける必要があることは、一時的なimpl Future戻り値のかなりの部分に名前を付ける必要があることとは大きく異なります。

コードを読みやすくするためにまれなimplFn戻り値に名前を付ける必要があることは、一時的なimplFuture戻り値のかなりの部分に名前を付ける必要があることとは大きく異なります。

この構文の選択が、結果タイプに明示的に名前を付ける必要がある回数にどのように影響するかはわかりません。 await? futureと同じように型推論に影響を与えることはないと思います。

ただし、皆さんはここで非常に良い点を指摘し、私が考案した例が多いほど（元の投稿を編集して、常に両方の構文バージョンが含まれるようにしました）、自分自身がfuture(await)に傾倒します。 入力するのは不合理ではありませんが、それでも、これが呼び起こすことを意図した関数呼び出し構文の明確さをすべて保持しています。

何回見ると思いますか-> impl Future

>非同期コードベースで？

これと同等のタイプ（結果を返す非同期fn）が常に表示されることを期待しています。おそらく、

追跡の問題に関する私の以前の投稿にリンクし、さらにいくつかの考えを追加します。

文字列awaitを含まない構文がこの構文で受け入れられる可能性はほとんどないと思います。 この時点で、この機能に関する1年間の作業の後、新しい構文を提案するよりも、既知の実行可能な代替案の長所と短所を比較検討して、どちらが最適かを見つけようとする方が生産的だと思います。 私の以前の投稿を考えると、私が思う構文は実行可能です：

• プレフィックスは必須の区切り文字で待機します。 ここでは、これはどの区切り文字（中括弧または親、あるいは両方を受け入れるか、これらすべてに独自の長所と短所があります）の決定でもあります。 つまり、 await(future)またはawait { future }です。 これにより、優先順位の問題は完全に解決されますが、構文的にノイズが多く、両方の区切り文字オ​​プションが混乱の原因となる可能性があります。
• プレフィックスは、 ?に関する「有用な」優先順位で待機します。 （つまり、待機は？よりも緊密にバインドされます）。 これは、コードを読んでいる一部のユーザーを驚かせるかもしれませんが、結果の先物を返す関数は、先物の結果を返す関数よりも圧倒的に一般的であると思います。
• プレフィックスは、 ?に関する「明らかな」優先順位で待機します。 （つまり、？は待つよりも緊密に結合します）。 待機と？を組み合わせた追加のシンタックスシュガーawait? オペレーター。 この構文糖衣構文は、この優先順位を実行可能にするために必要だと思います。そうしないと、誰もが常に(await future)?書き込むことになります。これは、私が列挙した最初のオプションのより悪い変形です。
• 後置は構文スペースawaitで待機します。 これは、2つの演算子の間に明確な視覚的順序を設定することにより、優先順位の問題を解決します。 私は多くの点でこの解決策に不安を感じています。

これらの選択に対する私自身のランキングは、問題を調べるたびに変わります。 現時点では、砂糖との明らかな優先順位を使用することは、人間工学、親しみやすさ、および理解の最良のバランスのように思われると思います。 しかし、過去には、他の2つのプレフィックス構文のいずれかを優先していました。

説明のために、次の4つのオプションに次の名前を付けます。

名前| 未来| 結果の未来| 未来の結果
--- | --- | --- | ---
必須の区切り文字| await(future)またはawait { future } | await(future)?またはawait { future }? | await(future?)またはawait { future? }
便利な優先順位| await future | await future? | await (future?)
砂糖付きの明らかな優先順位| await future | await? futureまたは(await future)? | await future?
接尾辞キーワード| future await | future await? | future? await

（私はこのオプションを「postfixmacro」のような他のpostfix構文と区別するために特に「postfixkeyword」を使用しました。）

便利な優先順位の「祝福」 await future?の欠点の1つだけでなく、後置として機能しない他の欠点は、 ?式を手動で変換する通常のパターンが適用されなくなる可能性があることです。または、 Futureが互換性のある方法でResultメソッドを明示的に複製することを要求します。 これは驚くべきことです。 それらが複製されると、どのコンビネータが戻ってきた未来に取り組み、どれが熱心であるかが突然混乱します。 言い換えれば、暗黙の待機の場合と同じように、コンビネータが実際に何をするかを決定するのは難しいでしょう。 （編集：実際には、以下の2つのコメントを参照してください。ここでは、 ?驚くべき置き換えを意味する、より技術的な観点があります）

エラーケースから回復できる例：

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);
}

この問題は、実際の修正後の演算子では発生しません。

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);

これらは異なる式であり、ドット演算子は「明白な優先順位」 await演算子よりも優先順位が高いため、同等のものは次のとおりです。

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

これは、 or_recoverが非同期であるかどうかとまったく同じあいまいさを持っています。 （私が主張することは重要ではありませんが、式全体が非同期であることを知っています。何らかの理由でその特定の部分が非同期であるかどうかを知る必要がある場合は、 or_recoverの定義を見ることができます）。

これには、or_recoverが非同期であるかどうかとまったく同じあいまいさがあります。

まったく同じではありません。 unwrap_or_elseは待機しているため、コルーチンを生成する必要があります。したがって、 get_resultがコルーチン（つまりコンビネータが構築される）であるか、 Result<impl Future, _> （およびOk ）であるかがあいまいになります。 Errコルーチンを作成します）。 どちらも、 awaitシーケンスポイントをjoinに移動することで、効率の向上を一目で識別できるという同じ懸念はありません。これは、の主要な懸念の1つです。暗黙の待機。 その理由は、どのような場合には、この中間の計算が同期でなければならないとのawait前のタイプに適用されている必要がなければならないということです。 ここにはお互いに大きな懸念があります：

これらは異なる式であり、ドット演算子は「明白な優先順位」の待機演算子よりも優先順位が高いため、同等のものは

これは混乱の一部であり、 ?を回復操作に置き換えると、 awaitの位置が根本的に変わりました。 ?構文のコンテキストでは、タイプT部分式exprが与えられると、変換から次のセマンティクスが期待されます（ T::unwrap_or_elseが存在すると仮定） ：

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

ただし、「便利な優先順位」とawait expr? （ await exprはT ）では、代わりに次のようになります。

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

一方、明らかな優先順位では、この変換は余分なパランセシスなしではまったく適用されませんが、少なくとも直感は「未来の結果」に対しては機能します。

そして、コンビネータシーケンスの2つの異なるポイントで待機するさらに興味深いケースはどうですか？ 接頭辞の構文では、これには括弧が必要だと思います。 Rust言語の残りの部分は、「式が左から右に評価される」ように、これを長々と回避しようとします。この1つの例は、自動参照マジックです。

複数のawait / try / combinationポイントを持つ長いチェーンでこれが悪化することを示す例。

// 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)?;
}

私が避けてほしいのは、Cの型解析のRustアナログを作成することです。
'pointer'および 'array'コンビネータの式の左側と右側。

@withoutboatsスタイルのテーブルエントリ：

| 名前| 未来| 結果の未来| 未来の結果|
|-|-|-|-|
| 必須の区切り文字| await(future) | await(future)? | await(future?) |
| 便利な優先順位| await future | await future? | await (future?) |
| 明らかな優先順位| await future | await? future | await future? |
| 接尾辞の呼び出し| future(await) | future(await)? | future?(await) |

| 名前| 連鎖|
|-|-|
| 必須の区切り文字| await(await(foo())?.bar())? |
| 便利な優先順位| await(await foo()?).bar()? |
| 明らかな優先順位| await? (await? foo()).bar() |
| 接尾辞の呼び出し| foo()(await)?.bar()(await) |

私はさまざまな理由で後置待機を強く支持していますが、 foo await.method()は紛らわしいです。

まず、同様の表を見てみましょうが、さらにいくつかの接尾辞のバリエーションを追加します。

| 名前| 未来| 結果の未来| 未来の結果|
| ---------------------- | -------------------- | ----- ---------------- | --------------------- |
| 必須の区切り文字| await { future } | await { future }? | await { future? } |
| 便利な優先順位| await future | await future? | await (future?) |
| 明らかな優先順位| await future | await? future | await future? |
| 接尾辞キーワード| future await | future await? | future? await |
| 接尾辞フィールド| future.await | future.await? | future?.await |
| 接尾辞メソッド| future.await() | future.await()? | future?.await() |

次に、連鎖した将来の式を見てみましょう。

| 名前| 結果の連鎖した未来|
| ---------------------- | -------------------------- ----------- |
| 必須の区切り文字| await { await { foo() }?.bar() }? |
| 便利な優先順位| await (await foo()?).bar()? |
| 明らかな優先順位| await? (await? foo()).bar() |
| 接尾辞キーワード| foo() await?.bar() await? |
| 接尾辞フィールド| foo().await?.bar().await? |
| 接尾辞メソッド| foo().await()?.bar().await()? |

そして今、実際の例として、 reqwestsから、連鎖した結果の未来を待ちたいと思うかもしれません（私の好みのawaitフォームを使用）。

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

実際、私はすべてのセパレーターが後置構文に対してうまく見えると思います、例えば：
let res: MyResponse = client.get("https://my_api").send()/await?.json()/await?;
しかし、私はどちらを使用するかについて強い意見を持っていません。

後置マクロ（つまりfuture.await!() ）はまだオプションですか？ それは明確、簡潔、そして明白です：

| 未来| 結果の未来| 未来の結果|
| --- | --- | --- |
| future.await！（）| future.await！（）？ | future？.await！（）|

また、接尾辞マクロは実装に必要な労力が少なく、理解と使用が簡単です。

また、接尾辞マクロは実装に必要な労力が少なく、理解と使用が簡単です。

また、一般的なlang機能を使用しているだけ

後置マクロは、後置の簡潔さと連鎖性を、魔法ではないプロパティとマクロの明らかな存在と組み合わせて、いくつかの.await_debug!() 、 .await_log!(WARN)などのサードパーティのユーザーマクロとうまく適合するので便利です。 .await_trace!()

接尾辞マクロは、マクロの非魔法のプロパティ[...]を組み合わせているので便利です。

@novacrazyこの引数の問題は、 await!マクロが魔法のようになり、ユーザー作成コードでは不可能な操作を実行することです（現在、基盤となるジェネレーターベースの実装は多少公開されていますが、私の理解では安定化する前に、これは完全に隠されます（そして、現時点で実際にそれと対話するには、とにかくいくつかのrustc内部の夜間機能を使用する必要があります））。

@ Nemo157うーん。 私はそれがそれほど不透明であることを意図していることに気づいていませんでした。

#[async]ような手続き型マクロを使用して、魔法のキーワードではなく、「非同期」関数からジェネレーター関数への変換を再検討するのは遅すぎますか？ 入力するのは3文字余分で、 #[must_use]または#[repr(C)]と同じ方法でドキュメントにマークを付けることができます。

実行の流れを直接制御する非常に多くの抽象化レイヤーを非表示にするというアイデアは本当に嫌いです。 Rustとは正反対の感じがします。 ユーザーは、コードを完全にトレースして、すべてがどのように機能し、どこで実行されるかを理解できる必要があります。 彼らは物事をハッキングしてシステムをだますように奨励されるべきであり、彼らが安全なRustを使用するならそれは安全でなければなりません。 低レベルのコントロールを失っても、これは何も改善しません。私は生の先物に固執したほうがよいでしょう。

言語（ std / coreではない）であるRustは、ユーザーまたはstdが実行できない（または非常に実用的でない）場合にのみ、抽象化と構文を提供する必要があると確信しています。 。 この完全な非同期性は、その点で手に負えなくなっています。 rustcのピンAPIとジェネレーター以外のものが本当に必要ですか？

@novacrazy私は一般的に感情には同意しますが、結論には同意しません。

抽象化と構文は、ユーザーまたは標準で実行できない（または非常に実用的でない）場合にのみ提供する必要があります。

言語にforループがある理由は、それらがブレーク付きでloop変わるマクロである可能性がある場合です。 || closureが専用のトレイトおよびオブジェクトコンストラクターである可能性がある場合、その理由は何ですか。 すでにtry!()があるのに、なぜ?を導入したのですか。 私がそれらの質問とあなたの結論に同意しない理由は、一貫性です。 これらの抽象化のポイントは、カプセル化する動作だけでなく、そのアクセシビリティにもあります。 for -replacementは、可変性、プライマリコードパス、および可読性に分類されます。 ||置換は宣言の冗長性に分類されます-現在のFuturesと同様です。 try!()は、表現と構成可能性の予想される順序で分類されます。

asyncは関数のデコレータであるだけでなく、 aync-blocksとasync ||によって追加のパターンを提供するという他の考えがあることを考慮してください。 さまざまな言語アイテムに適用されるため、マクロの使いやすさは最適ではないようです。 その場合、ユーザーに表示する必要がある場合は、実装についても考えないでください。

ユーザーは、コードを完全にトレースして、すべてがどのように機能し、どこで実行されるかを理解できる必要があります。 彼らは物事をハッキングしてシステムをだますように奨励されるべきであり、彼らが安全なRustを使用するならそれは安全でなければなりません。

完全にstd apiを使用してコルーチンを実装すると、 unsafe大きく依存する可能性があるため、この議論は当てはまらないと思います。 そして、逆の議論があります。なぜなら、それは実行可能であり、言語に構文的および意味的な方法があったとしても停止されないためです。変更は、 unsafe行われた仮定を破るリスクが非常に高くなります。 extern "rust-call"あり、これは現在の魔法として機能し、関数呼び出しにはそのような保証がないことを明確にします。 積み重ねられたコルーチンの運命はまだ決定されていませんが、実際にreturnにする必要はないかもしれませたい場合があります。

余談ですが、理論的には、完全に真面目な考えではありませんが、コルーチンが仮想のextern "await-call" fn () -> Tとして示されるのを待つことができますか？ もしそうなら、これは前奏曲で許可します

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

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

別名。 ユーザースペースに文書化されたアイテムのfuture.await() 。 または、そのことについては、他の演算子構文も可能である可能性があります。

@HeroicKatora

すでにtry!()持っているのに、なぜ?を導入したのですか？

公平を期すために、私もこれに反対しましたが、それは私に成長しました。 Tryが安定していればもっと受け入れられますが、それは別のトピックです。

あなたが与える「砂糖」の例の問題は、それらが非常に非常に薄い砂糖であるということです。 impl MyStructさえ、多かれ少なかれimpl <anonymous trait> for MyStruct砂糖です。 これらは、オーバーヘッドをまったく追加しない生活の質の砂糖です。

対照的に、ジェネレーターと非同期関数は、まったく重要ではないオーバーヘッドと重要な精神的オーバーヘッドを追加します。 ジェネレーターは特にユーザーとして実装するのが非常に難しく、言語自体の一部としてより効果的かつ簡単に使用できますが、非同期はその上に比較的簡単に実装できます。

非同期ブロックまたはクロージャについてのポイントは興味深いです、そして私はそこでキーワードがより有用であると認めます、しかし私はそれでも必要ならばより低いレベルのアイテムにアクセスすることができないことに反対します。

理想的には、 asyncキーワードと#[async]属性/手続き型マクロをサポートし、前者が生成された（しゃれを意図していない）ジェネレーターへの低レベルのアクセスを許可するのは素晴らしいことです。 一方、 yieldは、 asyncをキーワードとして使用するブロックまたは関数では禁止する必要があります。 彼らは実装コードを共有することさえできると確信しています。

await 、上記の両方が可能であれば、私たちは似た何かを、キーワード制限される可能性がawaitにasyncキーワード機能/ブロックを、とのいくつかの種類を使用しますawait!() #[async]関数のawait!()マクロ。

擬似コード：

// 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);
}

両方の長所。

これは、ユーザーに提示する複雑さのより自然な進行のように感じられ、より多くのアプリケーションでより効果的に使用できます。

この問題は、特にawait構文について説明するためのものであることを忘れないでください。 async関数とブロックがどのように実装されているかについての他の会話は、 await!がRustで書くことができる、またはこれからできることではないことを人々に思い出させる目的を除いて、範囲外です。表面言語。

すべての修正後の構文提案の長所と短所を具体的に重み付けしたいと思います。 構文の1つがわずかな短所で際立っている場合は、それを選択する必要があります。 ただし、ない場合は、必要に応じて、まだ決定されていないポストフィックスと前方互換性のある構文プレフィックス区切り構文をサポートするのが最善です。 Postfixは少数のメンバーにとって最も簡潔であると共鳴しているように見えるので、他のメンバーに移動する前に、最初にこれらを強く評価することが実用的であるように思われます。

比較はsyntax 、 example （@ mehcodeからのreqwestは、この点で使用可能な実際のベンチマークのように見えます）、次に（ concerns 、およびオプションのresolution 、例えば、それが教えることに帰着する可能性があることに同意した場合）。 構文や懸念事項を自由に追加してください。これらを編集してこの集合的な投稿にします。 私が理解しているように、 awaitを含まない構文は、初心者と経験豊富なユーザーの両方にとって異質であると感じる可能性が非常に高いですが、現在リストされているすべての構文に含まれています。

参照用の1つのプレフィックス構文の例ですが、この部分をバイクシェッドしないでください。

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

• 接尾辞キーワードfoo() await?
  
  
  
  • 例： client.get("https://my_api").send() await?.json() await?
  
  
  • | 懸念| 解決策|
    
    |-|-|
    
    | ?なしのチェーンは、混乱したり、許可されなかったりする可能性があります| |
  
  
• 接尾辞フィールドfoo().await?
  
  
  
  • 例： client.get("https://my_api").send().await?.json().await?
  
  
  • | 懸念| 解決策|
    
    |-|-|
    
    | フィールドのように見えます| |
  
  
• 接尾辞メソッドfoo().await()?
  
  
  
  • 例： client.get("https://my_api").send().await()?.json().await()?
  
  
  • | 懸念| 解決策|
    
    |-|-|
    
    | メソッドまたは特性のように見えます| それはops::特性として文書化されるかもしれませんか？ |
    
    | 関数呼び出しではありません| |
  
  
• 接尾辞の呼び出しfoo()(await)?
  
  
  
  • 例： client.get("https://my_api").send()(await)?.json()(await)?
  
  
  • | 懸念| 解決策|
    
    |-|-|
    
    | 実際の議論と混同される可能性があります| キーワード+ハイライト+重複しない|
  
  
• 接尾辞マクロfoo().await!()?
  
  
  
  • 例： client.get("https://my_api").send().await!()?.json().await!()?
  
  
  • | 懸念| 解決策|
    
    |-|-|
    
    | 実際にはマクロにはなりません…| |
    
    | …または、 awaitはキーワードではなくなりました| |
  
  

ジェネレーターを組み込む可能性の観点からのポストフィックスとプレフィックスに関する追加の考え：値を考慮すると、 yieldとawaitは2つの相反する種類のステートメントを占めます。 前者は関数から外部に値を与え、後者は値を受け入れます。

補足：Pythonには、 yieldが値を返すことができるインタラクティブなジェネレーターがあります。 対称的に、このようなジェネレーターまたはストリームの呼び出しには、厳密なタイプ設定で追加の引数が必要です。 あまり一般化しようとしないでください。どちらの場合でも、議論が移る可能性が高いことがわかります。

そして、これらの発言が似ているのは不自然だと私は主張します。 ここでは、代入式と同様に、他の言語によって設定された基準から逸脱する必要があります。その基準が一貫性が低く、Rustにとって簡潔でない場合です。 他の場所で表現されているように、 awaitを含め、同じ引数の順序を持​​つ他の式との類似性が存在する限り、別のモデルからの移行にも大きな障害はありません。

暗黙的であるように思われるので。

他の言語でasync / awaitを使用し、ここでオプションを確認したところ、futureを連鎖させることが構文的に快適であるとは思いませんでした。

テーブルにチェーン不可のバリアントはありますか？

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

それがパターンの一部であるという議論をすることができるので、私はこのようなものです。

バインディングを待機させることの問題は、エラーストーリーがあまり良くないことです。

// 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?;

コミュニティで待つことができるほぼすべての先物は誤りがあり、 ?と組み合わせる必要があることを覚えておく必要があります。

シンタックスシュガーが本当に必要な場合：

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

awaitとawait?両方をキーワードとして追加する必要があります。そうでない場合は、これをlet 、つまりlet? result = 1.divide(0);も拡張します。

Rustコードでチェーンが使用される頻度を考えると、チェーン待機が読者にできるだけ明確であることが重要であることに完全に同意します。 awaitの接尾辞バリアントの場合：

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

これは通常、Rustコードの動作と同じように動作します。 このコンテキストでのawait()は関数呼び出しのように感じますが、式のコンテキストでは魔法の（関数のようではない）動作をするという事実に問題があります。

接尾辞マクロバージョンはこれをより明確にします。 人々は「ここに魔法がある」という意味の錆びた感嘆符に慣れているので、私は確かにこのバージョンを好みます。

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

そうは言っても、その言語にはtry!(expr)があり、それが?前身であったことを考慮する価値があります。 追加await!(expr)マクロは、今どのようにと完全に一致するであろうtry!(expr)と?言語に導入されました。

await!(expr)バージョンのawaitでは、後で後置マクロ?スタイルの演算子を追加するかを選択できます。 ?似ていますが、待機する例：

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

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

非常に合理的で実用的であるため、今のところawait!(expr)またはawait!{expr}を使用する必要があると思います。 その後、接尾辞マクロが問題になった場合は、後でawaitの接尾辞バージョン（つまり、 .await!または.await!() ）に移行することを計画できます。 （または、最終的には、 ?スタイルの演算子を追加するルートになります...主題に関する多くのバイクシェッドの後：P）

参考までに、Scalaの構文はAwait.resultはありません。これは、ブロッキング呼び出しであるためです。 Scalaの先物はモナドであるため、通常のメソッド呼び出しまたはforモナド内包表記を使用します。

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

この恐ろしい表記の結果として、 scala-asyncというライブラリが、私が最も好む構文で作成されました。これは次のとおりです。

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
}

これは、必須の区切り文字を使用して、Rustコードをどのように見せたいかを強く反映しているため、現在の構文await!()を維持することについて他の人に同意したいと思います。 初期の錆はシンボルが重く、正当な理由で離れたと思います。 接尾辞演算子（またはあなたが持っているもの）の形でのシンタックスシュガーの使用は、いつものように、下位互換性があり、 await!(future)の明快さは明白です。 また、前述のように、 try!での進行状況も反映しています。

マクロとして保持することの利点は、それが通常の関数呼び出しではなく言語機能であることが一目ですぐにわかることです。 !追加しないと、エディター/ビューアーの構文の強調表示が呼び出しを見つけることができる最良の方法であり、これらの実装に依存することはより弱い選択だと思います。

私の2セント（通常の寄稿者ではありません、fwiw）私はtry!モデルをコピーすることに最も部分的です。 これは以前に一度行われたもので、うまく機能し、非常に人気が出た後、接尾辞演算子を検討するのに十分なユーザーがいました。

したがって、私の投票は次のようになります。 await!(...)安定し、Rust開発者の投票に基づいて、後置演算子をパントして、適切なチェーンを作成します。 Awaitはキーワードですが、 !はそれが私にとって「魔法」であり、括弧で囲まれていることを示しています。

また、比較：

| Postfix | 式|
| --- | --- |
| .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()$? |

私の3番目のセントは、 @ （「待機」の場合）と# （マルチスレッド/並行性を表すため）が好きなことです。

私も接尾辞@が好きです！ 実行可能ではないという感情があるように見えますが、実際には悪い選択肢ではないと思います。

• _ @ for await_は、覚えやすいニーモニックです。
• ?と@ 、非常に似て学習そうでしょう@学習後? 、このような飛躍すべきではありません
• 式を理解するために終了区切り文字を見つけるために前方にスキャンする必要なしに、式のチェーンを左から右にスキャンするのに役立ちます

私はawait? foo構文に非常に賛成です、そしてそれは数学で見られるいくつかの構文に似ていると思います。 sin²xは、（sin x）²を意味するために使用できます。 最初は少しぎこちなく見えますが、なかなか慣れやすいと思います。

上で述べたように、私は今のところtry!()ように、マクロとしてawait!()を追加し、最終的にそれを後置する方法を決定することに賛成です。 await!()呼び出しを接尾辞に自動的に変換するrustfixのサポートを念頭に置くことができれば、それはまだ決定されていません。

接尾辞のキーワードオプションは私にとって明らかな勝者です。

• 優先順位/順序の問題はありませんが、括弧を使用して順序を明示することができます。 しかし、ほとんどの場合、過度のネストは必要ありません（ 'try（）！'の代わりにpostfix '？'を優先するための同様の引数）。

• 複数行のチェーンで見栄えがよく（@earthengineによる以前のコメントを参照）、繰り返しになりますが、順序や何が待たされているかについて混乱はありません。 また、awaitを複数回使用する式には、入れ子/余分な括弧はありません。

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

• それは単純なawait！（）マクロに役立ちます（@novacrazyによる以前のコメントを参照）：

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

• 単一行の裸（「？」なし）の接尾辞awaitキーワードチェーンでも、左から右に読み取られ、後続のメソッドが操作する値が返されるのを待っているため、気になりません（ただし、複数行のrustfmtされたコードを好む）。 スペースは線を分割し、待っていることが起こっていることを視覚的に示す/合図で十分です：

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

私がまだ提案していない別の候補を提案するために（おそらくそれは解析できないため）、楽しい二重ドット '..'接尾辞演算子はどうですか？ それは私たちが何かを待っていることを思い出させます（結果！）...

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

私も接尾辞@が好きです！ 実行可能ではないという感情があるように見えますが、実際には悪い選択肢ではないと思います。

• _ @ for await_は、覚えやすいニーモニックです。
• ?と@ 、非常に似て学習そうでしょう@学習後? 、このような飛躍すべきではありません
• 式を理解するために終了区切り文字を見つけるために前方にスキャンする必要なしに、式のチェーンを左から右にスキャンするのに役立ちます

私は@を使って待つのが好きではありません。 右手の親指でalt-grを押してから、数字の行のキー2を押す必要があるため、fin / sweレイアウトキーボードで入力するのは面倒です。 また、@は（at）で十分に確立された意味を持っているので、なぜその意味を混同する必要があるのか​​わかりません。

単にawaitと入力したいだけですが、キーボードのアクロバットを必要としないため、より高速です。

これが私自身の非常に主観的な評価です。 future@awaitも追加しましたが、これは興味深いと思います。

| 構文| ノート|
| --- | --- |
| await { f } | 強い：

• 非常に簡単
• パラレルfor 、 loop 、 asyncなど。

• 非常に冗長（5文字、2ブレース、3オプション、ただしおそらくリントスペース）
• 連鎖すると、多くのネストされた中括弧が生成されます（ await { await { foo() }?.bar() }? ）

• Python、JS、C＃、Dartのawait構文に対応
• 簡単、短い
• 有用な優先順位と明らかな優先順位の両方が?うまく動作します（ await fut?対await? fut ）

• あいまい：有用な優先順位と明らかな優先順位を学習する必要があります
• 連鎖も非常に面倒です（ await (await foo()?).bar()?対await? (await? foo()).bar() ）

• 非常に簡単な連鎖が可能
• ショート
• 素晴らしいコード補完

• ユーザーをだまして、それがどこかで定義されたフィールド/関数/マクロであると思い込ませます。 編集： await!()が最も魔法が少ないと感じる@jplatteに同意し

• 非常に簡単な連鎖が可能
• ショート

• await変数がどこかに定義されており、先物は関数のように呼び出すことができるとユーザーを騙します

• 非常に簡単な連鎖が可能
• ショート

• Rustの構文には何も似ていない、明らかではない
• 私の脳はclient.get("https://my_api").send() await.unwrap().json() await.unwrap()をclient.get("https://my_api").send() 、 await.unwrap().json() 、 await.unwrap()グループ化します（最初にグループ化し、次に.グループ化します）これは正しくありません
• Haskellersの場合：カリー化のように見えますが、そうではありません

• 非常に簡単な連鎖が可能
• とても短い

• 少しぎこちなく見えます（少なくとも最初は）
• @を消費しますが、これは他の何かに適している可能性があります
• 特に大きな表現では見落としやすいかもしれません
• 他のすべての言語とは異なる方法で@します

• 非常に簡単な連鎖が可能
• ショート
• 素晴らしいコード補完
• awaitはキーワードになる必要はありません
• 上位互換性：新しい接尾辞演算子を@operator形式で追加できます。 たとえば、 ?は@tryとして実行できます。
• 私の脳はclient.get("https://my_api").send()@await.unwrap().json()@await.unwrap()を正しいグループにグループ化します（最初に.グループ化され、次に@グループ化されます）

• 他のすべての言語とは異なる方法で@します
• 不必要な接尾辞演算子を追加しすぎるとインセンティブになる可能性があります

私のスコア：

• 親しみやすさ（fam）：この構文が既知の構文（RustおよびPython、JS、C＃などの他の構文）にどれだけ近いか
• 自明性（obv）：これを他の誰かのコードで初めて読んだ場合、意味や優先順位などを推測できますか？
• 冗長性（vrb）：書き込むのに必要な文字数
• 可視性（vis）：コード内で（見落とすのではなく）見つけるのがいかに簡単か
• チェーン（cha）： .や他のawaitとチェーンするのは簡単です
• グループ化（grp）：私の脳がコードを正しいチャンクにグループ化するかどうか
• 上位互換性（fwd）：これが後で非破壊的な方法で調整できるかどうか

| 構文| ファム| obv | vrb | vis | チャ| 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 |

最初のカットでtry!()構文をミラーリングし、他の構文を導入する前にawait!(expr)の使用を実際に使用する必要があるように感じます。

ただし、代替構文を作成する場合は。

@は見苦しく、「async」の「at」は私にはそれほど直感的ではないと思います。この記号はすでにパターンマッチングに使用されています。

パーレンのないasyncプレフィックスは、 ? （多くの場合）と一緒に使用すると、明白でない優先順位または周囲のパーレンにつながります。

接尾辞.await!()うまくチェーンされ、その意味がすぐにわかりやすく、魔法を使うことを教えてくれる!が含まれており、構文的にはあまり目新しいものではないので、「次のカット」アプローチはI個人的にはこれを好むでしょう。 とは言うものの、私にとっては、最初のカットawait! (expr)よりも実際のコードがどれだけ改善されるかはまだわかりません。

単純なケースでは、プレフィックス演算子を使用します。
let result = await task;
結果の種類を書き出さないことを考えると、はるかに自然に感じるので、左から右に読むときに、結果が待機のタスクであることを理解するために、待機は精神的に役立ちます。
このように想像してみてください。
let result = somehowkindoflongtask await;
タスクの最後に到達しないまで、タスクが返すタイプを待つ必要があることに気づきません。 IntellijとしてのIDEが名前とequalsの間にタイプを（パーソナライズなしで）インライン化することも覚えておいてください（これは変更される可能性があり、言語の将来に直接リンクされていません）。
このように想像してください：

それは私の意見が接頭辞に対して100パーセントであるという意味ではありません。 結果が関係する場合は、futureのpostfixバージョンが非常に自然に感じられるので非常に好みます。 コンテキストがなくても、これらのどれが何を意味するのかを簡単に知ることができます。
future await?
future? await
代わりに、初心者の観点から、これら2つのうちどちらが正しいかを見てください。
await future? === await (future?)
await future? === (await future)?

私はプレフィックスキーワードawait futureに賛成です。

これは、async / awaitを備えたほとんどのプログラミング言語で使用されているものであるため、それらの1つを知っている人にはすぐに馴染みがあります。

await future?の優先順位について、一般的なケースは何ですか？

• 待たなければならないResult<Future>を返す関数。
• Result ： Future<Result>を返す、待たなければならない未来。

I / O操作が失敗する可能性があるため、一般的なシナリオを処理する場合は、2番目のケースの方がはるかに一般的だと思います。 したがって：

await future? <=> (await future)?

あまり一般的ではない最初のケースでは、括弧を付けてもかまいません： await (future?) 。 try!マクロが非推奨になっていない場合、これはawait try!(future)使用にも適している可能性があります。 このように、 awaitと疑問符の演算子は将来の異なる側面にありません。

awaitを最初の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);

ここで、 future.run(await)はawait future代わりになります。
それは、futureを取り、単にawait!()マクロを実行する通常のasync関数である可能性があります。

C ++（同時実行TR）

auto result = co_await task;

これはコルーチンTSにあり、並行性ではありません。

別のオプションは、 await代わりにbecomeキーワードを使用することです。

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は、保証されたTCOのキーワードになる可能性があります

その[概要]を@EyeOfPythonに感謝します。 これは、自転車小屋に参加したばかりの人にとって特に便利です。

個人的には、 f awaitから離れることを望んでいます。なぜなら、構文が非常に素朴でなく、特別で魔法のように見えるからです。 Rustを初めて使用するユーザーが多くのことについて混乱することは、これらのことの1つになります。そして、Rustのベテランでさえ、その価値があるほど明確にはならないように感じます。

@novacrazyこの引数の問題は、 await!マクロが魔法のようになり、ユーザー作成のコードでは不可能な操作を実行することです。

@ Nemo157 await!マクロが魔法になることに同意しますが、これは問題ではないと主張します。 stdは、そのようなマクロがすでに複数あります。たとえば、 compile_error! 、誰もそれらについて不満を言っているのを見たことがありません。 マクロを使用するのは、それがどのように行われるかではなく、何をするかを理解するだけであるのが普通だと思います。

私はPostfixが最も人間工学的であろうと、以前のコメンターに同意するが、私はむしろ、接頭マクロから始めますawait!(expr)それがものになるとし、後置マクロへの潜在的移行ではなく、持っているexpr.await （マジックコンパイラ組み込みフィールド）またはexpr.await() （マジックコンパイラ組み込みメソッド）。 どちらも、純粋にこの機能のための完全に新しい構文と、言語の一貫性を損なうだけのIMOを導入します。

@EyeOfPythonマインドはあなたのリストとテーブルにfuture(await)を追加しますか？ future.await()評価のすべての肯定的な点は、弱点なしに移行しているようです

構文の強調表示にもかかわらず、 foo.awaitはフィールドアクセスに非常に似ていると主張する人もいるため、トークン.を# 、代わりにfoo#awaitと書くことができます。 。 例えば：

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

GitHubがこれを構文の強調表示でどのようにレンダリングするかを説明するために、 awaitをmatch置き換えてみましょう。これらは同じ長さなので、次のようになります。

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

これは明確で人間工学的であるように思われます。

#の論理的根拠は特定されていませんが、トークンは非常に目立ちます。

だから、別の概念：未来が参照だった場合：

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;

これは本当に醜くて一貫性がありません。 少なくともその構文を明確にしましょう。

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;

より良いですが、それでも醜いです（さらに悪いことに、githubの構文が強調表示されます）。 ただし、これに対処するために、プレフィックス演算子を

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;

これはまさに私が欲しいものです！ await（ $ ）だけでなく、deref（ * ）とnegate（ ! ）も同様です。

この構文のいくつかの警告：

1. オペレーターの優先順位：私にとっては明らかですが、他のユーザーにとっては？
2. マクロの相互運用： $シンボルはここで問題を引き起こしますか？
3. 式の不整合：先頭のプレフィックス演算子は式全体に適用されますが、遅延プレフィックス演算子は.区切られた式にのみ適用されます（ await_chain fnはそれを示しています）、それは混乱しますか？
4. 構文解析と実装：その構文はまったく有効ですか？

@Centril
IMO＃が生のリテラル構文に近すぎますr#"A String with "quotes""#

IMO＃が生のリテラル構文に近すぎますr#"A String with "quotes""#

この場合の違いは、コンテキストからはかなり明らかなようです。

@Centril
そうですが、構文もRustがIMHOを使用するスタイルとはまったく異質です。 これは、同様の機能を持つ既存の構文とは似ていません。

@Laaas導入されたとき、 ?もしませんでした。 .await行けたら嬉しいです; しかし、他の人はそれに不満を持っているように見えるので、私はうまくいく何かを見つけようとしています（つまり、明確で、人間工学的で、入力が十分に簡単で、連鎖可能で、優先順位が高い）、 foo#awaitはそれをすべて満たすようです。

?は他にもたくさんの良い点がありますが、 .awaitようなものが必要な場合は、 .await!ないでしょうか。

@Centrilこれがfuture(await)背後にある主な理由であり、余分な演算子や外部構文を追加する必要がなく、フィールドアクセスを回避するためです。

#awaitはかなり恣意的です。

#は恣意的です、はい-それは成功ですか、それとも失敗ですか？ ある時点で新しい構文が発明されたとき、誰かがそれが見栄えが良いか理にかなっていると思ったので、それは恣意的でなければなりません。

なぜ.await!ないのですか？

それも同様に恣意的ですが、私はそれに反対していません。

@Centrilこれがfuture(await)背後にある主な理由であり、余分な演算子や外部構文を追加する必要がなく、フィールドアクセスを回避しました。

代わりに、 awaitをfuture渡す関数適用のように見えます。 それは「フィールドアクセス」よりも混乱しているように私を襲います。

代わりに、それはあなたが通過している関数適用のように見えます。 それは「フィールドアクセス」よりも混乱しているように私を襲います。

私にとって、それは簡潔さの一部でした。 Awaitは、関数呼び出し（呼び出し先があなたとあなたの結果の間で実行される）のような多くの側面であり、その関数にキーワードを渡すことで、これが別の種類の呼び出しであることが明らかになりました。 しかし、キーワードが他の引数と類似していることがどのように混乱する可能性があるかがわかります。 （マイナスの構文の強調表示と、そのメッセージを補強しようとするコンパイラエラーメッセージ。先物は、待機する以外の方法で呼び出すことはできません。その逆も同様です）。

@Centril

恣意的であることは否定的なことではありませんが、既存の構文に類似していることは肯定的なことです。 .await!は完全に新しい構文ではないため、それほど恣意的ではありません。 結局のところ、これはawaitという名前の修正後のマクロにすぎません。

特にawait新しい構文について明確にする/要点を追加するために、私が意味するのは、既存の構文とは異なる新しい構文を導入することです。 プレフィックスキーワードはたくさんあり、そのうちのいくつかはRust 1.0の後に追加されています（例： union ）が、AFAIKは単一のポストフィックスキーワードではありません（スペース、ドット、または他の何かで区切られていても） 。 また、接尾辞のキーワードを持つ他の言語は考えられません。

私見では、Rustの奇妙さを大幅に増加させない唯一の接尾辞構文は、メソッド呼び出しを反映しているが、以前にRustマクロを見たことがある人なら誰でもマクロとして明確に識別できるため、接尾辞マクロです。

標準のawait!()マクロも気に入りました。 それは明確で単純です。
awaitedとして共存するよりも、フィールドのようなアクセス（または他の接尾辞）を好みます。

• Awaitは、次の/正しいものが来るのを待っていると感じています。 待っていた、前に来た/去ったものに。
• イテレータのcloned()メソッドに一貫性があります。

また、 @?が?ような砂糖として好きでした。
これは個人的なことですが、 @は高すぎてラインをアンダーシュートする傾向があり、非常に気が散るので、実際には&?組み合わせを好みます。 &も背が高い（良い）が、アンダーシュートはしない（良い）。 残念ながら、 &すでに意味がありますが、常に?が続きます。

例えば。

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

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

私にとって、 @は肥大化したキャラクターのように感じ、読書の流れを邪魔します。 一方、 &?は心地よく、（私の）読書の邪魔にならず、 &と?間に素敵な上部スペースがあります。

個人的には、単純なawait!マクロを使用する必要があると思います。 修正後のマクロが言語に組み込まれた場合、マクロは単純に展開できますね。

@Laaas私が望む限り、Rustにはまだ接尾辞マクロがないので、それらは新しい構文です。 また、 foo.await!.barとfoo.await!().barは同じサーフェス構文ではないことに注意してください。 後者の場合、実際の接尾辞と組み込みマクロがあります（キーワードとしてawaitをあきらめる必要があります）。

@jplatte

多くのプレフィックスキーワードがあり、そのうちのいくつかはRust 1.0の後に追加されています（例： union ）。

unionは単項式演算子ではないため、この比較には関係ありません。 Rustには正確に3つの安定した単項プレフィックス演算子（ return 、 break 、およびcontinue ）があり、それらはすべて!入力されます。

うーん... @ 、私の以前の提案は少し良く見えます：

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これが私のポイントです。修正後のマクロはまだないので、単にawait!()ます。 また、私は.await!() FYIを意味しました。 awaitはキーワードである必要はないと思いますが、問題がある場合は予約できます。

unionは単項式演算子ではないため、この比較には関係ありません。 Rustには正確に3つの安定した単項プレフィックス演算子（ return 、 break 、およびcontinue ）があり、それらはすべて!入力されます。

これは、たとえタイプが異なっていても、接頭辞-キーワードバリアントが単項式演算子のグループに適合することを意味します。 接尾辞-キーワードの変形は、既存の構文からのはるかに大きな相違であり、私の意見では、言語におけるawaitの重要性に関連して大きすぎます。

プレフィックスマクロとポストフィックスへの移行の可能性について： awaitは、これが機能するためのキーワードのままである必要があります。 その場合、マクロは特別なlangアイテムになり、追加のr#なしで名前としてキーワードを使用でき、 r#await!()は同じマクロを呼び出すことができますが、おそらくそうすべきではありません。 それ以外は、それを利用可能にするための最も実用的な解決策のようです。

つまり、 awaitをキーワードとして保持し、 await!をlang-itemマクロに解決します。

@HeroicKatoraなぜそれが機能するためにキーワードのままである必要があるのですか？

@Laaas移行の可能性を開いたままにしておきたい場合は、それをキーワードとして使用する将来の修正後の構文のために開いたままにする必要があるためです。 したがって、移行のためにエディションを中断する必要がないように、キーワードの予約を維持する必要があります。

@Centril

また、foo.await！.barとfoo.await！（）。barは同じサーフェス構文ではないことに注意してください。 後者の場合、実際の接尾辞と組み込みマクロがあります（キーワードとしての待機をあきらめる必要があります）。

キーワードawaitを!と組み合わせて内部マクロ（通常の方法では定義できない）に解決することでこれを解決できませんか？ その後、キーワードのままですが、それ以外の場合はマクロ構文でマクロに解決されます。

@HeroicKatora x.await!() awaitが予約キーワードになるのはなぜですか？

そうではありませんが、修正後を未解決のままにしておけば、後の議論で到達する解決策である必要はありません。 それが唯一の合意された最良の可能性である場合、最初にこの正確な修正後の構文を採用する必要があります。

これは、接尾辞演算子としてはるかにうまく機能する何かに出くわすもう1つの機会です。 この大きな例はtry!で、最終的には独自のシンボル? 。 ただし、接尾辞演算子がより最適であり、すべてに独自の特別な文字を与えることができないのはこれが最後ではないと思います。 したがって、少なくとも@始めるべきではないと思います。 このようなことをする方法があればもっといいでしょう。 そのため、接尾辞マクロスタイル.await!()をサポートしています。

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

しかし、これが意味のある接尾辞マクロを理解するには、それら自体を導入する必要があります。 したがって、通常のawait!(foo)マクロ構文から始めるのが最善だと思います。 これがそれ自体のシンボルを正当化するのに十分重要であると本当に感じた場合、後でこれをfoo.await!()またはfoo@に拡張することができます。
このマクロに少しの魔法が必要になることは、stdにとって目新しいことではなく、私にとっては大きな問題ではありません。
@jplatteが言ったように：

@ Nemo157 await!マクロが魔法になることに同意しますが、これは問題ではないと主張します。 stdは、そのようなマクロがすでに複数あります。たとえば、 compile_error! 、誰もそれらについて不満を言っているのを見たことがありません。 マクロを使用するのは、それがどのように行われるかではなく、何をするかを理解するだけであるのが普通だと思います。

ここで説明している繰り返し発生する問題は、チェーンとその使用方法に関するものです。
式を連鎖させるのを待ちます。 多分別の解決策があるかもしれませんか？

連鎖のためにawaitを使用せず、awaitforのみを使用する場合
割り当て、letをawaitに置き換えるようなものがあります：
await foo = future

次に、チェーンの場合、 await res = fut1 -> fut2やawait res = fut1 >>= fut2ようなある種の操作を想像できます。

欠落している唯一のケースは、結果を待って返すことです、いくつかのショートカット
await res = fut; res 。
これは、単純なawait futで簡単に実行できます。

私はこのような別の提案を見たことがないと思います（少なくとも
チェーン）なので、ここにドロップするといいと思います。

@HeroicKatoraリストにfut(await)を追加し、私の意見に従ってランク付けしました。

誰かが私の得点がずれていると感じたら、教えてください！

構文的には、 .await!()はクリーンで、構文に奇妙な点を追加せずに連鎖できると思います。

ただし、「実際の」接尾辞マクロを取得した場合、おそらく.r#await!()がシャドウされる可能性があるのに対し、 .await!()はシャドウイングできないため、少し奇妙になります。

awaitが式の次の部分に結合されていることがわかったため、「postfixキーワード」オプション（ foo() await?.bar() await?ようなスペースで区切る）にはかなり強く反対しています。それが動作する部分ではありません。 ここでは、空白以外のほとんどすべての記号を好みます。また、長いチェーンの欠点にもかかわらず、これよりもプレフィックス構文を好みます。

必須の区切り文字は単一のステートメントを待つという非常に一般的なケースにとって苦痛であり、「有用な優先順位」はまったくないため、「明白な優先順位」（ await?砂糖を使用）が明らかに最良のプレフィックスオプションだと思います直感的で、したがって混乱します。

構文的には、 .await!()はクリーンで、構文に奇妙な点を追加せずに連鎖できると思います。

ただし、「実際の」接尾辞マクロを取得した場合、おそらく.r#await!()がシャドウされる可能性があるのに対し、 .await!()はシャドウイングできないため、少し奇妙になります。

postfixマクロを取得し、 .await!()を使用する場合、キーワードとしてawaitを予約解除し、それをpostfixマクロにすることができます。 このマクロの実装には、まだ少しの魔法が必要ですが、今日のcompiler_error!ように実際のマクロになります。

@EyeOfPython forward-compatibility検討する変更について詳しく説明していただけますか？ fut@awaitがfut.await!()より高く、 await { future }がawait!(future)より低くなる方法がわかりません。 verbosity列も少し奇妙に見えます。一部の式は短いですが、評価が低く、連鎖ステートメントなどが考慮されています。他のすべてはバランスが取れているようで、これまでで最もよく凝縮された広範な評価のようです。

この議論を読んだ後、多くの人が通常のawait!()マクロを追加し、後で後置バージョンを理解したいと思っているようです。 これは、実際にpostfixバージョンが必要であると想定しています。これについては、このコメントの残りの部分でも当てはまります。

だから私はここにいるみんなの意見を調査したいと思います：今のところawait!(future)構文に全員が同意する必要がありますか？ 長所は、その構文に構文解析のあいまいさがなく、マクロでもあるため、この変更をサポートするために言語の構文を変更しないことです。 短所は、チェーンの見栄えが悪いことですが、この構文は簡単に後置バージョンに自動的に置き換えることができるため、それは問題ではありません。

それを解決して言語に実装したら、postfix await構文についての議論を続け、できればもっと成熟した経験、アイデア、そしておそらく他のコンパイラ機能を使用することができます。

@HeroicKatora awaitを解放して通常の識別子として自然に使用でき、他の接尾辞演算子を追加できるので、私はそれを高く評価しましたが、 fut.await!()はawait方が良いと思いますfut.await!()が高い可能性があることも間違いなく有効です。

await { future }とawait!(future)場合、後者はオプションを開いたままにして他のほとんどすべてのオプションに変更できますが、前者は実際にはawait futureバリアントのいずれかのみを許可します（ @withoutboatsのブログエントリに記載されているfwd(await { future }) < fwd(await!(future))であるべきだと思います。

冗長性については、正解です。ケースをサブグループに分割した後、冗長性を再評価しませんでした。これは、すべての中で最も客観的なものであるはずです。

コメントを考慮して編集します、ありがとうございます！

await!(future)安定させることは、私が想像できる最悪の選択肢です。

1. これは、 awaitを予約解除する必要があることを意味します。これは、将来の言語設計がさらに困難になることを意味します。
2. これは、非推奨となったtry!(result)と同じルートを意図的に取っています（Rust 2018でr#try!(result)を記述する必要があります）。
   
   
   
   • await!(future)が不適切な構文であることがわかっている場合、最終的には非推奨にすることを意味します。これは意図的に技術的負債を生み出しています。
   
   
   • さらに、 try!(..)はRustで定義されていますが、 await!(future)は定義できず、代わりにコンパイラの魔法になります。
   
   
   • try!(..)廃止は容易ではなく、社会的に大きな打撃を与えました。 その試練をもう一度経験することは魅力的ではないようです。
   
   
3. これは、言語の中心的で重要な部分の1つにマクロ構文を使用します。 それは明らかに一流ではないようです。
4. await!(future)はうるさいです; 異なり、 await future次のように記述する必要があります!( ... ) 。
5. Rust API、特に標準ライブラリは、メソッド呼び出し構文を中心としています。 たとえば、 Iteratorを処理する場合、メソッドをチェーンするのが一般的です。 await { future }およびawait future同様に、 await!(future)構文はメソッドチェーンを困難にし、一時的なletバインディングを誘発します。 これは人間工学にとっても、読みやすさについても私の見解では悪いことです。

@Centril同意したいのですが、いくつかの未解決の質問があります。 1.よろしいですか？ それを「魔法」にすると、キーワードとしてドロップせずにマクロを参照できるようにすることで、さらに魔法にすることはできませんか？

私はRustに参加するのが遅すぎて、 2.の社会的視点を評価できませんtry!から変換されていないため、それが解決策であったことは明らかです。 それは、エディション2018に移行するインセンティブとして、 async/awaitを使用するのか、それとも辛抱強くこれを繰り返さないのかという問題を提起します。

3.に非常によく似た他の2つの（imho）中心機能： vec![]とformat! / println! 。 前者は安定したボックス構造がないためです。後者はフォーマット文字列構造であり、依存型の式がないためです。 これらの比較も部分的に4.を別の視点に置いていると思います。

私は英語のように読めない構文には反対です。 IE、「awaitx」は英語のようなものを読みます。 「x＃!! @！＆」はそうではありません。 「x.await」は英語のように興味をそそるように読みますが、xが長い名前のメンバー関数呼び出しや一連の連鎖イテレーターメソッドなどの重要な行である場合はそうではありません。

具体的には、「keyword x」をサポートしています。ここで、keywordはおそらくawaitです。 私はC ++コルーチンTSとUnityのc＃コルーチンの両方を使用しており、どちらもそれに非常によく似た構文を使用しています。 そして、それらを本番コードで何年も使用した後、私の信念は、あなたの歩留まりポイントがどこにあるかを一目で知ることは絶対に重要であるということです。 関数のインデント行をざっと読むと、200行の関数のすべてのco_await / yield returnを、認知的負荷なしで数秒で選択できます。

同じことは、後で待機するドット演算子、または他の接尾辞「シンボルの山」構文には当てはまりません。

awaitは基本的な制御フロー操作だと思います。 'if 、 while 、 match 、およびreturnと同じレベルの敬意を払う必要があります。 それらのいずれかが接尾辞演算子であると想像してみてください-Rustコードを読むことは悪夢です。 私のawaitの議論と同様に、Rust関数のインデント行をスキミングして、すべての制御フローをすぐに選択できます。 例外はありますが、それは例外であり、私たちが努力すべきものではありません。

@ejmahlerに同意します。 開発の反対側であるコードレビューを忘れてはなりません。 ソースコードを含むファイルは、読み取られてから書き込まれることがはるかに多いため、書き込みよりも読み取りと理解の方が簡単なはずです。 コードレビューでは、降伏点を見つけることが非常に重要です。 そして私は個人的にUseful precedence投票します。
私はこれを信じています：

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

これよりも理解しやすいです：

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

@HeroicKatora

@Centril同意したいのですが、いくつかの未解決の質問があります。 1.よろしいですか？ それを「魔法」にすると、キーワードとしてドロップせずにマクロを参照できるようにすることで、さらに魔法にすることはできませんか？

技術的には？ おそらく。 ただし、特別な場合には強力な正当化が必要であり、この場合、魔法に魔法をかけることは正当化されていないようです。

それは、エディション2018に移行するインセンティブとして、 async/awaitを使用するのか、それとも辛抱強くこれを繰り返さないのかという問題を提起します。

新しいモジュールシステム、 async / await 、およびtry { .. }をインセンティブにするつもりだと言ったかどうかはわかりません。 しかし、私たちの意図に関係なく、それは良いことだと思います。 私たちは、人々が最終的に新しい言語機能を使用して、より優れた慣用的なライブラリを作成し始めることを望んでいます。

3.に非常によく似た他の2つの（imho）中心機能： vec![]とformat! / println! 。 前者は、安定した箱型構造のアファイクがないため、非常に

前者は存在し、 vec![1, 2, 3, ..]と記述されて、配列リテラル式を模倣します（例： [1, 2, 3, ..] 。

@ejmahler

「x.await」は英語のように興味をそそるように読みますが、xが長い名前のメンバー関数呼び出しや一連の連鎖イテレーターメソッドなどの重要な行である場合はそうではありません。

チェーンされたイテレータメソッドの束の何が問題になっていますか？ それは明らかに慣用的なRustです。
rustfmtツールは、メソッドチェーンをさまざまな行にフォーマットするため、次のようになります（ここでも、 matchを使用して構文の強調表示を表示します）。

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

.awaitを「それから待つ」と読んだ場合、少なくとも私にとっては完全に読みます。

そして、それらを本番コードで何年も使用した後、私の信念は、あなたの歩留まりポイントがどこにあるかを一目で知ることは絶対に重要であるということです。

特に上記のrustfmtフォーマットでは、postfix awaitがそれをどのように否定するのかわかりません。 さらに、あなたは書くことができます：

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();

あなたがそれを空想するなら。

認知的負荷なしで、ほんの数秒で200行の機能で。

特定の機能についてあまり知らない限り、200 LOCはおそらく単一責任の原則に違反し、やりすぎであるように思われます。 解決策は、それをより少なくし、それを分割することです。 実際、それが保守性と読みやすさにとって最も重要なことだと思います。

awaitは基本的な制御フロー操作だと思います。

?です。 実際、 awaitと?はどちらも、「コンテキストから値を抽出する」という効果的な制御フロー操作です。 言い換えると、ローカルコンテキストでは、これらの演算子のタイプがawait : impl Future<Output = T> -> Tおよび? : impl Try<Ok = T> -> Tと想像できます。

例外はありますが、それは例外であり、私たちが努力すべきものではありません。

そして、ここでの例外は?ですか？

@andreytkachenko

@ejmahlerに同意します。 開発の反対側であるコードレビューを忘れてはなりません。 ソースコードを含むファイルは、読み取られてから書き込まれることがはるかに多いため、書き込みよりも読み取りと理解の方が簡単なはずです。

不一致は、読みやすさと人間工学にとって何が最善かということです。

これよりも理解しやすいです：

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

これはフォーマット方法ではありません。 rustfmtを実行すると、次のようになります。

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

@ejmahler @andreytkachenkoここで促されることです。 これはRust-yではなく、通常のフォーマット規則が修正後の構文でこれを補います。 また、 awaitは実際には、yieldのコードポイントではなく、yieldポイントに配置されていないため、プレフィックス構文ではyield-pointがよりあいまいであると考えています。

あなたはこの道を行く場合は、むしろして、それを綴るのための実験をしましょうawaitの代わりとしてlet本当にこれを施行する@Keruspeのアイデアの精神インチそれらはストレッチのように見えるので、他の構文拡張なし。

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

しかし、これらのどれについても、文法におけるそれらの構成可能性の喪失と複雑さを説明するのに十分な利点は見られません。

うーん...接頭辞と接尾辞の両方の形式を待つことが望ましいですか？ それとも接尾辞の形だけですか？

メソッド呼び出しを連鎖させることは、特に話しているときに慣用的です
イテレータとはるかに少ない程度のオプションですが、それを除けば、錆は
最初に命令型言語、次に関数型言語。

私は接尾辞が文字通り理解できないと主張しているのではありません、私はマキンです
最上位の制御フロー操作を隠す認知的負荷の議論、
「リターン」と同じ重要性を持ち、次の場合に認知的負荷を増加させます
行頭の近くに置くのと比較して-そして私は
この議論は、長年の生産経験に基づいて行われます。

11:59マズダク教Farrokhzadで土、2019年1月19日には[email protected]
書きました：

@HeroicKatora https://github.com/HeroicKatora

@Centril https://github.com/Centril同意したいのですが、あります
いくつかの未解決の質問。 1についてよろしいですか？ 私たちがそれを「魔法」にすれば
これがマクロなしでマクロを参照できるようにすることで、それをさらに魔法にすることはありません
キーワードとしてドロップしますか？

技術的には？ おそらく。 ただし、
特別な場合、そしてこの場合、魔法に魔法をかけることはないようです
正当化されます。

それは私たちが非同期/待機するつもりかどうかという問題を提起します
2018年版に移行するインセンティブ、またはむしろ忍耐強く、
これを繰り返します。

新しいモジュールシステム、async /を意図していると言ったかどうかはわかりません
待って、{..}をインセンティブにしようとします。 しかし、私たちの意図に関係なく
彼らはそうです、そしてそれは良いことだと思います。 最終的には人々に
新しい言語機能を使用して、より良く、より慣用的な文章を書き始めます
ライブラリ。

3に非常によく似た他の2つの（imho）中心機能：vec！[]とformat！/
println！。 前者は安定した箱がないのでとても
建設afaik、

前者は存在し、配列を模倣するためにvec！[1、2、3、..]と書かれています。
リテラル式、例：[1、2、3、..]。

@ejmahler https://github.com/ejmahler

「x.await」は英語のように食欲をそそるように読みますが、xが
長い名前のメンバー関数呼び出しや束などの重要な行
連鎖イテレータメソッドなどの

チェーンされたイテレータメソッドの束の何が問題になっていますか？ それは明らかに
慣用的なさび。
rustfmtツールは、メソッドチェーンをさまざまな行にフォーマットするため、
get（ここでもmatchを使用して構文の強調表示を表示します）：

foo = alpha（）。match？ //またはalpha() match? 、 alpha()#match? 、 alpha().match!()?
。ベータ
.some_other_stuff（）。match？
.even_more_stuff（）。match
.stuff_and_stuff（）;

.awaitを「thenawait」と読むと、少なくとも私にとっては完全に読みます。

そして、生産コードでそれらを使用して数年後、私の信念は知っているということです一目であなたのイールドポイントがどこにあるかは絶対に重要です。

特にrustfmtでは、postfixがどのようにそれを否定するのかわかりません
上記のフォーマット。 さらに、あなたは書くことができます：

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（）;

あなたがそれを空想するなら。

認知的負荷なしで、ほんの数秒で200行の機能で。

特定の機能についてあまり知らなくても、私には思えます
その200LOCは、おそらく単一責任の原則に違反しており、
過度に。 解決策は、それをより少なくし、それを分割することです。 実際、私は
それが保守性と読みやすさにとって最も重要なことだと思います。

待機は基本的な制御フロー操作だと思います。

そうですか？ 実際、待って？ どちらも効果的な制御フロー操作です
それは「文脈から価値を引き出す」と言っています。 言い換えれば、地元で
コンテキストでは、次のタイプの演算子がawait：implであると想像できます。
未来

-> Tと？ ：impl Try-> T。

例外はありますが、それは例外であり、私たちがすべきことではありません。
のために努力。

そしてここでの例外は？ ？

@andreytkachenko https://github.com/andreytkachenko

@ejmahlerhttps ： //github.com/ejmahlerに同意します。 すべきではない
開発の反対側を忘れてください-コードレビュー。 ソースコード付きのファイルは
読んだり書いたりすることがはるかに多いので、もっと簡単にできるはずです
読んで理解してから書く。

不一致は、読みやすさと
人間工学。

これよりも理解しやすいです：

...本文：MyResponse = client.get（ "https：// my_api"）。send（）。await？.into_json（）。await？;

これはフォーマット方法ではありません。 慣用的なrustfmtフォーマット
は：

本体：MyResponse =クライアント
.get（ "https：// my_api"）
.send（）
。一致？
.into_json（）
。一致？;

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/rust-lang/rust/issues/57640#issuecomment-455810497 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/ABGmeocFJpPKaypvQHo9LpAniGOUFrmzks5vE3kXgaJpZM4aBlba
。

@ejmahler私たちはreに同意しません。 "隠蔽"; 同じ議論がなされた。

?演算子は非常に短く、過去に返品を「隠す」と批判されてきました。 ほとんどの場合、コードは書き込まれるのではなく、読み取られます。 名前を?!に変更すると、2倍の長さになり、見落としにくくなります。

それにもかかわらず、私たちは最終的に?を安定させ、それ以来、予言は実現しなかったと思います。
私にとって、接尾辞awaitは、自然な読み順に従います（少なくとも左から右の言語を話す人にとって）。 特に、データフローの順序に従います。

構文の強調表示は言うまでもありません。待機に関連するものはすべて明るい色で強調表示できるため、一目で見つけることができます。 したがって、実際のawait単語の代わりに記号があったとしても、構文が強調表示されたコードで非常に読みやすく、見つけやすくなります。 そうは言っても、私はまだawait単語をgrepの理由で使用することを好みます-記号の代わりにawait単語だけを使用すると、待っているものすべてのコードをgrepする方が簡単です@や＃のように、その意味は文法に依存します。

これはすべてロケット科学ではありません

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

接尾辞...は非常に読みやすく、一目で見逃しにくく、将来の結果が利用可能になるのを待つ間、コードの一種の末尾として自然に読み取られるため、非常に直感的です。 誰もが以前に楕円を見たことがあるので、優先順位/マクロシェナニガンは必要なく、見慣れないシジルからの余分なラインノイズもありません。

（@solsonに謝罪）

@ ben0x539つまり、 future()....startような結果のメンバーにアクセスできるということですか？ または、 range().....ような範囲の結果を待ちますか？ そして、現在の省略記号..は、右側の二項演算子または二項演算子である必要があり、これは一目で非常に近いので、 no precedence/macro shenanigans necessary and正確に意味します。

はい ？ オペレーターが存在します。 私はすでにあったことを認めました
例外。 しかし、それは例外です。 制御フローの大部分は
Rustプログラムは、プレフィックスキーワードを介して行われます。

13:51ベンジャミン君の土、2019年1月19日には[email protected]
書きました：

これはすべてロケット科学ではありません

let body：MyResponse = client.get（ "https：// my_api"）。send（）...？。into_json（）...？;

接尾辞...は非常に読みやすく、一目で見逃しがたいです。
あなたはそれをコードのようなものとして自然に読むので直感的です
将来の結果が利用可能になるのを待つ間。 番号
優先順位/マクロシェナニガンが必要であり、からの余分なラインノイズはありません
誰もが以前に楕円を見たことがあるので、なじみのないシジル。

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/rust-lang/rust/issues/57640#issuecomment-455818177 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/ABGmen354fhk7snYsANTfp5oOuDb4OLYks5vE5NSgaJpZM4aBlba
。

@HeroicKatora少し人工的に見えますが、確かにそうです。 これは、提案されている他の接尾辞ソリューションと同様に、接尾辞操作であるため、 await x?直感に反する優先順位の必要性を回避し、マクロではないことを意味しました。

@ejmahler

はい ？ オペレーターが存在します。 私はすでに例外があったことを認めました。 しかし、それは例外です。

keyword exprに適合する2つの式形式、つまりreturn exprとbreak exprます。 前者は後者よりも一般的です。 continue 'label形式は、式ではありますが、 keyword expr形式ではないため、実際にはカウントされません。 これで、2つの接頭辞キーワード単項式フォームと1つの後置単項式フォームができました。 ?とawaitがawaitとreturnよりも似ていることを考慮する前に、私はreturn/break exprとはほとんど呼びません。 ?が例外となるルール。

Rustプログラムの制御フローの大部分は、プレフィックスキーワードを介して行われます。

前述のように、 break exprはそれほど一般的ではありません（ break;がより一般的で、 return;がより一般的であり、単項式ではありません）。 残っているのは初期のreturn expr;あり、これがmatch 、 ? 、ネストされたif letよりもはるかに一般的であることは私にはまったくわかりません。 else s、およびforループ。 try { .. }安定したら、 ?がさらに使用されると思います。

@ ben0x539準備ができたら、可変個引数ジェネリック用に...を予約する必要があると思います

私はここでpostfix構文で革新するというアイデアが本当に好きです。 フローの方がはるかに理にかなっており、プレフィックスtry!からポストフィックス?移行したときに、コードがどれだけ改善されたかを覚えています。 Rustコミュニティで、コードがどれだけ改善されたかを体験した人はたくさんいると思います。

.awaitのアイデアが気に入らない場合は、実際の接尾辞演算子を見つけるためにある程度の創造性を発揮できると確信しています。 一例として、 ++または@を使用して待機することが考えられます。

:(私はもう待ちたくないだけです。

誰もがマクロ構文に慣れています。他の意見で始まるこのスレッドのほとんどの人は、最終的にマクロ構文を好むようです。

確かにそれは「魔法のマクロ」になるでしょうが、ユーザーはマクロ展開がどのように見えるかを気にすることはめったになく、そうする人にとっては、ドキュメントでニュアンスを説明するのは簡単です。

通常のマクロ構文は、アップルパイのようなもので、誰もが2番目に好きなオプションですが、その結果、家族が好きなオプションです[0]。 重要なのは、tryのように！ 後でいつでも変更できます。 しかし、最も重要なことは、私たち全員が同意するのが早ければ早いほど、実際にそれを使い始めて生産的になることができるのです！

[0]（最初の1分間に参照） https://www.ted.com/talks/kenneth_cukier_big_data_is_better_data/transcript?language=en

match、if、if let、while、while、forは、すべて広範な制御フローです。
プレフィックスを使用します。 休憩と続行のふりをすることが唯一の制御フローです
キーワードはイライラするほど誤解を招くものです。

15:37 Yazad Daruvalaで土、2019年1月19日には[email protected]
書きました：

:(私はもう待ちたくないだけです。

誰もがマクロ構文に慣れています。このスレッドのほとんどの人は
他の意見から始めて、マクロ構文を支持することになったようです。

確かにそれは「魔法のマクロ」になるでしょうが、ユーザーはマクロが何であるかを気にすることはめったにありません
拡張は次のように見えます。そうする人にとっては、説明するのは簡単です。
ドキュメントのニュアンス。

通常のマクロ構文はアップルパイのようなもので、みんなの2番目です
お気に入りのオプションですが、結果として家族のお気に入りのオプション[0]。
重要なのは、tryのように！ 後でいつでも変更できます。 しかし、ほとんどの
重要なのは、私たち全員が同意するのが早ければ早いほど、私たち全員が早く始めることができるということです。
実際に使用して生産性を高めましょう！

[0]（最初の1分間に参照）
https://www.ted.com/talks/kenneth_cukier_big_data_is_better_data/transcript?language=en

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/rust-lang/rust/issues/57640#issuecomment-455824275 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/ABGmesz5_LfDKdcKn6zMO5uuSJs9lFiYks5vE6wygaJpZM4aBlba
。

@mitsuhiko同意します！ チェーンにより、Postfixはより素朴に感じます。 私が提案したfut@await構文は、他の提案ほど多くの欠点がないように見えるもう1つの興味深いオプションだと思います。 それがあまりにも遠すぎて、もっと現実的なバージョンが望ましいかどうかはわかりませんが。

@ejmahler

match、if、if let、while、while let、およびforはすべて、プレフィックスを使用する広範な制御フローです。 ブレークとコンティニューのふりをすることが、イライラするほど誤解を招く唯一の制御フローキーワードです。

誤解を招くことはまったくありません。 これらの構成に関連する文法は大まかに次のとおりです。

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 ","?;

ここで、フォームはif/while expr block 、 for pat in expr block 、およびmatch expr { pat0 => expr0, .., patn => exprn }です。 これらすべての形式で、後に続くものの前にキーワードがあります。 これが「プレフィックスを使用する」という意味だと思います。 ただし、これらはすべてブロック形式であり、単項接頭演算子ではありません。 したがって、 await exprとの比較は、一貫性やルールがないため、誤解を招く恐れがあります。 ブロックフォームとの一貫性を保つ場合は、 await blockではなくawait expr await blockと比較してください。

@mitsuhiko同意します！ チェーンにより、Postfixはより素朴に感じます。

さびは二元論的です。 命令型アプローチと機能的アプローチの両方をサポートします。 場合によっては、それぞれがより適している可能性があるため、問題ないと思います。

知りません。 両方があれば素晴らしいと思います：

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

しばらくScalaを使っていたので、私もそのように機能することがたくさん好きでした。 特にmatchとifは、Rustの接尾辞の位置にあると便利です。

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

これまでのまとめ

オプションマトリックス：

• ボートなし
• mehcode
• HeroicKatora
• アーロンフリエル
• EyeOfPython

オプションの要約マトリックス（ @を印章として使用しますが、ほとんど何でもかまいません）：

| 名前| Future<T> | Future<Result<T, E>> | Result<Future<T>, E> |
| --- | --- | --- | --- |
| プレフィックス| -| -| -|
| キーワードマクロ| await!(fut) | await!(fut)? | await!(fut?) |
| キーワード機能| await(fut) | await(fut)? | await(fut?) |
| 有用な優先順位| await fut | await fut? | await (fut?) |
| 明らかな優先順位| await fut | await? fut | await fut? |
| POSTFIX | -| -| -|
| キーワード付きFn | fut(await) | fut(await)? | fut?(await) |
| キーワードフィールド| fut.await | fut.await? | fut?.await |
| キーワードメソッド| fut.await() | fut.await()? | fut?.await() |
| 接尾辞キーワードマクロ| fut.await!() | fut.await!()? | fut?.await!() |
| スペースキーワード| fut await | fut await? | fut? await |
| シジルキーワード| fut@await | fut@await? | fut?@await |
| シジル| fut@ | fut@? | fut?@ |

「SigilKeyword」のsigilは#になることはできません。その場合、 rという未来ではそれを行うことができません。 ...は、私の最初の心配のように、印章がトークン化を変更する必要がないためです。

より現実の使用（PM私の複数持つ他の_real_のユースケースawait urloに、私はそれらを追加します）：

| 名前| （reqwest） Client |> Client::get |> RequestBuilder::send |> await |> ? |> Response::json | > ? |
| --- | --- |
| プレフィックス| -|
| キーワードマクロ| await!(client.get("url").send())?.json()? |
| キーワード機能| await(client.get("url").send())?.json()? |
| 有用な優先順位| (await client.get("url").send()?).json()? |
| 明らかな優先順位| (await? client.get("url").send()).json()? |
| POSTFIX | -|
| キーワード付きFn | client.get("url").send()(await)?.json()? |
| キーワードフィールド| client.get("url").send().await?.json()? |
| キーワードメソッド| client.get("url").send().await()?.json()? |
| 接尾辞キーワードマクロ| client.get("url").send().await!()?.json()? |
| スペースキーワード| client.get("url").send() await?.json()? |
| シジルキーワード| client.get("url").send()@await?.json()? |
| シジル| client.get("url").send()@?.json()? |

編集メモ： Response::jsonがFutureも返すことは理にかなっているかもしれないと私に指摘されました。ここで、 sendは発信IOを待機し、 json （または結果の他の解釈）は、着信IOを待機します。 ただし、式にIO待機ポイントが1つしかない場合でもチェーンの問題が適用されることを示すのは意味があると思うので、この例はそのままにしておきます。

プレフィックスオプションについては大まかなコンセンサスがあるようですが、（ await?砂糖と一緒に）明らかな優先順位が最も望ましいです。 ただし、上記のような連鎖を容易にするために、多くの人が後置ソリューションを支持するように言っています。 プレフィックスの選択には大まかなコンセンサスがありますが、どのポストフィックスソリューションが最適であるかについてのコンセンサスはないようです。 提案されたすべてのオプションは、簡単な混乱につながります（キーワードの強調表示によって軽減されます）。

• FnWithキーワード=> awaitという引数でfnを呼び出す
• キーワードフィールド=>フィールドアクセス
• キーワードメソッド=>メソッド呼び出し
• マクロ（プレフィックスまたはポストフィックス）=> awaitはキーワードですか？
• スペースキーワード=>グループ化を1行に分割します（複数行よりも優れていますか？）
• Sigil =>すでにsigilが多いと認識されている言語に新しいsigilsを追加します

その他のより抜本的な提案：

• プレフィックス（明らかな優先順位）とポストフィックス「フィールド」の両方を許可します（これは将来、 match 、 ifなどのより多くのキーワードに適用され、これを一般化されたパターンにすることができますが、不要ですこの討論への補遺）[[参照]（https://github.com/rust-lang/rust/issues/57640#issuecomment-455827164）]
• 先物を解決するためのパターンのawait （連鎖なし）[[参照]（https://github.com/rust-lang/rust/issues/57640）]
• プレフィックス演算子を使用しますが、遅延を許可します[[reference]（https://github.com/rust-lang/rust/issues/57640#issuecomment-455782394）]

キーワードマクロawait!(fut)での安定化は、もちろん、基本的に上記のすべてと将来互換性がありますが、マクロで通常の識別子の代わりにキーワードを使用する必要があります。

1つのチェーンで2つのawaitを使用する、ほとんど現実的な例がある場合は、ぜひご覧ください。 これまで誰も共有していません。 ただし、接尾辞awaitは、reqwestの例に示すように、チェーン内でawait複数回実行する必要がない場合でも役立ちます。

この要約コメントの上に注目すべき何かを見逃した場合は、urloで私、それを追加しようとします（ただし、大きな声の好意を避けるために、他の誰かのコメントを追加する必要があります）。

個人的に、私は歴史的に明らかな優先順位を持つプレフィックスキーワードを支持してきました。 キーワードマクロawait!(fut)安定化することは、実際のユースケースで待機が発生する場所に関する実際の情報を収集するのに役立ち、後でマクロ以外のプレフィックスまたはポストフィックスオプションを追加できると思います。 。

しかし、上記の要約を書く過程で、私は「キーワードフィールド」が好きになり始めました。 「スペースキーワード」は、複数の行に沿って分割すると快適になります。

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

しかし、1行では、式のグループ化が不十分な厄介な中断が発生します： client.get("url").send() await?.json()? 。 ただし、キーワードフィールドを使用すると、次の両方の形式で見栄えがよくなります。 client.get("url").send().await?.json()?

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

アクションなので「キーワードメソッド」の方が流れやすいと思いますが。 必要に応じて、 Future 「実際の」メソッドにすることもできます。

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

（ extern "rust-await"はもちろん、実際に待機を行うために必要なすべての魔法を意味し、実際には実際のfnではありません。キーワードの場合、構文がメソッドのように見えるため、主にそこにあります。メソッドが使用されます。）

プレフィックス（明らかな優先順位）とポストフィックス「フィールド」の両方を許可します...

接頭辞構文が選択されている場合（一緒に、または接頭辞の代わりに）、それは間違いなく将来の議論の議論になります。接頭辞と接尾辞の両方の表記で機能するキーワードがあります。もう1つは、ルールを統一しながら、意味のある場所で両方を許可し、構文の柔軟性を高めることができるかもしれません。 悪い考えかもしれませんし、却下されるかもしれませんが、 await postix表記が使用されている場合、将来的には間違いなく議論されるでしょう。

この構文でawait文字列を含まない構文が受け入れられる可能性はほとんどないと思います。

：+1：

ここにあるたくさんの例（ @mehcodeなど）を見た後に私が思いついたランダムな考え： .awaitについて覚えている不満の1つは、見づらいということです†。通常は間違いですが、 .await?あることが多いという事実は、とにかくそれに特別な注意を引くのに役立ちます。

†キーワードを強調しないものを使用している場合

@ejmahler

英語のように読めない構文には反対です

request.get().awaitようなものは、 body.lines().collect()ようなものと同じように読み取ります。 「チェーンされたイテレータメソッドの束」では、最初に「待機」と言ったことを覚えておく必要があり、何かが聞こえたときにそれが自分の目的になるかどうかわからないため、実際には_prefix_の読み取りが悪くなると思います。ちょっと待って、庭の小道の文章のように。

そして、何年にもわたって本番コードでそれらを使用した後、私の信念は、一目であなたの歩留まりがどこにあるかを知ることは絶対に重要であるということです。 関数の場合にインデント行をざっと読むと、認知的負荷なしで、200行の関数のすべてのco_await / yieldリターンを数秒で選択できます。

これは、Rustの式指向の性質を考えると、式の中には決して存在しないことを意味します。これは、私が絶対にサポートしない制限です。 そして、少なくともC＃のawaitでは、 CallSomething(argument, await whatever.Foo()を持つことは絶対にもっともらしいです。

async _will_が式の途中に表示されることを考えると、接頭辞よりも接頭辞の方が見やすい理由がわかりません。

'if、while、match、returnと同じレベルの敬意を払う必要があります。 それらのいずれかが接尾辞演算子であると想像してみてください-Rustコードを読むことは悪夢です。

return （およびcontinueとbreak ）とwhileは、常に!と()返すため、チェーンには_完全に_役に立たないことで注目に値します。 forを省略しましたが、特にレーヨンでは、 .for_each()を使用してコードが問題なく記述されていても悪影響はありません。

async/awaitが主要な言語機能になるという事実と和解する必要があるでしょう。 あらゆる種類のコードに表示されます。 それは生態系に浸透します-いくつかの場所ではそれは?と同じくらい一般的です。 人々はそれを学ぶ必要があります。

したがって、構文の選択は、最初にどのように感じるかではなく、長期間使用した後にどのように感じるかに意識的に焦点を合わせたいと思うかもしれません。

また、制御フロー構造に関する限り、 awaitは別の種類の動物であることを理解する必要があります。 return 、 break 、 continue 、さらにはyieldような構成は、 jmp観点から直感的に理解できます。 これらを見ると、関心のある制御フローが他の場所に移動しているため、目が画面上で跳ね返ります。 ただし、 awaitはマシンの制御フローに影響を与えますが、私たちの目やコードの直感的な理解にとって重要な制御フローは移動しません。

無条件の呼び出しをreturnまたはbreakにチェーンすることは意味がないため、誘惑されません。 同様の理由で、優先ルールを変更してそれに対応することはできません。 これらの演算子の優先順位は低くなります。 彼らはすべてを右に持って行き、どこかに戻し、その関数またはブロック内での実行を終了します。 ただし、 await演算子はチェーン化する必要があります。 これは式の不可欠な部分であり、式の終わりではありません。

このスレッドでの議論と例を検討した結果、驚くべき優先順位のルールを後悔するために生きるだろうというかじった感覚が残っています。

ストーキング馬の候補者は今のところawait!(expr)で行くようで、もっと良いものが後で解決されることを望んでいます。 @Centrilのコメントを読む前に、この重要な機能をほぼすべての構文で使用できるようにするために、これをサポートしていたと思います。 しかし、彼の議論は、これがただの取り締まりであると私に確信させます。 Rustではメソッド呼び出しの連鎖が重要であることを私たちは知っています。 そのため、 ?キーワードが採用され、広く普及し、大成功を収めました。 私たちが失望することがわかっている構文を使用することは、確かに技術的負債を追加するだけです。

このスレッドの早い段階で、 @ withoutboatsは、4つの既存のオプションのみが実行可能であるように見えることを示しました。 それらのうち、接尾辞expr await構文だけが私たちを長期的に幸せにする可能性があります。 この構文は、奇妙な優先順位の驚きを生み出しません。 ?演算子のプレフィックスバージョンを作成する必要はありません。 メソッドチェーンとうまく連携し、左から右への制御フローを分割しません。 成功した?演算子は、接尾辞演算子の前例として機能します。 awaitは、実際にはreturn 、 breakよりも?に似ています。 break 、またはyield 。 接尾辞の非記号演算子はRustの新機能かもしれませんが、 async/await使用法は、すぐに使い慣れるように十分に普及しています。

接尾辞構文のすべてのオプションは機能しているように見えますが、 expr awaitはいくつかの利点があります。 この構文は、 awaitがキーワードであることを明確にし、魔法の制御フローを強調するのに役立ちます。 expr.await 、 expr.await() expr.await! 、 expr.await!()などと比較すると、これはフィールド/メソッド/マクロのように見えることを説明する必要がありませんが、実際にはこの1つの特別なケースではありません。 ここでは、スペースセパレーターに慣れています。

awaitを@と綴ったり、解析の問題を引き起こさない他の記号を使用したりするのは魅力的です。 それは確かにそれを保証するのに十分重要なオペレーターです。 しかし、最終的にawaitと綴る必要がある場合は、それで問題ありません。 接尾辞の位置にある限り。

誰かが_実際の_例について言及したように...私は（tokeiによると）23,858行の錆びたコードベースを維持しています。これは非常に非同期で、先物0.1 await （非常に実験的です）。 （編集済みの）洞窟探検に行きましょう（すべてが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)
}

ここで、これを最も人気のあるプレフィックスバリアントに変換してみましょう。 明らかな理由で、これは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)
}

最後に、これを私のお気に入りの接尾辞バリアント「接尾辞フィールド」に変換しましょう。

// 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)
}

この演習の後、私はいくつかのことを見つけました。

• 私は今、 await? fooに強く反対しています。 単純な式には適していますが、複雑な式では?が失われているように感じます。 プレフィックスを付ける必要がある場合は、「便利な」優先順位を付けたいと思います。

• 後置表記を使用すると、ステートメントを結合し、不要なletバインディングを減らすことができます。

• postfix _field_表記を使用すると、rustfmtの用語でそれ自体の行ではなく、待機しているものの行に.await?を表示することを強く好みます。

上記の楕円の後置表記「...」は、その簡潔さと、他の何かを見越して一時停止を表す英語の象徴の両方に感謝します。 （非同期動作がどのように機能するかと同じように！）、それはまたうまく連鎖します。

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

他のオプションがこれほど簡潔で視覚的に意味があるとは思えません。

A

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();

長い連鎖が待っているのは良い形だとさえ考えるべきでしょうか？

通常のFutureコンビネータを単純に使用しないのはなぜですか？

実際、失敗時にバックアップ動作を実行したい場合、一部の式は待機チェーンにうまく変換されません。

個人的に私はこれだと思います：

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

value.unwrap()

これよりはるかに自然に読みます：

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()

結局のところ、私たちはまだゼロコスト先物の全力を手にしています。

それを考慮してください。

@EyeOfPython future@await @以外の選択肢があることを強調したいと思います。 future~awaitと書くことができます。ここで、 ~はセミハイフンのように機能し、可能なすべての接尾辞演算子に対して機能します。

ハイフン-は、マイナス演算子と負の演算子としてすでに使用されています。 もう良くない。 ただし、 ~は、Rustのヒープオブジェクトを示すために使用されていました。それ以外の場合、プログラミング言語ではほとんど使用されていませんでした。 他の言語の人にとっては混乱が少なくなるはずです。

@earthengine良い考えですが、 future~を使用することもできます~がawaitキーワードのように機能する未来を待つことを意味します（ ?記号のように）

未来| 結果の未来| 未来の結果
-| -| -
未来〜|未来〜？|未来？〜

また、次のような先物の連鎖：

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

Goが非同期プログラミングをどのように実装しているかを見て、そこで何か面白いものを見つけました。 Goの先物に最も近い代替手段はチャネルです。 そして、値を待つためのawaitまたは他の叫び声の構文の代わりに、Goチャネルはその目的のために<-演算子を提供するだけです。 私にとって、それはかなりきれいで簡単に見えます。 以前、Goのシンプルな構文と優れた非同期機能を人々がどのように称賛するかをよく見ました。そのため、その経験から何かを学ぶことは間違いなく良い考えです。

残念ながら、RustソースコードにはGoよりも多くの山括弧があるため、まったく同じ構文を使用することはできませんでした。これは主にジェネリックが原因です。 これにより、 <-演算子は非常に微妙になり、操作が快適ではなくなります。 もう1つの欠点は、関数シグネチャで->と反対に見える可能性があり、そのように考える理由がないことです。 さらにもう1つの欠点は、 <-印章がplacement newとして実装されることを意図していたため、人々がそれを誤解する可能性があることです。

したがって、構文をいくつか試した後、 <-- sigilで停止しました。

let output = <-- future;

asyncコンテキストでは、 <-未満ですが、 <--は非常に単純です。 ただし、代わりに、 <-やプレフィックスawaitよりも大きな利点があります。インデントでうまく機能します。

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);
}

私にとって、この演算子はawait （コードコンテキスト内の他のキーワードや変数のように見えます）よりもさらにユニークで見つけやすいように見えます。 残念ながら、Githubではコードエディターよりも薄く見えますが、それは致命的ではないと思います。 誰かが不快に感じたとしても、異なる構文の強調表示またはより良いフォント（特に合字の場合）はすべての問題を解決します。

この構文が好きなもう1つの理由は、概念的に「まだここにないもの」として表現できるためです。 矢印の右から左の方向は、テキストの読み方とは逆であり、「未来から来るもの」と表現することができます。 <--演算子の長い形状は、「永続的な操作が開始される」ことも示しています。 futureからの山かっこと2つのハイフンは、「継続的なポーリング」を表すことができます。 そして、それでも以前と同じように「待つ」と読むことができました。
ある種の悟りではありませんが、楽しいかもしれません。

この提案で最も重​​要なことは、人間工学的なメソッドチェーンも可能であるということです。 私が以前に提案した遅延プレフィックス演算子のアイデアは、ここにぴったりです。 このようにして、接頭辞と接尾辞のawait構文の両方の世界から最高のものを得ることができます。 以前に多くの場面で個人的に欲しかったいくつかの便利な追加機能も導入されることを本当に望んでいます：遅延間接参照と遅延否定構文。

全体として、ここで遅延語が適切かどうかはわかりません。別の名前を付ける必要があるかもしれません。

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

let not_empty = some_vec.!is_empty();

let deref = value.*as_ref();

演算子の優先順位は非常に明白に見えます：左から右へ。

この構文によって、 is_not_*関数を作成する必要性が減ることを願っています。この関数の目的は、 boolプロパティを無効にして返すことだけです。 また、ブール/逆参照式を使用すると、よりクリーンになる場合があります。

最後に、 @ mehcodeによって投稿された実際の例に適用しました。 <--がメソッド呼び出しチェーン内のasync関数を適切に強調する方法が気に入っています。 逆に、接尾辞awaitは、通常のフィールドアクセスまたは関数呼び出し（構文によって異なります）のように見え、特別な構文の強調表示またはフォーマットなしでそれらを区別することはほぼ不可能です。

// 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)
}

結局のところ、それが私が使用したい構文です。

@novacrazy

長い連鎖が待っているのは良い形だとさえ考えるべきでしょうか？ 通常のFutureコンビネータを単純に使用してみませんか？

私があなたを誤解しなかったかどうかはわかりませんが、それらは排他的ではありません、あなたはまだコンビネータを使うこともできます

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

ただし、これを機能させるには、 FnOnce(T) -> Uだけでなく、 FnOnce(T) -> impl Future<_>でand_then句を入力する必要があります。 将来的に連鎖コンビネータを実行すると、結果は接尾辞にparanthesisがなくてもきれいに機能します。

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

この投稿では、修正後の場合の演算子の優先順位の問題に焦点を当てます。 私の知る限り、少なくともある程度は機能する3つの実行可能な選択肢があり、それぞれが現在の構文でこれらの優先順位を持つ1つの修正後の式によって例示されています。 私は、どの提案も現在のオペレーターの優先順位を変えるべきではないと強く感じています。

• メソッド呼び出し（ future.await() ）
• フィールド式（ future.await ）
• 関数呼び出し（ future(await) ）

機能の違いはかなり小さいですが、存在します。 私はこれらすべてを受け入れることに注意してください、これはほとんど微調整です。 それらすべてを表示するには、いくつかのタイプが必要です。 例の不自然さについてコメントしないでください。これは、すべての違いを一度に表示する最も圧縮されたバージョンです。

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)

• メソッド呼び出し： foo.member.await()(42)
  最も強く結合するので、paranthesisはまったくありません
• メンバー： (foo.member.await)(42)
  これが呼び出し可能である場合、待機中の結果の周りにパランセシスが必要です。これは、呼び出し可能をメンバーとして持つことと一致します。そうでない場合、メンバー関数の呼び出しと混同されます。 これはまた、パターンで構造を破壊できるように示唆しています： let … { await: value } = foo.member; value(42)どういうわけか？
• 関数呼び出し： (foo.member)(await)(42)
  関数呼び出しとして動作するため、破棄（メンバーを移動）するためのparanthesisが必要です。

メンバーの移動によって入力構造体を分解したり、結果を呼び出し可能として呼び出したりしない場合、これら3つの優先クラスは次々に来るため、すべて同じように見えます。 先物をどのように振る舞わせたいですか？

メソッド呼び出しと最もよく似ているのは、 selfを受け取る別のメソッド呼び出しです。

メンバーに最もよく似ているのは、暗黙のメンバーawaitのみを持つ構造体であり、したがって、これから移動することによって構造体が破壊され、この移動は暗黙的に将来を待ちます。 これは最も目立たないように感じます。

関数と並行して呼び出されるのは、クロージャの動作です。 言語コーパスへの最もクリーンな追加としてこのソリューションをお勧めします（構文は型の可能性に最もよく似ています）が、メソッド呼び出しのいくつかの良い点であり、 .awaitは他のものより長くなることはありません。

@HeroicKatora我々は特殊なケースでし.awaitを可能にするlibsyntaxでfoo.await(42)が、これは矛盾/アドホックだろうが。 ただし、クロージャを出力する先物は存在しますが、おそらくそれほど一般的ではないため、 (foo.await)(42)は有用であるように思われます。 したがって、一般的なケースに合わせて最適化すると、 ()を.awaitに追加する必要がないため、バランスが取れている可能性があります。

@Centril同意します、一貫性が重要です。 似たような行動がいくつか見られたら、統合を通じて他の行動を推測したいと思います。 しかし、ここでは.awaitが扱いにくいように見えます。特に、上記の例では、暗黙の破棄と並行していることが明確に示されています（これらの影響が発生する別の構文が見つからない場合を除く）。 破棄を見ると、let-bindingsなどでこれを使用できるかどうかすぐに疑問に思います。ただし、そのようなメンバーがない元の型を分解するため、または特に型がimpl Future<Output=F>場合は、これは不可能です。 let _ =代わりに代替プレフィックスawait _ =に戻ります¹）。

構文自体を使用することを禁じているわけではありません。私はそれを学ぶことに対処できると思います。それが最終的なものであることが判明した場合は、精力的に使用しますが、明らかに弱点のようです。

¹これは、パターン内の名前の後ろに?を許可することで、 ?を許可しながら一貫性を保つことができます。

• await value? = failing_future();

ResultのOk部分と一致します。 これは、他のコンテキストでも調査するのは興味深いようですが、トピックから外れています。 また、同時にawaitプレフィックスとサフィックスの構文が一致することになります。

構文自体を使用することを禁じているわけではありません。私はそれを学ぶことに対処できると思います。それが最終的なものであることが判明した場合は、精力的に使用しますが、明らかに弱点のようです。

私はすべての解決策がいくつかの次元またはケースに関していくつかの欠点を持っていると思います。 一貫性、人間工学、連鎖性、可読性など...これにより、程度、ケースの重要性、典型的なRustコードおよびAPIへの適合性などが問題になります。

foo.await(42)書いているユーザーの場合..。

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

    foo.closure(42);
}

...私たちはすでに優れた診断を提供しています：

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

これをfoo.await(42)に合うように調整することは、かなり達成できるようです。 実際、私が見る限り、 foo.await(42)が書き込まれるときにユーザーが(foo.await)(42)意図していることがわかっているので、これをMachineApplicableでcargo fix編集できます。マナー。 実際、 foo.awaitを安定させても、 foo.await(42)を許可しない場合、 foo.await(42)は最初は合法ではないため、必要に応じて後で優先順位を変更することもできると思います。

さらなる入れ子が機能します（たとえば、閉鎖の結果の将来-これは一般的ではありません）：
`` `錆
struct HasClosure fn _foo（）->結果<（）、（）> {
let foo：HasClosure <_ i = "27"> = HasClosure {closure：Ok（| x | {}）};

foo.closure?(42);

Ok(())

}

例：閉鎖の結果の将来-これが一般的であるというわけではありません

追加の接尾辞?演算子は、どの修正後の例でも、構文を変更せずにこれを明確にします。 微調整は必要ありません。 問題は、 .member明示的にフィールドであり、最初に適用するために移動破壊が必要なことだけです。 そして、これを書くのは難しいとは言いたくありません。 私は主に、これは他の.member使用法と矛盾しているように思われると言いたいです。たとえば、マッチングに変換することができます。 元の投稿は、その点でポジティブとネガティブを比較検討していました。

編集： future.await(42)に合うように調整すると、これを作成する可能性があり、意図しない追加のリスクがあります。a）メンバーと同じ名前のメソッドが許可されているために、これが当てはまらないクロージャと矛盾します。 b） await議論を与えたい将来の開発を禁止する。 しかし、前に述べたように、クロージャを返すFuture微調整することは、最も差し迫った問題ではないはずです。

@novacrazy単に通常のFutureコンビネータを使用しないのはなぜですか？

Futures 0.3でどれだけの経験があるかはわかりませんが、一般的な予想では、コンビネータはあまり使用されず、プライマリ/イディオムの使用は非同期/待機になります。

Async / awaitには、コンビネータに比べていくつかの利点があります。たとえば、yieldポイント間での借用をサポートします。

コンビネータはasync / awaitのずっと前から存在していましたが、とにかくasync / awaitが発明されたのには、正当な理由があります。

Async / awaitはここにとどまります。つまり、人間工学的である必要があります（メソッドチェーンを含む）。

もちろん、必要に応じてコンビネータを自由に使用できますが、人間工学に基づいてコンビネータを使用する必要はありません。

@cramertjが言ったように、async / awaitの代わりではなく、async / awaitに焦点を当てて議論を続けるようにしましょう。

実際、失敗時にバックアップ動作を実行したい場合、一部の式は待機チェーンにうまく変換されません。

あなたの例は大幅に単純化することができます：

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()

これにより、どのパーツがエラーを処理しているか、どのパーツが通常のハッピーパス上にあるかが明確になります。

これはasync / awaitの優れた点の1つです。ループ、ブランチ、 match 、 ? 、 tryなど、言語の他の部分とうまく連携します。

実際、 await除けば、これはFuturesを使用していなかった場合に作成するコードと同じです。

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()

そして何よりも、通常のコードを別の関数に移動して、エラー処理コードをさらに明確にすることです。

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()

（これは@joshtriplettのコメントへの返信です）。

明確にするために、括弧を付ける必要はありません。括弧なしでは読むのが難しいと言う人がいるので、私はそれについて言及しました。 したがって、括弧はオプションのスタイルの選択です（複雑なワンライナーにのみ役立ち

状況によっては、すべての構文が括弧の恩恵を受けます。どの構文も完全ではありません。

また、あなたのコメントを読み直した後、おそらくあなたは私が接頭辞awaitを提唱していると思ったのですか？ 私はそうではありませんでした、私の例はpostfix await 。 私は全体的に接尾辞awaitが好きですが、他の構文もいくつか好きです。

私はfut.awaitに慣れ始めています、人々の最初の反応は「待って、それがあなたが待つ方法ですか？奇妙な」だろうと思います。 しかし後で彼らは便利のためにそれを好きになるでしょう。 もちろん、同じことが@awaitにも当てはまります。これは、 .awaitよりもはるかに際立っています。

その構文を使用すると、例のいくつかのレットを省略できます。

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()

これにより、 ?で何がアンラップされるのかが明確になり、 await some_op()?場合、 some_op()がアンラップされるのか、待機中の結果になるのかが明確になりません。

@Pauan

私はここでのトピックから焦点を移そうとしているのではなく、それがバブルの中に存在しないことを指摘しようとしています。 私たちは物事がどのように連携するかを考慮する必要があります。

理想的な構文が選択されたとしても、状況によってはカスタム先物とコンビネータを使用したいと思います。 それらがソフトに非推奨になる可能性があるという考えは、Rustの全体的な方向性に疑問を投げかけます。

あなたが与える例は、コンビネーターと比較してまだひどいように見えます、そしてジェネレーターのオーバーヘッドでおそらく少し遅くなり、より多くのマシンコードを生成します。

待っている限り、この接頭辞/接尾辞の印章/キーワードのバイクシェディングはすべて素晴らしいですが、おそらく私たちは実用的であり、Rustに来るユーザーに最も馴染みのある最も単純なオプションを選択する必要があります。 つまり、プレフィックスキーワード

今年は私たちが思っているよりも早く過ぎていくでしょう。 1月でもほとんど完了です。 ユーザーがプレフィックスキーワードに満足していないことが判明した場合は、2019/2020エディションで変更できます。 「後知恵は2020年」という冗談を言うことさえできます。

@novacrazy

私が見た一般的なコンセンサスは、第3版が必要な_最も早い_は2022年であるということです。私たちは間違いなく別の版を計画したくありません。 2018年版は素晴らしかったが、コストがかからなかったわけではなかった。 （そして、2018年版のポイントの1つは、非同期/待機を可能にすることです。それを取り戻して、「いいえ、今すぐ2020年版にアップグレードする必要があります！」と言うことを想像してください）

いずれにせよ、たとえそれが望ましいとしても、接頭辞キーワード->接尾辞キーワードの移行がエディションで可能であるとは思いません。 エディションに関する規則は、警告なしにコンパイルされ、エディションX + 1でも同じように機能するように、エディションXで慣用的なコードを記述する方法が必要であるということです。

別のソリューションでコンセンサスを得ることができれば、キーワードマクロで安定させたくないのと同じ理由です。 望ましくないことがわかっているソリューションを意図的に安定化すること自体が問題です。

待機ポイントが1つしかない式の場合でも、接尾辞ソリューションがより最適であることを示したと思います。 しかし、提案された接尾辞ソリューションのいずれかが他のすべてよりも明らかに優れているとは思えません。

ちょうど私の2セント（私は誰でもありませんが、私はかなり長い間議論に従います）。 私のお気に入りの解決策は@await postfixバージョンでしょう。 たぶん、いくつかの新しい接尾辞マクロ構文のように、接尾辞!await検討できますか？

例：

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

数回の言語反復の後、独自の接尾辞マクロを実装できることは素晴らしいことです。

...すべての新しいsygilsの提案

Rustはすでに構文/ sygilが重く、 awaitキーワードが予約されており、 stuff@await （または他のsygil）は奇妙で醜い（主観的、私は知っています）ように見えます。大きな赤い旗である言語の他のものと統合しません。

Goがどのように実装するかを見てきました
... <-...提案

@ I60R ：Goにはアドホックなソリューションでいっぱいのひどい構文があり、Rustとは非常に異なり、完全に必須です。 この提案もまた、この特定の機能のためだけに、sygil / syntaxが重く、完全にアドホックです。

@ I60R ：Goの構文はひどい

ここで他の言語をバッシングすることは控えましょう。 「Xはひどい構文を持っている」は悟りとコンセンサスにつながりません。

Python / JavaScript / Rustのユーザーであり、コンピューターサイエンスの学生である私は、個人的には接頭辞await + f.await()を両方の言語で使用することを好みます。

1. PythonとJavaScriptの両方にプレフィックスawaitます。 最初にawaitが表示されると思います。 これが非同期コードであることを理解するために行を深く読まなければならない場合、私は非常に不安を感じます。 RustのWASM機能を使用すると、多くのJS開発者を引き付ける可能性があります。 Rustにはすでに他にもたくさんの新しい概念があることを考えると、親しみやすさと快適さが本当に重要だと思います。

2. 接尾辞awaitは、設定を連鎖させるのに便利なようです。 ただし、 .await 、 @await 、 f awaitようなソリューションは、 await構文のアドホックソリューションのように見えますが、 .await()を考えるのは理にかなっているため、嫌いです。 futureメソッドを呼び出すときの.await() future 。

Rustはすでにjavascriptからの逸脱であり、awaitは、関数を使用してawaitを示す関数を呼び出す（つまり、関数を介してエミュレートできない）ようなものではなく、async-awaitに導入される最初のタイマーを混乱させます。 したがって、構文は異なるはずだと思います。

.await()はおそらく.awaitよりもはるかに望ましいと私は確信しましたが、この投稿の残りの部分はその位置を少しヘッジしています。

これは、 await!(fut)が_値でfutを消費する必要があるためです_。 フィールドアクセスのように見せることは_bad_です。これは、プレフィックスキーワードのように移動するという意味がなく、マクロやメソッド呼び出しのように移動する可能性がないためです。

興味深いことに、キーワードメソッドの構文により、暗黙の待機設計のように見えます。 残念ながら、 async fn() -> Tをfn() -> Future<T>と同じように使用したいので、Rustでは「明示的な非同期、暗黙の待機」はできません（したがって、このスレッドで再訴訟しないでください）。 「暗黙の待機」動作をアクティブにするのではなく。

.await()構文が（Kotlinが使用するような）暗黙の待機システムのように見えるという事実は、中傷になる可能性があり、not-の周りの魔法のために「暗黙の非同期、暗黙の待機」の感覚をほとんど与えます。本当にメソッド呼び出し.await()構文。 それをUFCSでawait(fut)として使用できますか？ UFCSの場合はFuture::await(fut)になりますか？ 言語の別の次元のように見える構文は、機能的でなくても、少なくとも構文的にある程度統一できない限り、問題を引き起こします。

後置ソリューションの概念は一般に接頭辞ソリューションの概念よりも望ましいものの、_個別の_後置ソリューションの利点が同じソリューションの欠点を上回っている場合、私は懐疑的です。

このスレッドが、最初の提案よりも大きなメリットをもたらすように見えるからではなく、可能であるために行われたように見える提案でいっぱいであることに少し驚いています。
$ 、 # 、 @ 、 ! 、 ~などについて、何が悪いのかという重要な議論をすることなく話すのをやめることはできますか？ await 、これはよく理解されており、他のさまざまなプログラミング言語で証明されていますか？

https://github.com/rust-lang/rust/issues/57640#issuecomment -455361619からの投稿には、すでにすべての適切なオプションがリストされていると思います。

それらから：

• 必須の区切り文字区切り文字は問題ないようです。少なくとも優先順位が何であるかは明らかであり、他のコードをより明確にすることなく読み取ることができます。 そして、2つの括弧を入力することはそれほど悪いことではありません。 おそらく唯一の欠点は、制御フローの操作がいくつか異なるにもかかわらず、関数呼び出しのように見えることです。
• 有用な優先順位が望ましいオプションかもしれません。 それは他のほとんどの言語が進んだ道のように思われるので、それはよく知られていて証明されています。
• 個人的には、空白を含むpostfixキーワードは、1つのステートメントに複数の待機があると奇妙に見えると思います。
  client.get("url").send() await?.json()? 。 間にあるその空白は、場違いに見えます。 かっこを使用すると、私にとってもう少し意味があります： (client.get("url").send() await)?.json()?
  しかし、プレフィックスバリアントを使用する場合よりも、制御フローを追跡するのがさらに難しいことがわかりました。
• 接尾辞フィールドは好きではありません。 awaitは非常に複雑な操作を実行します-Rustには計算可能なプロパティがなく、フィールドアクセスはそれ以外の場合は非常に単純な操作です。 したがって、この操作の複雑さについて間違った印象を与えるようです。
• 接尾辞の方法はOKかもしれません。 何人かの人々が彼らに複数の待機を伴う非常に長いステートメントを書くことを奨励するかもしれません、そしてそれはより多くの利回りポイントを隠すかもしれません。 また、何かが異なっていても、メソッド呼び出しのように見えます。

これらの理由から、私は「有用な優先順位」の後に「必須の区切り文字」が続くことを好みます

Goには、アドホックソリューションでいっぱいのひどい構文があり、Rustとは非常に異なり、完全に必須です。 この提案もまた、この特定の機能のためだけに、sygil / syntaxが重く、完全にアドホックです。

@dpc 、 <--提案を完全に読んだ場合、この構文はGoにのみ触発されていることがわかりますが、命令型と関数チェーンのどちらのコンテキストでもかなり異なり、使用できます。 また、 await構文がアドホックな解決策ではないこともわかりません。私にとっては、 <--よりもはるかに具体的で不器用です。 これは、 *reference代わりにderef reference / reference.deref / etcを使用するか、 result?代わりにtry result / result.try / etcを使用するのと似ています。 result? 。 JS / Python / etcに精通していること以外に、 awaitキーワードを使用する利点は見当たりません。これは、一貫性のある構成可能な構文よりも重要性が低いはずです。 そして、 <--印章を持っていることの不利な点は、それがawaitではないことを除いては見られません。

編集：これも@ Matthias247の投稿に対する良い答えになる可能性があります。これは、 awaitに対するいくつかの議論を提供し、同じ問題の影響を受けない可能な代替案を提案するためです。

歴史的で偏見のある理由に訴える議論から解放されて、 <--構文に対する批評を読むことは、私にとって本当に興味深いことです。

優先順位に関する実際の詳細について説明しましょう。

優先順位チャートそれが今日立っているよう：

演算子/式| 結合性
-| -
パス|
メソッド呼び出し|
フィールド式| 左から右へ
関数呼び出し、配列インデックス|
? |
単項- * ! & &mut |
as | 左から右へ
* / % | 左から右へ
+ - | 左から右へ
<< >> | 左から右へ
& | 左から右へ
^ | 左から右へ
\| | 左から右へ
== != < > <= >= | 括弧が必要
&& | 左から右へ
\|\| | 左から右へ
.. ..= | 括弧が必要
= += -= *= /= %= &= \|= ^= <<= >>= | 右から左へ
return breakクロージャ|

便利な優先順位はawaitを? await前に置くので、 ?よりも緊密にバインドされます。 したがって、チェーン内の?は、 `awaitをその前のすべてにバインドします。

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

はい、便利な優先順位で、それは「正しく機能します」。 それが一目で何をするか知っていますか？ それは（おそらく）悪いスタイルですか？ もしそうなら、rustfmtはそれを自動的に修正できますか？

明らかな優先順位により、 await ?より_どこか_下になります。 正確な場所はわかりませんが、それらの詳細はおそらくそれほど重要ではありません。

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

それが一目で何をするか知っていますか？ rustfmtは、垂直方向と水平方向のスペースを自動的に無駄にしない便利なスタイルにすることができますか？

後置キーワードはこれのどこに該当しますか？ おそらく、メソッド呼び出しを使用したキーワードメソッドとフィールド式を使用したキーワードフィールドですが、他のメソッドをどのようにバインドする必要があるのか​​わかりません。 awaitが驚くべき「議論」を受け取る可能性の低い構成につながるオプションは何ですか？

この比較では、「必須の区切り文字」（要約で

@ CAD97明確にするために、 .json()も未来であることを忘れないでください（少なくともreqwestsでは）。

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

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

複雑な錆の式を変換することで遊ぶほど（ただし、1つの待機が必要なものでも、20,000以上の将来のコードベースでは、ほぼすべての非同期式が待機し、その直後に別の待機が続くことに注意してください）、嫌いになります。 Rustのプレフィックス。

?演算子があるため、これは_all_です。 他の言語には、基本的に常に実際のコードでペアになっている接尾辞制御フロー演算子_および_ awaitがありません。

私の好みはまだ接尾辞フィールドです。 接尾辞制御演算子として、 future.awaitがfuture await以上を提供する厳密な視覚的グループ化が必要だと思います。 そして、 .await()?と比較して、 .await?が_奇妙な_ように見えるので、_気づかれ_、ユーザーはそれが単純な関数であるとは思わないでしょう（したがって、UFCSが機能しない理由を尋ねません） 。

後置を支持するもう1つのデータポイントとして、これが安定したら、 rustfixをawait!(...)から私たちが決定したものに移動することを非常に高く評価します。 ( ... )不必要にラップすることなく、接尾辞構文以外の何も明確に翻訳できる方法がわかりません。

最初に、「チェーンコンテキストでawait使用を奨励したいですか？」という質問に答える必要があると思います。 一般的な答えは「はい」だと思うので、後置バリアントの強力な議論になります。 await!(..)を追加するのが最も簡単ですが、 try!(..)話を繰り返すべきではないと思います。 また、「連鎖は潜在的にコストのかかる操作を隠す」という議論にも個人的に同意しません。すでに多くの連鎖方法があり、非常に重い可能性があるため、連鎖は怠惰を伴いません。

プレフィックスawaitキーワードは他の言語を使用するユーザーにとって最も馴染み深いものですが、それに基づいて決定する必要はないと思います。代わりに、使いやすさ、利便性、読みやすさなど、より長期的なものに集中する必要があります。 。 @withoutboatsは「親しみやすさの予算」について

今、私たちはおそらく同じことをする2つの方法を望まないので、接尾辞と接頭辞の両方のバリアントを導入するべきではありません。 したがって、オプションを接尾辞のバリアントに絞り込んだとしましょう。

まず、 fut awaitから始めましょう。このバリアントは、人間がコードを解析する方法を深刻に混乱させ、コードを読み取る際に常に混乱を招くため、非常に嫌いです。 （コードは主に読み取り用であることを忘れないでください）

次のfut.await 、 fut.await() 、 fut.await!() 。 最も一貫性があり、混乱の少ないバリアントは、接尾辞マクロのものになると思います。 いくつかの文字を節約するためだけに、新しい「キーワード関数」または「キーワードメソッド」エンティティを導入する価値はないと思います。

最後に、印章ベースのバリアント： fut@awaitおよびfut@ 。 fut@awaitバリエーションが好きではありません。印章を紹介すると、なぜawait部分に煩わされるのでしょうか。 将来の拡張fut@something計画はありますか？ そうでなければ、それは単に冗長に感じます。 だから私はfut@バリアントが好きです。それは優先順位の問題を解決し、コードは理解しやすく、書きやすく、読みやすくなります。 可視性の問題は、コードの強調表示によって解決できます。 この機能を「@forawait」と説明するのは難しいことではありません。 もちろん、最大の欠点は、非常に限られた「印章予算」からこの機能の料金を支払うことですが、機能の重要性と非同期コードベースで使用される頻度を考慮すると、長期的には価値があると思います。 そしてもちろん、 ?で特定の類似点を描くことができます。 （ただし、Rust批評家からのPerlジョークに備える必要があります）

結論：私の意見では、「印章予算」に負担をかける準備ができている場合はfut@を使用し、そうでない場合はfut.await!()ます。

Rustはニッチが異なり、すでに多くの点で異なって見えるため、親しみやすさについて話すとき、JS / Python / C＃の親しみやすさについてあまり気にする必要はないと思います。 これらの言語に類似した構文を提供することは、短期的で低報酬の目標です。 Rustが完全に異なる動作をする場合、使い慣れたキーワードを使用するためだけにRustを選択することはありません。

しかし、Rustは同様のニッチであり、哲学によってさえ、他の言語よりもGoに近いため、Goに精通していることが重要です。 そして、偏見のある憎しみのすべてにもかかわらず、両方の最大のポイントの1つは、機能を盲目的にコピーするのではなく、本当に理由のあるソリューションを実装することです。

IMO、この意味で<--構文はここで最も強力です

それでも、Rust式はいくつかの連鎖メソッドになる可能性があることを忘れないでください。 ほとんどの言語はそうしない傾向があります。

C＃開発チームの経験を思い出させたい：

C＃構文に対する主な考慮事項は、演算子の優先順位がfooを待つことです。

これは私がコメントできるような気がします。 'await'で優先順位をよく考え、必要なフォームを設定する前に多くのフォームを試しました。 私たちが見つけた中心的なことの1つは、この機能を使用したいと思っていた私たちと顧客（内部および外部）にとって、非同期呼び出しを超えて何かを「チェーン」したいと思うことはめったにありませんでした。

expr内で「await」を使用して「続行」したいという傾向はまれでした。 （await expr）.M（）のようなものが時々見られますが、それらはexpr.M（）を待つ人の数よりも一般的ではなく望ましくないようです。

そして

これが、「await」に「暗黙の」形式を使用しなかった理由でもあります。 実際には、それは人々が非常に明確に考えたいと思っていたものであり、彼らがそれに注意を払うことができるようにコードの中心に置きたいと思っていました。 興味深いことに、数年後もこの傾向は続いています。 つまり、何年も後に、何かが過度に冗長であることを後悔することがあります。 いくつかの機能は早い段階でそのように優れていますが、人々がそれに慣れたら、何かより簡潔なものに適しています。 'await'の場合はそうではあり

専用の（キーワード）単語ではなく、印章に対する良い点です。

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

あなたは本当に何百万ものユーザーを持つ人に耳を傾けるべきです。

したがって、何もチェーンしたくない、いくつかのawaitが必要なだけで、私の経験は同じです。 async/awaitコードを6年以上作成していて、そのような機能は必要ありませんでした。 接尾辞の構文は本当に異質に見え、決して起こらない可能性が高い状況を解決すると考えられています。 Async呼び出しは本当に大胆なものなので、1行で複数の待機が重すぎます。

expr内で「await」を使用して「続行」したいという傾向はまれでした。 （await expr）.M（）のようなものが時々見られますが、それらはexpr.M（）を待つ人の数よりも一般的ではなく望ましくないようです。

それは事後分析のようです。 おそらく、続行しない理由の1つは、プレフィックス構文で続行するのが非常に厄介なためです（演算子?読み取り可能なままであるため、ステートメントでtry!複数回実行したくない場合と比較して） ? ）。 上記は主に（私が知る限り）優先順位ではなく、優先順位を考慮しています。 また、C＃はRustではなく、トレイトメンバーは結果のメソッドを呼び出したいという欲求をかなり変える可能性があることを思い出してください。

@ I60R 、

1. 親しみやすさが重要だと思います。 Rustは比較的新しい言語であり、人々は他の言語から移行するでしょう。Rustが見慣れている場合は、Rustを選択する決定を下すのが簡単になります。
2. 私はメソッドのチェーン化をあまり楽しんでいません-長いチェーンをデバッグするのははるかに難しく、チェーン化はコードの可読性を複雑にするだけであり、追加のオプションとしてのみ許可される可能性があります（マクロ.await!() ）。 プレフィックス形式では、開発者は次のように、チェーンではなくメソッドにコードを抽出する必要があります。

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

このようなものに：

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

それは事後分析のようです。 おそらく、それらが継続しない理由の1つは、プレフィックス構文でそうすることが非常に厄介だからです。 上記は、位置ではなく、優先順位のみを考慮しています。 また、C＃はRustではなく、トレイトメンバーは結果のメソッドを呼び出したいという欲求をかなり変える可能性があることを思い出してください。

いいえ、プレフィックス/ポストフィックス/暗黙の形式の両方がある場合の内部C＃チームの実験に関するものです。 そして、私は接尾辞フォームのプロを見ることができないという単なる習慣ではない私の経験について話している。

@mehcodeあなたの例は私をやる気にさせません。 reqwestは、最初の要求/応答サイクルとそれに続く応答（ボディストリーム）の処理を別々の並行プロセスにすることを意識的に決定するため、 待機する必要があります。

reqwestは、次のAPIを完全に公開する可能性があります。

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

または

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

（後者はand_then超える単糖です）。

reqwestとhyperの最良のAPI決定はこれらを別々に保つことであるため、ここでの接尾辞の例の多くがこのチェーンを例として使用しているのは厄介です。

ここでのほとんどの接尾辞待機の例は、コンビネータ（および必要に応じて砂糖）を使用して書き直すか、同様の操作を続けて複数回待機する必要があると正直に信じています。

@andreytkachenko

プレフィックス形式では、開発者は次のように、チェーンではなくメソッドにコードを抽出する必要があります。

それは良いことですか、悪いことですか？ N個のメソッドがあり、それぞれがM個のフォローアップをもたらす可能性がある場合、開発者はN * Mメソッドを提供することになっていますか？ 個人的には、少し長くても、構成可能なソリューションが好きです。

このようなものに：

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

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

@Pzixel

C＃では、Rustの場合ほど多くの連鎖/関数型コードを取得できるとは思いません。 それとも私は間違っていますか？ これにより、C＃開発者/ユーザーの経験は興味深いものになりますが、必ずしもRustに適用できるとは限りません。 OcamlやHaskellと対比できたらいいのにと思います。

それが意見の相違の根本的な原因だと思います。私たちの中には命令型のスタイルを楽しんでいる人もいれば、機能的なスタイルを楽しんでいる人もいます。 以上です。 Rustは両方をサポートしており、議論の両側は、非同期が通常のコードの記述方法にうまく適合することを望んでいます。

@dpc

C＃では、Rustの場合ほど多くの連鎖/関数型コードを取得できるとは思いません。 それとも私は間違っていますか？ これにより、C＃開発者/ユーザーの経験は興味深いものになりますが、必ずしもRustに適用できるとは限りません。 OcamlやHaskellと対比できたらいいのにと思います。

LINQと機能スタイルはC＃でかなり人気があります。

@dpc 、
読みやすさについては、コードが明示的であると同じくらい優れています。私の経験では、メソッド/関数の名前が自己記述的である場合は、フォローアップを行う必要はありません。

オーバーヘッドについての場合-Rustコンパイラはそれらをインライン化するのがかなり賢いです（とにかく私たちは常に#[inline]持っています）。

@dpc

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

私の感じでは、これは基本的にfutures APIの問題を繰り返します。チェーンは簡単になりますが、そのチェーンのタイプは浸透してデバッグするのがはるかに難しくなります。

同じ議論が？にも当てはまりませんか？ でもオペレーター？ これにより、より多くの連鎖が可能になり、デバッグが困難になります。 しかし、なぜ私たちは選んだのですか？ やり過ぎ！ それなら？ そして、なぜRustはビルダーパターンのAPIを好むのですか？ そのため、Rustは、APIでのチェーンを支持する多くの選択をすでに行っています。 はい、それはデバッグを難しくするかもしれませんが、それは糸くずレベルで起こるべきではありません-多分大きすぎるチェーンのためのクリッピーのための新しい糸くず？ ここでの待機の違いについては、まだ十分な動機付けが必要です。

それは良いことですか、悪いことですか？ N個のメソッドがあり、それぞれがM個のフォローアップをもたらす可能性がある場合、開発者はN * Mメソッドを提供することになっていますか？ 個人的には、少し長くても、構成可能なソリューションが好きです。

NとMは必ずしも大きいわけではなく、すべてが関心のある/抽出に役立つとは限りません。

@andreytkachenko 、

1. 私は同意しません、親しみやすさはここで過大評価されています。 他の言語から移行するとき、最初の人々はasync-awaitスタイルのプログラミングを行う能力を求めますが、まったく同じ構文ではありません。 実装方法が異なるが、それによってプログラミングエクスペリエンスが向上する場合は、さらに別の利点になります。

2. 長いチェーンをデバッグできないことは、コードスタイルではなくデバッガーの制限です。 読みやすさについては状況次第だと思いますが、ここでは命令型を強制することは不必要に制限されています。 async関数呼び出しがまだ関数呼び出しである場合、チェーンをサポートしないのは驚くべきことです。 とにかく、 <--は、追加オプションとして関数チェーンで使用できるプレフィックス演算子です。

@skade同意しました。

待機の長いチェーンを持つすべての例は、コードの臭いです。 これらのジェネレータースパゲッティステートマシンを内部で作成するのではなく、コンビネーターまたは更新されたAPIを使用してはるかにエレガントに解決できます。 極端な省略構文は、現在の将来よりもさらに難しいデバッグのレシピです。

私はまだプレフィックスキーワードawaitとマクロawait!(...) / .await!()の両方のファンでasyncと#[async]ジェネレーター関数と組み合わせています、ここに私のコメント

すべてがうまくいけば、プレフィックスとサフィックスの両方を処理するためにawait!に対して単一のマクロを作成でき、 awaitキーワードはasync関数内のキーワードになります。

@skade 、
私にとって、 futureコンビネータを使用することの大きな欠点は、コンビネータがasync関数呼び出しを非表示にし、通常の関数と区別できないことです。 ビルダースタイルのチェーン内で使用される可能性が非常に高いため、すべてのサスペンド可能なポイントを確認したいと思います。

@ I60Rの長い呼び出しチェーンのデバッグは、デバッガーの問題ではありません。これらのチェーンの記述に関する問題は、型推論を正しく行うことだからです。 これらのメソッドの多くがジェネリックパラメーターを受け取り、クロージャーにバインドされる可能性のあるジェネリックパラメーターを配布することを考えると、深刻な問題です。

すべてのサスペンションポイントを表示することがこの機能の目的であるかどうかはわかりません。 これは実装者が決定する必要があります。 そして、それはawait構文の提案されたすべてのバージョンで完全に可能です。

@novacrazyの良い点、あなたがそれを言ったので、以前のjavascripterとして、私はawaitチェーンを決して使用しません、私は常にその後ブロックを使用しました

私はそれが次のように見えると思います

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

それが可能かどうかさえわかりませんが、Rustの先物を調べる必要があります

@richardanayaこれは完全に可能です（異なる構文）。

Box implのように：

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

次のように、新しいキーワードawaitを入力してAwaitを特性化できます。

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

また、メソッドおよびキーワードとしてawaitを使用します。

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

@richardanaya同意しました。 私は何年も前に私のwebdevのものにasync / awaitを採用した最初の開発者の一人でした、そして本当の力はasync / awaitを既存のPromises / Futuresと組み合わせることから来ました。 また、あなたの例でさえ、おそらく次のように単純化することができます。

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

let value = result.unwrap();

先物または先物の結果または結果の先物をネストしている場合、 .flatten()コンビネータはそれをさらに大幅に単純化できます。 手動ですべてを開梱して待つのは悪い形です。

@XXこれは冗長で無効です。 awaitはasync関数にのみ存在し、とにかくFuture / IntoFutureを実装する型でのみ機能するため、新しい関数は必要ありません。特性。

@ novacrazy 、 @ richardanaya

これらのジェネレータスパゲッティステートマシンを内部で作成するのではなく、コンビネータまたは更新されたAPIを使用してはるかにエレガントに解決できます。 極端な省略構文は、現在の将来よりもさらに難しいデバッグのレシピです。

@novacrazyの良い点、あなたがそれを言ったので、以前のjavascripterとして、私はawaitチェーンを決して使用しません、私は常にその後ブロックを使用しました

コンビネータは、Rusts async / awaitでまったく異なるプロパティとパワーを持っています。たとえば、yieldポイント間での借用に関してです。 非同期ブロックと同じ機能を持つコンビネータを安全に作成することはできません。 コンビネータの議論は役に立たないので、このスレッドから除外しましょう。

@ I60R

私にとって、将来コンビネータを使用することの大きな欠点は、それらが非同期関数呼び出しを非表示にし、それらを通常の関数と区別することが不可能になることです。 ビルダースタイルのチェーン内で使用される可能性が非常に高いため、すべてのサスペンド可能なポイントを確認したいと思います。

サスペンドポイントを非表示にすることはできません。 コンビネータが許可する唯一のことは、他の先物を作成することです。 ある時点で、それらを待たなければなりません。

C＃には、プレフィックスawaitを使用するほとんどのコードが、（既存の）ポストフィックス?演算子と結合するという問題がないことに注意してください。 特に、優先順位に関する質問、および2つの類似した「デコレータ」を持つことの一般的な厄介さは、式の反対側に表示されます。

@ Matthias247データを借用する必要がある場合は、確かに、複数のawaitステートメントを自由に使用してください。 ただし、多くの場合、単にデータを移動する必要があり、コンビネータはそのために完全に有効であり、より効率的なコードにコンパイルされる可能性があります。 完全に最適化されることもあります。

繰り返しますが、本当の力は物事を組み合わせることにあります。 これほど複雑なことをする正しい方法はありません。 そのため、この構文のバイクシェディングは、他の言語からの新しいユーザーを助けたり、保守可能でパフォーマンスが高くしたりするのに役立たない場合は、まさにそのように考えています。 80％の確率で、構文が何であれ、単純な先物を使用して最も安定したパフォーマンスの高いAPIを提供するために、 async / await触れることすらできないと思います。

その点で、プレフィックスキーワードawaitおよび/または混合マクロawait!(...) / .await!()は、最も読みやすく、使い慣れた、デバッグしやすいオプションです。

@andreytkachenko

私はあなたの投稿を見て、実際、私が「親しみやすさ」について考えた今、完全に同意します。親しみやすさには2つのタイプがあると思います。

1. await構文を、多くのawaitを使用する同様の言語のように見せます。 Javascriptはここではかなり大きく、コミュニティとしてのWASM機能に非常に関連しています。

2. 2番目のタイプの親しみやすさは、同期コードのみを扱う開発者にコードを親しみやすく見せることです。 awaitの最大の特徴は、非同期コードをLOOK同期にすることだと思います。 これは実際、javascriptが実際に間違っていることの1つです。これは、主に同期開発者にとってまったく異質に見えるチェーンよりも長く正規化されていることです。

javascript asyncの時代から私が提供したいことの1つは、振り返ってみると開発者として私にとってはるかに便利だったのは、promise / futureをグループ化する機能でした。 Promise.all（p1（）、p2（））なので、作業を簡単に麻痺させることができます。 then（）チェーンは、常にJavascriptの過去の約束の反響でしたが、私が考えると、かなり古風で不必要です。

私は多分この待つという考えを提供したいと思います。 「非同期コードと同期コードの違いを最小限に抑えるようにしてください」

@novacrazy非同期関数は、impl Futureタイプを返しますよね？ Futureトレイトにawaitメソッドを追加できない理由は何ですか？ このように：

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

@XX私が理解しているように、Rustのasync関数は、ジェネレーターを使用してステートマシンに変換されます。 この記事は良い説明です。 したがって、 awaitが機能するにasync関数が必要です。これにより、コンパイラーは両方を正しく変換できます。 awaitは、 async部分がないと機能しません。

Futureはwaitメソッドがあります。これはあなたが提案したものと似ていますが、現在のスレッドをブロックします。

@skade 、

しかし、コードスタイルが型推論にどのように影響する可能性がありますか？ 連鎖型および命令型で記述された同じコードに違いは見られません。 タイプは完全に同じである必要があります。 デバッガーがそれらを理解できない場合、それはコードではなくデバッガーで間違いなく問題です。

@ skade 、 @ Matthias247 、

コンビネータを使用すると、機能チェーンの先頭に1つの中断点がマークされます。 他のすべては内部で暗黙的になります。 これは、暗黙のmut場合とまったく同じ問題です。これは、個人的にはRustの最大の混乱点の1つでした。 一部のAPIは先物を返しますが、他のAPIは先物の結果を返します-私はそれを望んでいません。 サスペンションポイントは、可能であれば明示的である必要があり、適切に構成可能な構文は、

@ I60R letバインディングは、型推論へのジャンクションポイントであり、エラー報告に役立ちます。

@novacrazy

したがって、awaitで動作するには非同期関数が必要です

これは戻り値の型で表現できますか？ 例えば、戻り値の型があることをimpl Future + Asyncの代わりに、 impl Future 。

@skadeメソッド呼び出し構文の.はまったく同じ目的を果たすといつも思っていました

@dpc

C＃では、Rustの場合ほど多くの連鎖/関数型コードを取得できるとは思いません。 それとも私は間違っていますか？ これにより、C＃開発者/ユーザーの経験は興味深いものになりますが、必ずしもRustに適用できるとは限りません。 OcamlやHaskellと対比できたらいいのにと思います。

あなたは錆と同じくらい多くを得る。 LINQコードを見ると、それが表示されます。

典型的な非同期コードは次のようになります。

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();
    }
}

または、より一般的な

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

呼び出しを連鎖させるのではなく、変数に割り当ててから、なんらかの方法で使用します。 あなたがborrowcheckerを扱うとき、それは特に真実です。

私はあなたが一つの状況で先物を連鎖させることができることに同意することができます。 通話中に発生する可能性のあるエラーを処理する場合。 例： let a = await!(service_a)? 。 これは、postfixの代替が優れている唯一の状況です。 私はそれがここで利益を得るのを見ることができました、しかし私はそれがすべての短所を上回るとは思いません。

別の理由： impl Add for MyFuture { ... }とlet a = await a + b;どうですか？

postfixawaitキーワードのコンテキストで

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

接尾辞awaitキーワードと非常によく似ています。

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

正しくフォーマットされていない場合も同じ欠点があります。

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

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

Type Ascription RFCのピルを飲み込む場合は、一貫性を保つためにfut awaitを飲み込む必要があると思います。

ところで、これが有効な構文であることをご存知でしたか？

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

それでも、実際のコードではこれが発生することはありませんでした。

少し余談させてください。 @BenoitZugmeyerによって提案されているexpr!macroまたはexpr@macro 、あるいはexpr.macro!()としても実行できます。 最初のオプションが望ましいと思います。 それらが良いアイデアかどうかはわかりませんが、接尾辞を待っている間にアドホックな解決策ではなく一般的な概念を抽出したい場合は、少なくとも接尾辞マクロを潜在的な解決策として考える必要があります。

awaitを接尾辞マクロにしたとしても、それは魔法のマクロ（ compile_error! ）であることに注意してください。 ただし、 @ jplatteやその他の企業は、それが問題ではないことをすでに確立しています。

そのルートに行く場合、私は最初にpostfixマクロがどのように機能するかを正確に確立し、次にawaitのみを魔法のpostfixマクロとして許可し、後で独自に定義されたpostfixマクロを許可します。

字句解析

字句解析/構文解析に関しては、これは問題になる可能性があります。 expr!macroと、コンパイラはexpr!というマクロがあり、その後に無効な文字macroがあると考えるかもしれません。 ただし、 expr!macroは、先読みでlexできるはずであり、 expr後に!が続き、その直後にidentifierがあると、何かが接尾辞マクロになります。 expr!macro形式を取ることができると仮定します。

後置マクロは役に立ちますか？

頭のてっぺんに、後置マクロのこれらの他のユースケースを思いついた。 ただし、すべてをカスタムマクロで実装できるとは限らないため、このリストが非常に役立つかどうかはわかりません。

• stream!await_all ：ストリームを待機するため
• option!or_continue ： optionがNoneの場合、ループを続行します
• monad!bind ：名前にバインドせずに=<<を実行する場合

stream!await_all

これにより、先物だけでなくストリームも待つことができます。

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

（ async -stream-esqueブロック内）と同等になります：

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

UpdateTickerAction::new(exchange_rate.value)

option!or_continue

これにより、オプションのラップを解除し、それがNone場合は、ループを続行できます。

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);
}

と同等になります：

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

monad!bind

これにより、かなり素朴な（つまり表現中心の）方法でモナドを取得できます。 Rustにはまだモナドのようなものはなく、Rustに追加されても売られていません。 それでも、それらを追加する場合は、この構文が役立つ可能性があります。

ここから以下を取りました。

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 ++ "!")

次のようになります。

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;
}

または、 letが少ない、よりインライン化：

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;
}

評価

私はこれについて非常に分かれています。 私の脳の数学者の部分は、 await一般化された解決策を見つけたいと思っており、接尾辞マクロはそれらを達成する方法かもしれません。 私の脳の実用的な部分は次のように考えています。マクロシステムがまだ誰も理解していない言語をわざわざ作るのはなぜですか。

ただし、 ?とawaitから、非常に便利な接尾辞演算子の2つの例があります。 将来追加したいもの、おそらく私が言及したものに似たものを見つけたらどうしますか？ それらを一般化すれば、自然にRustに追加できます。 そうでない場合は、毎回さらに別の構文を考え出す必要があります。これにより、接尾辞マクロよりも言語が肥大化する可能性があります。

皆さんはどう思いますか？

@EyeOfPython

私は非常によく似たアイデアを思いつきました。Rustの接尾辞マクロは時間の問題です。
ndarrayスライスを扱うときは、毎回それについて考えています。

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

しかし、はるかに良いでしょう

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

また、 _withまたは_else接尾辞が付いたもののように、多くのコンビネータがなくなる可能性があります。

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

@EyeOfPython @andreytkachenko postfixマクロは現在Rustの機能ではなく、

これはRFCの議論ではなく、実装する必要のある受け入れられたRFCの議論です。

そのため、ここでそれらについて説明したり、非同期構文を提案したりすることは現実的ではないと思います。 それはさらに機能を大幅に遅らせるでしょう。

このすでに大規模な議論を抑制するために、ここでそれらを議論することは役に立たないと思います。それらは議論された問題の外にあると見なすことができます。

ちょっと考えてみてください。このスレッドは特にawaitを対象としていますが、今後はyield式についてもまったく同じ議論が行われると思いますが、これも同様に連鎖する可能性があります。 一般化できる構文を見たいのですが、見た目は同じです。

ここでマクロを使用しない理由：

1. マクロはドメイン固有のもののために提供されており、プログラムの制御フローを変更したり、コア言語機能をエミュレートしたりする方法でマクロを使用するのはやり過ぎです
2. 接尾辞マクロはすぐに悪用されて、カスタム演算子やその他のエソセリック言語機能を実装し、コードの誤りを引き起こします
3. 彼らは適切な言語機能の開発を思いとどまらせるでしょう：
   
   
   
   • stream.await_allはコンビネータの完璧なユースケースです
   
   
   • option.or_continueと_elseコンビネータの置き換えは、null合体演算子の完璧なユースケースです
   
   
   • monad.bindはif-letチェーンの完璧なユースケースです
   
   
   • ndarray slicingは、 constジェネリックの完璧なユースケースです
   
   
4. 彼らはすでに実装されている?演算子に疑問を投げかけます

@collinanderson

同様に連鎖する可能性があります

なぜ地球上でそれらが連鎖する可能性があると思いますか？ 上記のprintln例のように、実際のコードでは発生しません。

@Pzixel最終的にGenerator::resumeが値をとる可能性が高いため、 yield exprは非()タイプになります。

@vlaff awaitがTypeAscriptionと一致している必要があるという議論がはっきりとわかりません。 それらは非常に異なるものです。

また、タイプアクリプションは繰り返し試行される機能の1つであり、これが成功するという保証はありません。 私はこれに反対したくありませんが、TAは将来のRFCであり、これはすでに提案されている構文で受け入れられている機能についての議論です。

多くのコメントを読んで、なぜ待つのかについてさらに要約を追加するために！（...）は非常に理想的なパスに見えます：

1. マクロはなじみがあるので、既存のコードに最もなじみがあるように見えます
2. awaitを使用する既存の作業があります！（...） https://github.com/alexcrichton/futures-awaitし、コードの書き換えを減らすのに役立つ可能性があります
3. 接尾辞マクロはテーブルにないので、言語の一部になることは決してなく、「待ってください！」 非標準のコンテキストでは、RFCによる可能性すらありそうにありません
4. それは、コミュニティに、完全に標準から外れていない何かを提供しながら、広く普及した安定した使用の後の長期的な方向性を検討するためのより多くの時間を与えます（例：try！（））
5. 待機と歩留まりを満たすことができる公式の道を見つけるまで、次の歩留まりの同様のパターンとして使用できます！（）
6. 連鎖は期待したほど価値がない可能性があり、複数の行で複数の待機を行うことで、おそらく明確さがさらに向上します。
7. IDE構文ハイライターを変更する必要はありません
8. 他の言語の人々は、他のマクロの使用法を見た後、await！（...）マクロによって捨てられることはおそらくないでしょう（認知的過負荷が少ない）
9. 安定化に向けて前進するための、おそらくすべてのパスの中で最も最小限の労力パスです

待つ！ ここではマクロはすでにあります。問題はチェーンについてです。

考えれば考えるほど、接尾辞がよく見えます。 例えば：

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)`

任意のレベルのネストを許可し、読み取り可能です。 ?および将来のオペレーターとシームレスに連携します。 新規参入者にとっては少し異質に見えますが、文法上の利益がそれを上回る可能性があります。

主な理由は、 awaitは関数呼び出しではなく、個別のキーワードである必要があるためです。 重要すぎるため、独自のハイライトとテキスト内の配置を設定する必要があります。

@ Pzixel 、 @ HeroicKatora 、 @ skade

たとえば、Pythonのyieldとyield from式をyieldの結果となる値を提供できます。 これは@valffの意味であり、型の帰属とは何の関係もありません。 したがって、 yieldも!または()以外のタイプになります。

コルーチンのポイントから、 yieldとawait両方がコルーチンを一時停止し、（最終的に）値を返すことができます。 それらは同じコインの両面にすぎないので。

そして、別の構文の可能性、_square-brackets-with-keyword_を捨てて、これを部分的に強調します（構文の強調表示にyieldを使用）：

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

「接尾辞キーワード」は私にとって最も理にかなっています。 future-expressionとawait区切る空白以外の文字を使用した接尾辞も私には意味がありますが、「。」には意味がありません。 これはメソッド用であり、 awaitはメソッドではないためです。 ただし、プレフィックスキーワードとしてawaitが必要な場合は、たくさんのものをチェーンしたい人のためにawait selfを呼び出すだけのトレイトまたはメソッドの@XX提案が好きです（おそらくメソッドにawaitという名前を付けることはできませんwaitだけで十分だと思います）。 個人的には、長いチェーンは読みにくく、プレフィックスまたはポストフィックスが機能するため、チェーンごとではなく、行ごとに待機することになります。

[編集] waitすでに存在し、未来を阻んでいることを忘れたので、その考えをかき集めてください。

@roland私は特にこれを参照しており、タイプの帰属について説明しています： //github.com/rust-lang/rust/issues/57640#issuecomment -456023146

@rolandsteinerだからあなたは書く

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

私がそれを次のように書くとき：

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

@skadeああ、あなたは私が思っていたのとは違うコメントを意味しました、ごめんなさい。 ：stuck_out_tongue：

@Pzixel最終的にGenerator::resumeが値をとる可能性が高いため、 yield exprは非()タイプになります。

したがって、 yieldも!または()以外のタイプになります。

@ valff 、 @ rolandsteiner yieldが再開値を返す可能性は低いと思います。これは、ジェネレーターの構文や特性を操作するのが面倒になることなく、静的に型指定された言語に適合させるのは困難です。 履歴書引数を持つ元のプロトタイプでは、キーワードgen argを使用してこの引数を参照していました。このようなものは、IMOでうまく機能する可能性がはるかに高くなります。 その観点から、 yieldは()返すので、 awaitの議論にあまり影響を与えないはずです。

asyncはプレフィックス演算子であるため、 awaitはプレフィックス演算子である必要があると思います（ yieldもプレフィックスになると思います）。 または、通常の方法として使用し、接尾辞の位置で使用します。

ただし、ここですべてのバイクシェディングを実行しているわけではありません。Rustの他の誰も持っていない接尾辞キーワードを検討するのはなぜですか？ それは言語をとても奇妙にするでしょう。

また、先物を連鎖させると、なぜそれが面白いのかがわかります。 しかし、連鎖が待っていますか？ それはどういう意味ですか？ 新しい未来を返す未来？ Rustに一級市民としてそのイディオムを持たせたいのは本当に一般的なイディオムですか？ 私たちが本当にそれを気にするなら、私は私たちがすべきだと思います：

1. メソッドを選択します（つまり、 foo.await() ）。 それは奇妙な接尾辞キーワードを導入せず、私たちは皆それが何を意味するかを知っています。 それと連鎖することもできます。
2. キーワード/ロロペレーターが本当に必要な場合は、後でその質問を解決できます。

また、個人的な意見を述べるために、接尾辞のキーワード位置にあるawaitは嫌いです。

プレフィックスawaitは、他の言語で使用されている理由があります。これは自然言語と一致します。 あなたは「あなたの到着を待つ」とは言わない。 JavaScriptを書いたのですが、少し偏見があるかもしれません。

また、 awaitチェーンは過大評価されていると思います。 将来のコンビネータに対するasync/awaitの価値は、 if 、 matchなどの標準言語構造を利用して非同期コードを順番に記述できることです。 あなたはとにかくあなたの待機を分割したいと思うでしょう。

async/await魔法の構文を作りすぎないでください。これは、言語のごく一部にすぎません。 提案されたメソッド構文（つまり、 foo.await() ）は、IMOが通常のメソッド呼び出しに対して直交しすぎており、魔法のように外れています。 proc-macro機械が設置されているので、その背後に隠してみませんか？

関数の定義でasyncではなくawaitキーワードを使用するの

await fn foo(future: impl Future<Output = i32>) -> i32 {
    future
}

このawait fnは、 asyncコンテキストでのみ呼び出すことができます。

async {
    let n = foo(bar());
}

そして、 let n = (await foo(bar()));脱糖します。
次に、 awaitキーワードに加えて、トレイトFutureは、接尾辞の位置でawaitロジックを使用するためのawaitメソッドを実装できます。

async {
    let n = bar().awaited();
}

また、誰かが私に発電機との関係を説明できますか？ async / awaitが、ジェネレーターが（安定化されていても）実装される前に実装されていることに驚いています。

@phaazonジェネレーターがasync / await内部実装の詳細としてRustに追加されました。 それらを安定させる現在の計画はありません、そしてそれらが可能になる前にそれらはまだ非実験的なRFCを必要とします。 （個人的には安定させたいのですが、少なくとも1、2年は離れているようです。おそらく、 async / awaitが安定して、安定するまでRFCされないでしょう。それに関するいくつかの経験）。

@XX関数定義でawaitを使用すると、 asyncのセマンティクスを破っていると思います。 基準を守りましょうね。

@phaazonこれがasyncセマンティクスをどのように壊すかをより詳細に指定できますか？

ほとんどの言語はasyncを使用して非同期になるものを導入し、 awaitがそれを待ちます。 したがって、 await代わりにasyncは、私にはちょっと奇妙です。

@phaazonいいえ、代わりではありませんが、それに加えて。 完全な例：

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())`

それが有効である場合、チェーンで使用するためのawait-methodを実装することが可能になります。

async {
    let n = first().awaited()?.second().awaited()?;
    // let n = (await (await first())?.second())?;
}

私の意見では、postfixがあまりにも魔法のように「感じ」、言語に慣れていないのを待っているかどうかは問題ではありません。 メソッド構文.await()または.await!()を採用する場合、 Futureは.await()または.await!()メソッドがあることを説明するだけです。意味のある場合にそれらを待つために使用することもできます。 一度も見たことがなくても、5分かけて考えれば理解するのはそれほど難しいことではありません。

さらに、prefixキーワードを使用すると、次のようなクレートを作成できなくなります（現在、詳細を処理するインフラストラクチャがないため、不完全な擬似コード）。

trait AwaitChainable {
    fn await(self) -> impl Future;
}

impl<T: Future> AwaitChainable for T {
    fn await(self) -> impl Future {
        await self
    }
}

そうすれば、必要に応じてpostfixを待つことができます。 つまり、それがどういうわけか不可能であり、コンパイラによって魔法のように接尾辞待機を実装する必要がある場合でも、上記の例のようなものを使用して、それが主にどのように機能するかを説明できます。 学ぶのは難しいことではないでしょう。

@ivandardi私も同じことを考えました。 しかし、この定義

fn await(self) -> impl Future {
    await self
}

関数がasync contextでのみ呼び出すことができるとは言っていません。

@XXええ、私が言ったように、壊れた擬似コードを無視します：PIには現在、正しい構文と特性をそこに書き込む方法を調べるためのインフラストラクチャがありません:(非同期でのみ呼び出し可能にするものを書いたと想像してくださいコンテキスト。

@ XX 、 @ ivandardi定義にawaitはasyncコンテキストでのみ機能します。 したがって、これは違法です。

fn await(self) -> impl Future {
    await self
}

それは違いない

async fn await(self) -> impl Future {
    await self
}

これは、次のようなasyncコンテキストでのみ呼び出すことができます。

await future.await()

どのような種類が目的全体を打ち負かします。

これを機能させる唯一の方法は、 async完全に変更することです。これはテーブルから外れています。

@ivandardi私のバージョンのこの進化：

fn await(self) -> T { // How to indicate using in async-context only?
    await self
}

`` `錆
await fn await（self）-> T {//非同期がすでに取得されているため
自分を待つ
}

```rust
await fn await(self) -> T {
    self // remove excess await
}

@CryZe @XXなぜあなたは私をブーイングしているのですか？ 私は正しい。

@XX何をしようとしていることは、非同期の意味を変更して、完全に待つことです（たとえば、作成await文脈をから何とか違うasyncコンテキスト）。 言語開発者からのサポートはあまり得られないと思います

@EyeOfPythonこの定義は期待どおりに機能しません：

async fn await(self) -> impl Future {
    await self
}

より可能性が高い：

#[call_only_in_async_context_with_derived_await_prefix]
fn await(self) -> impl Future {
    self
}

これが架空の疑似構文であることを無視したため、私は反対票を投じています。 基本的に彼らのポイントは、Rustが言語が理解できるDrop and Copyのような特別な特性を追加できるということです。これにより、型に対して.await（）を呼び出す機能が追加され、awaitキーワードと同じように型と対話します。 また、賛成票/反対票によって視覚化されるような主観的な感情に基づくものではなく、客観的な解決策を見つけることが重要であるため、投票はとにかくRFCには無関係であると見なされます。

このコードが何をすべきかわかりません。 しかし、それはasyncawaitが現在どのように機能するかとは何の関係もありません。 気になる場合は、このスレッドから除外し、専用のRFCを作成してください。

@CryZeそのタイプが利用可能です。 それは未来と呼ばれています。 そして、async / awaitは、非同期コードの変換のみを対象としたメカニズムであることがずっと前に合意されました。 これは、一般的なバインド表記を意味するものではありません。

@ivandariあなたの接尾辞が待つのではなく、新しい未来を創造します。 それは本質的に恒等関数です。 通常の関数ではないため、暗黙的に待つことはできません。

@ Matthias247彼らが提案しようとしていたのは、メソッド呼び出しの構文を持つ接尾辞を待機させる方法でした。 そうすれば、Rustは、？で行ったように、＃、@、...などの任意の新しい記号を導入する必要がありません。 演算子、そしてそれでもかなり自然に見えます：

let result = some_operation().await()?.some_method().await()?;

したがって、コンパイラが通常のawaitキーワード（この場合はまったく必要ありません）と同じように認識し、非同期を変換する、Future特性の特別な種類のメソッドを何らかの方法で待機するというアイデアになります。そこからジェネレーターにコードします。 そうすれば、 await some_future()?で左右ではなく、左から右への適切な論理制御フローが得られ、奇妙な新しいシンボルを導入する必要はありません。

（つまり、tl; dr：メソッド呼び出しのように見えますが、実際には接尾辞が待っています）

後置構文を考慮して明示的に言及されていないことは、エラーとオプションのコンビネータの普及です。 これらは、錆が待っているすべての言語と最も異なる場所です-自動トレースバックの代わりに、 .map_err()?ます。

特に次のようなもの：

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))?;

読みにくい（どの接尾辞構文が考慮されるかは気にしない）：

let parsed = reqwest::get(..)
    .send() await
    .map_err(add_context)?
    .json() await
    .map_err(add_context)?;

このデフォルトのフォーマットには、多変数アプローチよりも多くの行があります。 複数の待機がない式は、postfix-awaitを使用して垂直方向のスペースを少なくする必要があるようです。

私は今非同期コードを書いていません、それで私は無知から話している、積み重ねて申し訳ありません-これが実際に問題でないなら、それは素晴らしいです。 エラー処理を異なる方法で行う他の言語に似せるために、適切なエラー処理を人間工学的でなくしたくありません。

はい、それが私の言いたいことです。 状況に応じて、プレフィックスとポストフィックスのどちらを使用するかを選択できるので、両方の長所があります。

@XXそれをユーザーコードで表現できない場合は、コンパイラを使用してその機能を実装する必要があります。 しかし、接尾辞がどのように機能するかを理解するという点では、表面的な理解であっても、以前に投稿した説明は引き続き機能します。

@ CryZe 、 @ XX 、

一見スムーズに見えますが、Rustの哲学とは完全に一致しません。 でもsortイテレータの方法は返しませんself配分を明示的にするためにと休憩メソッドの呼び出しチェーンを。 ただし、通常の関数呼び出しと区別がつかない完全に暗黙的な方法で、影響が少ないものが実装されることを期待します。 IMOの可能性はありません。

はい、それが私の言いたいことです。 状況に応じて、プレフィックスとポストフィックスのどちらを使用するかを選択できるので、両方の長所があります。

なぜそれが目標でなければならないのですか？ Rustは、他のすべての制御フロー（たとえば、 break 、 continue 、 ifなど）でこれをサポートしていません。「これは可能性があります。特定の意見では見栄えがします。

一般に、 awaitは非常に特別であり、通常のメソッド呼び出しではないことを皆さんに思い出させたいと思います。

• スタックが巻き戻されて再確立される可能性があるため、ステップオーバー待機時にデバッガーが奇妙な動作をする場合があります。 私が覚えている限り、C＃とJavascriptで非同期デバッグを機能させるには長い時間がかかりました。 そして、それらはデバッガーに取り組むチームに支払いをしました！
• 待機ポイントを通過しないローカルオブジェクトは、実際のOSスタックに格納できます。 生成されたfutureに移動する必要がないものは、最終的に必要なヒープメモリ（Futureが存在する場所）に違いをもたらします。
• 待機ポイントをまたがる借入は、生成された先物が!Unpinである必要がある理由であり、既存のコンビネータとメカニズムのいくつかに多くの不便を引き起こします。 asyncメソッドからUnpin先物を生成する可能性がありますが、将来は待機を超えて借用しません。 ただし、 awaitが表示されない場合、それは発生しません。
• async / awaitの現在の状態ではカバーされていない、他の予期しない借用チェッカーの問題がある可能性があります。

@Pzixel @lnicola

C＃の例は完全に必須であり、Rustでよく見られる機能的なスタイルのロングチェーンのようなものではありません。 そのLINQ構文は単なるDSLであり、私が少しグーグルで調べたfoo().bar().x().wih_boo(x).camboom().space_flight();ようなものではなく、C＃コード例は、ほとんどの一般的なプログラミング言語と同様に、100％必須に見えます。 だからこそ、ラングXがしたことをただ理解することはできません。なぜなら、それはまったく同じではないからです。

IMOプレフィックス表記は、命令型のコーディングに完全に適合します。 しかし、Rustは両方のスタイルをサポートしています。

@skade

機能的なスタイルの問題についてのあなたの（そして他の）コメントのいくつかに同意しません。 簡潔にするために、どちらか一方を強く好む人がいることに同意しましょう。

@ Matthias247いいえ、見た目以外に特別な理由があります。 Rustが連鎖を促進するからです。 そして、「ああ、他の制御フローメカニズムには接尾辞の構文がないのに、なぜ特別なものを待つ必要があるのですか？」と言うかもしれません。 まあ、それは間違った評価です。 接尾辞の制御フローがあります。 それらは、私たちが呼び出すメソッドの内部にあります。 Option::unwrap_orは、接尾辞の一致ステートメントを実行するようなものです。 Iterator::filterは、後置ifステートメントを実行するようなものです。 制御フローが連鎖構文自体の一部ではないという理由だけで、接尾辞の制御フローがまだないという意味ではありません。 その観点では、接尾辞awaitを追加することは、実際には私たちが持っているものと一致します。 この場合、 Iterator動作に似たものを使用することもでき、生の接尾辞を待機させる代わりに、 Future::await_orような待機コンビネータを使用することもできます。 いずれにせよ、接尾辞を待つことは見た目だけの問題ではなく、機能性と生活の質の問題です。 そうでなければ、まだtry!()マクロを使用しているでしょう？

@dpc

C＃の例は完全に必須であり、Rustでよく見られる機能的なスタイルのロングチェーンのようなものではありません。 そのLINQ構文は単なるDSLであり、foo（）。bar（）。x（）。wih_boo（x）.camboom（）。space_flight（）;のようなものではありません。 私は少しグーグルで調べましたが、C＃のコード例は、ほとんどの一般的なプログラミング言語と同じように、100％必須に見えます。 だからこそ、ラングXがしたことをただ理解することはできません。なぜなら、それはまったく同じではないからです。

それは真実ではありませんが（ pollyなどのフレームワークを確認できます）、それについては議論しません。 両方の言語で同じ数の連鎖コードが表示されます。 しかし、実際にはすべてが異なるものがあります。 そしてそれはTry特性と呼ばれます。 C＃にはそれに似たものがないため、 awaitポイントを超えて何もすることは想定されていません。 例外が発生した場合、それは自動的にラップされ、発信者のために発生します。

?演算子を手動で使用する必要があるRustの場合はそうではありません。

awaitポイントを超えるものが必要な場合は、「結合」演算子await?作成するか、言語ルールを拡張するなどする必要があります。または、接尾辞を待つだけで、物事がより自然になります（少し異質な構文ですが、誰が気にしますか？）

ですから、私は現在、より実行可能な解決策として接尾辞が待っていると考えています。 私が持っている唯一の提案は、 await()やawait!()ではなく、専用のスペース区切りのキーワードであるべきです。

通常の.await（）メソッドを正当化する正当な理由を思いついたと思います。 あなたがそれについて考えるならば、それは他のブロックの方法と何ら変わりはありません。 .await（）メソッドを呼び出すと、（おそらくグリーン）スレッドの実行が停止し、ある時点で実行中のランタイムがスレッドの実行を再開します。 したがって、Mutexチャネルまたはstdチャネルのいずれを使用している場合でも、すべての目的と目的で次のようになります。

let result = my_channel().recv()?.iter().map(...).collect();

またはそのような未来：

let result = my_future().await()?.iter().map(...).collect();

違いはありません。 それらは両方ともそれぞれのrecv（）/ await（）で実行をブロックし、両方とも同じ方法でチェーンします。 唯一の違いは、await（）がOSのヘビーウェイトスレッドではない別のエグゼキュータで実行されている可能性があることです（ただし、シングルスレッドのエグゼキュータの場合は非常によくあります）。 したがって、大量のチェーンを思いとどまらせることは、まったく同じように両方に影響を及ぼし、おそらく実際の糸くずの出ない糸くずにつながるはずです。

ただし、ここでの私のポイントは、このコードを書いている人の観点からは、.recv（）と.await（）に大きな違いはなく、どちらも実行をブロックし、結果が利用可能になると戻るメソッドであるということです。 。 したがって、すべての意図と目的のために、それはほとんど通常の方法であり、本格的なキーワードを必要としません。 Mutexとstdのチャネルのrecvまたはlockキーワードもありません。

ただし、rustcは明らかにコード全体をジェネレーターに変換したいと考えています。 しかし、それは言語の観点から実際に意味的に必要ですか？ 実際のOSスレッドをブロックすることでawaitを実装するrustcの代替コンパイラを作成できると確信しています（非同期fnを入力すると、スレッドが生成され、待機するとそのスレッドがブロックされます）。 これは非常に単純で遅い実装ですが、意味的にはまったく同じように動作します。 したがって、実際のrustcが待機をジェネレーターに変えるという事実は意味的に必要ではありません。 したがって、実際には、.await（）メソッドの呼び出しをジェネレーターに変換するrustcは、rustcの実装の詳細を最適化するものと見なすことができると主張します。 そうすれば、.await（）が完全なメソッドの一種であり、完全なキーワードではないことを正当化できますが、それでもrustcですべてをジェネレーターに変換することができます。

@CryZeは.recv()とは異なり、プログラム内の他の場所からawaitを安全に中断でき、 await横のコードは実行されません。 これは大きな違いであり、それがawait暗黙的に実行してはならない最も価値のある理由です。

@ I60Rそれはキーワードとして待つよりも明白です。 必要に応じて、IDEでも同じ方法で強調表示できます。 キーワードを接尾辞の位置に移動するだけです。ここでは、実際には見逃しにくいと思います（実行が停止する位置にあるため）。

クレイジーなアイデア：暗黙の待機。 別のスレッドに移動しました。これは、ポストフィックスとプレフィックスの議論ですでに忙しすぎているためです。

@CryZe

通常の.await（）メソッドを正当化する正当な理由を思いついたと思います。 あなたがそれについて考えるならば、それは他のブロックの方法と何ら変わりはありません。

https://github.com/rust-lang/rust/issues/57640#issuecomment-456147515をもう一度お読み

@ Matthias247これらは非常に良い点です、私はそれらを逃したようです。

関数、メンバー、またはその他の暗黙の待機を作成することに関するこのすべての話は、基本的に無効です。 それは行動ではなく、変革です。

コンパイラーは、高レベルで、キーワードまたはマクロを介して、待機式を特別なジェネレーターyield式に変換し、その場で借用やその他のものを処理します。

これは明示的である

キーワードとしてできるだけ見栄えがするか、明らかにマクロを使用してコードを生成する必要があります。

魔法の方法、特性、メンバーなどは、特に新しいユーザーにとっては、誤解や誤解が非常に簡単です。

プレフィックスキーワードawaitまたはプレフィックスマクロawaitは、これを行うための最も受け入れられる方法のように思われます。これは、他の多くの言語がそのように行うのと同じように理にかなっています。 私たちはそれを良くするために特別である必要はありません。

@novacrazy

魔法の方法、特性、メンバーなどは、特に新しいユーザーにとっては、誤解や誤解が非常に簡単です。

それを拡張できますか？ より具体的には、可能であれば.await!()バリアントについて。

私の意見では、 foo.await!()を持っていることは、特に適切な構文の強調表示を使用して読むのは難しくありません。これは無視してはなりません。

それの意味を誤解していますか？ 何が本質的に次のとおりです（タイプmystakesを無視してください）：

trait Future {
    fn await!(self) -> Self::Item {
        await self
    }
}

別名await this_fooとthis_foo.await!()はまったく同じです。 それについて誤解しやすいものは何ですか？

そして、新しいユーザーのトピックについて：新しいユーザーは何に？ プログラミング一般、または言語としてのRustの新規ユーザーですが、プログラミング言語のバックグラウンドがありますか？ 前者の場合、彼らが非同期プログラミングに手を出すとは思えないからです。 後者の場合、混乱することなく、（上記で説明したように）後置待機のセマンティクスを説明する方が簡単です。

あるいは、プレフィックスawaitのみが追加された場合、私が知っていることは、フォームのRustコードを入力として受け取るプログラムの作成を停止することはありません。

foo.bar().baz().quux().await!().melo().await!()

そしてそれをに変換します

await (await foo.bar().baz().quux()).melo()

@ivandardi

.await!()は場合によっては便利で、おそらく次のようにawait!(...)と一緒に機能します。

macro_rules! await {
    // prefix
    ($fut:expr) => {...}

    // postfix
    ($self:Self) => { await!($self) }
}

ただし、接尾辞メソッドのマクロは現在存在せず、存在しない可能性があります。

それが将来の可能性であると考える場合は、今のところマクロawait!(...)を使用し、それが実装されたときに将来的に接尾辞を追加するだけです。

両方のマクロを使用するのが理想的ですが、将来的に接尾辞マクロを実装する予定がない場合は、プレフィックスキーワードawaitがおそらく最善の策です。

@novacrazy私はそれに同意することができ、それは私の最初の提案です。 今のところawait!()を追加し、接尾辞フォームを理解する必要があります。 後置マクロの可能性についても話し合う可能性があります。また、言語で後置マクロを完全にサポートする前に、後置.await!()をその言語にアドホックに追加できるかどうかについても話し合います。 ?とTry特性で起こったことのように、最初に特別なケースとして追加され、その後、より一般的なケースに拡張されています。 決定するときに注意する必要がある唯一のことは、一般的な接尾辞マクロ構文がどのように見えるかです。これは、別の議論に値するかもしれません。

プレフィックスキーワードawaitまたはプレフィックスマクロawaitは、これを行うための最も受け入れられる方法のように思われます。これは、他の多くの言語がそのように行うのと同じように理にかなっています。

それは明らかに_実行可能_ですが、私はそれについて2つの議論しか覚えておらず、説得力があるとは思いません。

• それが他の言語のやり方です
  
  
  
  • それはうれしいですが、我々はすでに実行していない-unless-のように違うことをやっているpollの代わりに実行されているアップツー・初段の編await 、錆が根本的に異なっているので、言語
  
  
• 行の先頭にawaitれるのが好きな人
  
  
  
  • しかし、常にそこにあるとは限らないので、それだけが見える場所であれば問題が発生します
  
  
  • それは見るためだけの簡単なようだawait s内のfoo(aFuture.await, bFuture.await) 、彼らは接頭辞であるかのように
  
  
  • さびた状態では、制御フローを見ると、すでに行の_end_で?スキャンしています。
  
  

私は何か見落としてますか？

もし議論が「まあ、それらはすべてほぼ同じだ」だったとしたら、私は「まあ、私たちが本当に気にしないのなら、他のみんながやっていることをやったほうがいい」と絶対に同意するでしょう。 しかし、私たちはそこにいるとは思いません。

@scottmcmはい、「

したがって、読みやすさ、親しみやすさ、保守性、パフォーマンスの適切なバランスを見つける必要があります。 したがって、最後のコメントの私のステートメントは当てはまります。将来、後置メソッドマクロ（ .await!() ）を追加する場合は、マクロawait!()を使用するか、退屈なプレフィックスキーワードawaitを追加します。それ以外の場合は

退屈は良いので、私は退屈と言います。 これらを使用してコードを作成するときは、構文自体に注意を払わないようにします。

f.await()が適切でない場合は、プレフィックス構文を使用します。

1. ユーザーとして、私が使用する言語に構文規則がいくつかあることを願っています。これらの規則を使用すると、それが何をしているのかを確実に推測できます。 あちこちで例外ではありません。 Rustでは、 asyncが最初にあり、最初のawaitも例外ではありません。 ただし、 f await 、投稿キーワードフォームは次のようになります。 f.awaitはフィールドアクセスのように見えますが、例外です。 f.await!()は、言語に接尾辞マクロが表示されたことがなく、例外として、他にどのような場合に適しているかわかりません。 これらの構文が1回限りの例外ではなくルールになる方法については回答がありません。

2. 例外が発生した場合、それが直感的に理解できることを願っています。 例として?を取り上げます。これは、他の言語では頻繁ではないため、例外と見なすことができます。 f()?.map() compute f（）とほとんど同じように読み取れますが、この結果は良い結果ですか？ ここの?はそれ自体を説明しています。 しかし、 f await 、なぜ接尾辞なのか、 f.await awaitはフィールド、 f.await!() 、マクロがその位置に表示される理由を尋ねます。 少なくとも一見しただけでは、説得力のある直感的な感覚は得られません。

3. 最初のポイントを拡張して、Rustはシステム言語になりたいと考えています。 ここでの主要なプレーヤーであるC / C ++ / Go / Javaは、すべてやや不可欠です。 また、ほとんどの人は命令型言語、HaskellではなくC / Python / Javaなどでキャリアを開始すると思います。システム開発者や次世代開発者にRustを採用するように説得すると思いますが、Rustは最初に命令型でうまく機能し、次に機能的である必要があります。非常に機能的ですが、なじみのある命令的な感覚はありません。

4. チェーンを分割して数行に書くのは悪いことではないと思います。 冗長ではありません。 明示的です。

ディスカッションがどのようにある方向から別の方向に継続的に移動するか（プレフィックスとポストフィックス）を見ると、 awaitキーワードに問題があり、完全に撤回する必要があるという強い意見がありました。 代わりに、現在のスレッドで公開されたすべての意見の中で非常に良い妥協点になると思う次の構文を提案します。

// 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();

最初のステップでは、特定の上部構造の処理でエラーが発生することなく、通常のプレフィックス演算子と同じように実装します。

// 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()?;

2番目のステップでは、適切なエラー処理も可能にする遅延プレフィックス演算子構文を実装します。

// now `go` takes precedence over `?` if present
let response = client.get("https://my_api").go send()?;
let body: MyResponse = response.go into_json()?;

それで全部です。

次に、より多くのコンテキストを提供するいくつかの追加の例を見てみましょう。

// 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この構文は、あらゆる面で他の構文よりも優れています。

✓一貫性：Rustコード内では非常に有機的に見え、コードスタイルを壊す必要はありません
✓構成可能性：チェーンやエラー処理などの他のRust機能とうまく統合できます
✓シンプルさ：短く、説明的で、理解しやすく、操作しやすい
✓再利用性：遅延プレフィックス演算子の構文は、他のコンテキストでも役立ちます
✓ドキュメント：呼び出し側のディスパッチがどこかに流れ、戻るまで待機することを意味します
✓親しみやすさ：すでになじみのあるパターンを提供しますが、トレードオフが少なくなります
✓読みやすさ：平易な英語として読み、単語の意味を歪めない
✓可視性：その位置により、コードのどこかに偽装することが非常に困難になります
✓到達可能性：非常に簡単にグーグルで検索できます
✓十分にテスト済み：golangは最近人気があり、構文は似ています。
✓驚き：その構文を誤解したり乱用したりするのは難しい
✓満足度：少しの学習の後、すべてのユーザーは結果に満足します

編集： @ivandardiが以下のコメントで指摘したように、いくつかのことを明確にする必要があります：

1.はい、この構文は少し見づらいですが、同時に、読みやすさの問題がない構文をここで発明することは不可能です。 go構文は、プレフィックス位置ではプレフィックスawaitとまったく同じであり、遅延位置ではポストフィックスawaitよりもIMOが読みやすいため、ここではそれほど邪悪ではないようです。例えば：

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

ここで、 awaitはあいまいに見え、既存のすべてのキーワードとは異なる結合性を持っていますが、将来的にawaitブロックを実装することを決定した場合、ブロッカーになる可能性もあります。

2. RFCを作成し、「遅延プレフィックス演算子」構文を実装および安定化する必要があります。 この構文は非同期コードに固有のものではありませんが、非同期で使用することが主な動機になります。

3. 「遅延プレフィックス演算子」構文では、次の理由でキーワードが重要になります。

• 長いキーワードは変数とメソッドの間のスペースを増やし、読みやすさを損ないます
• longキーワードはプレフィックス演算子の奇妙な選択です
• 非同期コードを同期として見せたい場合、longキーワードは不必要に冗長です

とにかく、 await代わりにgo await使い始めて、2022年版で名前を変更することはかなり可能です。 その時まで、異なるキーワードまたは演算子が発明される可能性が非常に高いです。 また、名前の変更はまったく必要ないと判断することもできます。 awaitも読みやすいことがわかりました。

// 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()?;

反対票を投じるためにここにいる場合は、次のことを確認してください。

• 私は新しいことを説明するのに最適なスピーカーではないかもしれないので、あなたはそれを正しく理解していると
• あなたの意見は偏見がないということですが、その構文がどこから来たのかについては多くの偏見があります
• サイレントダウン投票は非常に有毒であるため、以下に正当な理由を記載します
• 私はここで長期的な機能を設計しようとしたので、あなたの理由は即時の感情に関するものではないということです

@ I60R

私はそれにいくつかの不満を持っています。

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

それは少し目で解析するのが難しいです。 一見、 db.goで一致していると思うかもしれませんが、それ以上のものがあり、「うーん、わかりました、ロードはdbのメソッドです」と言います。 メソッドは常にそれらが属するオブジェクトの近くにあり、メソッド間にスペースやキーワードの中断がないため、構文は主に機能しません。

第二に、あなたの提案では、「据え置きプレフィックス演算子構文」とは何かを定義し、場合によっては最初に言語で一般化する必要があります。 それ以外の場合は、非同期コードにのみ使用されるものになり、「なぜ後置マクロを使用しないのか」の説明に戻ります。 あまりにも。

第三に、キーワードはまったく重要ではないと思います。 ただし、キーワードは2018年版用に予約されているため、 awaitを優先する必要がありますが、 goキーワードは、提案される前に、より詳細なcrates.io検索を実行する必要はありません。

議論がどのようにある方向から別の方向に継続的に移動するか（接頭辞と接尾辞）を見ると、awaitキーワードに何か問題があり、完全に撤回する必要があるという強い意見がありました。

（半）暗黙的に待つことができ、すべてがうまくいくでしょうが、非同期関数の全体的なポイントは実装の詳細を隠してそれらを正しく見せることであるという事実にもかかわらず、Rustコミュニティでは売れ行きが悪いでしょうiooneをブロックするようなものです。

@dpcつまり、半暗黙的な待機と、コードセクションを明示的にunsafe似たものです。

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

awaitブロック内のすべてが自動的に待機される場所。 代わりにチェーン全体を待つことができるので、これにより、後置がチェーンを待つ必要がなくなります。 しかし同時に、その形が望ましいかどうかはわかりません。 たぶん、他の誰かがこれに対して本当に正当な理由を見つけることができます。

@dpc非同期関数のポイントは、詳細を非表示にすることではなく、より

どの言語でも、非同期関数と同期関数を混同することはありません。 ステートマシンを手書きするのではなく、操作のシーケンスをより読みやすく保守しやすい形式で整理することだけが目的です。

また、 @ ivandardiの例に示されている暗黙のFutureコンビネータを使用できなくなります。これは、すでに示したように、依然として非常に強力です。 Futureを取得して待つことはできません。これは、非常に非効率的です。

、明示的なおなじみの、読みやすい、保守性、およびパフォーマンス：プレフィックスキーワードawaitマクロawait!()潜在的にpostfixのマクロで、 .await!()将来インチ

@novacrazy理想的な構文が選択されたとしても、状況によってはカスタム先物とコンビネータを使用したいと思います。 それらがソフトに非推奨になる可能性があるという考えは、Rustの全体的な方向性に疑問を投げかけます。

もちろん、コンビネータを引き続き使用できます。非推奨になるものはありません。

これは?と同じ状況です。新しいコードは通常?使用しますが（コンビネーターよりも優れているため）、Option / Resultコンビネーターは引き続き使用できます（ or_elseようなファンキーなものも使用できます）

特に、async / awaitはmapとand_thenを完全に置き換えることができますが、よりファンキーなFutureコンビネータは引き続き使用できます（今後も使用できます）。

あなたが与える例は、コンビネータと比較してまだひどいように見えます、

私はそうは思いません。標準のRust機能を使用しているので、はるかに明確だと思います。

明確さは文字数についてはめったにありませんが、それは精神的な概念と関係があります。

postfix awaitすると、さらに見栄えが良くなります。

some_op().await?
    .another_op().await?
    .final_op().await

あなたはそれをあなたのオリジナルと比較することができます：

some_op()
    .and_then(|v| v.another_op())
    .and_then(|v2| v2.final_op())

ジェネレータを使用すると、オーバーヘッドが少し遅くなり、より多くのマシンコードが生成されます。

なぜasync / awaitから余分なオーバーヘッドがあると主張するのですか？ ジェネレーターとasync / awaitはどちらも、ゼロコストで大幅に最適化されるように特別に設計されています。

特に、async / awaitは、Futureコンビネーターとまったく同じように、高度に最適化されたステートマシンにコンパイルされます。

これらのジェネレータスパゲッティステートマシンを内部で作成するのではなく。

フューチャーコンビネーターは、ボンネットの下に「スパゲッティステートマシン」も作成します。これはまさに彼らが行うように設計されたものです。

それらは基本的にasync / awaitと何ら変わりはありません。

[将来のコンビネータ]は、より効率的なコードにコンパイルされる可能性があります。

誤った情報を広めるのはやめてください。 特に、async / awaitはFutureコンビネータよりもます。

ユーザーがプレフィックスキーワードに満足していないことが判明した場合は、2019/2020エディションで変更できます。

他の人が言っているように、エディションは、私たちが好きなときに作る恣意的なものではなく、（早くても）数年ごとにのみ発生するように特別に設計されています。

そして@Centrilが指摘したように、後でそれを置き換えるためだけに悪い構文を

現在、議論のペースはかなり速いです。 そのため、物事を遅くし、人々が追いつくことができるようにするために、私は問題を一時的にロックしました。 1日以内にロックが解除されます。 その際は、なるべく建設的になるよう努めてください。

1日後に問題のロックを解除します...すでに指摘されていないことを検討し、トピックについてコメントを残してください（たとえば、これは暗黙の待機やその他の範囲外のことを検討する場所ではありません）。

これは長いスレッドだったので、そこに埋め込まれている最も興味深いコメントのいくつかを強調しましょう。

@mehcodeは、プレフィックスとポストフィックスの両方の位置にawaitを含む広範な実世界のコードを提供してくれました： https ：

@Centrilは、 await!(expr)を安定させることは、技術的負債を故意に追加することになると説得力を持って主張しました： https ：

@valffは、 expr await postfixキーワード構文が一般化されたタイプの説明に最もきれいに適合することを私たちに思い出させhttps ：

@quodlibetorは、ErrorおよびOptionコンビネータの構文効果がRustに固有であることを強調し、後置構文を支持すると主張しています： https ：

一日の終わりに、langチームはここに電話をかける必要があります。 コンセンサスにつながる可能性のある共通の根拠を特定するために、後置構文の重要な問題に関するlangチームメンバーの述べられた立場を要約すると役立つでしょう。

• @Centrilは、後await!(expr)を安定させたくありません。

• @cramertjは、接尾辞構文、特にexpr await接尾辞キーワード構文のサポートを

• @joshtriplettは、接尾辞構文の表明し、接頭辞バージョンも提供する

• @scottmcmは、後置構文のサポートを

• @withoutboatsは、マクロ構文を安定させはexpr await接尾辞キーワード構文が「実際のショット」であると見なします。

• @ aturon 、 @ eddyb 、 @ nikomatsakis 、および@pnkfelixは、問題＃57640または＃50547で構文に関する立場をまだ表明していません。

したがって、はい/いいえの答えを理解するために必要なこと：

• プレフィックス構文が必要ですか？
• 接尾辞の構文が必要ですか？
• 今すぐプレフィックス構文を用意し、後でポストフィックス構文を理解する必要がありますか？

プレフィックス構文を使用する場合、このコメントに見られるように、人々が最も受け入れていると私が感じる2つの主要な候補があります。有用と明白です。 await!()に対する議論はかなり強いので、私はそれが除外されたと考えています。 したがって、有用な構文と明白な構文のどちらが必要かを判断する必要があります。 私の意見では、一般的に括弧の少ない構文を使用する必要があります。

そして、接尾辞の構文に関しては、それはトリッキーです。 スペース付きの接尾辞awaitキーワードについても強力な議論があります。 しかし、それはコードのフォーマット方法に大きく依存します。 コードのフォーマットが不適切な場合、スペースを含む接尾辞awaitキーワードは非常に見栄えが悪くなる可能性があります。 したがって、最初に、すべてのRustコードがrustfmtで正しくフォーマットされ、rustfmtが単一行に収まる場合でも、常にチェーン待機を異なる行に分割することを想定する必要があります。 それができれば、その構文は非常に問題ありません。これは、読みやすさと単一行チェーンの途中のスペースとの混同の問題を解決するためです。

そして最後に、接頭辞と接尾辞の両方を使用する場合は、両方の構文のセマンティクスを理解して書き留め、それらが互いにどのように相互作用し、一方が他方にどのように変換されるかを確認する必要があります。 postfixまたはprefixawaitのどちらを選択しても、コードの実行方法は変わらないため、これを実行できるはずです。

私の思考プロセスと、表面構文の提案にどのようにアプローチして評価するかを明確にするため。 await 、
これが私が持っている目標です（重要性の順序なしで）：

1. awaitは、将来の言語設計を可能にするためのキーワードのままにする必要があります。
2. 構文はファーストクラスを感じるはずです。
3. 待機は、Rustで普及しているため、 ?および一般的なメソッドでうまく構成できるように連鎖可能である必要があります。 意味のある細分化ではないかもしれない一時的なletバインディングを強制的に作成するべきではありません。
4. 待機ポイントはgrepになりやすいはずです。
5. 待機ポイントが一目でわかるはずです。
6. 構文の優先順位は直感的である必要があります。
7. 構文は、IDEと筋肉の記憶でうまく構成されているはずです。
8. 構文は簡単に習得できるはずです。
9. 構文は人間工学的に書く必要があります。

私の目標のいくつかを定義した（そしておそらく忘れた...）ので、ここにそれらに関するいくつかの提案の要約と私の評価があります：

1. awaitをキーワードとして保持すると、 await!(expr)またはexpr.await!()どちらであっても、マクロベースの構文を使用することが困難になります。 マクロ構文を使用するには、マクロとしてのawaitがハードコードされて名前解決と統合されない（つまり、 use core::await as foo;が不可能になる）か、 awaitがキーワードとして完全に放棄されます。

2. マクロは、ユーザースペースで構文を発明することを目的としているため、明らかに一流ではない感覚を持っていると思います。 技術的なポイントではありませんが、このような言語の中心的な構成でマクロ構文を使用すると、洗練されていない印象を与えます。 間違いなく、 .awaitと.await()構文も、最もファーストクラスの構文ではありません。 しかし、マクロが感じるほど二流ではありません。

3. チェーンを容易にしたいという願望は、プレフィックス構文の動作を低下させますが、ポストフィックス構文は、メソッドチェーン、特に?で自然に構成されます。

4. awaitキーワードが接尾辞、プレフィックス、マクロなどで使用されている場合、グレッピングが最も簡単です。シジルベースの構文が使用されている場合、たとえば# 、 @ 、 ~ 、grepが難しくなります。 違いは大きくありませんが、 .awaitは、 awaitやawaitよりもわずかに簡単にgrepできます。どちらもコメントに単語として含まれている可能性があるためですが、 .await 。

5. awaitは見やすく、特に構文が強調表示されているのに対し、印章は一目で見つけるのが難しい可能性があります。 .awaitまたは他の接尾辞の構文は一目で見つけるのが難しいか、接尾辞awaitは読みやすさが悪いことが示唆されています。 しかし、私の見解では、 @ scottmcmは、結果の先物は一般的であり、 .await?はそれ自体に特別な注意を引くのに役立つと正しく述べています。 さらに、Scottは、接頭辞awaitはガーデンパス文につながり、式の途中で待機する接頭辞は接尾辞よりも読みやすくないと述べています。 ?演算子の出現により、Rustプログラマーはすでに行末を

6. .awaitと.await()の優先順位は、完全に予測可能であることで注目に値します。 それらは、フィールドアクセスおよびメソッド呼び出しの対応物として機能します。 接尾辞マクロは、おそらくメソッド呼び出しと同じ優先順位を持ちます。 一方、プレフィックスawaitは、 ? （つまり、 await (expr?) ）に対して一貫性があり、予測可能で、役に立たない優先順位を持っているか、優先順位が一貫性がなく、有用です（つまり、 (await expr)? ）。 印章には、希望する優先順位を付けることができます（たとえば、 ?から直感をとること）。

7. 2012年、 @ nikomatsakisは、サイモンペイトンジョーンズが「ドットの力」と、それがIDEの魔法をどのように提供するかをうらやましく思っていることを指摘しました（p。56） 。 ドットの力は多くの一般的な言語（Java、C＃、C ++など）に存在するため、これにより「ドットに到達する」ことが筋肉の記憶に浸透します。 この習慣がいかに強力であるかを説明するために、 @ scottmcmによるRe＃erを使用した
   

   C＃には接尾辞がありません。 それでも、これは非常に便利なので、有効な構文ではなくオートコンプリートリストに表示されます。 ただし、 .awaitが表面構文でない場合、 .awを試すことは、私も含めて多くの人には起こらないかもしれません。 もしそうなら、IDEエクスペリエンスへのメリットを検討してください。 await exprおよびexpr await構文は、その利点を提供しません。

8. 印章はおそらくあまり馴染みがないでしょう。 プレフィックスawaitは、C＃、JSなどに精通しているという利点があります。ただし、これらはawaitと?を別個の操作に分離しませんが、Rustは分離します。 また、 await exprからexpr.await移行するのも簡単ではありません。この変更は、印章を使用する場合ほど急進的ではありません。 さらに、前述のドットパワーにより、 .awaitは、 expr.と入力し、オートコンプリートポップアップの最初のオプションとしてawaitを表示することで学習される可能性があります。

9. 印章は書きやすく、優れた人間工学を提供します。 ただし、 .awaitは入力に時間がかかりますが、書き込みフローをさらに改善できるドットパワーも付属しています。 letステートメントに割り込む必要がないため、人間工学も向上します。 プレフィックスawait 、またはさらに悪いことにawait!(..) 、ドットパワーとチェーン機能の両方が不足しています。 .await 、 .await() 、および.await!()比較すると、最初のオファーは最も簡潔です。

すべての目標を同時に達成するのに最適な構文はないため、トレードオフを行う必要があります。 私にとって、最もメリットがあり、デメリットが最も少ない構文は.awaitです。 特に、チェーン化でき、キーワードとしてawaitを保持し、greppableであり、ドットパワーを備えているため、学習可能で人間工学的であり、明らかな優先順位があり、最終的に読み取り可能です（特に、適切なフォーマットと強調表示を使用）。

@Centrilいくつかの質問をクリアするためだけに。 まず、接尾辞だけを待ちたいということを確認したいのですが。 次に、フィールドアクセスである.awaitの二重性にどのようにアプローチしますか？ .awaitをそのまま使用しても問題ありませんか、それとも、そこで何らかの操作が行われていることを示すために、括弧付きの.await()を優先する必要がありますか？ そして第三に、 .await構文では、それがキーワードになるのでしょうか、それとも単なる「フィールドアクセス」識別子になるのでしょうか。

まず、接尾辞だけを待ちたいということを確認したいのですが。

うん。 少なくとも今は。

次に、フィールドアクセスである.awaitの二重性にどのようにアプローチしますか？

これはわずかな欠点です。 ドットの力には大きな利点があります。 この区別は、特にキーワードが強調表示され、構成が頻繁に使用されるため、ユーザーがすぐに習得できると私が信じているものです。 さらに、スコットが指摘したように、 .await?が最も一般的であり、状況をさらに緩和するはずです。 また、たとえばfn場合と同じように、rustdocにawait新しいキーワードエントリを追加するのも簡単です。

.awaitをそのまま使用しても問題ありませんか、それとも、ある種の操作がそこで行われていることを示すために、括弧付きの.await()を優先する必要がありますか？

私はテールのない.awaitを好みます() ; 最後に()があると、ほとんどの場合、不要な塩のように見え、ユーザーがこの方法を探す傾向が強くなると思います。

そして第三に、 .await構文では、それがキーワードになるのでしょうか、それとも単なる「フィールドアクセス」識別子になるのでしょうか。

awaitはキーワードのままです。 おそらく、 .後にawait発生したときにエラーが発生しないようにlibsyntaxを変更し、ASTまたはHIRに下げるときに別の方法で表現します...しかし、これは主に実装の詳細です。

すべてをクリアしてくれてありがとう！ 👍

この時点で重要な問題は、接尾辞構文を追求するかどうかにあるようです。 それが方向性なら、確かにどちらに絞り込むことができます。 部屋を読んで、接尾辞構文の支持者のほとんどは、接頭辞構文よりも合理的な接尾辞構文を受け入れます。

このスレッドに入ると、接尾辞の構文は弱者のようでした。 しかし、それは4人のlangチームメンバーの明確な支持と5人目からの開放性を引き付けました（他の4人はこれまで沈黙していました）。 さらに、ここでコメントしている幅広いコミュニティからかなりの支持を集めています。

さらに、後置構文の支持者は、それがRustにとって最良の道であるという明確な確信を持っているようです。 この支持を取り消すには、これまでに進んだ議論に対するいくつかの深い問題または説得力のある反論が必要であるように思われる。

これを考えると、確かにこのスレッドを密接にフォローしている@withoutboatsと、他の4人のlangチームメンバーから

おっと、 @ Centrilがすでにコメントしていることに気づいたので、清潔さのために投稿を非表示にします。

@ivandardi投稿の目標（1）を考えると、 loop {}が構造体リテラル式ではないのと同じように、awaitは引き続きキーワードであるため、フィールドアクセスになることはないというのが私の理解です。 そして、より明確にするために強調表示されることを期待します（https://github.com/rust-lang/rust-enhanced/issues/333がSublimeで行うのを待っているように）。

私の1つの懸念は、待機構文を別のアクセスのように見せることで、2015年版のコードベースで気付かないうちに混乱が生じる可能性があることです。 （2015は、指定されていない場合、他の誰かのプロジェクトを開く場合などのデフォルトです。） awaitフィールドがない場合（および存在する場合は警告）、2015エディションに明確なエラーがある限り、私は思いますそれは（Centrilの素晴らしい議論とともに）キーワードフィールド（またはメソッド）についての私の個人的な心配を取り除きます。

ああ、そして私たちがそれにいる間に私たちも決定しなければならないことの1つは、rustfmtがそれをどのようにフォーマットするかということです。

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

1. await -チェック
2. ファーストクラス-チェック
3. 連鎖-チェック
4. グレッピング-チェック
5. 非印章-チェック
6. 優先順位-¹チェック
7. ドットパワー-²チェック
8. 習得が簡単-³チェック
9. 人間工学的-チェック

¹優先順位： await後のスペースは、据え置き位置では明確になりません。 ただし、次のコードとまったく同じです： client.get("https://my_api").await_send()?.await_json()? 。 すべての英語を話す人にとって、それは他のすべての提案よりもさらに自然です

²ドットパワー：次に. 、 ?または;を入力した後、メソッド呼び出しの左側にawaitを移動するには、IDEの追加サポートが必要になります。 実装するのはそれほど難しいことではないようです

³習得が容易：接頭辞の位置では、プログラマーにはすでに馴染みがあります。 延期された位置では、構文が安定した後は明らかです

しかし、この構文の最大のポイントは、非常に一貫性があることです。

• プロパティへのアクセスと混同することはできません
• ?明らかに優先されます
• 常に同じフォーマットになります
• それは人間の言語と一致します
• メソッド呼び出しチェーンでの可変水平オカレンスの影響を受けません*

postfixバリアントでは、どの関数がasyncあり、横軸で次にawait発生する場所を予測するのは困難です。

let res = client.get("https://my_api")
    .very_long_method_name(param, param, param).await?
    .short().await?;

据え置きバリアントでは、ほとんどの場合同じです。

let res = client.get("https://my_api")
    .await very_long_method_name(param, param, param)?
    .await short()?;

はありませんか。 待機と次のメソッド呼び出しの間に？ お気に入り
get().await?.json() 。

2019年1月23日水曜日、05：06 I60R < [email protected]は次のように書いています。

val =未来を待つ;
let res = client.get（ "https：// my_api"）。await send（）?. await json（）?;

1. 待機を使用します-チェック
2. ファーストクラス-チェック
3. 連鎖-チェック
4. グレッピング-チェック
5. 非印章-チェック
6. 優先順位-¹チェック
7. ドットパワー-²チェック
8. 習得が簡単-³チェック
9. 人間工学的-チェック

---

¹優先順位：スペースがあると、据え置き位置ではわかりにくくなります。 しかしそれは
次のコードとまったく同じです：client.get（ "https：// my_api
"）.await_send（）？。 await_json（）?.すべての英語を話す人にとってはさらに多くの
他のすべての提案よりも自然

²ドットパワー：IDEが待機するための追加サポートが必要になります
の後のメソッド呼び出しの左側。 または？ 次に入力します。 あまりにもないようです
実装が難しい

³習得が容易：接頭辞の位置では、プログラマーにはすでに馴染みがあります。
そして、延期された位置では、その構文が

安定した

しかし、この構文の最大のポイントは、非常に
一貫性：

• プロパティへのアクセスと混同することはできません
• それは明らかに優先されますか？
• 常に同じフォーマットになります
• それは人間の言語と一致します
• メソッド呼び出しでの可変水平オカレンスの影響を受けません
  鎖*

*説明はスポイラーの下に隠されています

postfixバリアントでは、どの関数が非同期であるかを予測するのは困難です。
横軸で次に発生するawaitはどこになりますか。

res = client.get（ "https：// my_api"）

.very_long_method_name(param, param, param).await?

.short().await?;

据え置きバリアントでは、ほとんどの場合同じです。

res = client.get（ "https：// my_api"）

.await very_long_method_name(param, param, param)?

.await short()?;

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/rust-lang/rust/issues/57640#issuecomment-456693759 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AIA8Ogyjc8LW6teZnXyzOCo31-0GPohTks5vGAoDgaJpZM4aBlba
。

また、rustfmtがどのようにフォーマットするかを決定する必要があります。

これはhttps://github.com/rust-dev-tools/fmt-rfcsのドメインであるため、この問題ではトピックから外れていると言えます。 どんな修正性と優先順位が選択されても、それと一致する何かがあると確信しています。

@ I60R

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

それはどのように無料の関数関数を探しますか？ 私が正しく読んでいるとしたら、それは実際には接頭辞awaitです。

これは、C＃言語チームの経験をそれほど早く信用してはいけないことを示していると思います。 マイクロソフトはユーザビリティの研究に多くの考慮を払っています。ここでは、1行のコードと、Rustが他のすべての言語とは異なる構文を持つのに十分なほど特別であるという前提に基づいて決定を下しています。 私はその前提に同意しません-私は上記のLINQと拡張メソッドがC＃で普及していると述べました。

ただし、 .awaitが表面構文でない場合に、 .awを試すことは、私も含めて多くの人には起こらないかもしれません。

〜他の言語に精通している人には起こらないと思います。〜それはさておき、完了ポップアップにawaitとFuture両方のメソッドが含まれると思いますか？

[...]ここでは、1行のコードと、Rustが他のすべての言語とは異なる構文を持つのに十分なほど特別であるという前提に基づいて決定を下しています。 私はその前提に同意しません[...]

@lnicolaあなたや他の人がそれを見逃した場合に備えて指摘したいだけです（コメントの大洪水で見逃しがちです）： https ：

実際の製品コードからのいくつかの実際の例。

上記の@Centrilのコメントを考えると、最も強い競合のある接尾辞オプションは、 expr await接尾辞キーワード構文とexpr.await接尾辞フィールド構文であるようです（おそらく、接尾辞メソッド構文はまだ出ていません）。

@Centrilは、postfixキーワードと比較して、postfixフィールドは「ドットの力」の恩恵を受けていると主張しています

逆に、 @ cramertjは、postfixキーワード構文がメソッド呼び出しやフィールドアクセスではないことを明確にすることに基づいて、その構文を支持すると主張しています。 @withoutboatsは、postfixキーワードがpostfixオプションの中で最もよく知られていると主張しています。

「ドットの力」に関しては、IDEがドットの後の補完としてawaitを提供し、補完が選択されたときに単にドットを削除できることを考慮する必要があります。 十分にスマートなIDE（RLSなど）は、未来に気づき、スペースの後にawaitを提供することさえできます。

postfixフィールドとメソッドのオプションは、postfixキーワードと比較して、あいまいさのために、反対意見に対してより大きな表面積を提供するようです。 postfixキーワードに対するpostfixフィールド/メソッドのサポートの一部は、メソッドチェーンにスペースが存在することに対するわずかな不安から来ているように思われるため、postfixキーワード（ foo.bar() awaitという@valffの観察を確認して関与する必要があります。 foo.bar() await ）は、一般化されたタイプのアクリプション（ foo.bar() : Result<Vec<_>, _> ）よりも驚くことではありません。 どちらの場合も、このスペースで区切られた間奏の後、連鎖が続きます。

@ ivandardi 、 @ lnicola 、

最近のコメントを更新して、無料の関数呼び出しの例がありません。 より多くの例が必要な場合は、私の前のコメントの最後のネタバレを参照できます

future.await?対future await?を議論するために..。

あまり議論されていないのは、メソッドチェーンの視覚的なグループ化またはgrepです。

検討してください（構文の強調表示にはawaitではなくmatch ）

post(url).multipart(form).send().match?.error_for_status()?.json().match?

と比較して

post(url).multipart(form).send() match?.error_for_status()?.json() match?

私は視覚的にするための第1のチェーンをスキャンするとawait私は明確かつ迅速に識別send().await? 、我々は結果待っていることがわかりsend() 。

ただし、2番目のチェーンでawaitを視覚的にスキャンすると、最初にawait?.error_for_status()が表示され、バックアップしてからsend() await接続する必要があります。

はい、これらの同じ議論のいくつかは一般化されたタイプの帰属に適用されますが、それはまだ受け入れられている機能ではありません。 私はある意味でタイプアクリプションが好きですが、_general_式のコンテキストでは（あいまいですが）、親でラップする必要があると感じています。 しかし、それはこの議論ではすべてトピックから外れています。 また、コードベースのawaitの量は、型の帰属の量よりも大幅に大きくなるという大きな変化があることにも注意してください。

Generalized Type Ascriptionは、個別の演算子:使用して、型を属性付き式にバインドします。 他の二項演算子と同じように、それを読むと、2つの式が単一のツリーであることが（視覚的に）明らかになります。 future awaitは演算子がなく、最初の名前がキーワードである場合を除いて、演算子で区切られていない2つの名前がめったに表示されないため、 future_awaitと間違えられがちです（例外が適用されますが、そうではありません）。私は接頭辞構文を好むと言いますが、そうではありません）。

必要に応じて、これを英語と比較してください。ハイフン（ - ）を使用して、単語を視覚的にグループ化します。

これは、C＃言語チームの経験をそれほど早く信用してはいけないことを示していると思います。

ここでは「そんなに速い」と「信用できない」は公平ではないと思います。 ここでは、async / await RFC自体で発生したのと同じことが起こっていると思います。それが一方向で行われた理由を慎重に検討し、バランスが同じように得られるかどうかを判断します。 C＃チームは、次の1つで明示的に言及されています。

• 2394-async_await.md＃polymorphic-return-a-non-factor-for-us
• 2394-async_await.md＃hot-async-functions

awaitのアイデアは、将来ではなく実際に結果が欲しいということだと思いました
したがって、await構文は「ref」構文のようになります。

let future = task()
だが
let await result = task()

したがって、チェーンの場合は、どちらかを実行する必要があります

task().chained_method(|future| { /* do something with future */ })

だが

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

それらはすべて連鎖でうまく機能し、すべてが実際のフィールド/メソッド/マクロではない短所を持っています。
ただし、キーワードとしてのawaitはすでに特別なものであるため、特別なものにする必要はありません。
最も単純なfoo.await選択する必要があります。 ここでは、 ()と!()両方が冗長です。

@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

最初のチェーンを視覚的にスキャンして待機するとき、send（）。awaitを明確かつ迅速に識別しますか？ send（）の結果を待っていることを確認してください。

未来がどこに構築され、どこでそれが待たれるかを見るのがはるかに簡単なので、私はスペースドバージョンがもっと好きです。 何が起こるかを確認するのははるかに簡単です、私見

ドット区切りを使用すると、メソッド呼び出しに非常によく似ています。 コードの強調表示はあまり役に立ちませんし、常に利用できるとは限りません。

最後に、チェーンは主なユースケースではないと思います（ ?を除くが、 foo await?は可能な限り明確です）。

post(url).multipart(form).send().match?

vs

post(url).multipart(form).send() match?

後者がはるかにスリムなimoに見えるところ。

したがって、 future awaitとfuture.awaitに絞り込んだ場合、魔法の「ドット」をオプションにすることはできますか？ 人々が欲しいものを選ぶことができるように、そして最も重要なことに、議論をやめて前進してください！

オプションの構文があっても害はありません。Rustにはそのような例がたくさんあります。 最もよく知られているのは最後のスペレーター（ ;または,など、最後のアイテムの後、 (A,B,) ）はほとんどオプションです。 ドットをオプションにできないという強い理由はわかりませんでした。

Nightlyでこれを実行し、エコシステムにどちらが最適かを決定させるのは良い時期だと思います。 好みのスタイルを適用するための糸くずを使用して、カスタマイズ可能にすることができます。

次に、Stableに着陸する前に、コミュニティの使用状況を確認し、どちらかを選択するか、両方を残すかを決定します。

私は、マクロがこの機能に対して一流であるとは感じられないという考えに完全に同意しません（そもそも、このようなコア機能とは見なしません）。 await!()に関する以前のコメントを再度強調したいと思いますawait!() （プレフィックスかポストフィックスかに関係なく）は「実際のマクロ」ではありませんが、結局、ポストフィックスマクロでこれをブロックするのではなく、この機能をできるだけ早く安定させたいと思う人が多すぎると思います。 Rustにぴったりです。

いずれにせよ、このスレッドを1日ロックしてもあまり役に立たなかったので、今すぐ登録を解除します。 私のポイントの1つに直接返信する場合は、遠慮なく私に言及してください。

.した構文に対する私の主張は、 awaitはフィールドではないため、フィールドのように見えるべきではないということです。 構文の強調表示と太字のフォントを使用しても、それはどういうわけか特別なフィールドのように見えます。カスタムフォーマットでも、 .後に単語が続くことはフィールドアクセスに強く関連しているため、フィールドではないことを強調できません。

Intellij IDEAで利用可能な接尾辞補完機能のようなものを使用することで、 .補完でさまざまな構文を強化できるため、IDE統合を改善するために.で構文を使用する理由もありません。

awaitを制御フローのキーワードとして認識する必要があります。 Postfix 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)
        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?;

これは、フォーマットに関する@ivandardiポイントへの回答にもなります。

後置のこれらすべての例は、それよりもそれに

比較します（構文の強調表示のためにmatchをawaitものとして）：

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

途中で待機が不足していることに気づきましたか？ なぜなら、連鎖は通常、より良いAPI設計によって解決できるからです。 send()が、たとえば200以外のステータスメッセージをハードエラーに変換するための追加のメソッドを含むカスタムfutureを返す場合、追加の待機は必要ありません。 現在、少なくともreqwestでは、インプレースで実行され、新しい未来ではなく、単純なResultを生成しているように見えます。これが、ここでの問題の原因です。

私の意見では、連鎖が待っているのは強いコードの臭いであり、 .awaitまたは.await()は多くの新規ユーザーを混乱させ、面白くもありません。 .await特にPythonまたはPHPのようなもののように感じます。この場合、変数メンバーへのアクセスは魔法のように特別な動作をする可能性があります。

awaitは、「続行する前に、これを待つ」ではなく、「次に、これを待つ」と言っているかのように、前もって明白である必要があります。 後者は文字通りand_thenコンビネータです。

それについて考えるもう1つの潜在的な方法は、 async / await式と先物をイテレーターのように考えることです。 彼らは、両方の怠惰されている多くの状態を持つことができ、（構文で終了することができますfor-inイテレータのため、 await先物のため）。 ここにいるような正規表現としてイテレータをチェーン化するための構文拡張を提案しませんか？ それらは連鎖にコンビネータを使用し、非同期操作/将来は同じことを行う必要があり、1回だけ終了します。 それはかなりうまくいきます。

最後に、そして最も重要なこととして、関数の最初のいくつかのインデントを垂直方向にスキミングして、非同期操作が発生する場所を明確に確認できるようにしたいと思います。 私のビジョンはそれほど素晴らしいものではありません。ラインの最後で待ったり、途中で立ち往生したりすると、物事が非常に難しくなり、生の先物に完全にとどまる可能性があります。

コメントする前に、このブログ投稿を読んで

Async / awaitは利便性ではありません。 コンビネータを回避することではありません。

それは、コンビネータでは不可能な新しいことを可能にすることです。

したがって、「代わりにコンビネータを使用しましょう」という提案はトピックから外れており、別の場所で議論する必要があります。

途中で待機が不足していることに気づきましたか？ なぜなら、連鎖は通常、より良いAPI設計によって解決できるからです。

実際の非同期の例では、きれいなチェーンは得られません。 実際の例：

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)
})

コンビネータはここでは役に立ちません。 入れ子は削除できますが、簡単ではありません（2回試しましたが失敗しました）。 最後にたくさんのEither:A(Either:A(Either:A(...)))があります。

OTOH async / awaitで簡単に解決できます。

@Pauanは私が投稿を終える前にそれを書いています。 だからそれでいい。 コンビネータについては言及しないでください。 async/awaitは同じように見えるべきではありません。 もしそうならそれは問題ありません、考慮すべきもっと重要なことがあります。

私のコメントに反対票を投じても、コンビネータはより便利にはなりません。

タイプアクリプションコメントを読んで、それがawaitとどのように組み合わされるかを考えていました。 一部の人々が.awaitまたは.await()を混乱させるメンバーフィールド/メソッドアクセスとして持っている予約を考えると、一般的な「ascription」構文がオプションになるのではないかと思います（つまり、「give me what awaitが返されます "）。

構文の強調表示にawaitにyieldを使用する

let result = connection.fetch("url"):yield?.collect_async():yield?;

タイプアクリプションと組み合わせて、例：

let result = connection.fetch("url") : yield?
    .collect_async() : yield Vec<u64>?;

利点：見栄えがよく（IMHO）、フィールド/メソッドアクセスとは構文が異なります。
短所：タイプアクリプション（？）との潜在的な競合、理論的には複数のアクリプションが可能：

foo():yield:yield

編集： 2つのアクリプションを使用すると、組み合わせた例の方が論理的であることがわかりました。

let result = connection.fetch("url") : yield?
    .collect_async() : yield : Vec<u64>?;

@Pauanそのブログ投稿を過剰に適用することは不適切です。 コンビネータは、await構文と組み合わせて適用して、説明されている問題を回避できます。

中心的な問題は常に、スポーン可能な未来は'staticでなければならないということ'staticではない未来になってしまいました。 しかし、 'static未来を待っても、あなたがいる非同期fnは'staticはありません。 したがって、次のようなことができます。

`` `錆
//スライス：＆[T]

x = await future.and_then（| i | ifスライス.contains（i）{async_fn（slice）}）;

それで、私はまったくコメントしないことを計画していました、しかし私は多くの非同期コードを書かない誰かからのいくつかのメモを追加したかったです、しかしそれでもそれを読まなければなりません：

• プレフィックスawaitは、はるかに気づきやすいです。 これは、期待している場合（ async fnの内部）または外部（マクロ本体の式）の両方です。
• キーワードである接尾辞awaitは、他のキーワードがほとんどまたはまったくないチェーンでよく目立つ可能性があります。 しかし、他の制御構造と同様のクロージャがあるとすぐに、 awaitsは目立たなくなり、見落としやすくなります。
• .awaitを疑似フィールドとして非常に奇妙だと思います。 それは私にとって重要な他の分野とはまったく異なります。
• IDEの検出と構文の強調表示に依存するのが良い考えかどうかはわかりません。 構文の強調表示が利用できない場合、読みやすさに価値があります。 さらに、文法の複雑化とそれがツールにもたらす問題についての最近の議論を踏まえると、IDE /エディターが物事を正しく行うことに依存するのは良い考えではないかもしれません。

私は、マクロとしてのawait!() 「一流だとは感じない」という感情を共有しません。 マクロはRustの完全に一流の市民です。 また、「ユーザーコードで構文を発明する」ためだけのものではありません。 多くの「ビルトイン」マクロは、ユーザー定義ではなくそこに単なる構文上の理由ではありません。 format!()は、コンパイラに静的に型チェックするフォーマット文字列の能力を与えるためにあります。 include_bytes!()もユーザー定義ではなく、単なる構文上の理由で存在しません。これも構文拡張である必要があるためマクロです。これも、コンパイラー内で特別なことを行うため、できませんでした。コア言語機能として追加せずに、他の方法で合理的に記述します。

そして、これは私のポイントの一種です。マクロは、コンパイラの魔法を統一された驚くべき方法で導入および非表示にするための完璧な方法です

ですから、特別なキーワードの必要性はまったくわかりません。 とは言うものの、それがキーワードになるのであれば、それは単なるキーワードであるはずです。私はそれをフィールドに偽装する動機を本当に理解していません。 それは間違っているように思えます、それはフィールドアクセスではなく、フィールドアクセスのようにリモートでもありません（たとえば、砂糖を使ったゲッター/セッターメソッドとは異なります）ので、それを1つとして扱うことは、今日の言語でのフィールドの動作と矛盾します。

@ H2CO3 await!マクロは、次の2つのプロパティを除いて、すべての望ましい方法に適しています。

1. あなたがまだ何千もの待っていると書くとき、余分な中括弧は本当に迷惑です。 Rustは、同じ理由でif/while/...ブロックから中括弧を削除しました（私は信じています）。 重要でないATMに見えるかもしれませんが、実際にはそうです
2. asyncがキーワードである非対称性。 Asyncは、メソッド本体で1つのマクロを許可するよりも大きなことを行う必要があります。 それ以外の場合は、関数の上にある#[async]属性である可能性があります。 属性ではブロックなどで使用できないことは理解していますが、 awaitキーワードに遭遇する可能性があります。 この期待は、知っている他の言語での経験によって引き起こされるかもしれませんが、私はそれが存在すると強く信じています。 対処されていない可能性がありますが、考慮する必要があります。

それ以外の場合は、関数の上にある#[async]属性である可能性があります。

長い間そうでした、そしてそれが行くのを見てすみません。 #[async]属性は完全に正常に機能し、属性のような手続き型マクロが安定しているのに対し、別のキーワードを導入します。これは、まだわかっていても、構文的にも意味的にも他の言語と一貫性があります。 （そして特別に処理される）コンパイラーによって。

@ H2CO3ユーザーの観点からマクロとしてawaitを使用する目的または利点は何ですか？ プログラムが内部のフローを制御するように変更する組み込みマクロはありますか？

@ I60R利点は、言語の他の部分との統一性であり、したがって、それ自体がもたらすすべての手荷物で、さらに別のキーワードについて心配する必要がありません。たとえば、優先順位とグループ化は、マクロ呼び出しで明らかです。

2番目の部分が関連する理由がわかりません–何か新しいことをする組み込みマクロはありませんか？ 実際、ほとんどすべての組み込みマクロは、コンパイラのサポートなしでは（合理的/効率的に/など）達成できない「奇妙な」ことをしていると思います。 await!()は、この点で新しい侵入者ではありません。

以前は暗黙的な待機を提案しましたが、最近では

コミュニティは明示的な待機を非常に強く支持しているようです（私はそれが変わることを望んでいますが…）。 ただし、明示性の粒度が定型文を作成するものです（つまり、同じ式で何度もそれを必要とすることで定型文が作成されるようです）。

[警告：次の提案は物議を醸すでしょうが、それを心からのチャンスを与えてください]

コミュニティのほとんどが妥協して「部分的に暗黙の待機」を許可するかどうか知りたいですか？ たぶん、式チェーンごとに1回の読み取り待機は、十分に明示的ですか？

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

これは、値の構造化に似たものであり、私はこれを式の構造化と呼んでいます。

// 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?);

また、「式チェーンごとに1回読み取るのは十分に明示的である可能性が高い」という、コアアイデアの他の実装にも満足しています。 ボイラープレートを減らすだけでなく、誰もが最もよく知っているプレフィックスベースの構文でチェーンを可能にするためです。

@yazaddaruvala上記の警告がありましたので、注意してください。

コミュニティのほとんどが妥協して「部分的に暗黙の待機」を許可するかどうか知りたいですか？ たぶん、式チェーンごとに1回の読み取り待機は、十分に明示的ですか？

1. 私は、コミュニティのほとんどが部分的、暗黙的、何かを望んでいるとは思いません。 Rustネイティブのアプローチは、「すべてを明示する」ようなものです。 キャストu8-> u32でさえ明示的に行われます。
2. より複雑なシナリオではうまく機能しません。 コンパイラはVec<Future>何をすべきですか？

await response = client.get("https://my_api").send()?.json()?.parse_as::<Vec<String>>()?.map(|x| client.get(x))?;

ネストされた呼び出しごとにawaitを実行する必要がありますか？ おそらく、1行のコードでawaitを機能させることができます（したがって、ネストされたmapFuncは待機されません）が、この動作を破るのは簡単すぎます。 awaitが1つのコード行で機能する場合、「値の抽出」などのリファクタリングはそれを壊します。

@yazaddaruvala

あなたが意図していることは、 ?よりも優先されるプレフィックスawaitであり、letキーワードの代わりにawaitを使用してコンテキストを変更し、すべてのimpl Future <_iを振りかける可能性があることを理解していますか？ = "7">待って戻ってきますか？

以下の3つのステートメントの意味は同等です。

// foo.bar() -> Result<impl Future<_>, _>>
let a = await foo.bar()?;
let a = await (foo.bar()?);
await a = foo.bar()?;

そして、以下の2つのステートメントは同等です。

// foo.bar() -> impl Future<Result<_, _>>
await a = foo.bar()?;
let a = await (foo.bar())?;

構文が理想的かどうかはわかりませんが、「暗黙のコンテキストを待つ」に変更されるキーワードがあると、プレフィックスキーワードの問題が少なくなる可能性があります。 同時に、必要なときにawaitが使用される場所をよりきめ細かく制御できるようにします。

私の意見では、短いワンライナーの接頭辞awaitには、他の多くのプログラミング言語と多くの人間の言語の両方に類似しているという利点があります。 最終的にawaitを接尾辞のみにすることが決定された場合、私が傾いていると感じたときに、 Await!()マクロ（または同様の形式がキーワードと衝突しないもの）を使用することになると思います。英語の文の構造に精通していると、コードの読み取り/書き込みの精神的なオーバーヘッドを減らすのに役立ちます。 より長い連鎖式の接尾辞形式には明確な価値がありますが、私の明示的に客観的事実に基づいていない見解は、接頭辞の人間の複雑さが話し言葉によって助成されているので、1つの形式だけを持つことの単純さの利点は両方を持つことの潜在的なコードの明確さを明確に上回っていません。 少なくとも現在のコードのチャンクに最も適切な方をプログラマーが選択することを信頼していると仮定します。

@Pzixel

私は、コミュニティのほとんどが部分的、暗黙的、何かを望んでいるとは思いません。 Rustネイティブのアプローチは、「すべてを明示する」ようなものです。

私はそれを同じように見ていません。 私はそれが常に明示的および暗黙的な妥協であると思います。 例えば：

• 関数スコープでは変数のタイプが必要です
  
  
  
  • 変数のタイプは、ローカルスコープ内で暗黙的に指定できます。
  
  
  • クロージャーコンテキストは暗黙的です
  
  
  • ローカル変数についてすでに推論できることを考えると。
  
  
• 借用チェッカーを支援するには、寿命が必要です。
  
  
  
  • しかし、ローカルスコープ内ではそれらを推測することができます。
  
  
  • 関数レベルでは、ライフタイムがすべて同じ値である場合、ライフタイムを明示的にする必要はありません。
  
  
• もっとあると確信しています。

チェーンのすべての利点を備えた、式/ステートメントごとに1回だけawaitを使用することは、明示的な定型文と削減定型文の間の非常に合理的な妥協点です。

より複雑なシナリオではうまく機能しません。 コンパイラはVecで何をすべきか？

await response = client.get("https://my_api").send()?.json()?.parse_as::<Vec<String>>()?.map(|x| client.get(x))?;

コンパイラはエラーになるはずだと私は主張します。 推測できない大きなタイプの違いがあります。 一方、 Vec<impl Future>は、このスレッドのどの構文でも解決されません。

// 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])?;

Vec<impl Future>は悪い例であると私は主張します。そうでなければ、提案されたすべての構文を同じ標準に保つ必要があります。 一方、私が提案した「partial-implicit await」構文は、通常の接尾辞またはプレフィックスawait let (a, b) = (client.get("a") await?, client.get("b") await?);を使用するawait (a, b) = (client.get("a")?, client.get("b")?);ようなより複雑なシナリオでは、現在の提案よりもうまく機能します。 -暗黙的なバージョンは、コンパイラが適切に脱糖することで同時に実行できます（元の投稿で示したように）。

2011年に、C＃のasync機能がまだテスト中であったときに、 awaitがプレフィックス演算子であることについて質問し、C＃言語PMから応答を受け取りました。 Rustがプレフィックス演算子を使用すべきかどうかについての議論があるので、その応答をここに投稿することは価値があるかもしれないと思いました。 なぜ「await」は接尾辞演算子ではなく接頭辞演算子なのですか？ ：

ご想像のとおり、await式の構文は、現在の状況を決定する前の大きな議論のポイントでした:-)。 ただし、接尾辞演算子についてはあまり考慮していませんでした。 接尾辞（HP計算機とプログラミング言語Forthを参照）には、原則として物事を単純にし、実際には近づきにくく、読みにくくする何かがあります。 多分それは数学表記が子供として私たちを洗脳する方法です...

プレフィックス演算子（文字通り命令型のフレーバー-「これを実行してください！」）がはるかに直感的であることが間違いなくわかりました。 私たちの単項演算子のほとんどはすでに接頭辞が付いており、awaitはそれに適合するようです。 はい、それは複雑な式で溺れますが、例えば関数適用も接尾辞ではないという事実のために、一般的に評価順序もそうです。 最初に引数（右側にあります）を評価してから、関数（左側にあります）を呼び出します。 はい、C＃の関数適用構文にはすでに括弧が組み込まれているという違いがありますが、待機する場合は通常、括弧を削除できます。

私が広く見ている（そして私自身が採用している）のは、多くの一時変数を使用するスタイルです。 私は好む傾向があります

var bResult = await A().BAsync();
var dResult = await bResult.C().DAsync();
dResult.E()

またはそのようなもの。 一般に、私は通常、最も単純な式を除いてすべてで複数の待機を回避し（つまり、それらはすべて同じ関数または演算子への引数です。おそらく問題ありません）、待機式を括弧で囲むことを避け、両方のジョブに追加のローカルを使用することを好みます。 。

意味がありますか？

Mads Torgersen、C＃言語PM

C＃開発者としての私の個人的な経験では、構文によってそのスタイルの複数のステートメントを使用するようになり、非同期コードは同期コードよりも読み取りと書き込みがはるかに厄介になります。

@yazaddaruvala

私はそれを同じように見ていません。 私はそれが常に明示的および暗黙的な妥協であると思います

それはまだ明白です。 ところで、トピックに関する良い記事をリンクすることができます。

コンパイラはエラーになるはずだと私は主張します。 推測できない大きなタイプの違いがあります。 一方、Vecの例このスレッドのどの構文でも解決されません。

なぜエラーになるのでしょうか？ Vec<impl future>を持っていて、一緒に参加できてうれしいです。 あなたは理由もなく追加の制限を提案します。

私はVecがこれは悪い例です。そうでない場合は、提案されたすべての構文を同じ標準に保つ必要があります。

すべてのケースを調べる必要があります。 「まあ、あなたが知っている、とにかく誰もこれを書かない」ので、私たちはエッジケースを単に無視することはできません。 言語設計は、主にエッジケースに関するものです。

@chescock私はあなたに同意しますが、前に言われたように、RustはここでC＃と非常に大きな違いがあります：C＃では(await FooAsync()).Bar()書くことはありません。 しかし、Rustではそうします。 そして、私は?について話している。 C＃では、非同期呼び出しを介して伝播される暗黙の例外があります。 しかし、さびた場合は、明示的にして、関数の結果を待った後に?を書き込む必要があります。

もちろん、ユーザーに書き込みを依頼することもできます

let foo = await bar();
let bar = await foo?.baz();
let bar = bar?;

しかし、それはよりもはるかに奇妙です

let foo = await? bar();
let bar = await? foo.baz();

これははるかに見栄えがしますが、 awaitと? doint (await expr)?新しい組み合わせを導入する必要があります。 さらに、他の演算子がある場合は、 await?&@#と記述して、すべての組み合わせを完全に機能させることができます...少し複雑に見えます。

しかし、その後、接尾辞として待機するだけで、現在の言語に自然に適合します。

let foo = bar() await?;
let bar = foo.baz() await?;

現在、 await?は2つの別々のトークンですが、それらは完全に機能します。 await?&@#を使用することができ、コンパイラ自体にハッキングする必要はありません。

もちろん、プレフィックスの方法よりも少し奇妙に見えますが、言われているように、それはすべてRust / C＃の違いに関するものです。 C＃エクスペリエンスを使用して、キーワードが分離されている可能性が高い明示的な待機構文が必要であることを確認できますが、同じ方法を盲目的にたどってRust / C＃の違いを無視するべきではありません。

私は長い間プレフィックスawait提案者であり、C＃言語の開発者をトピックに招待しました（2011年よりも新しい情報があります😄）が、今ではポストフィックスawaitだと思います

毎晩あることを忘れないでください。より良い方法が見つかったら、後でやり直すことができます。

次の組み合わせで両方の世界を最大限に活用できる可能性があることに気づきました。

• プレフィックスasyncキーワード
• 一般的な接尾辞マクロ機能

これを組み合わせると、コンパイラの魔法なしで接尾辞.await!()マクロを実装できます。

今のところ、接尾辞.await!()マクロにはコンパイラの魔法が必要です。 ただし、 awaitキーワードのプレフィックスバリアントが安定化されている場合、これは当てはまりません。ポストフィックス.await!()マクロは、引数（式）のプレフィックスを付けるマクロとして簡単に実装できます。 awaitキーワードを使用して、すべてを括弧で囲みます。

このアプローチの利点：

• 接頭辞awaitキーワードが利用可能であり、他の言語からその構成に精通しているユーザーがアクセスできます。
• プレフィックスasyncキーワードは、式の非同期性を「目立たせる」ことが望ましい場合に使用できます。
• 後置バリアント.await!()があり、チェーンの状況や、プレフィックス構文が扱いにくいその他の状況で使用できます。
• 接尾辞のバリアントには（予期しない可能性のある）コンパイラマジックは必要ありません（そうでなければ、接尾辞のフィールド、メソッド、またはマクロオプションの問題になります）。
• 後置マクロは、同様の理由で偶然にも後置マクロ構文が必要な他の状況（ .or_else!(continue) ）でも使用できます（それ以外の場合は、前の式を扱いにくく読みにくい方法でラップする必要があります）。
• プレフィックスawaitキーワードは、ポストフィックスマクロの実装を待たずに、比較的迅速に安定化できます（エコシステムの開発が可能になります）。 しかし、中長期的には、後置構文が待機する可能性を残しておきます。

@ nicoburns 、 @ H2CO3 、

await!()や.or_else!(continue)ような制御フロー演算子をマクロとして実装するべきではありません。ユーザーの観点からは、そうする意味のある理由がないからです。 とにかく、両方の形式で、ユーザーはまったく同じ機能を持ち、両方を学習する必要がありますが、これらの機能がマクロとして実装される場合、さらにユーザーは、なぜ正確にこのように実装されるの

await前に追加の.を追加した場合とまったく同じ答えです。必要ありません。 マクロは、ファーストクラスの制御フローを模倣することはできません。マクロは、形式が異なり、ユースケースが異なり、強調表示が異なり、動作が異なり、認識もまったく異なります。

.await!()と.or_else!(continue)両方の機能には、美しい構文を備えた適切で人間工学的なソリューションが存在します。 awaitキーワードとnone合体演算子です。 一般的で、めったに使用されず、接尾辞マクロのように見苦しいものではなく、それらを実装することをお勧めします。

マクロを使用する理由はありません。 format!()ような複雑なものはなく、 include_bytes!()ようにめったに使用されないものもありません。また、カスタムDSLもありません。ユーザーコードの重複が削除されることもありません。 varargのような構文は必要ありません。見た目が異なるものは必要ありません。また、可能であるという理由だけでこの方法を使用することはできません。

ユーザーの観点からはそれを行う意味のある理由がないため、制御フロー演算子をマクロとして実装するべきではありません。

try!()はマクロとして実装されました。 それには完全に良い理由がありました。

awaitをマクロにする理由については、すでに説明しました。既存の機能でも目標を達成できる場合は、新しい言語要素は必要ありません。

format!()ような複雑なものはありません

私は違うように頼みます： format!()は複雑さについてではなく、コンパイル時のチェックについてです。 コンパイル時のチェック用でない場合は、関数である可能性があります。

ちなみに、私はそれが接尾辞マクロであるべきだとは提案しませんでした。 （私はそうすべきではないと思います。）

どちらの機能にも、美しい構文を備えた適切で人間工学的なソリューションが存在します

すべての関数呼び出し、フロー制御式、またはマイナーな便利な機能に独自の非常に特別な構文を与えるべきではありません。 それは、理由もなく構文でいっぱいの肥大化した言語をもたらすだけであり、それは「美しい」の正反対です。

（私はできることを言いました;私はこれ以上質問のこの側面に答えるつもりはありません。）

@nicoburns

次の組み合わせで両方の世界を最大限に活用できる可能性があることに気づきました。

• プレフィックスawaitキーワード
• 一般的な接尾辞マクロ機能

これには、現在の実際のキーワードではなく、 awaitをコンテキストキーワードにする必要があります。 私たちはそうすべきではないと思います。

これを合わせると、コンパイラの魔法なしで接尾辞.await!()マクロを実装できます。

これは、 foo awaitやfoo.await （特に後者）よりも実装的に複雑なソリューションです。 それと同じくらい、まだ「魔法」があります。 会計操作を行ったところです。

このアプローチの利点：

• 接頭辞awaitキーワードが使用可能であり、他の言語からその構成に精通しているユーザーがアクセスできます。

後で.await!()を追加する場合は、ユーザーに学習内容を提供するだけで（ await fooとfoo.await!()両方）、ユーザーは「どちらを使用すればよいか」と尋ねます。いつ.."。 これは、単一のソリューションのように、 foo awaitまたはfoo.awaitよりも複雑さの予算を使い果たしているようです。

• 後置マクロは、同様の理由で偶然にも後置マクロ構文が必要な他の状況（ .or_else!(continue) ）でも使用できます（それ以外の場合は、前の式を扱いにくく読みにくい方法でラップする必要があります）。

接尾辞マクロには価値があり、言語に追加する必要があると思います。 ただし、これはawait ingに使用する必要があるという意味ではありません。 おっしゃるように、 .or_else!(continue)や、接尾辞マクロが役立つ場所は他にもたくさんあります。

• プレフィックスawaitキーワードは、ポストフィックスマクロの実装を待たずに、比較的迅速に安定化できます（エコシステムの開発が可能になります）。 しかし、中長期的には、後置構文が待機する可能性を残しておきます。

「開かれた可能性を残す」ことには価値がありません。 構成、IDEエクスペリエンスなどの接尾辞の価値は、今日知られています。 「今日はawait foo安定させ、明日はfoo.await!()合意に達することを

@ H2CO3

try!()はマクロとして実装されました。 それには完全に良い理由がありました。

try!(..)は非推奨になりました。これは、特に接尾辞がないため、この言語には適さないと判断したことを意味します。 それを議論として使うことは-私たちがしてはいけないこと以外に-奇妙に思えます。 さらに、 try!(..)は、コンパイラからのサポートなしで

ちなみに、私はそれが接尾辞マクロであるべきだとは提案しませんでした。 （私はそうすべきではないと思います。）

awaitは「すべてのシングル..」ではありません。特に、マイナーな便利な機能ではありません。 むしろ、追加されているのは主要な言語機能です。

@phaylon

さらに、文法の複雑化とそれがツールにもたらす問題についての最近の議論を踏まえると、IDE /エディターが物事を正しく行うことに依存するのは良い考えではないかもしれません。

構文foo.awaitは、Rustを適切にサポートしているように見えるエディターは、すでに.ident形式を理解しているため、ツールの問題を減らすことを目的としています。 編集者がする必要があるのは、キーワードのリストにawaitを追加することだけです。 さらに、優れたIDEにはすでに.基づくコード補完があります。したがって、RLS（または同等のもの...）を拡張して、ユーザーが.入力したときの最初の提案としてawaitを提供する方が簡単なようです。 . my_future後の. my_future 。

文法の複雑化に関しては、構文で.awaitをサポートすることは本質的に.$identを解析し、 ident == keywords::Await.name()エラーが発生しないことを考えると、 .awaitが実際に文法を複雑化する可能性は最も低くなります。 ident == keywords::Await.name() 。

構文foo.awaitは、Rustを適切にサポートしているように見えるエディターは、すでに.ident形式を理解しているため、ツールの問題を減らすことを目的としています。 編集者がする必要があるのは、キーワードのリストに待機を追加することだけです。 さらに、優れたIDEには、に基づくコード補完がすでにあります。 -したがって、RLS（または同等のもの...）を拡張して、ユーザーが入力したときの最初の提案として待機を提供する方が簡単なようです。 my_futureの後。

私はこれが文法の議論と対立していることに気づきました。 そして、問題は今だけではなく、5、10、20年後に数回の版を経てです。 ただし、お気づきのことと思いますが、キーワードが強調表示されていても、他のキーワードが含まれていると、待機ポイントが見過ごされる可能性があることにも注意してください。

文法を複雑にすることに関しては、構文で.awaitをサポートすることは本質的に。$ identを解析し、ident == keys :: Await.name（）でエラーが発生しないことを考えると、.awaitが実際に文法を複雑にする可能性は最も低くなります。

名誉はすでに文法で完全にサポートされているので、 await!(future)に属すると思います。

@Centril try!は、 ?演算子がより厳密に実行できるため、最終的に冗長になりました。 それは「言語にふさわしくない」ということではありません。 しかし、あなたはそれを気に入らないかもしれませんが、私はそれを受け入れます。 しかし、私にとって、それは実際にはRustが発明した最高のもののひとつであり、セールスポイントの1つでした。 そして、コンパイラのサポートなしで実装されていることは知っていますが、制御フローを実行するかどうかを議論するときに、それがどのように関連するのかわかりません。 関係なく、そうです。

awaitは「すべてのシングル..」ではありません。

しかし、ここで言及されている他のもの（たとえば、 or_else ）はそうです、そして私のポイントはとにかく主要な機能にまだ当てはまります。 構文を追加するためだけに構文を追加することは利点ではないため、より一般的なケースですでに機能するものがある場合は常に、新しい表記法を発明するよりも優先する必要があります。 （マクロに対する他の議論は、「それらは接尾辞ではない」ということです。それ自体の接尾辞演算子であるのを待つことの利点は、コストを正当化するほど高くないと思います。入れ子関数呼び出しを生き延びました。ネストされたマクロをいくつか記述した後も、同様に問題ありません。）

2019年1月23日水曜日09:59:36 PM +0000に、MazdakFarrokhzadは次のように書いています。

• 後置マクロは、同様の理由で偶然にも後置マクロ構文が必要な他の状況（ .or_else!(continue) ）でも使用できます（それ以外の場合は、前の式を扱いにくく読みにくい方法でラップする必要があります）。

接尾辞マクロには価値があり、言語に追加する必要があると思います。 ただし、これはawait ingに使用する必要があるという意味ではありません。 おっしゃるように、 .or_else!(continue)や、接尾辞マクロが役立つ場所は他にもたくさんあります。

.await!()を使用する主な理由は、マクロのように見えることで
制御フローに影響を与える可能性があることは明らかです。

.awaitはフィールドアクセスのように見え、 .await()は関数のように見えます
呼び出し、およびフィールドアクセスも関数呼び出しも制御に影響を与えることはできません
フロー。 .await!()はマクロのように見え、マクロは制御に影響を与える
フロー。

@joshtriplett標準的な意味での制御フローには影響しません。 これは、ボローチェッカーが定義されたように先物で機能することを正当化するための基本的な事実です（そしてピンはその方法の理由です）。 ローカル関数の実行の観点からは、awaitの実行は他のほとんどの関数呼び出しと同じです。 中断したところから続行し、スタックに戻り値があります。

私はこれが文法の議論と対立していることに気づきました。 そして、問題は今だけではなく、5、10、20年後に数回の版を経てです。

これが何を意味するのかわかりません。

名誉はすでに文法で完全にサポートされているので、 await!(future)に属すると思います。

私は理解していますが、現時点では、この構文には他にも多くの欠点があるため、事実上除外されていると思います。

@Centril try!は、 ?演算子がより厳密に実行できるため、最終的に冗長になりました。 それは「言語にふさわしくない」ということではありません。 しかし、あなたはそれを_好き_ではないかもしれませんが、私はそれを受け入れます。

Rust 2018でtry!(expr)を書き込むことは明示的に非推奨であり、さらに難しいエラーです。私たちはまとめてそうすることを決定したため、不適切と見なされました。

.await!()を使用する主な理由は、マクロのように見えることで、制御フローに影響を与える可能性があることが明らかになるためです。

.awaitはフィールドアクセスのように見え、 .await()は関数呼び出しのように見え、フィールドアクセスも関数呼び出しも制御フローに影響を与えることはできません。

私は区別は、ユーザーが特にとして、比較的容易に学ぶことができます何かであると信じて.await通常が続く? （関数ローカル制御フローです）。 関数呼び出しに関しては、前述のように、イテレータメソッドは制御フローの一形態であると言っても過言ではありません。 さらに、マクロが制御フローに影響を与えるがあるからといって、それは限りません。 多くのマクロはそうではありません（例： dbg! 、 format! 、...）。 .await!()または.awaitが制御フローに影響を与えるという理解（ @HeroicKatoraのメモに?よりもはるかに弱い意味で）は、 awaitという単語から流れます。

@Centril

これには、現在の実際のキーワードではなく、コンテキストキーワードを待機させる必要があります。 私たちはそうすべきではないと思います。

イーク。 それは少し痛いです。 おそらく、マクロは.wait!()や.awaited!()ような別の名前を持つ可能性があります（後者は、前の式に適用されることが明確になるため、非常に便利です）。

「これを組み合わせると、コンパイラの魔法なしで接尾辞.await！（）マクロを実装できます。」
これは、foo awaitまたはfoo.await（特に後者）よりも実装的に複雑なソリューションです。 それと同じくらい、まだ「魔法」があります。 会計操作を行ったところです。

さらに、try！（..）は、コンパイラーのサポートなしで定義されています。

また、プレフィックスawaitキーワードとポストフィックスマクロがある場合、 .await!() （おそらく別の名前）もコンパイラサポートなしで実装できますよね？ もちろん、 awaitキーワード自体には、かなりの量のコンパイラマジックが必要ですが、それは単にマクロの結果に適用され、 try!()との関係と同じです。 returnキーワード。

後で.await！（）を追加する場合は、ユーザーに学習内容を提供するだけで（await fooとfoo.await！（）の両方）、ユーザーは「いつどちらを使用すればよいか」と尋ねます。 これは、単一のソリューションのようにfooawaitまたはfoo.awaitよりも複雑さの予算を使い果たしているようです。

これがユーザーに追加

「Rustの未来を待つには、 await foo.bar();とfoo.bar().await!() 2つの方法があります。どちらを使用するかは文体の好みであり、実行フローに違いはありません。」

「開かれた可能性を残す」ことには価値がありません。 構成、IDEエクスペリエンスなどの接尾辞の価値は、今日知られています。

それは本当です。 私の考えでは、私たちの実装が将来、より統一された言語を持つ可能性を閉じないようにすることがより重要だと思います。

これが何を意味するのかわかりません。

それほど重要ではありません。 しかし、一般的には、構文が明確で、強調表示が適切でない場合にも、私はそれを好みます。 したがって、 git diffやその他のそのようなコンテキストでは物事が際立っています。

理論的にはそうです、そして些細なプログラムについてはそうですが、実際にはプログラマー
それらのサスペンドポイントがどこにあるかを知る必要があります。

簡単な例として、サスペンドポイントを越えてRefCellを保持し、
プログラムの動作は、RefCellがあった場合とは異なります。
サスペンドポイントの前にリリースされます。 大規模なプログラムでは
このような無数の微妙な点、現在の機能が
一時停止は重要な情報です。

14:21 HeroicKatoraで水曜日、2019年1月23日には[email protected]
書きました：

@joshtripletthttps ：//github.com/joshtriplettコントロールには影響しません
標準的な意味での流れ。 これは、それを正当化するための基本的な事実です
借り入れチェッカーは、定義されているように先物で機能するはずです。 の観点から
ローカル関数の実行、awaitの実行は、他の関数呼び出しと同じです。

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/rust-lang/rust/issues/57640#issuecomment-456989262 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/ABGmeqcr2g4olxQhH9Fb9r6g3XRaFUu2ks5vGOBkgaJpZM4aBlba
。

2019年1月23日水曜日02:26:07 PM -0800に、MazdakFarrokhzadは次のように書いています。

.await!()を使用する主な理由は、マクロのように見えることで、制御フローに影響を与える可能性があることが明らかになるためです。

.awaitはフィールドアクセスのように見え、 .await()は関数呼び出しのように見え、フィールドアクセスも関数呼び出しも制御フローに影響を与えることはできません。

区別は、ユーザーが比較的簡単に学ぶことができるものだと思います

なぜ彼らはしなければならないのですか？

この区別は、特に.awaitの後に通常は？が続くため、ユーザーが比較的簡単に学習できるものだと思います。 （これは関数ローカル制御フローです）。

多くの場合、そうですが、常にではありません。構文は、そうでない場合でも確実に機能するはずです。

関数呼び出しに関しては、前述のように、イテレータメソッドは制御フローの一形態であると言っても過言ではありません。

returnまたは? （またはbreak ）と同じ方法ではありません。 関数呼び出しがそれを呼び出した関数から2レベル戻ることができるか（Rustに例外がない理由の1つは、これが驚くべきことであるという理由だけです）、または呼び出しのループから抜け出すことができれば、非常に驚くでしょう。関数。

さらに、マクロが制御フローに影響を与える可能性があるからといって、それが影響を与えるとは限りません。 多くのマクロはそうではありません（例えば、dbg！、format！、...）。 .await！（）または.awaitが制御フローに影響を与えるという理解（ @HeroicKatoraのメモによると？よりもはるかに弱い意味で）は、awaitという単語自体から流れます。

私はこれがまったく好きではありません。 制御フローに影響を与えることは、非常に重要な副作用です。 通常これを行うことができないコンストラクトとは異なる構文形式を持つ必要があります。 Rustでこれを実行できる構造は、キーワード（ return 、 break 、 continue ）、演算子（ ? ）、およびマクロ（1つに評価することによる）です。他の形式の）。 例外を追加して水を濁らせるのはなぜですか？

@ejmahler通常の関数呼び出しと比較して、RefCellの保持がどのように異なるかわかりません。 また、内部関数が同じRefCellを取得したい場合もあります。 しかし、潜在的なコールグラフ全体をすぐに把握できないという大きな問題を抱えている人はいないようです。 同様に、スタックの枯渇に関する問題は、提供されたスタックスペースに注釈を付ける必要があるという特別な懸念はありません。 ここでの比較はコルーチンにとって有利です！ インライン化されていない場合、通常の関数呼び出しをより見やすくする必要がありますか？ ライブラリに関するこのますます困難になる問題を把握するには、明示的な末尾呼び出しが必要ですか？

答えは、私見ですが、RefCellを使用して待つときの最大のリスクは不慣れです。 上記の他の問題をハードウェアから抽象化できる場合、プログラマーとしての私たちも、精査された場合を除いて、歩留まりポイント全体でRefCellなどを保持しないことを学ぶことができると信じています。

2019年1月23日水曜日、午後10時30分10秒+0000に、エリオットマーラーは次のように書いています。

理論的にはそうです、そして些細なプログラムについてはそうですが、実際にはプログラマー
それらのサスペンドポイントがどこにあるかを知る必要があります。

：+1：

@HeroicKatora

重要な違いは、検査する必要のあるコードの量、数です
あなたが説明しなければならない可能性。 プログラマーはすでに慣れています
彼らが呼び出すものが、チェックしたRefCellも使用していないことを確認します
アウト。 しかし、待っていると、単一の呼び出しスタックを検査する代わりに、
待機中に実行される内容の制御-文字通り、
プログラムが実行される可能性があります。 私の直感によると、平均的なプログラマーは
この可能性の爆発に対処するための設備がはるかに少ないため、
それほど頻繁に対処する必要はありません。

ゲーム内の重要な情報であるサスペンドポイントの別の例については
プログラミングでは、通常、再開することを目的としたコルーチンを作成します
フレームごとに1回、履歴書ごとにゲームの状態を変更します。 見落としたら
これらのコルーチンの1つでポイントを一時停止すると、ゲームが壊れたままになる可能性があります
複数のフレームの状態。

これらはすべて、「賢くなり、少なくする」と言うことで対処できます。
もちろん間違い」ですが、そのアプローチは歴史的には機能しません。

14:44ジョシュ・トリプレットで水曜日、2019年1月23日には[email protected]
書きました：

2019年1月23日水曜日、午後10時30分10秒+0000に、エリオットマーラーは次のように書いています。

理論的にはそうです、そして些細なプログラムについてはそうですが、実際にはプログラマー
それらのサスペンドポイントがどこにあるかを知る必要があります。

：+1：

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/rust-lang/rust/issues/57640#issuecomment-456995913 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/ABGmep05nhZizdE5xil4FsnpONJCxqn-ks5vGOXhgaJpZM4aBlba
。

重要な情報であるサスペンドポイントの別の例として、ゲームプログラミングでは、通常、フレームごとに1回再開することを目的としたコルーチンを記述し、再開するたびにゲームの状態を変更します。 これらのコルーチンの1つでサスペンドポイントを見落とすと、ゲームが複数のフレームで壊れた状態のままになる可能性があります。

キーをSlotMapにドロップすると、メモリがリークします。 言語自体は、本質的にこれを支援しません。 私が言いたいのは、待機が漠然と十分に見えないというあなたの例（それがキーワードである限り、その発生は一意である）は、他の機能では発生していない問題に一般化されていないようです。 言語がすぐに提供する機能については、待つのではなく、独自の機能を表現できるようにする方法について評価する必要があると思います。 ツールを評価してから適用します。 ゲームの状態の解決策を提案し、これに十分に対処する方法：ゲームの状態が実際に必要な量をチェックしたことを返すラッパーを作成します。非同期を使用すると、その原因のために独自の状態を借用できます。 その区分化されたコードで他の人が待っていることを禁止します。

RefCellの状態の急増は、他の場所で使用されていないことを確認しなかったためではなく、その不変条件に依存していることを知らず、サイレントに追加した他のコードポイントから発生します。 これらは同じ方法で対処され、ドキュメント、コメント、正しいラッピングです。

RefCell保持することは、ioをブロックするときにMutexすることと大差ありません。 パニックよりもデバッグが難しく、デバッグが難しいデッドロックが発生する可能性があります。 それでも、明示的なblockキーワードでブロッキング操作に注釈を付けることはありません。 :)。

非同期関数間でRefCell共有すると、一般的なユーザビリティ（ !Send ）が大幅に制限されるため、一般的ではないと思います。 また、 RefCellは一般的に避け、使用する場合はできるだけ短時間借りる必要があります。

ですから、誤って降伏点を超えてRefCell手に入れることは大したことではないと思います。

これらのコルーチンの1つでサスペンドポイントを見落とすと、ゲームが複数のフレームで壊れた状態のままになる可能性があります。

コルーチンと非同期関数は別のものです。 yield暗黙的にしようとしているのではありません。

ここで、キーワード構文ではなくマクロ構文を好む人へ：マクロである必要があることを意味するawaitについて説明してください。また、たとえば、 whileとはどのように違うのかを説明してください。ただwhile!マクロmacro_rules!だけを使用しても、特別な大文字小文字はまったく使用しません）。

編集：これはレトリックではありません。 私は本当にそのようなことに興味があります。私が最初に待つことを望んでいたのと同じように（C＃のように）、RFCはそうではないと私に確信させました。

ここで、キーワード構文ではなくマクロ構文を好む人へ：それがマクロであるべきであることを意味するawaitとは何か、そしてそれが、たとえば、しばらくの間だったかもしれないwhileとどのように違うのかを説明してください！ マクロ（macro_rulesだけを使用しても！;特別なケースはまったくありません）。

私はこの推論にほぼ同意します。プレフィックス構文にキーワードを使用したいと思います。

ただし、上記で概説したように（https://github.com/rust-lang/rust/issues/57640#issuecomment-456990831）、接尾辞構文用の接尾辞マクロ（おそらく.awaited!()も使用することに賛成です.awaited!()は、名前がプレフィックスキーワードと衝突しないようにします）。 私の考えは、一方向にしか使用できないキーワードを使用することで物事が簡単になり、マクロのバリエーションがさらに節約されるということもありますが、主に私が見る限り、誰も接尾辞を思い付くことができませんでした私が受け入れられると思うキーワード構文：

• foo.bar().awaitとfoo.bar().await()は技術的にはキーワードですが、フィールドアクセスまたはメソッド呼び出しのように見え、このような制御フロー変更構造をこのように非表示にする必要はないと思います。
• foo.bar() awaitは、特にfoo.bar() await.qux()ようなさらなる連鎖では、混乱を招きます。 私はそのような接尾辞として使用されるキーワードを見たことがありません（それらが存在することは確かですが、実際には、このように機能するキーワードについて知っている言語での単一の例を考えることはできません）。 そして、私はのawaitが適用されるかのように、それは非常に紛らわしい読み込みと思いますqux()ませんfoo.bar() 。
• foo.bar()@awaitまたはその他の句読点が機能する可能性があります。 しかし、それは特にいいことではなく、かなりアドホックな感じがします。 私は実際、この構文に重大な問題はないと思います（上記のオプションとは異なります）。 シジルを追加し始めると、バランスがカスタム構文を放棄し、それがマクロになる方向に傾くように感じます。

新しい考えや考慮事項を微調整しましたが、以前のアイデアをもう一度繰り返します。その後、沈黙を守ろうとします。

キーワードとしてのawaitは、とにかくasync関数内でのみ有効であるため、他の場所で識別子awaitを許可する必要があります。 変数の名前がawait外側の範囲には、内からアクセスすることができないasyncそれが生の識別子として使用されていない限りブロック。 または、たとえば、 await!マクロ。

さらに、そのようなキーワードを適応させることで、私の要点が可能になります。次のように、ジェネレーターと非同期関数の混合とマッチングを許可する必要があります。

// 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);
}

これは、ファンキーなことをしたい非常に上級のユーザーには十分に透過的であると思いますが、新規および中程度のユーザーは必要なものだけを使用できます。 2と3は、 yieldステートメントなしで使用した場合、実質的に同じです。

また、プレフィックスawait?は、非同期操作の結果に?を追加するための優れた省略形だと思いますが、これは必ずしも必要ではありません。

postfixマクロが公式のものになった場合（私はそうなることを願っています）、 await!(...)と.await!()両方が一緒に存在する可能性があり、特定のユースケースとスタイルに対して、3つの同等の待機方法が可能になります。 これが認知的オーバーヘッドを追加するとは思わないが、より大きな柔軟性を可能にするだろう。

理想的には、 async fnと#[async] fn*は、基盤となるジェネレーターを非同期ステートマシンに変換するための実装コードを共有することさえできます。

これらの問題により、真に好ましいスタイルは1つもないことが明らかになりました。そのため、私が期待できる最善の方法は、クリーンで柔軟性があり、読みやすく、複雑さのレベルに簡単にアプローチできるようにすることです。 上記のスキームは将来の良い妥協点だと思います。

キーワードとしてのawaitは、とにかくasync関数内でのみ有効であるため、識別子を他の場所で待機できるようにする必要があります。

衛生的なマクロを考えると、それがRustで実用的かどうかはわかりません。 私が呼び出す場合foo!(x.await)またはfoo!(await { x })それが望んでいるときexpr 、私はあることの明白なされるべきだと思うawaitない-望まれるキーワードawaitフィールドまたはawait構造体リテラル式とフィールド初期化の省略形-同期メソッドでも。

3つの同等の方法で待機できます

いいえ、お願いします。 （少なくともcore 。明らかに、人々は自分のコードでマクロを作成できます。必要に応じて）

現時点では、接尾辞.await！（）マクロにはコンパイラの魔法が必要です。 ただし、awaitキーワードのプレフィックスバリアントが安定化されている場合、これは当てはまりません。postfix.await！（）マクロは、引数（式）の前にawaitキーワードを付けてラップするマクロとして簡単に実装できます。括弧内のすべて。

これも同様に当てはまりますが、簡単です。 -逆の方向： .awaitキーワード構文を安定させると、接尾辞が十分に嫌いな場合は、すでにawaited!()プレフィックスマクロを作成できます。

複数の許可されたバリアント（プレフィックスやポストフィックスなど）を追加するというアイデアは嫌いですが、ユーザーが尋ねる理由とは少し異なります。 私はかなり大きな会社で働いており、コードスタイルをめぐる争いは本物です。 明確で正しいフォームを1つだけ使用したいと思います。 結局のところ、この点に関してはpythonのZenが正しいかもしれません。

複数の許可されたバリアント（プレフィックスやポストフィックスなど）を追加するというアイデアは嫌いですが、ユーザーが尋ねる理由とは少し異なります。 私はかなり大きな会社で働いており、コードスタイルをめぐる争いは本物です。 明確で正しいフォームを1つだけ使用したいと思います。 結局のところ、この点に関してはpythonのZenが正しいかもしれません。

あなたが言っていることがわかります。 ただし、プログラマーがawait!()ようなことを行う独自のマクロを定義するのを止める方法はありません。 似たような構造体は常に可能です。 とにかく実際にはさまざまなバリエーションがあります。

まあ、少なくともそれはエラーになるので、 await!(...)ではありません。 しかし、ユーザーがmacro_rules! wait { ($e:expr) => { e.await }; }を定義し、それをwait!(expr)として使用すると、明らかに単調に見え、すぐに時代遅れになる可能性があります。 これにより、エコシステムの変動の可能性が大幅に減少し、ユーザーが学習するスタイルが少なくなります。 したがって、 @ yasammezのポイントは適切だと思います。

@Centril誰かが悪いことをしたいのなら、彼らはほとんど止められません。 _await!()またはawai!()どうですか？

または、Unicode識別子が有効になっている場合は、 àwait!()ます。

..。

@earthengine目標は、さまざまな人々が故意に奇妙なことをするのを防ぐことではなく、コミュニティの規範を設定することです（スタイルリントやrustfmt行うのと同様）。 ここでは確率を扱っていますが、 _await!()されないという絶対的な保証ではありません。

各接尾辞構文の引数を要約して確認しましょう。

• __ expr await （postfixキーワード）__：Postfixキーワード構文は、すでに予約したawaitキーワードを使用します。 Awaitは魔法のような変化であり、キーワードを使用すると、それを適切に目立たせることができます。 フィールドアクセスやメソッドまたはマクロ呼び出しのようには見えないので、これを例外として説明する必要はありません。 これは、現在の解析ルールおよび?演算子によく適合します。 メソッドチェーンのスペースは、何らかの形で受け入れられる可能性が高いRFCであるGeneralized TypeAscriptionよりも間違いなく悪くありませawaitオートコンプリートを提供するためにさらに魔法をかける必要があるかもしれません。 特にawaitが各行を終了するようにコードがフォーマットされていない場合、メソッドチェーンのスペースが煩わしすぎると感じるかもしれません（ @withoutboatsはそれが利点かもしれないと主張していますが）。 別のアプローチをとった場合に使用を回避できる可能性のあるキーワードを使用します。

• __ expr.await （接尾辞フィールド）__：接尾辞フィールドの構文は「ドットの力」を活用します-チェーンで自然に見え、感じ、IDEが他の操作（など）を実行せずにawaitをオートコンプリートできるようにしますドットを

• __ expr.await() （後置メソッド）__：後置メソッドの構文は後置フィールドに似ています。 逆に、 ()呼び出し構文は、「これは何かをします」と読者に示します。 ローカルで見ると、ブロッキングメソッドの呼び出しがマルチスレッドプログラムで実行されるのとほぼ同じ方法でawaitの魔法の振る舞いをメソッドとして偽装すると混乱する可能性があります。 awaitは、Schemeのcall/ccが関数であるのと同じ限定的な意味でのメソッドであると言えます。 方法として、 Future::await(expr)がUFCSと一貫して

• __ expr.await!() （接尾辞マクロ）__：接尾辞マクロ構文は、同様に「ドットの力」を活用します! bangは、「これは何か魔法をかけるかもしれない」ことを示しています。 欠点としては、これはさらにノイズが多く、マクロは魔法をかけますが、通常、 awaitように周囲のコードに魔法をかけません。 また、欠点として、汎用の接尾辞マクロ構文を標準化すると仮定すると、 awaitをキーワードとして扱い続けることに問題が生じる可能性があり

• __ expr@ 、 expr# 、 expr~ 、およびその他の単一文字記号__： ?場合と同様に単一文字を使用すると、簡潔さが最大化され、おそらく接尾辞の構文が作成されます。より自然に見えます。 ?同様に、 awaitがコードに浸透し始めた場合、この簡潔さに感謝するかもしれません。 欠点としては、コードにawait散らかすという苦痛が問題になるまで、そして問題にならない限り、そのような構文を採用することに固有のトレードオフについてコンセンサスが形成されるのを見るのは困難です。