Rust: async / awaitの追跡の問題（RFC 2394）

ここでの議論は終わったようですので、 await構文の質問の一部としてここにリンクします： https ：

＃50307で実装がブロックされています。

構文について：単純なキーワードとしてawaitが本当に欲しいです。 たとえば、ブログの懸念事項を見てみましょう。

awaitキーワードにどの構文が必要かは正確にはわかりません。 何かが結果の未来である場合（IOの未来のように）、それを待ってから?演算子を適用できるようにする必要があります。 しかし、これを有効にするには、優先順位は意外に思えるかもしれない- await io_future?でしょうawait第一および?にもかかわらず二、 ?辞書的に、より緊密のawaitよりも拘束されるもの。

私はここで同意しますが、中かっこは悪です。 ?優先順位はawaitよりも低く、それで終わることを覚えておく方が簡単だと思います。

let foo = await future?

読みやすく、リファクタリングも簡単です。 私はそれがより良いアプローチだと信じています。

let foo = await!(future)?

操作が実行される順序をよりよく理解できますが、読みにくくなります。

await foo?が最初にawait実行すると、問題はないと思います。 おそらく字句的にはもっと結びついていますが、 awaitは左側にあり、 ?は右側にあります。 したがって、最初にawait 、その後にResultを処理するのに十分論理的です。

意見の相違がある場合は、話し合うためにその旨を表明してください。 サイレントダウン投票が何を意味するのかわかりません。 私たちは皆、Rustに良いことを願っています。

awaitがキーワード@Pzixelであるという見方はまちまちです。 asyncがキーワードであることを考えると、それは確かに美的魅力があり、おそらくより一貫性がありますが、どの言語でも「キーワードの肥大化」は本当の関心事です。 そうは言っても、 asyncなしでawaitを使用することは、機能的にも意味がありますか？ もしそうなら、おそらく私たちはそれをそのままにしておくことができます。 そうでなければ、私はawaitをキーワードにすることに傾倒するでしょう。

?優先順位はawaitよりも低く、それで終わることを覚えておく方が簡単だと思います

それを学び、内面化することは可能かもしれませんが、触れているものは空白で区切られているものよりも緊密に結びついているという強い直感があるので、実際には常に間違って読まれるだろうと思います。

また、すべての場合に役立つわけではありません。たとえば、 Result<impl Future, _>を返す関数：

let foo = await (foo()?)?;

ここでの懸念は、単に「単一の待機+ ?の優先順位を理解できるか」だけでなく、「複数の待機を連鎖させるとどのように見えるか」でもあります。 したがって、優先順位を選択しただけでも、 await (await (await first()?).second()?).third()?問題が発生します。

await構文のオプションの要約。一部はRFCからのもので、残りはRFCスレッドからのものです。

• await { future }?またはawait(future)?ような区切り文字が必要です（これはノイズが多いです）。
• await future?または(await future)?が期待どおりに機能するように、優先順位を選択するだけです（どちらも意外な感じです）。
• 2つの演算子をawait? futureようなものに結合します（これは珍しいことです）。
• future await?やfuture.await?ように、なんとかしてawait接尾辞を作成します（これは前例のないことです）。
• future@?ように、 ?ように新しい印章を使用します（これは「ラインノイズ」です）。
• 構文をまったく使用せず、awaitを暗黙的にします（これにより、一時停止ポイントが見にくくなります）。 これが機能するためには、未来を構築する行為も明示的にされなければなりません。 これは、上記でリンクした内部スレッドの主題です。

そうは言っても、 awaitなしでasyncを使用することは、機能的にも意味がありますか？

@alexregそうです。 たとえば、Kotlinはこのように機能します。 これは「暗黙の待機」オプションです。

@rpjohnst興味深い。 ええと、私は一般的にasyncとawaitを言語の明示的な機能として残しているのです。なぜなら、それはRustの精神に基づいていると思うからですが、非同期プログラミングの専門家ではありません。 ..

@alexreg async / awaitは、C＃（私の第一言語）で日常的に使用しているので、本当に素晴らしい機能です。 @rpjohnstは、すべての可能性を非常にうまく分類しました。 私は2番目のオプションを好みます、私は他の考慮事項に同意します（騒々しい/異常な/ ...）。 私は過去5年間か何かで非同期/待機コードを扱ってきました、そのようなフラグキーワードを持つことは本当に重要です。

@rpjohnst

したがって、優先順位を選択しただけでも、await（await（await first（）？）。second（）？）。third（）?.の問題が発生します。

私の練習では、1行に2つのawait書くことはありません。 ごくまれに、必要なときにthenと書き直し、awaitをまったく使用しないでください。 あなたはそれが読むよりもはるかに難しいことを自分自身で見ることができます

let first = await first()?;
let second = await first.second()?;
let third = await second.third()?;

ですから、主要なケースをより単純でより良いものにするために、言語がそのような方法でコードを書くことを思いとどまらせても大丈夫だと思います。

ヒーローアウェイfuture await?は見慣れないものの面白そうに見えますが、それに対する論理的な反論は見当たりません。

私の練習では、1行に2つのawait書くことはありません。

しかし、これは構文に関係なく悪い考えであるためですか、それともC＃の既存のawait構文が醜いためです。 人々はtry!() （ ?の前身）について同様の議論をしました。

接尾辞と暗黙のバージョンははるかに醜いです：

first().await?.second().await?.third().await?

first()?.second()?.third()?

しかし、これは構文に関係なく悪い考えであるためですか、それともC＃の既存のawait構文が醜いためです。

async操作ごとに1行にすることは、理解するのに十分複雑でデバッグが難しいため、構文に関係なく、これは悪い考えだと思います。 それらを単一のステートメントに連鎖させることはさらに悪いようです。

たとえば、実際のコードを見てみましょう（プロジェクトから1つ取っています）。

[Fact]
public async Task Should_UpdateTrackableStatus()
{
    var web3 = TestHelper.GetWeb3();
    var factory = await SeasonFactory.DeployAsync(web3);
    var season = await factory.CreateSeasonAsync(DateTimeOffset.UtcNow, DateTimeOffset.UtcNow.AddDays(1));
    var request = await season.GetOrCreateRequestAsync("123");

    var trackableStatus = new StatusUpdate(DateTimeOffset.UtcNow, Request.TrackableStatuses.First(), "Trackable status");
    var nonTrackableStatus = new StatusUpdate(DateTimeOffset.UtcNow, 0, "Nontrackable status");

    await request.UpdateStatusAsync(trackableStatus);
    await request.UpdateStatusAsync(nonTrackableStatus);

    var statuses = await request.GetStatusesAsync();

    Assert.Single(statuses);
    Assert.Equal(trackableStatus, statuses.Single());
}

実際には、構文で許可されていてもawaitをチェーンする価値はないことを示しています。これは、 awaitが完全に読み取り不能になるため、ワンライナーの書き込みと読み取りがさらに困難になるためですが、私はそうします。それが悪い理由はそれだけではないと信じています。

接尾辞と暗黙のバージョンははるかに醜いです

タスクの開始とタスクの待機を区別する可能性は非常に重要です。 たとえば、私はよくそのようなコードを記述します（これもプロジェクトのスニペットです）。

public async Task<StatusUpdate[]> GetStatusesAsync()
{
    int statusUpdatesCount = await Contract.GetFunction("getStatusUpdatesCount").CallAsync<int>();
    var getStatusUpdate = Contract.GetFunction("getStatusUpdate");
    var tasks = Enumerable.Range(0, statusUpdatesCount).Select(async i =>
    {
        var statusUpdate = await getStatusUpdate.CallDeserializingToObjectAsync<StatusUpdateStruct>(i);
        return new StatusUpdate(XDateTime.UtcOffsetFromTicks(statusUpdate.UpdateDate), statusUpdate.StatusCode, statusUpdate.Note);
    });

    return await Task.WhenAll(tasks);
}

ここでは、N個の非同期リクエストを作成し、それらを待機しています。 各ループの反復を待つことはありませんが、最初に非同期リクエストの配列を作成し、次にそれらすべてを一度に待ちます。

Kotlinを知らないので、どういうわけか解決するかもしれません。 しかし、タスクの「実行中」と「待機中」が同じである場合、どのように表現できるかわかりません。

したがって、暗黙のバージョンは、C＃のようなさらに多くの暗黙の言語では使用できないと思います。
u8をi32に暗黙的に変換することさえできないルールを持つRustでは、はるかに混乱します。

@Pzixelええ、2番目のオプションはより好ましいオプションの1つのように聞こえます。 私はC＃でもasync/awaitを使用しましたが、ここ数年は主にC＃でプログラミングしていないため、あまり使用していません。 優先順位に関しては、 await (future?)方が自然です。

@rpjohnst私は接尾辞演算子のアイデアが好きですが、読みやすさと人々が行う仮定についても心配しています。 structという名前のawaitメンバーにとっては簡単に混乱する可能性があります。 。

タスクの開始とタスクの待機を区別する可能性は非常に重要です。

価値があるのは、暗黙のバージョンがこれを行うことです。 RFCスレッドと内部スレッドの両方で死ぬまで議論されたので、ここではあまり詳しく説明しませんが、基本的な考え方は、タスク待機からタスク構築に明示性を移動することだけです。新しい暗黙性を導入しないでください。

あなたの例は次のようになります。

pub async fn get_statuses() -> Vec<StatusUpdate> {
    // get_status_updates is also an `async fn`, but calling it works just like any other call:
    let count = get_status_updates();

    let mut tasks = vec![];
    for i in 0..count {
        // Here is where task *construction* becomes explicit, as an async block:
        task.push(async {
            // Again, simply *calling* get_status_update looks just like a sync call:
            let status_update: StatusUpdateStruct = get_status_update(i).deserialize();
            StatusUpdate::new(utc_from_ticks(status_update.update_date), status_update.status_code, status_update.note))
        });
    }

    // And finally, launching the explicitly-constructed futures is also explicit, while awaiting the result is implicit:
    join_all(&tasks[..])
}

これが私が意味したことです。「これが機能するためには、未来を構築する行為も明確にされなければなりません」。 これは、同期コードでスレッドを操作するのと非常によく似ています。関数の呼び出しは、呼び出し元を再開する前に常に関数の完了を待機し、並行性を導入するための個別のツールがあります。 たとえば、クロージャとthread::spawn / joinは、非同期ブロックとjoin_all / select / etcに対応します。

価値があるのは、暗黙のバージョンがこれを行うことです。 RFCスレッドと内部スレッドの両方で死ぬまで議論されたので、ここではあまり詳しく説明しませんが、基本的な考え方は、タスク待機からタスク構築に明示性を移動することだけです。新しい暗黙性を導入しないでください。

そうだと思います。 この関数でどのようなフローが発生するかはわかりません。ここで、待機が完了するまで実行が中断されます。 「こんにちは、ここのどこかに非同期関数があります。どれを見つけてみてください。驚かれることでしょう！」というasyncブロックしか表示されません。

もう1つのポイント：錆は、ベアメタルに近いなど、すべてを表現できる言語になる傾向があります。 かなり人工的なコードを提供したいのですが、それはその考えを示していると思います。

var a = await fooAsync(); // awaiting first task
var b = barAsync(); //running second task
var c = await bazAsync(); // awaiting third task
if (c.IsSomeCondition && !b.Status = TaskStatus.RanToCompletion) // if some condition is true and b is still running
{
   var firstFinishedTask = await Task.Any(b, Task.Delay(5000)); // waiting for 5 more seconds;
   if (firstFinishedTask != b) // our task is timeouted
      throw new Exception(); // doing something
   // more logic here
}
else
{
   // more logic here
}

さびは常に何が起こっているかを完全に制御する傾向があります。 await使用すると、継続プロセスを実行するポイントを指定できます。 また、future内の値をunwrapすることもできます。 使用側で暗黙的な変換を許可する場合、いくつかの影響があります。

1. まず、この動作をエミュレートするために、ダーティなコードを作成する必要があります。
2. これで、RLSとIDEは、値がFuture<T>か、 T自体が待機していることを期待する必要があります。 キーワードの問題ではありません。存在する場合、結果はTになります。それ以外の場合Future<T>
3. コードを理解しにくくします。 あなたの例では、なぜそれがget_status_updates行で実行を中断するのかわかりませんが、 get_status_updateでは実行されません。 それらは互いに非常に似ています。 そのため、元のコードのように機能しないか、非常に複雑であるため、主題に精通していても表示されません。 どちらの方法でも、このオプションは有利にはなりません。

この関数でどのようなフローが発生するかはわかりません。ここで、待機が完了するまで実行が中断されます。

はい、これは私が「サスペンションポイントが見づらくなる」という意味です。 リンクされた内部スレッドを読んだら、なぜこれがそれほど大きな問題ではないのかについて議論しました。 新しいコードを記述する必要はありません。注釈を別の場所に配置するだけです（ await ed式の代わりにasyncブロック）。 IDEは、タイプが何であるかを問題なく認識します（関数呼び出しの場合は常にTであり、 asyncブロックの場合はFuture<Output=T>です）。

また、構文に関係なく、あなたの理解はおそらく間違っていることに注意します。 Rustのasync関数は、何らかの方法で待機するまでコードをまったく実行b.Status != TaskStatus.RanToCompletionチェックは常に合格します。 これがこのように機能する理由に興味がある場合は、RFCスレッドでこれについても議論されました。

あなたの例では、なぜそれがget_status_updates行で実行を中断するのかわかりませんが、 get_status_updateでは実行されません。 それらは互いに非常に似ています。

これは、両方の場所での割り込み実行を行います。 重要なのは、 asyncブロックは、待機するまで実行されないということです。これは、前述したように、Rustのすべての先物に当てはまるためです。 私の例では、 get_statusesはget_status_updates get_statuses呼び出し（したがって待機し）、ループ内でcount先物を構築します（ただし待機しません）。次に呼び出します（したがって待機します）。 ） join_all 、その時点でそれらの先物は同時にget_status_update呼び出します（したがって待機します）。

あなたの例との唯一の違いは、先物が実行を開始するときです-あなたの中で、それはループの間にあります。 私の場合、それはjoin_allます。 しかし、これはRust先物が機能する基本的な部分であり、暗黙の構文やasync / awaitはまったく関係ありません。

また、構文に関係なく、あなたの理解はおそらく間違っていることに注意します。 Rustの非同期関数は、何らかの方法で待機されるまでコードをまったく実行しないため、b.Status！= TaskStatus.RanToCompletionチェックは常に合格します。

はい、C＃タスクは最初の一時停止ポイントまで同期的に実行されます。 ご指摘いただきありがとうございます。
ただし、メソッドの残りの部分を実行している間、バックグラウンドでいくつかのタスクを実行し、バックグラウンドタスクが終了したかどうかを確認できるはずなので、実際には問題ではありません。 たとえば、

var a = await fooAsync(); // awaiting first task
var b = Task.Run(() => barAsync()); //running background task somehow
// the rest of the method is the same

私はasyncブロックについてあなたの考えを持っています、そして私が見るようにそれらは同じ獣ですが、より多くの不利な点があります。 元の提案では、各非同期タスクはawaitとペアになっています。 asyncブロックを使用すると、各タスクは構築ポイントでasyncブロックとペアになるため、以前とほぼ同じ状況（1：1の関係）になりますが、コールサイトの動作はコンテキストに依存するため、より不自然で理解しにくくなります。 待っていると、 let a = foo()またはlet b = await foo() 、このタスクが作成されたか、作成されて待機していることがわかります。 let a = foo()とasyncブロックが表示された場合、上にasyncがあるかどうかを確認する必要があります。この場合は、正しいと思います。

pub async fn get_statuses() -> Vec<StatusUpdate> {
    // get_status_updates is also an `async fn`, but calling it works just like any other call:
    let count = get_status_updates();

    let mut tasks = vec![];
    for i in 0..count {
        // Here is where task *construction* becomes explicit, as an async block:
        task.push(async {
            // Again, simply *calling* get_status_update looks just like a sync call:
            let status_update: StatusUpdateStruct = get_status_update(i).deserialize();
            StatusUpdate::new(utc_from_ticks(status_update.update_date), status_update.status_code, status_update.note))
        });
    }

    // And finally, launching the explicitly-constructed futures is also explicit, while awaiting the result is implicit:
    join_all(&tasks[..])
}

ここですべてのタスクを一度に待っています

pub async fn get_statuses() -> Vec<StatusUpdate> {
    // get_status_updates is also an `async fn`, but calling it works just like any other call:
    let count = get_status_updates();

    let mut tasks = vec![];
    for i in 0..count {
        // Isn't "just a construction" anymore
        task.push({
            let status_update: StatusUpdateStruct = get_status_update(i).deserialize();
            StatusUpdate::new(utc_from_ticks(status_update.update_date), status_update.status_code, status_update.note))
        });
    }
    tasks 
}

私たちはそれらを1つずつ実行しています。

したがって、この部分の正確な動作は何であるかを言うことはできません。

let status_update: StatusUpdateStruct = get_status_update(i).deserialize();
StatusUpdate::new(utc_from_ticks(status_update.update_date), status_update.status_code, status_update.note))

より多くのコンテキストを持たずに。

そして、ネストされたブロックで物事はより奇妙になります。 工具などに関する質問は言うまでもありません。

コールサイトの動作はコンテキストに依存するようになります

これは、通常の同期コードとクロージャではすでに当てはまります。 例えば：

// Construct a closure, delaying `do_something_synchronous()`:
task.push(|| {
    let data = do_something_synchronous();
    StatusUpdate { data }
});

vs

// Execute a block, immediately running `do_something_synchronous()`:
task.push({
    let data = do_something_synchronous();
    StatusUpdate { data }
});

完全な暗黙の待機提案から注意する必要があるもう1つのことは、 asyncコンテキストからasync fn呼び出すことができないことです。 つまり、関数呼び出し構文some_function(arg1, arg2, etc)は、 some_functionがasyncであるかどうかに関係なく、呼び出し元が続行する前に常にsome_functionの本体を実行して完了します。 したがって、 asyncコンテキストへのエントリは常に明示的にマークされ、関数呼び出しの構文は実際にはより一貫性があります。

await構文について：メソッド構文を持つマクロはどうですか？ 私はこれを可能にするため、実際のRFCを見つけることができませんが、私はいくつかの議論（見つけた1 、 2アイデアは前例のないではありませんので、redditの上を）。 これにより、 await 、キーワードにすることなく、またはこの機能のみに新しい構文を導入することなく、接尾辞の位置で機能することができます。

// Postfix await-as-a-keyword. Looks as if we were accessing a Result<_, _> field,
// unless await is syntax-highlighted
first().await?.second().await?.third().await?
// Macro with method syntax. A few more symbols, but clearly a macro invocation that
// can affect control flow
first().await!()?.second().await!()?.third().await!()?

モナドの構成を単純化するScala-worldのライブラリがあります： http ：

たぶん、いくつかのアイデアはRustにとって興味深いものです。

ドキュメントからの引用：

ほとんどの主流言語は、async / awaitイディオムを使用した非同期プログラミングをサポートしているか、それを実装しています（F＃、C＃/ VB、Javascript、Python、Swiftなど）。 便利ですが、async / awaitは通常、非同期計算（Task、Futureなど）を表す特定のモナドに関連付けられています。

このライブラリは、async / awaitに似たソリューションを実装しますが、任意のモナドタイプに一般化されています。 この一般化は、一部のコードベースが非同期計算にFutureに加えてTaskなどの他のモナドを使用することを考慮すると主要な要因です。

モナドM与えられた場合、一般化では、通常の値をモナドに持ち上げ（ T => M[T] ）、モナドインスタンスから値を持ち上げない（ M[T] => T ）という概念を使用します。 >使用例：

lift {
  val a = unlift(callServiceA())
  val b = unlift(callServiceB(a))
  val c = unlift(callServiceC(b))
  (a, c)
}

リフトは非同期に対応し、リフトを解除して待機することに注意してください。

これは、通常の同期コードとクロージャではすでに当てはまります。 例えば：

ここにいくつかの違いがあります。

1. Lambdaコンテキストは避けられませんが、 awaitはありません。 awaitの場合、コンテキストはありません。 async場合、コンテキストが必要です。 前者は同じ機能を提供しますが、コードについてあまり知る必要がないため、勝ちます。
2. ラムダは短く、多くても数行である傾向があるため、全身を一度に見ることができ、シンプルです。 async関数は非常に大きく（通常の関数と同じくらい大きい）、複雑な場合があります。
3. ラムダがネストされることはめったにありません（ then呼び出しを除きますが、 awaitが提案されています）。 asyncブロックは頻繁にネストされます。

完全な暗黙のawait提案から注意しなければならないもう1つのことは、非同期コンテキストから非同期fnsを呼び出すことができないということです。

うーん、気づかなかった。 私の練習では、非同期コンテキストから非同期を実行したいことが多いので、それは良く聞こえません。 C＃では、 asyncは、コンパイラが関数本体を書き換えることを可能にする単なるキーワードであり、関数インターフェイスにはまったく影響しないため、 async Task<Foo>とTask<Foo>は完全に交換可能であり、実装とAPIを切り離します。

asyncタスクをブロックしたい場合があります。たとえば、 mainからネットワークAPIを呼び出したい場合などです。 ブロックする必要があります（そうでない場合は、OSに戻り、プログラムが終了します）が、非同期HTTPリクエストを実行する必要があります。 mainをハッキングして非同期にする以外に、どのような解決策があるのか​​わかりません。また、非同期のメインから呼び出せない場合は、 Resultメインリターンタイプを使用します。 。

現在のawaitを支持する別の考慮事項は、他の一般的な言語でどのように機能するかです（ @fdietzeで示されてい

ここにいくつかの違いがあります

また、メインRFCにはすでにasyncブロックがあり、暗黙的なバージョンと同じセマンティクスを持っていることも理解しておく必要があります。

私の練習では、非同期コンテキストから非同期を実行したいことが多いので、それは良く聞こえません。

これは問題ではありません。 asyncコンテキストでもasyncブロックを使用でき（通常どおりF: Futureと評価されるため、これで問題ありません）、先物でスポーンまたはブロックできます。以前とまったく同じAPIを使用します。

async fn呼び出すことはできませんが、代わりにasyncブロックでそれらへの呼び出しをラップします- F: Futureが必要な場合は、現在のコンテキストに関係なく行います。

asyncは、コンパイラが関数本体を書き換えることを可能にする単なるキーワードであり、関数インターフェイスにはまったく影響しません。

はい、これは提案間の正当な違いです。 内部スレッドでもカバーされていました。 おそらく、2つのインターフェースが異なると便利です。これは、 async fnバージョンでは構築の一部としてコードが実行されないのに対し、 -> impl Futureバージョンではリクエストを開始してからリクエストを送信できることを示しているためです。 F: Future 。 また、 async fnは、通常のfnの整合性が高くなります。つまり、 -> Tとして宣言されたものを呼び出すと、それがそうであるかどうかに関係なく、常にTが得られます。 async 。

（また、ルーストに間にかなりの飛躍まだあることに注意してくださいasync fnとFuture RFCで説明したように-returningバージョンは、。 async fnバージョンは言及しませんFutureは署名のどこにでもあり、手動バージョンにはimpl Traitが必要ですが、これには生涯に関するいくつかの問題があります。これは、実際、 async fn動機の一部です。そもそも

C＃/ TypeScript / JS / Pythonなどの他の言語からの移行が容易になります

これは、Rustではそれ自体でかなり問題となるリテラルawait future構文の場合にのみ利点です。 それ以外の場合も、これらの言語との不一致がありますが、暗黙の待機には、少なくともa）Kotlinとの類似点、およびb）同期スレッドベースのコードとの類似点があります。

はい、これは提案間の正当な違いです。 内部スレッドでもカバーされていました。 間違いなく、2つのインターフェイスが異なると便利です

APIを実装の詳細に依存させることは私には良くないように思われるので、_ 2つのインターフェースが異なることにはいくつかの利点がある_と思います。 たとえば、内部の未来への呼び出しを単に委任する契約を書いている

fn foo(&self) -> Future<T> {
   self.myService.foo()
}

そして、ログを追加したいだけです

async fn foo(&self) -> T {
   let result = await self.myService.foo();
   self.logger.log("foo executed with result {}.", result);
   result
}

そしてそれは壊滅的な変化になります。 うわあ？

これは、Rustではそれ自体でかなり問題となるリテラルawaitfuture構文の場合にのみ利点です。 それ以外の場合も、これらの言語との不一致がありますが、暗黙の待機には、少なくともa）Kotlinとの類似点、およびb）同期スレッドベースのコードとの類似点があります。

これは、 await構文、 await foo / foo await / foo@ / foo.await / ...の利点です。同じことですが、唯一の違いは、キーワードの代わりに前後に配置するか、印章を付けることです。

また、RFCで説明されているように、Rustでは、非同期fnとFuture-returningバージョンの間にまだかなりの飛躍があることに注意する必要があります。

私はそれを知っています、そしてそれは私をとても不安にさせます。

そしてそれは壊滅的な変化になります。

asyncブロックを返すことで、これを回避できます。 暗黙の待機提案では、例は次のようになります。

fn foo(&self) -> impl Future<Output = T> { // Note: you never could return `Future<T>`...
    async { self.my_service.foo() } // ...and under the proposal you couldn't call `foo` outside of `async` either.
}

そしてロギング付き：

fn foo(&self) -> impl Future<Output = T> {
    async {
        let result = self.my_service.foo();
        self.logger.log("foo executed with result {}.", result);
        result
    }
}

この区別を持つことに関するより大きな問題は、エコシステムが手動の将来の実装とコンビネーター（今日の唯一の方法）から非同期/待機に移行するときに発生します。 しかし、それでも、この提案により、古いインターフェースを維持し、新しい非同期インターフェースを提供することができます。 たとえば、C＃はそのパターンでいっぱいです。

まあ、それは合理的に聞こえます。

ただし、そのような暗黙性（ここでfoo()が非同期または同期機能であるかどうかはわかりません）は、COM +などのプロトコルで発生したのと同じ問題を引き起こし、WCFが実装された理由であると私は信じています。 非同期リモートリクエストが単純なメソッド呼び出しのように見えると、人々は問題を抱えていました。

このコードは、非同期または同期のリクエストがあるかどうかがわからないことを除いて、完全に正常に見えます。 重要な情報だと思います。 例えば：

fn foo(&self) -> impl Future<Output = T> {
    async {
        let result = self.my_service.foo();
        self.logger.log("foo executed with result {}.", result);
        let bars: Vec<Bar> = Vec::new();
        for i in 0..100 {
           bars.push(self.my_other_service.bar(i, result));
        }
        result
    }
}

barが同期関数なのか非同期関数なのかを知ることは重要です。 ループ内のawaitは、負荷とパフォーマンス全体を改善するためにこのコードを変更する必要があることを示すマーカーとしてよく見られます。 これは私が昨日レビューしたコードです（コードは最適ではありませんが、レビューの反復の1つです）：

ご覧のとおり、ここでループが待機していることに簡単に気づき、変更するように依頼しました。 変更がコミットされると、ページの読み込みが3倍高速化されました。 awaitなければ、私はこの不正行為を簡単に見落とすことができました。

Kotlinを使用したことがないことは認めますが、前回その言語を調べたときは、機械的に相互に簡単に翻訳できるようになるまで、ほとんどの場合、構文が少ないJavaのバリアントのようでした。 また、Javaの世界（構文が少し多い傾向がある）でなぜそれが好まれるのか想像できます。最近、特にJavaではないために人気が高まっていることを認識しています（Oracle対Googleの状況）。 ）。

ただし、人気と親しみやすさを考慮に入れることにした場合は、JavaScriptの機能を確認することをお勧めします。これは、明示的なawaitます。

とは言うものの、 awaitはC＃によって主流の言語に導入されました。これは、使いやすさが最も重要であると考えられていた言語の1つである可能awaitキーワードだけでなく、メソッド呼び出しのAsyncサフィックスによっても示されます。 await 、 yield returnと最も共有する他の言語機能も、コードで目立つように表示されます。

何故ですか？ 私の考えでは、ジェネレーターと非同期呼び出しは強力な構造であるため、コードで気付かれずに渡すことはできません。 制御フロー演算子の階層があります。

• ステートメントの順次実行（暗黙的）
• 関数/メソッドの呼び出し（非常に明白です。たとえば、呼び出しサイトでnullary関数と変数の間に違いがないPascalと比較してください）
• goto （大丈夫、厳密な階層ではありません）
• ジェネレーター（ yield returnは目立つ傾向があります）
• await + Asyncサフィックス

また、表現力やパワーに応じて、冗長性が低いものから冗長なものへと変化していることに注目してください。

もちろん、他の言語は異なるアプローチを取りました。 （のようにSchemeの継続call/ccからあまり違いはありません、 awaitまたはマクロ）を使用すると、呼び出しているかを示すために何の構文を持っていません。 マクロの場合、Rustはマクロを見やすくするというアプローチを取りました。

したがって、構文を少なくすること自体は望ましくなく（APLやPerlのような言語があります）、構文は単なる定型文である必要はなく、読みやすさにおいて重要な役割を果たします。

平行した議論もあります（申し訳ありませんが、ソースを思い出せませんが、言語チームの誰かから来た可能性があります）人々は新しい機能のノイズの多い構文に慣れていますが、それらが一般的に使用されるようになると、冗長性が低くなります。

await!(foo)?対await foo?の質問については、私は前のキャンプにいます。 ほとんどすべての構文を内部化できますが、間隔と近接性から手がかりを得るのに慣れすぎています。 await foo?すると、2つの演算子の優先順位を二番目に推測する可能性が高くなりますが、中括弧は何が起こっているかを明確にします。 3文字節約する価値はありません。 await!を連鎖させる方法については、一部の言語では一般的なイディオムかもしれませんが、読みやすさの悪さやデバッガーとの相互作用など、最適化する価値のない欠点が多すぎると感じています。

3文字節約する価値はありません。

私の逸話的な経験では、余分な文字（長い名前など）はそれほど問題にはなりませんが、余分なトークンは本当に迷惑になる可能性があります。 CPUの例えでは、長い名前は局所性の良い直線的なコードであり、筋肉の記憶から入力するだけですが、複数のトークン（句読点など）が含まれる場合の同じ文字数は分岐しており、キャッシュミスでいっぱいです。

（ await foo?は非常に非自明であり、回避する必要があり、さらにトークンを入力する必要があることに完全に同意します。私の観察では、すべての文字が同じように作成されるわけではありません。）

@rpjohnst代替案が「暗黙の

barが同期関数なのか非同期関数なのかを知ることは重要です。

これが、ある関数が安価か高価か、IOを実行するかどうか、またはグローバルな状態に触れるかどうかを知ることと実際に異なるかどうかはわかりません。 （これは@lnicolaの階層にも当てはまります-非同期呼び出しが同期呼び出しと同じように完了するまで実行される場合、それらはパワーの点で実際には違いはありません！）

たとえば、呼び出しがループ内にあったという事実は、それが非同期であったという事実と同じくらい重要です。 そして、並列化を正しく行うのが非常に簡単なRustでは、高価な同期ループをRayonイテレーターに切り替えることを提案することもできます。

したがって、 await要求することは、これらの最適化をキャッチするために実際にはそれほど重要ではないと思います。 ループはすでに最適化を探すのに適した場所であり、 async fnは、安価なIO同時実行性を取得できることを示す優れた指標です。 これらの機会を逃していることに気付いた場合は、たまに実行する「ループ内の非同期呼び出し」用のClippylintを作成することもできます。 同期コードにも同様のlintがあると便利です。

「明示的な非同期」の動機は、 @ lnicolaが示唆するように、単に「構文が少ない」ことではありません。 これは、関数呼び出し構文の動作をより一貫性のあるものにして、 foo()常にfooの本体を最後まで実行するようにするためです。 この提案では、アノテーションを省略すると、並行性の低いコードが得られます。これは、事実上すべてのコードがすでに動作している方法です。 「explicitawait」では、注釈を省略すると、偶発的な同時実行、または少なくとも偶発的なインターリーブが発生しますが、

あなたの代替案は、「暗黙の待機」ではなく「明示的な非同期」として提示された場合、わずかに良い受信になる可能性があると思います:-)

スレッドの名前は「明示的な将来の構築、暗黙的な待機」ですが、後者の名前は固執しているようです。 ：P

これが、ある関数が安価か高価か、IOを実行するかどうか、またはグローバルな状態に触れるかどうかを知ることと実際に異なるかどうかはわかりません。 （これは@lnicolaの階層にも当てはまります-非同期呼び出しが同期呼び出しと同じように完了するまで実行される場合、それらはパワーの点で実際には違いはありません！）

これは、関数がいくつかの状態を変更することを知っているのと同じくらい重要だと思います。また、呼び出し側と呼び出し側の両方にmutキーワードがあります。

「明示的な非同期」の動機は、 @ lnicolaが示唆するように、単に「構文が少ない」ことではありません。 これは、関数呼び出し構文の動作をより一貫性のあるものにして、foo（）が常にfooの本体を最後まで実行するようにするためです。

一方では、それは良い考慮事項です。 もう1つは、将来の作成と将来の実行を簡単に分離できます。 つまり、 fooが抽象化を返し、 runを呼び出して結果を得る場合、 fooは何もしない無駄なゴミにはなりませんが、非常に効果的です。便利なこと：後でメソッドを呼び出すことができるオブジェクトを構築します。 違いはありません。 私たちが呼び出すfooメソッドは単なるブラックボックスであり、そのシグネチャFuture<Output=T> 、実際には未来が返されます。 したがって、必要に応じて明示的にawaitします。

スレッドの名前は「明示的な将来の構築、暗黙的な待機」ですが、後者の名前は固執しているようです。 ：P

私は個人的に、より良い代替案は「明示的な非同期の明示的な待機」であると考えています:)

PS

私も今夜の考えに見舞われました：C＃LDMと通信しようとしましたか？ たとえば、 @ HaloFour 、 @ gafter 、 @ CyrusNajmabadiなどです。 なぜ彼らが取った構文を取ったかを彼らに尋ねることは本当に良い考えかもしれません。 他の言語の人にも聞いてみることを提案したいのですが、私は彼らを知らないだけです:)彼らは既存の構文について複数の議論をしていて、すでに多くの議論をすることができ、いくつかの有用なアイデアを持っているかもしれません。

C＃が持っているので、Rustがこの構文を持っている必要があるという意味ではありませんが、それはより重みのある決定をすることを可能にするだけです。

私は個人的に、より良い代替案は「明示的な非同期の明示的な待機」であると考えています:)

主な提案は「明示的な非同期」で暗黙の非同期」です。 Futureが署名のどこにも表示されていなくても、注釈のない関数呼び出しは、それを待たずに未来を構築している可能性があります。

価値があるのは、内部スレッドに「明示的な非同期明示的な待機」の代替手段が含まれていることです。これは、どちらの主要な代替手段とも将来互換性があるためです。 （最初の投稿の最後のセクションを参照してください。）

C＃LDMと通信しようとしましたか？

メインRFCの作者はそうしました。 私が覚えている限り、そこから生まれた主なポイントは、 async fnの署名にFutureを含めないという決定でした。 C＃では、 Taskを他のタイプに置き換えて、関数の駆動方法をある程度制御できます。 しかし、Rustでは、そのようなメカニズムはありません（そしてありません）。すべての先物は単一の特性を通過するため、毎回その特性を書き出す必要はありません。

また、Dart言語の設計者とも連絡を取り、それが「明示的な非同期」の提案を作成する動機の大部分でした。 Dart 1には問題がありました。これは、呼び出されたときに関数なかったため（Rustの動作とはまったく同じではありませんが、類似しています）、Dart 2で変更されたため、関数が最初の待機状態まで実行されるという大きな混乱を引き起こしました。呼び出されたら待ちます。 Rustは他の理由でそれを行うことはできませんが、呼び出されたときに関数全体を実行できるため、混乱を避けることもできます。

また、Dart言語の設計者とも連絡を取り、それが「明示的な非同期」の提案を作成する動機の大部分でした。 Dart 1には問題がありました。これは、呼び出されたときに関数が最初の待機状態まで実行されなかったため（Rustの動作とはまったく同じではありませんが、類似しています）、Dart 2で変更されたため、関数が最初の待機状態まで実行されるという大きな混乱を引き起こしました。呼び出されたら待ちます。 Rustは他の理由でそれを行うことはできませんが、呼び出されたときに関数全体を実行できるため、混乱を避けることもできます。

素晴らしい経験、私はそれを知りませんでした。 あなたがそのような大規模な仕事をしたと聞いてうれしいです。 よくやった👍

私も今夜の考えに見舞われました：C＃LDMと通信しようとしましたか？ たとえば、 @ HaloFour 、 @ gafter 、 @ CyrusNajmabadiなどです。 なぜ彼らが取った構文を取ったかを彼らに尋ねることは本当に良い考えかもしれません。

興味のある情報を提供させていただきます。ただし、私はそれをざっと見ただけです。 あなたが現在持っている特定の質問を要約することは可能でしょうか？

await構文について（これは完全にばかげているかもしれません。遠慮なく私に向かって叫んでください。私は非同期プログラミングの初心者で、何について話しているのかわかりません）：

「await」という単語を使用する代わりに、 ?ような記号/演算子を導入することはできません。 たとえば、 #や@など、現在使用されていないものである可能性があります。

たとえば、接尾辞演算子の場合：

let stuff = func()#?;
let chain = blah1()?.blah2()#.blah3()#?;

これは非常に簡潔で、左から右に自然に読み取られます。最初に待機し（ # ）、次にエラーを処理します（ ? ）。 .awaitが構造体メンバーのように見えるpostfixawaitキーワードのような問題はありません。 #は明らかに演算子です。

postfixが適切な場所であるかどうかはわかりませんが、優先順位のためにそのように感じました。 プレフィックスとして：

let stuff = #func()?;

または一体でも：

let stuff = func#()?; // :-D :-D

これは今までに議論されたことがありますか？

（私は、このようなものが、Perlが悪名高い「シンボルのランダムキーボードマッシュ」構文に近づき始めていることを認識しています... :-D）

@rayvector https://github.com/rust-lang/rust/issues/50547#issuecomment -388108875、5番目の選択肢。

@CyrusNajmabadi来てくれてありがとう。 主な質問は、リストされているものから、現在のRust言語にそのまま適していると思うオプションはどれか、または他の選択肢があるかどうかです。 このトピックはそれほど長くないので、簡単に上から下にすばやくスクロールできます。 主な質問：Rustは現在のC＃/ TS / ... await方法に従うべきか、それとも独自に実装する必要があるのか​​。 現在の構文は、何らかの方法で変更したいある種の「レガシー」ですか、それともC＃に最適であり、新しい言語にも最適なオプションですか？

C＃構文に対する主な考慮事項は、演算子の優先順位await foo?を最初に待機してから、 ?演算子を評価する必要があることと、C＃とは異なり、最初のawaitまで呼び出し元のスレッドで実行されないという違いです。 GetEnumeratorが最初に呼び出されるまで、否定性チェックを実行しません。

IEnumerable<int> GetInts(int n)
{
   if (n < 0)
      throw new InvalidArgumentException(nameof(n));
   for (int i = 0; i <= n; i++)
      yield return i;
}

私の最初のコメントとその後の議論でより詳細に。

@Pzixelああ、私が以前にこのスレッドを

いずれにせよ、私はその簡単な言及を除いて、これについて多くの議論を見たことがありません。

賛成/反対の良い議論はありますか？

@rayvectorここでは、より冗長な構文を支持するために少し議論しました。 その理由の1つは、あなたが言及した理由です。

Perlが悪名高い「記号のランダムキーボードマッシュ」構文

明確にするために、私はawait!(f)?が実際に最終的な構文のために実行されているとは思いません。それは、特定の選択にコミットしない確かな方法であるという理由で特に選択されました。 まだ「実行中」だと思う構文（ ?演算子を含む）は次のとおりです。

• await f?
• await? f
• await { f }?
• await(f)?
• (await f)?
• f.await?

または、おそらくこれらの組み合わせ。 重要なのは、それらのいくつかには優先順位を明確にするために中括弧が含まれており、ここには多くのオプションがあります-しかし、最終バージョンではawaitがマクロではなくキーワード演算子になることを意図しています（ rpjohnstが提案したようないくつかの大きな変更を除いて）。

単純なpostfixawait演算子（例： ~ ）か、括弧がなく、優先順位が最も高いキーワードのいずれかに投票します。

私はこのスレッドを読んでいますが、次のことを提案したいと思います。

• await f?は、最初に?演算子を評価し、次に結果の未来を待ちます。
• (await f)?は最初に未来を待ち、次に?演算子を結果と比較して評価します（通常のRust演算子の優先順位による）
• await? fは、 `（await f）？のシンタックスシュガーとして使用できます。 「将来結果を返す」というのは非常に一般的なケースだと思うので、専用の構文は非常に理にかなっています。

awaitは明示的でなければならないという他のコメント提供者に同意します。 JavaScriptでこれを行うのは非常に簡単です。また、Rustコードの明示性と可読性に本当に感謝しています。非同期を暗黙的にすると、非同期コードではこれが台無しになると思います。

「暗黙の非同期ブロック」は、将来の前にawaitキーワードを挿入するだけのproc_macroとして実装可能である必要があることに気づきました。

主な質問は、リストされているものの中から、現在のRust言語に適していると思うオプションはどれかということです。

C＃デザイナーに、Rust言語に最適なものを尋ねるのは...興味深いです:)

私はそのような決定をする資格がないと感じています。 私はさびとそれに手を出すのが好きです。 しかし、それは私が毎日使っている言語ではありません。 また、私はそれを私の精神に深く根付いていません。 そのため、ここでこの言語の適切な選択について主張する資格はないと思います。 Go / TypeScript / C＃/ VB / C ++について質問したい。 確かに、私ははるかに快適に感じるでしょう。 しかし、さびは私の専門分野から外れすぎて、そのような考えに満足することはできません。

C＃構文に対する主な考慮事項は、演算子の優先順位await foo?

これは私がコメントできるような気がします。 'await'で優先順位をよく考え、必要なフォームを設定する前に多くのフォームを試しました。 私たちが見つけた中心的なことの1つは、この機能を使用したいと思っていた私たちと顧客（内部および外部）にとって、非同期呼び出しを超えて何かを「チェーン」したいと思うことはめったにありませんでした。 言い換えれば、人々は「待つ」があらゆる表現の最も重要な部分であり、したがってそれをトップに近づけることに強く引き寄せられているように見えました。 注：「完全な式」とは、式ステートメントの上部にある式、最上位の割り当ての右側にある式、または「引数」として何かに渡す式などを意味します。

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

これが、「await」に「暗黙の」形式を使用しなかった理由でもあります。 実際には、それは人々が非常に明確に考えたいと思っていたものであり、彼らがそれに注意を払うことができるようにコードの中心ませんでした。 人々はまだそのキーワードの重い性質と私たちが選んだ優先順位を本当に気に入っているようです。

これまでのところ、視聴者の優先順位の選択に非常に満足しています。 将来的には、ここでいくつかの変更を加える可能性があります。 しかし、全体として、そうすることへの強い圧力はありません。

-

また、C＃の実行とは異なり、最初に待機するまで呼び出し元のスレッドで実行されないが、まったく開始されないという違いに加えて、現在のコードスニペットは、GetEnumeratorが最初に呼び出されるまでネガティブチェックを実行しません。

IMO、私たちが列挙子を作成した方法は、いくぶん間違いであり、何年にもわたって多くの混乱を招きました。 多くのコードを次のように記述しなければならない傾向があるため、これは特に悪いことです。

`` `c＃
void SomeEnumerator（X args）
{{
// Argsを検証し、同期作業を行います。
SomeEnumeratorImpl（args）;を返します。
}

void SomeEnumeratorImpl（X args）
{{
//..。
収率
//..。
}

People have to write this *all the time* because of the unexpected behavior that the iterator pattern has.  I think we were worried about expensive work happening initially.  However, in practice, that doesn't seem to happen, and people def think about the work as happening when the call happens, and the yields themselves happening when you actually finally start streaming the elements.

Linq (which is the poster child for this feature) needs to do this *everywhere*, this highly diminishing this choice.

For ```await``` i think things are *much* better.  We use 'async/await' a ton ourselves, and i don't think i've ever once said "man... i wish that it wasn't running the code synchronously up to the first 'await'".  It simply makes sense given what the feature is.  The feature is literally "run the code up to await points, then 'yield', then resume once the work you're yielding on completes".  it would be super weird to not have these semantics to me since it is precisely the 'awaits' that are dictating flow, so why would anything be different prior to hitting the first await.

Also... how do things then work if you have something like this:

```c#
async Task FooAsync()
{
    if (cond)
    {
        // only await in method
        await ...
    }
} 

このメソッドを完全に呼び出すことができ、待機することはありません。 「最初に待機するまで実行が呼び出し元のスレッドで実行されない」場合、実際にここで何が起こりますか？

待つ？ fは `（await f）？の構文糖衣として利用できます。 「将来結果を返す」というのは非常に一般的なケースだと思うので、専用の構文は非常に理にかなっています。

これは私に最も共鳴します。 これにより、「await」を最上位の概念にすることができますが、結果タイプの簡単な処理も可能になります。

C＃からわかっていることの1つは、優先順位に関する人々の直感は空白に結びついているということです。 それで、あなたが「xを待つ」を持っているなら？ ?が式に隣接しているため、 await優先順位は?よりも低いようにすぐに感じられます。 上記が実際に(await x)?として解析された場合、それは私たちの聴衆にとって驚くべきことです。

await (x?)として解析すると、構文から最も自然に感じられ、future / taskの「結果」を取得する必要性に適合し、実際に値を受け取った場合はそれを「待機」する必要があります。 。 その後、結果が返される場合は、それを「await」と組み合わせて、後で発生することを通知するのが適切だと感じます。 そうawait? x?各?しっかりとそれが最も自然に関連するコードの部分に結合するが。 最初の?はawait （特にその結果）に関連し、2番目はxます。

「最初に待機するまで実行が呼び出し元のスレッドで実行されない」場合、実際にここで何が起こりますか？

呼び出し側が戻り値待ってまで、何も起こりませんFooAsyncポイントで、 FooAsyncまでのいずれかの体の実行awaitまたはそれが返されます。

Rust Futureはポーリング駆動型で、スタックに割り当てられ、 poll最初に呼び出した後は移動できないため、このように機能します。 呼び出し元は、それらを所定の位置に移動する機会が必要です。トップレベルのFutureのヒープ上、または親Future内の値による、多くの場合「スタックフレーム」上にあります。呼び出し元のasync fn --before任意のコードが実行されます。

これは、a）呼び出し時にコードが実行されないC＃ジェネレーターのようなセマンティクス、またはb）関数の呼び出しもすぐに暗黙的に待機するKotlinコルーチンのようなセマンティクス（クロージャーのようなasync { .. } ）のいずれかに固執していることを意味します同時実行が必要な場合の

後者の方が好きです。C＃ジェネレーターで言及した問題を回避し、演算子の優先順位の質問も完全に回避できるからです。

@CyrusNajmabadi Rustでは、 Futureは通常、 Taskとして生成されるまで機能しません（F＃ Async非常に似ています）：

let bar = foo();

この場合、 foo()はFuture返しますが、実際には何もしません。 手動でスポーンする必要があります（これもF＃ Async似ています）：

tokio::run(bar);

スポーンされると、 Futureます。 これはFutureのデフォルトの動作であるため、Rustのasync / awaitは、生成されるまでコードを実行しない方が一貫性があります。

明らかに、C＃では状況が異なります。C＃ではfoo()を呼び出すと、すぐにTask実行が開始されるため、C＃では最初のawaitまでコードを実行するのが理にかなっています。 。

また...このようなものがある場合、どのように機能するのでしょうか[...]このメソッドを完全に呼び出すことができ、待機することはありません。 「最初に待機するまで実行が呼び出し元のスレッドで実行されない」場合、実際にここで何が起こりますか？

FooAsync()を呼び出すと、何も実行されず、コードは実行されません。 次に、それを生成すると、コードが同期的に実行され、 awaitは実行されないため、すぐに() （Rustのvoidのバージョン）が返されます。

つまり、「実行は最初に待機するまで呼び出し元のスレッドで実行されない」ではなく、「明示的に生成されるまで実行は実行されません（ tokio::run ）」です。

呼び出し元がFooAsyncの戻り値を待つまでは何も起こりません。その時点で、FooAsyncの本体は、待つか戻るまで実行されます。

いや。 それは残念なことのようです。 多くの場合、私は何かを待つことに慣れていない可能性があります（多くの場合、キャンセルやタスクの構成が原因です）。 開発者として、私はまだ初期のエラーを受け取っていただければ幸いです（これは、人々が実行を待ち望んでいる最も一般的な理由の1つです）。

これは、a）呼び出し時にコードが実行されないC＃ジェネレーターのようなセマンティクス、またはb）関数の呼び出しもすぐに暗黙的に待機するKotlinコルーチンのようなセマンティクス（クロージャーのような非同期{）のいずれかに固執していることを意味します。 。}同時実行が必要な場合のブロック）。

これらを考えると、私は後者よりも前者の方がはるかに好きです。 ただ私の個人的な好みです。 kotlinのアプローチがドメインにとってより自然であると感じた場合は、それを選択してください。

@CyrusNajmabadiIck 。 それは残念なことのようです。 多くの場合、私は何かを待つことに慣れていない可能性があります（多くの場合、キャンセルやタスクの構成が原因です）。 開発者として、私はまだ初期のエラーを受け取っていただければ幸いです（これは、人々が実行を待ち望んでいる最も一般的な理由の1つです）。

正反対だと思います。 私のJavaScriptの経験では、 await使用を忘れることは非常に一般的です。 その場合、 Promiseは引き続き実行されますが、エラーは飲み込まれます（または他の奇妙なことが起こります）。

Rust / Haskell / F＃スタイルでは、 Futureが（正しいエラー処理で）実行されるか、まったく実行されません。 次に、実行されていないことに気付いたので、調査して修正します。 これにより、コードがより堅牢になると思います。

@ Pauan @ rpjohnst説明ありがとうございます。 それらも私たちが検討したアプローチでした。 しかし、実際にはそれほど望ましいものではないことが判明しました。

「実際には何もしない。手動でスポーンする必要がある」場合は、オンデマンドでタスクを生成するものを返すものとしてモデル化する方がクリーンであることがわかりました。 つまり、 Func<Task>ような単純なものです。

正反対だと思います。 JavaScriptの私の経験では、awaitの使用を忘れることは非常に一般的です。

C＃は、タスクを待機しているか、そうでなければタスクを適切に使用していることを確認するように機能します。

しかし、エラーは飲み込まれます

それは私が言っていることの反対です。 私は、コードを熱心に実行して、タスクでコードを実行することにならない場合でも、エラーがすぐに発生するようにしたいと言っています。 これはイテレータでも同じです。 イテレータがストリーミングされている場合/場合は、関数を呼び出した時点で、潜在的にはるかに先の時点で、正しく作成されていなかったことをかなり知っています。

次に、実行されていないことに気付いたので、調査して修正します。

私が話しているシナリオでは、「実行されていない」ことは完全に合理的です。 結局のところ、私のアプリケーションは、実際にタスクを実行する必要がないといつでも判断する可能性があります。 それは私が説明しているバグではありません。 私が説明しているバグは、検証に合格しなかったことです。実際に作業を実行する必要がある時点ではなく、論理的に作業を作成した時点に近いことを知りたいと思います。 これらが非同期処理を説明するためのモデルであることを考えると、これらが互いに遠く離れている場合がよくあります。 したがって、問題に関する情報をできるだけ早く発生させることは価値があります。

前述のように、これも仮説ではありません。 同様のことがストリーム/イテレータでも発生します。 人々はしばしばそれらを作成しますが、その後までそれらを実現しません。 これらのことをソースまで追跡しなければならないことは、人々にとって余分な負担でした。 これが、非常に多くのAPI（hte BCLを含む）が同期/初期作業と実際の遅延/遅延作業の間で分割を行わなければならない理由です。

それは私が言っていることの反対です。 私は、コードを熱心に実行して、タスクでコードを実行することにならない場合でも、エラーがすぐに発生するようにしたいと言っています。

初期のエラーへの欲求は理解できますが、混乱しています。どのような状況で、「 Futureをスポーンすることができなくなってしまう」のでしょうか。

RustでFutureが機能する方法は、さまざまな方法（非同期/待機、並列コンビネータなどを含む）でFuture一緒に作成することです。これを行うことで、すべてのサブFutureを含む単一融合Future 。 次に、プログラムのトップレベル（ main ）で、 tokio::run （または同様のもの）を使用してプログラムを生成します。

mainでのその単一のtokio::run呼び出しを除いて、通常は手動でFutureのではなく、それらを作成するだけです。 そして、コンポジションは、スポーン/エラー処理/キャンセルなどを自然に処理します。 正しく。

私も何かを明確にしたいと思います。 私が次のようなことを言うとき：

しかし、実際にはそれほど望ましいものではないことが判明しました。

私は私たちの言語/プラットフォームで物事について非常に具体的に話している。 C＃/。Net / CoreFxなどに意味のある決定についてのみ洞察を与えることができます。状況が異なり、最適化する対象と取るべきアプローチの種類が完全に異なる場合もあります。別の方向。

初期のエラーへの欲求は理解できますが、私は混乱しています。どのような状況で、「未来を生み出すことに取り掛かることができなくなる」のでしょうか。

いつも:)

Roslyn（C＃/ VBコンパイラ/ IDEコードベース）自体がどのように記述されているかを考えてみてください。 それは非常に非同期でインタラクティブです。 つまり、その主な使用例は、アクセスする多くのクライアントと共有して使用することです。 最も簡単なサービスは、豊富な機能を介してユーザーとやり取りするのが一般的です。その多くは、ユーザーが任意の数のアクションを実行するため、当初は重要だと考えていた作業を行う必要がなくなったと判断します。 たとえば、ユーザーが入力しているときに、大量のタスクの構成と操作を行っていますが、数ミリ秒後に別のイベントが発生したため、それらを実行することすらできないと判断する可能性があります。

たとえば、ユーザーが入力しているときに、大量のタスクの構成と操作を行っていますが、数ミリ秒後に別のイベントが発生したため、それらを実行することすらできないと判断する可能性があります。

でも、それはキャンセルだけで処理されているのではないですか？

そして、コンポジションは、スポーン/エラー処理/キャンセルなどを自然に処理します。 正しく。

物事を表現するための2つの非常に異なるモデルがあるように思えます。 それは問題ありません:)私の説明は、私たちが選択したモデルのコンテキストで行われることを意図しています。 選択しているモデルには意味がない場合があります。

物事を表現するための2つの非常に異なるモデルがあるように思えます。 それは問題ありません:)私の説明は、私たちが選択したモデルのコンテキストで行われることを意図しています。 選択しているモデルには意味がない場合があります。

絶対に、私はあなたの視点を理解しようとしているだけでなく、私たちの視点も説明しています。 説明に時間を割いていただきありがとうございます。

でも、それはキャンセルだけで処理されているのではないですか？

キャンセルは、非同期と直交する概念です（私たちにとって）。 それらは一般的に一緒に使用されます。 しかし、どちらももう一方を必要としません。

完全にキャンセルせずにシステムを使用することもできますが、作成したタスクを「待機」するコードの実行に取り掛かることができない場合もあります。 つまり、論理的な理由で、コードは「「t」を待つ必要はありません。何か他のことをするだけです」と表示される場合があります。 （私たちの世界では）タスクについては、そのタスクが待たれることが期待されるべきであると指示したり、必要としたりするものは何もありません。 そのようなシステムでは、私は早期の検証を得たいと思います。

注：これはイテレータの問題に似ています。 誰かに電話して、後でコードで使用する予定の結果を取得することができます。 ただし、さまざまな理由により、実際に結果を使用する必要がなくなる場合があります。 私の個人的な望みは、たとえ技術的に検証結果を取得できず、プログラムを成功させたとしても、検証結果を早期に取得することです。

どちらの方向にも合理的な議論があると思います。 しかし、私の考えでは、同期アプローチには短所よりも長所があります。 もちろん、実際のimplがどのように機能したいかによって同期アプローチが文字通り適合しない場合、それはあなたが何をする必要があるかについての質問に答えるようです：D

言い換えれば、私はあなたのアプローチがここで悪いとは思わない。 そして、それがRustに適していると思うこのモデルの周りに強力な利点がある場合は、defがそれを実行します:)

完全にキャンセルせずにシステムを使用することもできますが、作成したタスクを「待機」するコードの実行に取り掛かることができない場合もあります。 つまり、論理的な理由で、コードは「「t」を待つ必要はありません。何か他のことをするだけです」と表示される場合があります。

個人的には、これは通常のif/then/elseロジックで処理するのが最適だと思います。

async fn foo() {
    if some_condition {
        await!(bar());
    }
}

しかし、あなたが言うように、それはC＃とは非常に異なる視点です。

個人的には、これは通常のif / then / elseロジックで処理するのが最適だと思います。

はい。 タスクが作成されるのと同じ時点で条件のチェックを実行できれば、それは問題ありません（そして、多くの場合はこのようなものです）。 しかし、私たちの世界では、物事がそのようにうまくつながっているということは一般的にはありません。 結局のところ、ユーザーに応じて（必要なときに結果が準備できるように）熱心に非同期作業を実行したいのですが、後で気にしないと判断する可能性があります。

私たちのドメインでは、「待機」は、人が「値を必要とする」時点で発生します。これは、別の決定/コンポーネントなどです。 「価値に取り組み始めるべきか」という決定から。

ある意味で、これらは非常に切り離されており、それは美徳と見なされています。 プロデューサーとコンシューマーは完全に異なるポリシーを持つことができますが、「タスク」の優れた抽象化を通じて実行されている非同期作業について効果的に通信できます。

とにかく、私は同期/非同期の意見から撤退します。 明らかに、ここでは非常に異なるモデルが使用されています。 :)

優先順位に関しては、C＃が物事をどのように考えるかについていくつかの情報を提供しました。 お役に立てば幸いです。 さらに詳しい情報が必要な場合はお知らせください。

@CyrusNajmabadiはい、あなたの洞察は非常に役に立ちました。 個人的には、 await? fooが進むべき道であることに同意します（ただし、「明示的なasync 」の提案も気に入っています）。

ところで、非同期/同期作業のモデリングに関する.netモデルのすべての複雑さ、およびそのシステムのすべての長所/短所に関する最高の専門家の意見の1つが必要な場合は、 @ stephentoubが

私の記憶から、これらの分割についての同様の考えが初期の.netのアプローチに取り入れられ、彼は行われた最終的な決定とそれらがどれほど適切であったかについて非常によく話すことができたと思います。

少し見慣れないように見えても、私はまだawait? futureに賛成票を投じます。 それらを構成することの本当の欠点はありますか？

コールド（F＃）とホット（C＃、JS）の非同期の長所と短所の別の徹底的な分析は次のとおりです： http ：//tomasp.net/blog/async-csharp-differences.aspx

専用の構文変更なしでpostfix awaitを試すことができるpostfixマクロの新しいRFCがあります： https ：

await {}はここで私のお気に入りで、 unsafe {}彷彿とさせ、さらに優先順位を示します。

let value = await { future }?;

@seunlanlege
はい、それは記憶に残るので、人々はこのようなコードを書くことができるという誤った仮定を持っています

let value = await {
   let val1 = future1;
   future2(val1)
}

しかし、彼らはできません。

@Pzixel
私があなたを正しく理解しているなら、あなたは人々が先物がawait {}ブロック内で暗黙のうちに待っていると想定するだろうと仮定していますか？ 私はそれに同意しません。 await {}は、ブロックが評価する式でのみ待機します。

let value = await {
    let future = create_future();
    future
};

そしてそれは落胆するパターンでなければなりません

簡略化

let value = await { create_future() };

あなたは、複数の表現が「推奨されるべきではない」というステートメントを提案します。 何かおかしいと思いませんか？

awaitをパターンにするのは好ましいですか（ refなどは別として）？
何かのようなもの：

let await n = bar();

私はそれを呼び出すことを好むasyncよりも、パターンをawait私はそれパターン構文作るの多くの利点が表示されませんが、。 パターン構文は、通常、対応する式に関して二重に機能します。

https://doc.rust-lang.org/nightly/std/task/index.htmlの現在のページによると、タスクmodはlibcoreからの再エクスポートとliballocの再エクスポートの両方で構成されているため、結果は少し...最適ではありません。 それが安定する前に、これが何らかの形で対処されることを願っています。

コードを見てみました。 そして、私はいくつかの提案があります：

• [x] UnsafePollトレイトとPoll列挙型の名前は非常に似ていますが、関連性はありません。 私は名前を変更することをお勧めUnsafePollに、例えばUnsafeTask 。
• [x]先物クレートでは、コードは異なるサブモジュールに分割されました。 現在、ほとんどのコードはtask.rsまとめられているため、ナビゲートが難しくなっています。 もう一度分割することをお勧めします。
• [x] TaskObj#from_poll_task()名前が変わっています。 代わりにnew()という名前を付けることをお勧めします
• [x] TaskObj#poll_taskはpoll()可能性があります。 フィールドpoll呼び出される可能性poll_fnも、それは関数ポインタだことを示唆しています
• Wakerは、 TaskObjと同じ戦略を使用して、vtableをスタックに置くことができる場合があります。 ただのアイデアですが、これが必要かどうかはわかりません。 間接参照が少し少ないので、もっと速くなりますか？
• [] dynはベータ版で安定しています。 コードはおそらく適用される場所でdyn使用する必要があります

私もこのようなもののPRを提供することができます。 @cramertj @aturon詳細については、Discord経由で

すべてのFutureメソッドawait()を追加するのはどうですか？

    /// just like and_then method
    let x = f.and_then(....);
    let x = f.await();

    await f?     =>   f()?.await()
    await? f     =>   f().await()?

/// with chain invoke.
let x = first().await().second().await()?.third().await()?
let x = first().await()?.second().await()?.third().await()?
let x = first()?.await()?.second().await()?.third().await()?

@zengsai問題は、 awaitが通常の方法のように機能しないことです。 実際、 asyncブロック/関数にない場合、 awaitメソッドが何をするかを考慮してください。 メソッドはどのコンテキストで実行されるかわからないため、コンパイルエラーを引き起こすことはありません。

@xfixこれは一般的には当てはまりません。 コンパイラーは必要なことを何でも実行でき、この場合は特別にメソッド呼び出しを処理できます。 メソッドスタイルの呼び出しは設定の問題を解決しますが、予期しないものであり（awaitは他の言語ではこのように機能しません）、コンパイラーの醜いハックになる可能性があります。

@elszbenコンパイラがやりたいことを何でもことは、コンパイラはありません。

future.await()は通常の関数呼び出しのように聞こえますが、そうではありません。 このようにしたい場合は、上記のどこかで提案されたfuture.await!()構文で同じセマンティクスが可能になり、「ここで何か奇妙なことが起こっている」というマクロで明確にマークされます。

編集：投稿が削除されました

この投稿を先物RFCに移動しました。 リンク

async fnと#[must_use]間の相互作用を見た人はいますか？

async fn場合、それを直接呼び出すとコードは実行されず、 Futureが返されます。 すべてのasync fnは「外側」のimpl Futureタイプに固有の#[must_use]を持っているはずなので、 Future何かをしなければそれらを呼び出すことはできません。

その上、 #[must_use]を自分でasync fnアタッチすると、それが内部関数の戻り値に適用されるように見えます。 したがって、 #[must_use] async fn foo() -> T { ... }と書くと、awaitの結果を使って何かをしなければawait!(foo())を書くことはできません。

誰かが非同期fnと＃[must_use]の間の相互作用を見たことがありますか？

このディスカッションに関心のある他の人については、 https：//github.com/rust-lang/rust/issues/51560を参照して

非同期関数をどのように実装するかを考えていたところ、これらの関数は再帰も相互再帰もサポートしていないことに気づきました。

await構文については、個人的には修正後のマクロに向かっています。暗黙のawaitアプローチはなく、チェーンが簡単で、メソッド呼び出しのように使用することもできます。

@ warlord500あなたは、上記の何百万もの開発者の経験全体を完全に無視しています。 awaitをチェーンしたくない。

@Pzixelは、私がスレッドや欲しいものを読んでいないと
一部の寄稿者は連鎖を許可したくないかもしれないことを知っていますが、私たちの何人かは
そうする開発者。 私が無視していたという考えをどこで得たのかわかりません
開発者の意見、私のコメントは、コミュニティのメンバーの意見とその意見を保持する理由を指定することだけでした。

編集：あなたが意見の違いを持っ​​ているなら、共有してください！ なぜあなたが言うのか興味があります
構文のようなメソッドを介して連鎖待機を許可するべきではありませんか？

@ warlord500は、MSチームが数千の顧客と数百万の開発者の間でその経験を共有したためです。 私は毎日非同期/待機コードを書いているので、それを自分で知っています。あなたはそれらを連鎖させたくないのです。 必要に応じて、正確な見積もりを以下に示します。

'await'で優先順位をよく考え、必要なフォームを設定する前に多くのフォームを試しました。 私たちが見つけた中心的なことの1つは、この機能を使用したいと思っていた私たちと顧客（内部および外部）にとって、非同期呼び出しを超えて何かを「チェーン」したいと思うことはめったにありませんでした。 言い換えれば、人々は「待つ」があらゆる表現の最も重要な部分であり、したがってそれをトップに近づけることに強く引き寄せられているように見えました。 注：「完全な式」とは、式ステートメントの上部にある式、最上位の割り当ての右側にある式、または「引数」として何かに渡す式などを意味します。

expr内で「await」を「続行」したいという傾向はまれでした。 (await expr).M()ようなものを時々目にしますが、それらはawait expr.M()実行している人の数よりも一般的ではなく、望ましくないようです。

私は今かなり混乱しています、私があなたを正しく理解しているなら、私たちはサポートするべきではありません
一般的に使用されていないので、修正後の簡単なチェーンスタイルを待ちますか？ 待機は表現の最も重要な部分であるとみなされます。
この場合、私はあなたを正しく理解していることを確認するためだけに推測します。
私が間違っている場合は、私を修正することを躊躇しないでください。

また、見積もりを入手した場所へのリンクを投稿してください。
ありがとうございます。

上記の2つの点に対する私の反論は、あなたが何かを一般的に使用しないという理由だけであり、それがコードをよりクリーンにする場合にそれをサポートすることが有害であるとは限らない。

将来生成される式が
最も重要な部分であり、それを上に配置したい場合でも、通常のマクロスタイルに加えて後置マクロスタイルを許可すれば、それを行うことができます。

また、見積もりを入手した場所へのリンクを投稿してください。
ありがとうございます。

しかし...しかし、あなたはスレッド全体を読んだと言いました...😃

しかし、私はそれを共有することに問題はありません： https ：//github.com/rust-lang/rust/issues/50547#issuecomment-388939886。 Cyrusのすべての投稿を読むことをお勧めします。これは、C＃/。Netエコシステム全体の実際の経験であり、Rustで再利用できる貴重な経験です。

式の最も重要な部分を待つこともあります

引用は明らかに反対を言っています😄そしてあなたが知っている、私は毎日同じように非同期/待機を書いています。

async / awaitの経験はありますか？ それでは共有してもらえますか？

うわー、私はそれを逃したとは信じられない。 それをリンクするためにあなたの一日の時間を割いていただきありがとうございます。
私は経験がないので、壮大な計画では私の意見はそれほど重要ではないと思います

@Pzixel async / awaitを使用して、あなたや他の人の経験に関する情報を共有していただきありがとうございますが、他の貢献者に敬意を表してください。 自分の技術的なポイントを聞くために、他の人の経験レベルを批判する必要はありません。

モデレーター注： @Pzixelコミュニティメンバーへの個人的な攻撃は許可されていません。 私はあなたのコメントからそれを編集しました。 再びそれをしません。 モデレートポリシーについて質問がある場合は、 rust-mods @ rust-lang.orgまでフォローアップしてください

@crabtw私は誰も批判しませんでした。 ご不便をおかけして申し訳ございません。

私は、人が「待っている」を連鎖させるのに実際に必要があるのか​​、それとも今日の機能の彼の外挿であるのかを理解したいときに、経験について一度尋ねました。 私は権威に訴えたくありませんでした。それは「自分で試して、この真実を自分で理解する必要がある」と言える有用な情報の集まりにすぎません。 ここでは不快なことは何もありません。

コミュニティメンバーへの個人的な攻撃は許可されていません。 私はあなたのコメントからそれを編集しました。

個人的な攻撃はありません。 私が見ることができるように、あなたは反対票についての私の参照をコメントアウトしました。 まあ、それは私のポストの反対票の私のリアクターであり、特別なことは何もありませんでした。 削除されたので、その参照を削除することも合理的です（これ以上の読者にとっては混乱を招く可能性があります）。削除していただきありがとうございます。

参照していただきありがとうございます。 私が言っていることを「福音」とは見なさないでください：）RustとC＃は異なる言語であり、コミュニティ、パラダイム、イディオムが異なります。 あなたはdefがあなたの言語のために最良の選択をするべきです。 私の言葉がお役に立てば幸いです。 しかし、常にさまざまな方法で物事を行うことができます。

私の望みは、あなたがRustにとって素晴らしい何かを思いつくことです。 その後、我々はあなたが何をしたか見ることができると優雅にC＃のためにそれを採用スチール:)

私の知る限り、リンクされた引数は、主の優先順位について語っawait 、特に、それはパースに理にかなっていると主張しているawait x.y()のようにawait (x.y())ではなく(await x).y()は、ユーザーが前者の解釈をより頻繁に望んで期待するためです（また、間隔はその解釈を示唆しています）。 そして、私は同意する傾向がありますが、 await!(x.y())ような構文があいまいさを取り除くことも観察します。

ただし、それがx.y().await!().z()ような連鎖の価値に関する特定の答えを示唆しているとは思いません。

引用されたコメントは、Rustに大きな違いがあるため、部分的に興味深いものです。これは、最終的なawait構文の理解を遅らせる大きな要因の1つです。C＃には?演算子がないため、コードがありません。 (await expr)?と書く必要があります。 彼らは(await expr).M()を本当に珍しいと説明しており、それはRustでも当てはまると思う傾向がありますが、私の観点からすると、それに対する唯一の例外は?であり、これは非常に一般的です。多くの先物が結果に評価されるためです（たとえば、現在存在するすべての先物が評価されます）。

@withoutboatsはい、そうです。 この部分をもう一度引用したいと思います。

私の観点からすると、それに対する唯一の例外は？

例外しかない場合は、 (await foo)?ショートカットとしてawait? fooを作成し、両方の長所を活用するのが妥当と思われます。

今のところ、少なくとも、の提案構文await!()の明確な使用できるようになります? 。 awaitの基本構文を変更する場合は、 awaitと?の組み合わせの構文が短くなることがあります。 （そして、我々はそれを変更するものに応じて、我々はすべての問題を持っていない可能性があります。）

@joshtriplettこれらの余分な中括弧はあいまいさを取り除きますが、実際には非常に重いものです。 たとえば、現在のプロジェクト全体を検索します。

Matching lines: 139 Matching files: 10 Total files searched: 77

私は2743slocで139を待っています。 大したことではないかもしれませんが、ブレースレスの代替品をよりクリーンで優れたものとして検討する必要があると思います。 とはいえ、 ?が唯一の例外であるため、中かっこなしでawait fooを簡単に使用でき、この特殊なケースのためだけに特別な構文を導入できます。 それは大したことではありませんが、LISPプロジェクトのためにいくつかの中括弧を節約することができます。

非同期関数が署名に外部戻り型アプローチを使用する必要があると思う理由についてのブログ投稿を作成しました。 読書を楽しむ！

https://github.com/MajorBreakfast/rust-blog/blob/master/posts/2018-06-19-outer-return-type-approach.md

私はすべての議論に従わなかったので、私がそれを逃したならば、これがすでに議論されていたであろう場所を私に指摘してください。

内部リターンタイプのアプローチに関する追加の懸念事項は次のとおりです。 Streamの構文は、指定されるとどのようになりますか？ async fn foo() -> impl Stream<Item = T>は見栄えがよく、 async fn foo() -> impl Future<Output = T>と一致すると思いますが、内部リターンタイプのアプローチでは機能しません。 そして、 async_streamキーワードを導入したいとは思わない。

@Ekleog Streamは、別のキーワードを使用する必要があります。 impl Traitは逆に機能するため、 async使用することはできません。 特定の特性が確実に実装されるようにすることしかできませんが、特性自体は、基礎となる具象型にすでに実装されている必要があります。

ただし、いつか非同期ジェネレーター関数を追加したい場合は、外部戻り型のアプローチが役立ちます。

async_gen fn foo() -> impl AsyncGenerator<Yield = i32, Return = ()> { yield 1; ... }

Streamは、 Return = ()を使用してすべての非同期ジェネレーターに実装できます。 これにより、これが可能になります。

async_gen fn foo() -> impl Stream<Item = i32> { yield 1;  ... }

注：ジェネレーターはすでに夜間に使用されていますが、この構文は使用されていません。 また、先物0.3のStreamとは異なり、現在はピン留めに対応していません。

編集：このコードは以前はGenerator 。 StreamとGenerator違いを見逃しました。 ストリームは非同期です。 これは、値を生成する必要はないかもしれないが、生成する必要がないことを意味します。 Poll::ReadyまたはPoll::Pendingいずれかで応答できます。 一方、 Generatorは、常に同期して譲歩または完了する必要があります。 これを反映するために、 AsyncGeneratorに変更しました。

Edit2： @Ekleogジェネレーターの現在の実装では、マーカーのない構文を使用しており、本体内のyield探すことで、ジェネレーターである必要があることを検出しているようです。 これは、 asyncを再利用

実際、私はasyncを再利用できると考えていました。これは、このRFCに従って、 asyncがFutureでのみ許可されるため、検出できたからです。リターンタイプ（ FutureまたはStreamいずれかである必要があります）を確認することにより、 Streamしています。

私たちは同じにしたい場合ので、私は今、これを引き上げてる理由は、 async生成するためのキーワードを両方ともFuture sおよびStream sが、その後、私は外側のリターンを考えますタイプアプローチは明示的であるため、はるかにクリーンであり、 async fn foo() -> i32がi32ストリームを生成することを誰も期待しないと思います（これは、本文に含まれている場合に可能です） yieldで、内部リターンタイプのアプローチが選択されました）。

ジェネレーターの2番目のキーワード（例： gen fn ）を作成し、両方を適用するだけでストリームを作成できます（例： async gen fn ）。 アウターリターンタイプは、これに入る必要はまったくありません。

@rpjohnst外部リターン型アプローチにより、2つの関連する型を簡単に設定できるため、私はそれを取り上げました。

2つの関連するタイプを設定したくありません。 ストリームはまだ単一のタイプであり、 impl Iterator<Item=impl Future>>などではありません。

@rpjohnst私は（非同期）ジェネレーターの関連するタイプYieldとReturnを意味しました

gen fn foo() -> impl Generator<Yield = i32, Return = ()> { ... }

これは私の元のスケッチでしたが、ジェネレーターについて話すことは、少なくとも追跡の問題に関しては、私たちよりもはるかに進んでいると思います。

// generator
fn foo() -> T yields Y

// generator that implements Iterator
fn foo() yields Y

// async generator
async fn foo() -> T yields Y

// async generator that implements Stream
async fn foo() yields Y

より一般的には、RFCで行われた決定を再検討する前に、実装についてより多くの経験を積む必要があると思います。 すでに行ったのと同じ議論を回っています。再重み付けが必要かどうかを確認するには、RFCによって提案された機能の経験が必要です。

私はあなたに完全に同意したいのですが、私があなたのコメントを正しく読んだ場合、非同期/待機構文の安定化は、非同期ストリームの適切な構文と実装を待ち、それらの2つで経験を積むのでしょうか？ （安定すると、外部リターンタイプと内部リターンタイプを切り替えることができないため）

Rust 2018には非同期/待機が期待されていて、それまでに非同期ジェネレーターの準備が整うことを望んでいないと思いましたが…？

（また、私のコメントは@MajorBreakfastのブログ投稿への追加の議論としてのみ意図されていましたが、このトピックに関する議論は完全に消去されたようです…それは私の目的ではありませんでした。議論は再び集中する必要があると思います。このブログ投稿？）

awaitキーワードの狭いユースケースは、まだ私を混乱させます。 （特にFuture vs Stream vs Generator）

すべてのユースケースでyieldキーワードで十分ではないでしょうか。 のように

{ let a = yield future; println(a) } -> Future

これにより、戻りタイプが明示的に保たれるため、キーワードとライブラリを緊密に融合することなく、すべての「継続」ベースのセマンティクスに必要なキーワードは1つだけです。

（私たちは粘土言語でこれを行いました）

@aep awaitは、ジェネレーターから未来を生成しません。 Futureの実行を一時停止し、呼び出し元に制御を戻します。

@cramertjは、まさにそのtho（yieldキーワードの後に​​継続を含むfutureを返す）を正確に実行できた可能性があります。これは、はるかに広範なユースケースです。
しかし、私はその議論のためにパーティーに少し遅れていると思いますか？ :)

@aep await固有のキーワードの理由は、将来のジェネレーター固有のyieldキーワードとの構成可能性のためです。 非同期ジェネレーターをサポートしたいので、2つの独立した継続「スコープ」を意味します。

また、Rust先物は、少なくとも部分的にメモリ管理上の理由から、コールバックベースではなくポーリングベースであるため、継続を含む先物を返すことはできません。 yieldが単一のオブジェクトへの参照をスローするよりも、 pollが単一のオブジェクトを変更する方がはるかに簡単です。

async / awaitは、言語自体を汚染するキーワードの原因であってはならないと思います。なぜなら、asyncは言語の内部ではなく、単なる機能だからです。

@sackeryこれは言語の内部の一部であり、純粋にライブラリとして実装することはできません。

したがって、nimと同じように、キーワードとして作成します。c＃の場合と同じです。

質問：可変参照によって値をキャプチャするasync非移動クロージャのシグネチャはどうあるべきですか？ 現在、彼らは完全に禁止されています。 閉鎖の借用が将来が死ぬまで続くことを可能にするある種のGATアプローチが必要なようです。例：

trait AsyncFnMut {
    type Output<'a>: Future;
    fn call(&'a mut self, args: ...) -> Self::Output<'a>;
}

@cramertjここには、クロージャのキャプチャされた環境への可変参照を返すという一般的な問題があります。 おそらく、ソリューションを非同期fnに関連付ける必要はありませんか？

@withoutboatsの権利、それはおそらく他の場所よりもasync状況ではるかに一般的になるでしょう。

fn async代わりにasync fnどうですか？
私のようにlet mutより良いmut let 。

fn foo1() {
}
fn async foo2() {
}
pub fn foo3() {
}
pub fn async foo4() {
}

pub fnを検索しても、ソースコード内のすべてのパブリック関数を見つけることができます。しかし、現在の構文はそうではありません。

fn foo1() {
}
async fn foo2() {
}
pub fn foo3() {
}
pub async fn foo4() {
}

この提案はそれほど重要ではありません、それは個人的な好みの問題です。
だから私はあなた方全員への意見を尊重します:)

私はすべての修飾子がfnの前に行くべきだと信じています。 それは明らかであり、それが他の言語でどのように行われるかです。 それは常識です。

@Pzixelアクセス修飾子は重要なので、 fn前に配置する必要があることを私は知っています。
しかし、 asyncはおそらくそうではないと思います。

@xmeta私はこれまでこのアイデアが提案されたのを見たことがありません。 一貫性をfnために、 asyncを置きたいと思うかもしれませんが、すべてのオプションを検討することが重要だと思います。 投稿してくれてありがとう！

// Status quo:
pub unsafe async fn foo() {} // #![feature(async_await, futures_api)]
pub const unsafe fn foo2() {} // #![feature(const_fn)]

@MajorBreakfast返信ありがとうございます、こんな感じでした。

{ Public, Private } ⊇ Function  → put `pub` in front of `fn`
{ Public, Private } ⊇ Struct    → put `pub` in front of `struct`
{ Public, Private } ⊇ Trait     → put `pub` in front of `trait`
{ Public, Private } ⊇ Enum      → put `pub` in front of `enum`
Function ⊇ {Async, Sync}        → put `async` in back of `fn`
Variable ⊇ {Mutable, Imutable}  → put `mut` in back of `let`

@xmeta @MajorBreakfast

async fnは不可分であり、非同期関数を表します。

async fnは全体です。

pub fn検索します。これは、パブリック同期機能を検索していることを意味します。
同様に、 pub async fn検索します。つまり、パブリック非同期関数を検索します。

@ZhangHanDong

• async fnは、futureを返す通常の関数を定義します。 未来を返すすべての関数は「非同期」と見なされます。 async fnの関数ポインタと、未来を返す他の関数は同じです°。 これが遊び場の例です。 「asyncfn」を検索すると、表記を使用する関数のみが検索され、すべての非同期関数が検索されるわけではありません。
• pub fnを検索しても、 unsafeまたはconst関数は見つかりません。

° async fnによって返される具象型は、もちろん匿名です。 つまり、どちらもFutureを実装する型を返します

@xmetaは、 mutは「letの後に移動」しないことに注意してください。つまり、 mutはlet変更しないことに注意してください。 letはパターンを取ります、つまり

let PATTERN = EXPRESSION;

mutはPATTERN一部であり、 let自体の一部ではありません。 例えば：

// one is mutable one is not
let (mut a, b) = (1, 2);

@steveklabnikわかりました。 階層構造と語順の関係を示したかっただけです。 ありがとう

asyncブロック内のreturnとbreakの望ましい動作について、人々はどのように考えていますか？ 現在、 returnは非同期ブロックから返されますreturnを許可する場合、これが実際に可能な唯一のオプションです。 returnを完全に禁止し、 'label: async { .... break 'label x; }ようなものを使用して非同期ブロックから戻ることができます。 これは、ブロック解除機能（https://github.com/rust-lang/rust/issues/）にキーワードbreakとreturnどちらを使用するかについての会話にもつながります。 48594）。

私はreturnを許可するためのものです。 それを禁止する主な懸念は、それが現在の関数からではなく、非同期ブロックから戻るため、混乱する可能性があることです。 しかし、私はそれが混乱することになるとは思えません。 閉鎖returnすでにreturnが非同期ブロックにも適用されることを学ぶのはIMOが簡単であり、それを許可することはIMOにとって非常に価値があります。

@cramertj returnは、内部ブロックではなく、常に包含関数を終了する必要があります。 それが機能するのに意味がない場合、それは機能しないように聞こえますが、 returnはまったく機能しないはずです。

これにbreakを使用するのは残念なことのようですが、残念ながらlabel-break-valueがあることを考えると、少なくともそれと一致しています。

非同期の移動と閉鎖はまだ計画されていますか？ 以下はRFCからのものです：

// closure which is evaluated immediately
async move {
     // asynchronous portion of the function
}

そしてさらにページを下に

async { /* body */ }

// is equivalent to

(async || { /* body */ })()

これにより、 returnがクロージャーと一致し、簡単に理解して説明できるようになります。

ブレークツーブロックRFCは、ラベル付きの内部クロージャーからジャンプできるようにすることを計画していますか？ そうでない場合（そして私はそれがそれを許可するべきだとは示唆していません）、 returnsの一貫した振る舞いを禁止し、それからまたbreak-to-blocksのrfcと矛盾する代替手段を使用することは非常に残念です。

@memoryruins async || { ... return x; ... }は絶対に機能するはずです。 asyncがクロージャではないという理由だけで、 async { ... return x; ... }はすべきではないと言っています。 returnは、「含まれている関数から戻る」という非常に具体的な意味があります。 クロージャは機能です。 非同期ブロックはそうではありません。

@memoryruinsこれらは両方ともすでに実装されています。

@joshtriplett

非同期ブロックはそうではありません。

それは私には理にかなっているように、私がいることを、私はまだそれらを含むブロックとは別に定義された実行コンテキストと体だという意味での関数としてそれらを考えると思いますreturn内部でasyncブロック。 ここでの混乱はほとんど構文的に見えます。ブロックは通常、コードを||やasyncように新しい実行コンテキストに取り込むものではなく、式の単なるラッパーです。

ただし、@ cramertjの「構文」は重要です。

このように考えてください。 関数のように見えないもの（またはクロージャのように見え、クロージャを関数として認識することに慣れているもの）があり、 returnが表示された場合、メンタルパーサーはそれがどこに行くと思いますか？

returnを乗っ取るものはすべて、他人のコードを読むのをより混乱させます。 人々は、少なくともという考えに使用されているbreak一部の親ブロックに戻り、彼らが持っているでしょうが、どのブロックを知るためにコンテキストを読み取ること。 returnは常に、関数全体から返される大きなハンマーでした。

それらがすぐに評価されたクロージャと同様に扱われていない場合、特に構文的には、リターンに一貫性がないことに同意します。 非同期ブロックの?がすでに決定されている場合（RFCはまだ決定されていないと言っています）、それと一致すると思います。

@joshtriplett関数とクロージャ（構文的には非常に異なる）を「リターンスコープ」として認識できると言うのは恣意的ですが、非同期ブロックは同じ行に沿って認識できません。 なぜ2つの異なる構文形式が受け入れられるのに、3つは受け入れられないのですか？

RFCでこのトピックに関するいくつかのました。 私がそこで言ったように、私はラベルを提供する必要なしにbreakを使用する非同期ブロックを支持しています（非同期ブロックから外側のループに抜け出す方法がないので、表現度を失うことはありません）。

@withoutboatsクロージャは単なる別の種類の関数です。 「クロージャは関数である」を学んだら、「 return常に含まれている関数から戻る」など、関数について知っているすべてのものをクロージャに適用できます。

@ Nemo157ラベルのないbreakがasyncブロックをターゲットにしている場合でも、非同期ブロック内のループから早期に戻るためのメカニズム（ 'label: async ）を提供する必要があります。 。

@joshtriplett

クロージャは別の種類の関数です。 「クロージャは関数である」を学んだら、「リターンは常に含まれている関数から戻る」など、関数について知っているすべてのものをクロージャに適用できます。

asyncブロックも一種の「関数」だと思います。引数がなく、非同期で実行して完了することができます。 これらは、引数がなく、事前に適用されているasyncクロージャの特殊なケースです。

@cramertjうん、必要に応じて暗黙のブレークポイントにもラベルを付けることができると思っていました（現在はすべてラベルを付けることができると思います）。

制御フローを追跡しにくくするもの、特にreturn意味を再定義するものはすべて、コードをスムーズに読み取る機能に大きな負担をかけます。

同じように、Cの標準的なガイダンスは、「マクロの途中から戻るマクロを記述しない」です。 または、あまり一般的ではありませんが、まだ問題のあるケースとして、ループのように見えるマクロを作成する場合、 breakとcontinueはその内部から機能するはずです。 実際に2つのループを埋め込んだループっぽいマクロを作成する人を見たことがあります。そのため、 breakは期待どおりに機能せず、非常に混乱します。

非同期ブロックも一種の「機能」だと思います

それは、実装の内部を知ることに基づく視点だと思います。

私はそれらを関数としてはまったく見ていません。

私はそれらを関数としてはまったく見ていません。

@joshtriplett

私の疑惑は、クロージャーのある言語に初めて同じ議論をしただろうということですreturnはクロージャー内ではなく、定義関数内で機能するはずです。 そして確かに、Scalaのように、この解釈を採用する言語があります。

@cramertj私はしません、いいえ。 関数内で定義されたラムダや関数の場合、それらが関数であることは完全に自然なことです。 （これらに最初に触れたのはPython、FWIWで、ラムダはreturnを使用できず、ネストされた関数ではreturnを含む関数からreturnが返されます。）

非同期ブロックが何をするのかがわかれば、 returnがどのように動作しなければならないかが直感的にわかると思います。 実行の遅延を表していることがわかったら、 returnが関数に適用できないことは明らかです。 ブロックが実行されるまでに、関数がすでに戻っていることは明らかです。 これを学ぶIMOは、それほど難しいことではありません。 少なくとも試してみる必要があります。

このRFCは、 ?演算子とreturn 、 break 、 continueなどの制御フロー構造が非同期ブロック内でどのように機能するかを提案していません。

専用のRFCが作成されるまで、制御フロー演算子を禁止したり、ブロックを延期したりするのが最善でしょうか？ 後で説明するように言及された他の望ましい機能がありました。 それまでの間、非同期関数、クロージャ、 await! :)

ここで@memoryruinsに同意します。これらの詳細について詳しく説明するために、別のRFCを作成する価値があると思います。

core::task::context()と呼ばれる可能性のある非同期fn内からコンテキストにアクセスできるようにする関数についてどう思いますか？ 非同期fnの外部から呼び出された場合、それは単にパニックになります。 たとえば、エグゼキュータにアクセスして何かを生成する場合など、これは非常に便利だと思います。

@MajorBreakfastその関数はlazyと呼ばれます

async fn foo() -> i32 {
    await!(lazy(|ctx| {
        // do something with ctx
        42
    }))
}

スポーンのようなより具体的なものについては、人間工学的にするヘルパー関数がある可能性があります

async fn foo() -> i32 {
    let some_task = lazy(|_| 5);
    let spawned_task = await!(spawn_with_handle(some_task));
    await!(spawned_task)
}

@ Nemo157実はspawn_with_handleがこれを使いたいところです。 コードを0.3に変換すると、コンテキストにアクセスする必要があるため、 spawn_with_handleは実際には未来にすぎないことに気付きました（コードを参照）。 私がやりたいのは、 spawn_with_handleメソッドをContextExtに追加し、 spawn_with_handleを非同期関数内でのみ機能する無料の関数にすることです。

fn poll(self: PinMut<Self>, cx: &mut Context) -> Poll<Self::Output> {
     let join_handle = ctx.spawn_with_handle(future);
     ...
}

async fn foo() {
   let join_handle = spawn_with_handle(future); // This would use this function internally
   await!(join_handle);
}

これにより、現在私たちが持っているすべての二重待機ナンセンスが削除されます。

考えてみると、メソッドはcore::task::with_current_context()と呼ばれる必要があり、参照を格納することは不可能でなければならないため、少し異なる動作をします。

編集：この関数はget_task_cxという名前で既に存在します。 現在、技術的な理由でlibstdにあります。 libcoreに入れることができたら、パブリックAPIにすることを提案します。

async関数から呼び出すことができる関数を使用して、TLSから移動すると、親のasync関数からコンテキストを取得できるとは思えません。 その時点で、コンテキストはasync関数内の非表示のローカル変数のように扱われる可能性が高いため、その関数でコンテキストに直接アクセスするマクロを作成できますが、 spawn_with_handle方法はありません。

だから、潜在的に次のようなもの

fn spawn_with_handle(executor: &mut Executor, future: impl Future) { ... }

async fn foo() {
    let join_handle = spawn_with_handle(async_context!().executor(), future);
    await!(join_handle);
}

@ Nemo157あなたが正しいと思います：私が提案しているような関数は、非同期fn内から直接呼び出されないと機能しない可能性があります。 おそらく最良の方法は、 spawn_with_handle await内部でselect!やjoin! ）。

async fn foo() {
    let join_handle = spawn_with_handle!(future);
    await!(join_handle);
}

これは見栄えがよく、マクロ内のawait!(lazy(|ctx| { ... }))介して簡単に実装できます。

async_context!()は、待機ポイント間でコンテキスト参照を保存することを妨げることができないため、問題があります。

async_context!()は、待機ポイント間でコンテキスト参照を格納することを妨げることができないため、問題があります。

実装によっては、可能です。 完全なジェネレーター引数が復活した場合、いずれにせよ降伏点全体で参照を保持できないように制限する必要があります。引数の背後にある値の有効期間は、降伏点までしか実行されません。 Async / awaitは、その制限を継承するだけです。

@ Nemo157このような意味ですか？

let my_arg = yield; // my_arg lives until next yield

@Pzixel _おそらく_古い議論を目覚め

はい、私はawait!()構文が?ようなものと組み合わせるときに曖昧さを取り除くのが好きですが、この構文が単一のプロジェクトで1000回入力するのが面倒であることにも同意します。 また、ノイズが多く、クリーンなコードが重要だと思います。

そのため、 something_async()@をawaitものと比較するなど、接尾辞の付いた記号（以前に数回言及されています）に対する実際の引数は何であるか疑問に思っています。おそらくawait原因です。 @は、awaitのaに似ているので面白いかもしれませんが、うまくフィットするシンボルであればどれでもかまいません。

基本的に接尾辞?になったtry!()で同様のことが起こったので、そのような構文の選択は論理的であると私は主張します（これは完全に同じではないことを私は知っています）。 簡潔で、覚えやすく、入力も簡単です。

このような構文のもう1つのすばらしい点は、 ?記号と組み合わせると、動作がすぐに明確になることです（少なくともそうなると思います）。 以下を見てください。

// Await, then unwrap a Result from the future
awaiting_a_result()@?;

// Unwrap a future from a result, then await
result_with_future()?@;

// The real crazy can make it as funky as they want
magic()?@@?@??@; 
// - I'm joking, of course

await future?ように、このような状況を知らない限り何が起こるかが一目でわからない場合のように、これには問題はありません。 それでも、その実装は?と一致しています。

さて、私が考えることができるいくつかの_マイナー_なことがこのアイデアに対抗するでしょう：

• awaitものとは異なり、簡潔すぎて目立たない/冗長である可能性があります。これにより、関数内の一時停止ポイントを見つけるのが困難になります。
• asyncキーワードとは非対称である可能性があります。一方はキーワードで、もう一方はシンボルです。 ただし、 await!()には、キーウェアとマクロの同じ問題があります。
• 記号を選択すると、さらに別の構文要素と学習することが追加されます。 しかし、これが一般的に使用されるものになるかもしれないと仮定すると、これは問題ではないと思います。

@phauxは、 ~記号の使用についても言及しました。 ただし、この文字はかなりの数のキーボードレイアウトで入力するのがファンキーだと思うので、そのアイデアを削除することをお勧めします。

みんなどう思いますか？ try!() ?になった方法とどういうわけか似ていることに同意しますか？ awaitとシンボルのどちらが好きですか、そしてその理由は何ですか？ 私はこれについて話し合うことに夢中ですか、それとも何かが足りないのでしょうか？

私が使用した可能性のある誤った用語で申し訳ありません。

私が印章ベースの構文で抱えている最大の懸念は、あなたが親切に示したように、それが簡単にグリフスープに変わる可能性があることです。 Perl（pre-6）に精通している人なら誰でも、私がこれをどこに使うのか理解するでしょう。 ラインノイズを回避する

そうは言っても、おそらく最善の方法は、実際にはtry!とまったく同じですか？ つまり、明示的なasync!(foo)マクロから開始し、必要に応じて、そのための砂糖となる印章を追加します。 確かに、それは問題を後で延期しますが、 async!(foo)はasync / awaitの最初の反復には十分であり、比較的議論の余地がないという利点があります。 （そして、 try! / ?の前例があることは、印章が発生する必要があります）

@withoutboatsこのスレッド全体を読んだことはありませんが、実装を手伝ってくれる人はいますか？ 開発ブランチはどこにありますか？

そして、残りの未解決の考慮事項に関して、Rustコミュニティ外の専門家に助けを求めた人はいますか？ Joe Duffyは、並行性について多くのことを知っていて気にかけていて、厄介な詳細を非常によく理解しています。彼はRustConfで

@BatmanAoD最初の実装はhttps://github.com/rust-lang/rust/pull/51580に上陸しました

元のRFCスレッドには、Rust以外でも、PLT分野の多くの専門家からのコメントがありました:)

時は金なりなので、先物を待つための「$」記号を提案したいと思います。これをコンパイラーに思い出させたいと思います。

ただの冗談。 待つためのシンボルを持つのは良い考えではないと思います。 Rustとは、明示的であり、人々が低レベルのコードを強力な言語で記述できるようにすることです。 記号はawait!マクロよりもはるかに曖昧であり、読みにくいコードを書くことで、人々が別の方法で自分の足を撃つことができます。 ?は一歩遠すぎると私はすでに主張します。

また、 async fn形式で使用されるasyncキーワードがあることに同意しません。 これは、非同期に対するある種の「バイアス」を意味します。 なぜ非同期はキーワードに値するのですか？ 非同期コードは、必ずしも必要ではない、私たちにとって単なる別の抽象化です。 非同期属性は、より強力なコードを記述できるようにする、基本のRust方言の「拡張」のように機能すると思います。

私は言語アーキテクトではありませんが、JavaScriptでPromisesを使用して非同期コードを作成した経験が少しあります。そこで行われる方法により、非同期コードを作成するのが楽しくなると思います。

@steveklabnikああ、moveサポートなしの実装」と「完全実装」に分割する必要がありますか？

次の実装の反復は、いくつかのパブリックフォーク/ブランチで作業されていますか？ または、RFC 2418が受け入れられるまで、それを進めることさえできませんか？

なぜ非同期/待機構文の問題がRFCではなくここで議論されているのですか？

@ c-edw asyncキーワードに関する質問は、「関数は何色ですか？」によって回答される

@parasyteその投稿は、実際には、自動的に管理されるグリーンスレッドスタイルの同時実行性のない非同期関数のアイデア全体に反対する議論であることが私に示唆されています。

グリーンスレッドは（管理された）ランタイムなしでは透過的に実装できないため、私はこの立場に同意しません。Rustがそれを必要とせずに非同期コードをサポートするのには十分な理由があります。

しかし、あなたの投稿を読んでいると、 async / awaitセマンティクスは問題ないようですが、キーワードについて導き出される結論はありますか？ それを拡張していただけませんか？

そこでのあなたの見方にも同意します。 私はasyncキーワードが必要であるとコメントしていました、そして記事はその背後にある理由を説明します。 著者が導き出した結論は別の問題です。

@parasyteああ、

私はそれを正義とは言えなかったと感じているので、さらに明確にしたいと思います。

二分法は避けられません。 一部のプロジェクトでは、すべての関数呼び出しを非同期にして、同期関数呼び出しが存在しないようにすることで、それを消去しようとしました。 みどりはその一例です。 そして他のプロジェクトは、同期関数のファサードの後ろに非同期関数を隠すことによって二分法を消そうとしました。 geventはこの種の例です。

どちらも同じ問題を抱えています。 非同期タスクが完了するのを、タスクを非同期的に開始することを区別するための二分法が必要です。

• みどりだけでなく、導入awaitキーワードが、また、 asyncキーワード関数呼び出しのサイトを。
• geventは、通常の関数呼び出しの暗黙の待機に加えて、 gevent.spawnを提供します。

それが、「なぜasyncはキーワードに値するのか」という質問に答えるため、color-a-functionの記事を取り上げた理由です。

まあ、スレッドベースの同期コードでさえ、「タスクが完了するのを待つ」（結合）と「タスクを開始する」（スポーン）を区別することができます。 すべてが非同期（実装に関して）である言語を想像できますが、 awaitはアノテーションがなく（デフォルトの動作であるため）、Midoriのasyncは代わりにspawn渡されるクロージャです

したがって、非同期はキーワードに値することに同意しますが、Rustはこのレベルでの実装のメカニズムに関心があり、そのために両方の色を提供する必要があるため、それ以上のように思えます。

@rpjohnstはい、あなたの提案を読みました。 これは、概念的には、色を非表示にすることと同じです。 まったく同じスレッドの錆のフォーラムで私はこれを批判しました。 すべての関数呼び出しは同期しているように見えます。これは、関数が非同期パイプラインで同期とブロッキングの両方を行っている場合に特に危険です。 この種のバグは予測不可能であり、トラブルシューティングするのに実際の災害です。

私は特に私の提案について話しているのではなく、すべてが非同期である言語について話しているのです。 あなたはそのように二分法から逃れること

IIUCはまさにミドリが試みたものです。 その時点で、キーワードとクロージャはセマンティクスを主張しているだけです。

2018年7月12日木曜日午後3時1分、ラッセルジョンストン[email protected]
書きました：

二分法の理由の議論としてキーワードの存在を使用しました
みどりにはまだ存在します。 それらを削除した場合、二分法はどこにありますか？ The
構文はall-syncコードと同じですが、非同期の機能を備えています
コード。

結果を待たずに非同期関数を呼び出すと、
同期的にpromiseを返します。 これは後で待つことができます。 😐

_うわー、誰かがみどりについて何か知っていますか？ 生き物がほとんどいないクローズドプロジェクトだといつも思っていました。 誰かがそれについてもっと詳しく書いていたら面白いでしょう。_

/オフトピック

@Pzixelプロジェクトがシャットダウンされたため、生き物はまだ作業していません。 しかし、JoeDuffyのブログには興味深い詳細がたくさんあります。 上記の私のリンクを参照してください。

ここで軌道に乗ってしまったので、繰り返しているような気がしますが、それは「キーワードの存在」、つまりawaitキーワードの一部です。 キーワードをspawnやjoinなどのAPIに置き換えると、完全に非同期になりますが（Midoriのように）、二分法はありません（Midoriのように）。

言い換えれば、私が前に言ったように、それは基本的ではありません-私たちが選択し

@CyrusNajmabadiもう一度pingをます。

二度と言及されたくない場合は、教えてください。 私はあなたが興味を持っているかもしれないと思っただけです。

＃wg-netの不和チャンネルから：

@cramertj
思考の糧： async { ... }ブロックの最後にOk::<(), MyErrorType>(())を書くことがよくあります。 エラータイプの制約を簡単にするために考えられることがあるでしょうか。

@withoutboats
[...]おそらく[ try ]と一貫性を持たせたいですか？

（ tryブロックがどのようにリターンタイプを宣言できるかについての比較的最近の議論を覚えていますが、今はそれを見つけることができません...）

言及された色合い：

async -> io::Result<()> {
    ...
}

async: io::Result<()> {
    ...
}

async as io::Result<()> {
    ...
}

tryできることの1つは、 asyncが人間工学的ではありませんが、変数バインディングまたは型の割り当てを使用することです。

let _: io::Result<()> = try { ... };
let _: impl Future<Output = io::Result<()>> = async { ... };

私は以前、 Futureトレイトにfnのような構文を許可するというアイデアを投げかけていました（例： Future -> io::Result<()> 。 それはまだ多くの文字ですが、それは手動タイプ提供オプションを少し見栄えよくします：

let _: impl Future -> io::Result<()> = async {
}

async -> impl Future<Output = io::Result<()>> {
    ...
}

私の選択になります。

これは、既存のクロージャ構文に似てい

|x: i32| -> i32 { x + 1 };

編集：そして最終的にTryFutureがFutureを実装することが可能になったとき：

async -> impl TryFuture<Ok = i32, Error = ()> {
    ...
}

Edit2：正確には、上記は今日の特性定義で機能します。 TryFutureタイプは、現在Future実装していないため、今日ほど有用ではありません。

@MajorBreakfastなぜ-> impl Future<Output = io::Result<()>>ではなく-> io::Result<()>ですか？ すでにasync fn foo() -> io::Result<()>に対してreturn-type-desugaringを実行しているので、IMOが->ベースの構文を使用する場合、ここで同じ砂糖が必要になることは明らかです。

@cramertjはい、一貫している必要があります。 上記の私の投稿は、アウターリターンタイプのアプローチが優れていることを皆さんに納得させることができると仮定しています😁

async -> R { .. }場合は、おそらくtry -> R { .. }を使用する必要があります。また、タイプの割り当てには一般にexpr -> TheTypeを使用する必要があります。 言い換えれば、私たちが使用する型の帰属構文は、どこにでも均一に適用されるべきです。

@Centril同意します。 どこでも使えるはずです。 ->が本当に正しい選択であるかどうか->を呼び出し可能に関連付けます。 そして、非同期ブロックはそうではありません。

@MajorBreakfast私は基本的に同意します。 タイプの割り当てには:を使用する必要があると思います。したがって、 async : Type { .. } 、 try : Type { .. } 、およびexpr : Typeです。 Discordの潜在的なあいまいさについて説明しましたが、 :で前進する方法を見つけたと思います...

もう1つの質問は、 Either列挙型についてです。 futuresクレートにはすでにEitherがあります。 また、そうでない場合はeitherクレートのEitherように見えるため、混乱を招きます。

Futuresはstd（少なくともその非常に基本的な部分）にマージされているように見えるので、そこにEither含めることもできますか？ 関数からimpl Futureを返すことができるようにするには、それらを用意することが重要です。

たとえば、私はよく次のようなコードを記述します。

fn handler() -> impl Future<Item = (), Error = Bar> + Send {
    someFuture()
        .and_then(|x| {
            if condition(&x) {
                Either::A(anotherFuture(x))
            } else {
                Either::B(future::ok(()))
            }
        })
}

私はそれを次のように書くことができるようにしたいと思います：

async fn handler() -> Result<(), Bar> {
    let x = await someFuture();
    if condition(&x) {
        await anotherFuture(x);
    }
}

しかし、私が理解しているように、 asyncが展開されると、ここにEitherを挿入する必要があります。

_必要に応じて、ここで実際のコードを見つけることができます。

@Pzixel async関数内にEitherは必要ありません。ただし、先物がawaitある限り、 asyncが行うコード変換によってこれら2つが非表示になります。内部で型を指定し、コンパイラに単一の戻り型を提示します。

@Pzixelまた、私は（個人的に） EitherがこのRFCで導入されないことを望んでいます。これは、 https：//github.com/rust-lang/rfcs/issuesの制限付きバージョンを導入するためですFutureのみ機能します）。したがって、一般的なソリューションがマージされた場合は、API cruftが追加される可能性があります。 @ Nemo157が述べたように、今Either持っている:)

@Ekleog確かに、私は既存の非同期コードに実際に大量のeitherがあるというこの考えに見舞われ、それらを本当に取り除きたいと思っています。 次に、依存関係にeitherクレートがあるためにコンパイルされないことに気付くまで、30分ほど費やしたときの混乱を思い出しました（将来のエラーは非常に理解しにくいため、かなり時間がかかりました）。 だから、この問題が何らかの形で解決されていることを確認するために、私がコメントを書いたのはこのためです。

もちろん、これはasync/awaitだけに関連しているのではなく、より一般的なものなので、独自のRFCに値します。 futuresがeitherについて知っているか、またはその逆（ IntoFuture正しく実装するため）であることを強調したかっただけです。

@Pzixel先物クレートによってエクスポートされたEitherは、 eitherクレートからの再エクスポートです。 futuresクレート0.3は、孤立したルールのため、 Eitherに対してFutureを実装できません。 一貫性を保つためにEither StreamとSink implsをEitherから削除し、代わりに代替手段を提供する可能性が高いです（ここで説明します）。 さらに、 eitherクレートは、おそらく機能フラグの下で、 Future 、 Stream 、およびSink自体を実装できます。

とは言うものの、 Either代わりに非同期関数を使用する方が良いでしょう。

async : Type { .. }ものがhttps://github.com/rust-lang/rfcs/pull/2522で提案されてい

Send自動的に実装するasync / await関数

次の非同期関数は（まだ？） Sendはないようです：

pub async fn __receive() -> ()
{
    let mut chan: futures::channel::mpsc::Receiver<Box<Send + 'static>> = None.unwrap();

    await!(chan.next());
}

完全なリプロデューサーへのリンク（ futures-0.3がないためにプレイグラウンドでコンパイルされない）はここにあり

また、この問題を調査しているときに、https：//github.com/rust-lang/rust/issues/53249に出くわしました。これは、一番上の投稿の追跡リストに追加する必要があると思います:)

これは、 Send _ should_を実装するasync / await関数が機能することを示す遊び場です。 Rcバージョンのコメントを解除すると、その関数が非Sendとして正しく検出されます。 私はあなたの特定の例を少し見て（このマシンにはRustコンパイラはありません：slightly_frowning_face :)、それが機能しない理由を解明することができます。

@Ekleog std::mpsc::ReceiverはSyncではなく、あなたが書いたasync fnはそれへの参照を保持しています。 !Syncアイテムへの!Sendは

@cramertjうーん…しかし、私は所有しているmpsc::Receiverを持っていませんか？ジェネリック型がSend場合、 Sendになるはずです。 （また、 std::mpsc::Receiverなくfutures::channel::mpsc::Receiver 。これは、タイプがSend場合もSyncです。 mpsc::Receiver気付かずに申し訳ありません。 mpsc::Receiver ！）

@ Nemo157ありがとう！ この問題に関するノイズが多すぎるのを避けるために、https：//github.com/rust-lang/rust/issues/53259を開きました:)

asyncブロックが?およびその他の制御フローを許可するかどうか、およびどのように許可するかという問題は、 tryブロックとの相互作用を保証する可能性があります（たとえば、 try async { .. } ?を許可するreturn ？）。

これは、 asyncブロックのタイプを指定するためのメカニズムが、 tryブロックのタイプを指定するためのメカニズムと相互作用する必要がある可能性があることを意味します。 帰属構文RFCにコメントを残しました： https ：

最初はfutures-rs問題だと思っていたものをヒットしましたが、実際には非同期/待機の問題である可能性があるため、 https ：

1つの新しい問題： https ：

数日前に不和で議論されたように、 awaitはまだキーワードとして予約されていません。 2018リリースの前にこの予約を取得する（そして2018年版のキーワードlintに追加する）ことは非常に重要です。 今のところマクロ構文を使い続けたいので、少し複雑な予約です。

Future / Task APIには、ローカルの未来を生み出す方法がありますか？
SpawnLocalObjErrorがあるようですが、未使用のようです。

@panicbitワーキンググループでは、現在、コンテキストにスポーン機能を含めることが理にかなっているかどうかについて話し合っています。 https://github.com/rust-lang-nursery/wg-net/issues/56

（ SpawnLocalObjErrorは完全に未使用ではありません：先物クレートのLocalPoolがそれを使用します。ただし、libcoreの何もそれを使用しないというのは正しいです）

@withoutboats問題の説明にあるリンクのいくつかがhttps： //github.com/rust-lang/rfcs/pull/2418が閉じられ、 https： //github.com/rust-lang-nursery/futures-rs/issues/1199がhttps：/に移動されました

NB。 この追跡問題の名前はasync / awaitですが、タスクAPIにも割り当てられています。 タスクAPIには現在保留中の安定化RFCがあります： https ：

キーワードを代替の非同期実装で再利用できるようにするチャンスはありますか？ 現在はFutureを作成していますが、プッシュベースの非同期をより使いやすくする機会を逃したようなものです。

@aep oneshot::channelを使用すると、プッシュベースのシステムからプルベースのFutureシステムに簡単に変換できます。

例として、JavaScript Promisesはプッシュベースであるため、stdwebはoneshot::channelを使用してJavaScriptPromisesをRustFuturessetTimeoutなどの他のプッシュベースのコールバックAPIにもoneshot::channelを使用します。

Rustのメモリモデルのため、プッシュベースのFutureは、プルと比較して追加のパフォーマンスコストがかかります。 したがって、Futureシステム全体をプッシュベースにするのではなく、必要な場合にのみ（たとえば、 oneshot::channel ）そのパフォーマンスコストを支払う方が適切です。

そうは言っても、私はコアチームやラングチームの一員ではないので、私が言うことには何の権限もありません。 それは私の個人的な意見です。

実際には、リソースに制約のあるコードではその逆です。 プルモデルにはペナルティがあります。これは、待機中の関数のスタックを介して次の準備完了値を供給するのではなく、プルされているものの内部にリソースが必要になるためです。 futures.rsの設計は、ネットワークスイッチ（私のユースケース）やゲームレンダラーなど、ハードウェアに近いものには高すぎるだけです。

ただし、この場合、ここで必要なのは、ジェネレーターのように非同期で出力させることだけです。 前に言ったように、2つのキーワードを単一のライブラリにバインドするのではなく、十分に抽象化すれば、非同期とジェネレータは実際には同じものだと思います。

ただし、この場合、ここで必要なのは、ジェネレーターのように非同期で出力させることだけです。

この時点でのasyncは、文字通りジェネレータリテラルの最小限のラッパーです。 ジェネレーターがプッシュベースの非同期IOにどのように役立つかを理解するのに苦労していますが、それらのCPS変換が必要ではありませんか？

「引っ張られているものの中にリソースが必要だ」とはどういう意味か、具体的に教えてください。 なぜそれが必要になるのか、または「待機中の関数のスタックを介して次の準備完了値をフィードする」がpoll()とどのように異なるのかわかりません。

私は、プッシュベースの先物はより高価である（したがって、制約のある環境で使用するのは難しい）という印象を受けました。 任意のコールバックをfutureにアタッチできるようにするには、何らかの形式の間接参照（通常はヒープ割り当て）が必要です。そのため、ルートfutureに一度割り当てるのではなく、すべてのコンビネーターに割り当てます。 また、スレッドの安全性の問題によりキャンセルもより複雑になるため、キャンセルをサポートしないか、レースを回避するためにすべてのコールバック完了でアトミック操作を使用する必要があります。 私が知る限り、これらすべてを合計すると、フレームワークを最適化するのがはるかに困難になります。

それらのためにCPS変換が必要ではありませんか？

ええ、現在のジェネレーター構文は継続の引数がないため、そのためには機能しません。そのため、非同期がそれを行う方法をもたらすことを望んでいました。

引っ張られているものの中にリソースが必要ですか？

これは、非同期の順序を2回逆にするとコストがかかるという私のひどい言い方です。 つまり、ハードウェアから先物へ、そしてチャネルを使用して再び戻ってきます。 ハードウェアに近いコードではメリットがないものをたくさん運ぶ必要があります。

一般的な例は、ソケットのファイル記述子の準備ができていることがわかっている場合は、futureスタックを呼び出すことはできませんが、代わりに、すべての実行ロジックを実装して、実際のイベントをfutureにマップする必要があります。これには、ロックなどの外部コストがかかります。コードサイズ、そして最も重要なのはコードの複雑さ。

任意のコールバックをfutureにアタッチできるようにするには、何らかの形の間接参照が必要です

はい、一部の環境ではコールバックが高価であることを理解しています（実行速度が関係ない私のものではありませんが、合計メモリが1MBなので、futures.rsはフラッシュにも適合しません）。継続のようなもの（現在のジェネレーターの概念は半分実装されています）。

また、スレッドセーフのため、キャンセルもより複雑になります

ここでは混乱していると思います。 私はコールバックを支持していません。 継続は静的スタックでも問題ありません。 たとえば、clay言語で実装したのは、プッシュまたはプルに使用できる単なるジェネレーターパターンです。 すなわち：

async fn add (a: u32) -> u32 {
    let b = await
    a + b
}

add(3).continue(2) == 5

マクロでそれを続けることができると思いますが、ここで1つの特定の概念に言語キーワードを浪費する機会を逃したように感じます。

実行速度が関係ない私のものではありませんが、私は合計1MBのメモリを持っているので、futures.rsはフラッシュにも適合しません

現在の先物は、メモリに制約のある環境で実行することを目的としていると確信しています。 何がそんなに多くのスペースを占めているのですか？

編集：このプログラムは、コンパイル時に295KBのディスクスペースを必要とします-私のMacBookでリリースします（基本的なhello worldは273KBを必要とします）：

use futures::{executor::LocalPool, future};

fn main() {
    let mut pool = LocalPool::new();
    let hello = pool.run_until(future::ready("Hello, world!"));
    println!("{}", hello);
}

実行速度が関係ない私のものではありませんが、私は合計1MBのメモリを持っているので、futures.rsはフラッシュにも適合しません

現在の先物は、メモリに制約のある環境で実行することを目的としていると確信しています。 何がそんなに多くのスペースを占めているのですか？

また、記憶とはどういう意味ですか？ 128kBフラッシュ/ 16kBRAMを搭載したデバイスで現在の非同期/待機ベースのコードを実行しました。 現在、async / awaitには確かにメモリ使用の問題がありますが、これらは主に実装の問題であり、いくつかの最適化を追加することで改善できます（https://github.com/rust-lang/rust/issues/52924など）。

一般的な例は、ソケットのファイル記述子の準備ができていることがわかっている場合は、futureスタックを呼び出すことはできませんが、代わりに、すべての実行ロジックを実装して、実際のイベントをfutureにマップする必要があります。これには、ロックなどの外部コストがかかります。コードサイズ、そして最も重要なのはコードの複雑さ。

どうして？ これはまだ先物があなたを強制するもののようには見えません。 プッシュベースのメカニズムと同じくらい簡単にpollを呼び出すことができます。

また、記憶とはどういう意味ですか？

これは関係ないと思います。 この議論全体では、私が意図していなかった点を無効にすることについて詳しく説明しました。 私は、その設計をコア言語に組み込むのは間違いであると言う以外に、未来を批判するためにここにいるわけではありません。

私のポイントは、asyncキーワードが適切に実行されれば、将来の証拠となる可能性があるということです。 継続は私が望むものですが、おそらく他の人々がさらに良いアイデアを思い付くでしょう。

プッシュベースのメカニズムと同じくらい簡単にpollを呼び出すことができます。

はい、 Future：pollがargsを呼び出していれば、それは理にかなっています。 投票は抽象的である必要があるため、それらを含めることはできません。 代わりに、asyncキーワードから継続を発行し、引数がゼロの継続に対してFutureを実装することを提案しています。

これはシンプルで手間のかからない変更であり、先物にコストをかけることはありませんが、現在1つのライブラリ専用のキーワードを再利用できます。

ただし、継続はもちろんプリプロセッサを使用して実装することもできます。これを実行します。 残念ながら、脱糖は閉鎖にすぎず、適切な継続よりも費用がかかります。

@aepキーワード（ asyncおよびawait ）を再利用できるようにするにはどうすればよいですか？

@Centril私の素朴なクイックフィックスは、FutureではなくGeneratorへの非同期を下げることです。 これにより、先物専用のバックエンドではなく、ジェネレーターを適切な継続に役立つようにする時間ができます。

たぶん10行のPRのようです。 しかし、私はそれをめぐってミツバチの巣箱と戦う忍耐力がないので、別のキーワードを脱糖するための前処理を作成します。

私は非同期のものをフォローしていないので、これが以前/他の場所で議論されている場合はお詫びしますが、非同期をサポートするための（実装）計画は何ですか/ no_stdますか？

AFAICT現在の実装ではTLSを使用してWakerを渡しますが、 no_std / coreはTLS（またはスレッド）のサポートはありません。 @alexcrichtonから、 Generator.resumeが引数のサポートを取得した場合、TLSを削除できる可能性があると聞きました。

非同期の安定化をブロックする計画/実装されているno_stdサポートを待つ計画はありますか？ または、 std async / await on stableを出荷するために安定化される部分を変更せずに、 no_stdサポートを追加できると確信していますか？

@japaric pollは、コンテキストを明示的に取得するようになりました。 AFAIK、TLSはもう必要ありません。

https://doc.rust-lang.org/nightly/std/future/trait.Future.html#tymethod.poll

編集：async / awaitには関係なく、先物にのみ関係します。

[...] std async / await on stableを出荷するために安定化される部分を変更せずに、 no_stdサポートを追加できると確信していますか？

私はそう信じています。 関連する部分はstd::futureの関数であり、これらはすべて、安定化されることのない追加のgen_future不安定な機能の背後に隠されています。 asyncトランスフォームはset_task_wakerを使用してウェイカーをTLSに格納し、 await!はpoll_with_tls_wakerを使用してアクセスします。 ジェネレーターがレジューム引数のサポートを取得した場合、代わりにasyncトランスフォームはウェイカーをレジューム引数として渡すことができ、 await!はそれを引数から読み取ることができます。

編集：ジェネレーターの引数がなくても、これは非同期変換の少し複雑なコードでも実行できると思います。 個人的には、他のユースケースにジェネレーター引数を追加してもらいたいのですが、TLS要件の有無にかかわらず削除できると確信しています。

@japaric同じボート。 誰かが先物を組み込みで動作させたとしても、そのすべてのTier3以来、それは非常に危険です。

非同期を修正するよりもはるかに少ない作業で済む醜いハックを見つけました：アークで織りますジェネレータのスタックを介して。

1. 「Poll」引数を参照してくださいhttps://github.com/aep/osaka/blob/master/osaka-dns/src/lib.rs#L76そのアーク
2. 行87で投票物に何かを登録する
3. 92行目に継続点を生成するためのyield
4. ジェネレーターからジェネレーターを呼び出して、207行目に上位レベルのスタックを作成します
5. 最後に、215行目でランタイムを渡してスタック全体を実行します

理想的には、Futureではなく「純粋な」クロージャースタックに非同期を下げるだけなので、実行時の仮定は必要なく、ルートで引数として不純な環境をプッシュできます。

私はそれを実装する途中でした

https://twitter.com/arvidep/status/1067383652206690307

しかし、私だけがそれを望んでいるのなら、ずっと行くのは無意味です。

そして、ジェネレーター引数なしでTLSなしの非同期/待機が可能かどうかについて考えるのをやめることができなかったので、 no_std proc-macroベースのasync_block! / await!マクロペアを実装しましたローカル変数のみを使用します。

現在のTLSベースのソリューションやジェネレーター引数ベースのソリューションよりもはるかに微妙な安全性の保証が必要です（少なくとも、基礎となるジェネレーター引数が健全であると仮定した場合）が、それは健全であると確信しています（誰もいない限り）回避策を見つけることができなかったかなり大きな衛生ホールを使用します。これは、名前のないgensym identを使用して非同期変換と待機マクロの間で通信できるため、コンパイラ内の実装では問題になりません）。

OPでawait!をstdからcoreに移動することについての言及がないことに気づきました。おそらく、追跡するための安定化の前に、解決する問題のリストに＃56767を追加できます。これ。

@ Nemo157 await!は安定化することが期待されていないので、とにかくブロッカーではありません。

@Centril誰があなたにawait!が安定することは期待されていないと言ったのかわかりません...：wink：

@cramertj彼は、私が信じているキーワードバージョンではなく、マクロバージョンを意味していました...

@ crlf0710暗黙のawait /明示的な非同期ブロックバージョンについてはどうですか？

@ crlf0710私もやった:)

@cramertj現在、コンパイラにawaitとawait!の両方の存在を可能にする醜いハックがあるので、マクロを削除したくないですか？ マクロを安定させると、マクロを削除できなくなります。

@stjepang await!の構文については、後置表記の一般的な好みや、あいまいさや発音できない/ Googleで使用できない記号が嫌いなことを除けば、あまり気にしません。 私の知る限り、現在の提案（優先順位を明確にするために?を使用）は次のとおりです。

• await!(x)? （今日あるもの）
• await x? （ awaitは?よりも緊密にバインドされますが、それでもプレフィックス表記であり、メソッドをチェーンするための括弧が必要です）
• await {x}? （上記と同じですが、曖昧さを解消するために一時的に{}が必要です）
• await? x （ awaitはあまり緊密にバインドされませんが、それでもプレフィックス表記が必要で、メソッドをチェーンするための括弧が必要です）
• x.await? （フィールドアクセスのように見えます）
• x# / x~ /など。 （いくつかの記号）
• x.await!()? （postfix-macro-style、 @ withoutboatsと私はおそらく他の人はpostfix-macrosファンではないと思います。なぜなら彼らは.がタイプベースのディスパッチを許可することを期待しているからです。 ）。

配送への最善のルートは、 await!(x)を着陸させ、 awaitキーワード化せず、最終的には後置マクロの素晴らしさを人々に売り、 x.await!()を追加できるようにすることだと思います。

私はこの問題を非常に大まかにフォローしていますが、ここに私の意見があります：

個人的には、 await!マクロがそのままで、ここで説明されているように気に入っています： https ：

これは、魔法や新しい構文ではなく、通常のマクロです。 結局のところ、少ないほど多くなります。

その後、再び、私はまた、好適try!通り、 Try 、まだ安定していません。 ただし、 await!(x)?は、砂糖と明白な名前付きアクションの間の適切な妥協点であり、うまく機能すると思います。 さらに、デバッグトレースなどの追加機能を処理するために、サードパーティライブラリ内の他のマクロに置き換えられる可能性があります。

一方、 async / yieldは、ジェネレーターにとって「単なる」シンタックスシュガーです。 JavaScriptが非同期/待機サポートを取得していて、非同期コードをトランスパイルしてジェネレーターとPromises / Futuresを非同期操作に使用するBabelやRegeneratorのようなプロジェクトがあった時代を思い出します。これは、基本的に私たちが行っていることと同じです。

最終的には、非同期とジェネレーターを別個の機能にし、潜在的には相互に構成可能にする（ Streamを生成する）必要があることに注意してください。 await!をyield下げるマクロとして残すことは、永続的な解決策ではありません。

待ってます！ ただ低下して歩留まりを上げるマクロは、恒久的な解決策ではありません。

yieldに下がることをユーザーに永続的に表示することはできませんが、そのように実装し続けることはできます。 非同期+ジェネレーター= Stream場合でも、たとえばyield Poll::Pending;とyield Poll::Ready(next_value)ます。

最終的には、非同期とジェネレーターを別個の機能にする必要があることに注意してください

非同期とジェネレーターは別個の機能ではありませんか？ もちろん関連していますが、これをJavaScriptのやり方ともう一度比較すると、非同期はジェネレーターの上に構築されるといつも思っていました。 非同期関数である唯一の違いは、通常の値とは対照的に、 Futureを返し、生成することです。 エグゼキュータは、非同期関数が実行されるのを評価して待機する必要があります。 それに加えて、私にはわからないいくつかの余分な生涯のもの。

実際、私はかつてこの正確なことについてライブラリを作成し、Promises / Futuresを返す非同期関数とジェネレータ関数の両方を再帰的に評価しました。

@cramertj 2つが別個の「効果」である場合、そのように実装することはできません。 これに関するいくつかの議論がここにあります： https ： yield Poll::Ready(next_value)は必要ありません。 yield next_valueし、同じ関数の他の場所にawaitます。

@rpjohnst

Poll :: Ready（next_value）を生成したくないので、next_valueを生成したいので、同じ関数の他の場所で待機します。

はい、もちろんそれはユーザーにはどのように見えるかですが、脱糖に関しては、 yieldをPoll::Readyでラップし、 Poll::Pendingを追加するだけです。 yieldから生成await! 。 構文的には、エンドユーザーには個別の機能として表示されますが、コンパイラーで実装を共有することはできます。

@cramertjこれも：

• await? x

@novacrazyはい、それらは別個の機能ですが、一緒に構成可能である必要があります。

そして実際、JavaScriptではそれらは構成可能です：

https://thenewstack.io/whats-coming-up-in-javascript-2018-async-generators-better-regex/

「非同期ジェネレーターとイテレーターは、非同期関数とイテレーターを組み合わせたときに得られるものであるため、待機できる非同期ジェネレーターや、生成できる非同期関数のようなものです」と彼は説明しました。 以前は、ECMAScriptを使用すると、譲歩または待機できる関数を作成できましたが、両方を作成することはできませんでした。 「これは、特にFetchオブジェクトがストリームを公開する場合に、Webプラットフォームの一部になりつつあるストリームを消費するのに非常に便利です。」

非同期イテレータはObservableパターンに似ていますが、より柔軟性があります。 「Observableはプッシュモデルです。 購読すると、準備ができているかどうかに関係なく、イベントや通知が全速力で爆発するため、おしゃべりに対処するためにバッファリングまたはサンプリング戦略を実装する必要があります」とTerlson氏は説明します。 非同期イテレータはプッシュプルモデルであり、値を要求すると値が送信されます。これは、ネットワークIOプリミティブなどに適しています。

@Centril ok、オープン＃56974、それは未解決の質問としてOPに追加されるのに十分正しいですか？

await構文のバイクシェッドに再び入りたくないのですが、少なくとも1つのポイントに応答する必要があります。

個人的には、 await!マクロがそのままで、ここで説明されているように気に入っています： https ：

また、次の理由を拡張するために、マクロがライブラリに実装されたマクロのままであるとは思わないと述べたことにも注意してください（ユーザーにマクロとして表示され続けるかどうかは無視します）。

1. 未解決の問題の1つとして、現在|| await!()を使用してジェネレーターを作成できると述べているため、基盤となる実装を非表示にします。
2. @cramertjが言及しているように、非同期ジェネレーターをサポートするには、 yieldによって追加されたawaitと、ユーザーによって作成された他のyield区別する必要があります。 これは_if_、ユーザーがしたかったことはありません、事前にマクロ展開の段階として行うこと_could_ yieldマクロの内部が、非常に便利があるyieldのような-in-マクロ構造yield_from! 。 マクロ内のyieldサポートする必要があるという制約があるため、これには少なくともawait!が組み込みマクロである必要があります（実際の構文でない場合）。
3. no_std async fnをサポートします。 私はこれを実装する2つの方法を知っています。どちらの方法でも、ウェイカーが格納されている識別子を共有するためにasync fn -created- Futureとawaitが必要です。両方がコンパイラに実装されている場合、これら2つの場所で衛生的に安全な識別子が共有されていることがわかります。

ここには少し混乱があると思います。 await!をyield呼び出しのラッパーに公開して拡張できるようにすることは、決して意図されていませんyield 。 await!マクロのような構文の将来は、現在のコンパイラでサポートされているcompile_error! 、 assert! 、 format_args!などの実装と同じように実装に依存します。コンテキストに応じて、異なるコードにデシュガーすることができます。

ここで理解する必要がある唯一の重要な点は、提案された構文のいずれにも意味上の大きな違いはないということです。これらは単なる表面構文です。

await構文を解くための代替案を書きます。

まず第一に、私はawaitを接尾辞演算子として置くという考えが好きです。 しかし、すでに指摘したように、 expression.awaitはフィールドに非常に似ています。

だから私の提案はexpression awaitedです。 ここでの欠点は、 awaitedがまだキーワードとして保存されていないことですが、英語ではより自然であり、Rustではそのような表現（つまり、 expression [token]ような文法形式）は有効ではありません。今のところ、これは正当化できます。

その後、我々は書くことができるexpression? awaited待つためにResult<Future,_> 、およびexpression awaited?待つためのFuture<Item=Result<_,_>> 。

@earthengine

私はawaitedキーワードで売られていませんが、あなたは何かに興味があると思います。

ここでの重要な洞察は次のとおりです。 yieldとawaitはreturnと?です。

return xは値x return x返しますが、 x?結果xアンラップし、 Errの場合は早期に戻ります。
yield xは値x yield x生成しますが、 x awaitedは将来のx 、 Pendingの場合は早期に戻ります。

それには素晴らしい対称性があります。 おそらくawait実際には接尾辞演算子である必要があります。

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

@cramertjが示した正確な理由から、私は後await! / awaitようにネストする感覚はありません。 ?のような単純さはなく、接尾辞演算子に使用する記号が不足しています...

個人的には、前に説明した理由から、私はまだawait!を支持しています。 それはさびた感じで、ナンセンスではありません。

特に長い式や連鎖式の場合、全体的な読みやすさが低下します。

Rustfmt規格では、例を記述します。

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

これが読みやすさにどのように影響するかはほとんどわかりません。

postfixawaitも好きです。 スペースを使うのは珍しく、精神的なグループ化を壊す傾向があると思います。 ただし、 .await!()はうまくペアになり、 ?は前または後のいずれかに適合し、 !は制御フローの相互作用を可能にすると思います。

（これには、完全に一般的な後置マクロメカニズムは必要ありません。コンパイラーは、特別な場合に.await!()ます。）

接尾辞await （ .または() ）はかなり奇妙に見えるので、私は本当に強く嫌いになりましたawait他の言語から来た人々は私たちの確かに費用。 それは私たちが真剣に受け止めなければならないコストです。 ただし、 x awaitは明らかに関数呼び出しやフィールドアクセスではなく（ x.await / x.await() / await(x)すべてこの問題があります）、ファンキーなものは少なくなります優先順位の問題。 この構文は、 ?とメソッドアクセスの優先順位を明確に解決します。たとえば、 foo await?とfoo? awaitどちらも、 foo await?.xとfoo await?.yと同様に、明確な優先順位を持っています。

私もそう思います

stream.for_each(async |item| {
    ...
}) await;

よりよく読む

await!(stream.for_each(async |item| {
    ...
});

全体として、私はこれを支持するでしょう。

@joshtriplett RE .await!()個別に話し合う必要があります-最初はこれにも賛成でしたが、一般的にpostfixマクロも取得できない場合は、これを着陸させるべきではないと思います。彼らに対してはかなりの反対があり（残念な理由はありますが）、 await安定化を妨げないようにしたいと思います。

なぜ両方ではない？

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

私は今、postfixの魅力をよりよく理解しており、いくつかのシナリオではそれをもっと好きになることに国境を接しています。 特に上記のチートでは、Rust自体が提供する必要さえないほど単純です。

したがって、後置の場合は+1です。

後置バージョンに加えて、前置機能も必要だと思います。

後置構文の詳細については、 .await!()が唯一の実行可能な後置構文であると言っているのではありません。 私は先頭にスペースがあるpostfix awaitファンではありません。

1行に1つのステートメントを使用してフォーマットする場合は（まだ珍しいですが）問題ないように見えますが、1行に単純なステートメントをフォーマットする場合ははるかに合理的ではありません。

postfixキーワード演算子が気に入らない場合は、 await適切な記号演算子を定義できます。

今のところ、接尾辞演算子の単純なASCII文字の演算子が不足していました。 しかし、どうですか

let x = do_something()⌛.do_somthing_else()⌛;

プレーンASCIIが本当に必要な場合は、（上記の形状に触発されて）思いついた。

let x = do_something()><.do_somthing_else()><;

または（水平位置での類似形状）

let x = do_something()>=<.do_somthing_else()>=<;

もう1つのアイデアは、 await構造体を角かっこにすることです。

let x = >do_something()<.>do_something_else()<;

これらすべてのASCIIソリューションは、 <..>がすでに過度に使用されているという同じ合格の問題を共有しており、 <と>解析の問題があります。 ただし、 ><または>=<は、演算子内にスペースを必要とせず、現在の位置に開いている<がないため、これに適している場合があります。

間にスペースが気に入らないが、後置キーワード演算子は問題ない場合は、ハイフンを使用してください。

let x = do_something()-await.do_something_else()-await;

同じコードを書くための多くの異なる方法があることについて、私は個人的にそれが好きではありません。 初めての人にとって、それが正しい方法またはそれを持っていることのポイントが何であるかを適切に理解することがはるかに難しい主な理由。 2番目の理由は、異なる構文を使用する多くの異なるプロジェクトがあり、それを飛び越えて読むのが難しいことです（特に錆びたばかりの人にとって）。 実際に違いがあり、いくつかの利点がある場合にのみ、異なる構文を実装する必要があると思います。 多くのコードシュガーは、言語を学び、操作することをはるかに難しくしています。

@goffrieはい、同じことをするために多くの異なる方法をとるべきではないことに同意します。 しかし、私はさまざまな代替案を提案していました。コミュニティは1つを選択するだけで済みます。 したがって、これは実際には問題ではありません。

さらに、 await!マクロに関しては、ユーザーが独自のマクロを作成して別の方法で実行するのを止める方法はありません。Rustはこれを可能にすることを目的としています。 したがって、「同じことを行うための多くの異なる方法を持つ」ことは避けられません。

私が示した単純なダムマクロは、私たちが何をしても、ユーザーはとにかくやりたいことを何でもすることを示していると思います。 キーワードは、接頭辞であれ接尾辞であれ、関数のような接頭辞マクロ、またはおそらく接尾辞のメソッドのようなマクロが存在する場合はいつでも作成できます。 awaitに関数またはメソッドのようなマクロを選択した場合でも、それらはさらに別のマクロで反転される可能性があります。 それは本当に問題ではありません。

したがって、柔軟性とフォーマットに焦点を当てる必要があります。 これらすべての可能性を最も簡単に満たすソリューションを提供します。

さらに、この短い時間で私は接尾辞のキーワード構文に執着するようになりましたが、 awaitは、おそらく接頭辞のキーワードであるジェネレーターでyield決定されたものを反映するはずです。 後置ソリューションを希望するユーザーにとって、メソッドのようなマクロはおそらく最終的には存在するでしょう。

私の結論は、プレフィックスキーワードawaitが今のところ最良のデフォルト構文であり、おそらく通常のクレートがユーザーにawait!マクロのような関数を提供し、将来的にはポストフィックスメソッドのようなものを提供するということです。 .await!()マクロ。

@novacrazy

さらに、この短い時間で私は接尾辞のキーワード構文に執着するようになりましたが、 awaitは、おそらく接頭辞のキーワードであるジェネレーターでyield決定されたものを反映するはずです。

式yield 42はタイプ!にありますが、 foo.awaitはタイプTあり、 foo: impl Future<Output = T>です。 @stjepangは、ここで?とreturnと正しく類似しています。 awaitはyieldます。

なぜ両方ではない？

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

awaitは真のキーワードのままである必要があるため、マクロに別の名前を付ける必要があります。

さまざまな理由から、接頭辞await反対しているので、ブロックはawait { ... }ます。

まず、 await expr?に優先順位の問題があり、一貫した優先順位はawait (expr?)が、 (await expr)?が必要です。 優先順位の問題の解決策として、 await? exprに加えてawait expr await? exprを提案する人もいます。 これには、ユニットおよび特別なケーシングとしてのawait?が必要です。 これは不当であり、複雑な予算の浪費であり、 await exprに深刻な問題があることを示しています。

さらに重要なことに、Rustコード、特に標準ライブラリは、ドットとメソッド呼び出しの構文の力に重点を置いています。 awaitがプレフィックスの場合、メソッドを単純に連鎖させるのではなく、一時的なletバインディングを発明するようにユーザーに促します。 これが?が接尾辞である理由であり、同じ理由で、 awaitも接尾辞である必要があります。

さらに悪いのはawait { ... }です。 この構文は、 rustfmtに従って一貫してフォーマットされている場合、次のようになります。

    let x = await { // by analogy with `loop`
        foo.bar.baz.other_thing()
    };

これは人間工学的ではなく、関数の垂直方向の長さを大幅に膨らませます。

代わりに、 ? 、メソッドチェーンを中心とするRustエコシステムに適合するため、待機する必要があります。 いくつかの後置構文が言及されています。 それらのいくつかを見ていきます：

1. foo.await!() -これは接尾辞マクロソリューションです。 私はpostfixマクロを強く支持していますが、 https： //github.com/rust-lang/rust/issues/50547#issuecomment -454225040の@cramertjに同意します。これは、postfixもコミットしない限り実行しないで

2. foo await -これはそれほど悪くはありません。実際には接尾辞演算子（ expr op ）のように機能しますが、このフォーマットには何かが欠けているように感じます（つまり、「空」と感じます）。 対照的に、 expr? ?をexpr直接アタッチします。 ここにはスペースがありません。 これにより、 ?は視覚的に魅力的に見えます。

3. foo.await -これはフィールドアクセスのように見えると批判されています。 そしてそれは本当です。 ただし、 awaitはキーワードであるため、そのように強調表示された構文になることを覚えておく必要があります。 IDEまたは同等のGitHubでRustコードを読み取る場合、 awaitはfooとは異なる色または太字になります。 別のキーワードを使用して、これを示すことができます。

   let x = foo.match?;
   

   通常、フィールドも名詞ですが、 awaitは動詞です。

   foo.awaitについては最初の嘲笑の要素がありますが、視覚的に魅力的でありながら読みやすい構文として、真剣に検討する必要があると思います。

   ボーナスとして、 .awaitを使用すると、ドットのパワーと、 IDEでドットが通常持つオートコンプリートが得られます（56ページを参照）。 たとえば、 foo.と書くことができ、 fooが将来の場合、 awaitが最初の選択肢として表示されます。 ドットに到達することは多くの開発者が筋肉の記憶に訓練したものであるため、これは人間工学と開発者の生産性の両方を促進します。

   考えられるすべての接尾辞の構文では、フィールドアクセスのように見えることについての批判にもかかわらず、これは私のお気に入りの構文のままです。

4. foo# -これは、印章#を使用してfooを待機します。 ?も印章であり、軽量になるので、印章を検討するのは良い考えだと思います。 ?と組み合わせると、 foo#?ようになります。これで問題ありません。 ただし、 #は具体的な理由はありません。 むしろ、それはまだ利用可能な単なる印章です。

5. foo@ -別の印章は@です。 ?と組み合わせると、 foo@?ます。 この特定の印章の正当化の1つは、 a -ish（ @wait ）に見えることです。

6. foo! -最後に、 !ます。 ?と組み合わせると、 foo!?ます。 残念ながら、これには特定のWTF感があります。 ただし、 !は、「待機」に適合する値を強制するように見えます。 foo!()すでに正当なマクロ呼び出しであるという欠点があります。そのため、関数の待機と呼び出しは(foo)!()と記述する必要があります。 構文としてfoo!を使用すると、キーワードマクロ（例： foo! expr ）を持つ機会も奪われます。

もう1つの印章はfoo~です。 波は「エコー」または「時間がかかる」と理解できます。 それでも、Rust言語のどこでも使用されていません。

チルダ~は、昔はヒープ割り当てタイプに使用されていました： https ：

?は再利用できますか？ それとも魔法が多すぎますか？ impl Try for T: Futureどのようになりますか？

@parasyteはい、覚えています。 しかし、それでもそれはずっと消えていました。

@jethrogb impl Try直接機能していることを確認する方法はありません。 ?明示的にreturn Tryは、現在の関数からのawaitはyield awaitする必要があります。

たぶん?は、ジェネレーターのコンテキストで何か他のことをするために特別な場合があり、適用される式のタイプに応じてyieldまたはreturnかになります。 、しかしそれがどれほど理解できるかはわかりません。 また、どのようにしてその相互作用するFuture<Output=Result<...>> 、あなたがしなければならないlet foo = bar()??;の両方にない"のawait"とし、取得OkのバリアントをResult （または、ジェネレーターの?は、 yield 、 returnまたは単一のアプリケーションで値に解決できるトライステート特性に基づいていますか？

enum GenOp<T, U, E> { Break(T), Yield(U), Error(E) }

trait TryGen {
    type Ok;
    type Yield;
    type Error;

    fn into_result(self) -> GenOp<Self::Ok, Self::Yield, Self::Error>;
}

loop {
    match TryGen::into_result(foo) {
        GenOp::Break(val) => break val,
        GenOp::Yield(val) => yield val,
        GenOp::Return(val) => return Try::from_error(val.into()),
    }
}

残念ながら、このようなスキームでwakerコンテキスト変数を処理する方法がわかりません。おそらく、 ?がジェネレーターではなくasync特別な場合ですが、特別なものになる場合は-ここでのケースでは、他のジェネレーターのユースケースで使用できると便利です。

?再利用については@jethrogbと同じ考えでした。

@ Nemo157

impl Try直接機能していることを確認する方法はありません。 ?明示的にreturn s現在の関数からのTryの結果であり、待機はyield必要があります。

おそらく、 ?とTry特性に関する詳細が欠けていますが、それはどこで/なぜ明示されているのでしょうか。 そして、非同期クロージャのreturnは、とにかくyieldと本質的に同じではなく、ただ異なる状態遷移ですか？

たぶん?は、ジェネレーターのコンテキストで何か他のことをするために特別な場合があり、適用される式のタイプに応じてyieldまたはreturnかになります。 、しかしそれがどれほど理解できるかはわかりません。

なぜそれが混乱するのかわかりません。 ?を「継続または分岐」と考えると、当然のように思えます、私見。 確かに、関連付けられたリターンタイプに異なる名前を使用するようにTryトレイトを変更すると役立ちます。

また、それはFuture<Output=Result<...>>とどのように相互作用しますか、 let foo = bar()??ます;

結果を待ち、エラー結果を早期に終了したい場合は、それが論理式になります。 特別なトライステートTryGenはまったく必要ないと思います。

残念ながら、このようなスキームでwakerコンテキスト変数を処理する方法がわかりません。 ジェネレーターではなく非同期用に特別にケース化されていましたが、ここで特別なケースになる場合は、他のジェネレーターのユースケースで使用できると便利です。

この部分がわかりません。 詳細を教えていただけますか？

@jethrogb @rolandsteiner構造体は、 TryとFuture両方を実装できます。 この場合、どちらを?アンラップする必要がありますか？

@jethrogb @rolandsteiner構造体は、TryとFutureの両方を実装できます。 この場合、どちらをすべきですか？ アンラップ？

いいえ、それはブランケットimplのせいでできませんでした。TryforT：Future。

明示的な構築と暗黙的な待機の提案について誰も話していないのはなぜですか？ これはsyncioと同じですが、スレッドではなくタスクをブロックしているだけです。 スレッドのブロックはタスクのブロックよりも侵襲的であるとさえ言えますが、なぜthread-blocking-ioに特別な「await」構文がないのでしょうか。

しかし、それはすべて自転車のシェーディングです。少なくとも今のところ、単純なマクロ構文await!(my_future)で解決する必要があると思います。

しかし、それはすべて自転車のシェーディングです。少なくとも今のところ、単純なマクロ構文await!(my_future)で解決する必要があると思います。

いいえ、それはあたかもそれが平凡で取るに足らないものであるかのように「ただの」自転車の脱落ではありません。 awaitがプレフィックスとポストフィックスのどちらで記述されるかは、非同期コードの記述方法に基本的に影響します。 メソッドの連鎖とそれがどのように構成可能であるか。 await!(future)安定させるには、キーワードとしてのawaitを放棄する必要があり、将来的にawaitをキーワードとして使用することは不可能になります。 「少なくとも今のところ」は、後でより良い構文を見つけることができ、これに伴う技術的負債を無視することを示唆しています。 私は、後で置き換えられることを意図した構文に故意に借金を導入することに反対しています。

また、await！（future）での安定化には、キーワードとしてのawaitが放棄されるため、キーワードとしてのawaitの将来の使用が不可能になります。

try場合と同じように、次のエポックでそれをキーワードにして、マクロの生のident構文を要求することができます。

@chpio awaitは、 Rust2018のキーワードです。

@rolandsteiner

そして、非同期クロージャのreturnは、とにかくyieldと本質的に同じではなく、ただ異なる状態遷移ですか？

yieldは非同期クロージャには存在しません。これは、 async / await構文からジェネレーター/ yieldローイング中に導入された操作です。 現在のジェネレーター構文では、 yieldはreturnとはかなり異なります。ジェネレーター変換の前に?展開が行われると、いつ挿入するかがわかりません。 returnまたはyield 。

結果を待ちたい場合、nalsoがエラー結果の早い段階で終了する場合は、それが論理式になります。

論理的かもしれませんが、非同期関数を記述している多くの（ほとんどの？）ケースがIOエラーに対処するために2倍の??で満たされることは私には欠点のようです。

残念ながら、ウェイカーコンテキスト変数を処理する方法がわかりません...

この部分がわかりません。 詳細を教えていただけますか？

非同期変換は、生成されたFuture::poll関数でwaker変数を受け取ります。次に、これを変換されたawait操作に渡す必要があります。 現在、これは両方の変換が参照するstdによって提供されるTLS変数で処理されます。代わりに、 ?が_ジェネレーターレベルで_再生成ポイントとして処理された場合、非同期変換は途中で失われます。この変数参照を挿入します。

2か月前の私の好みを概説したawait構文についてのブログ投稿を書きまし

• 私の一般的な意見は、Rustはすでにその不慣れな予算を本当に伸ばしているということです。 サーフェスレベルのasync / await構文は、JavaScript、Python、またはC＃からのユーザーにできるだけ馴染みがあることが理想的です。 この観点からは、標準からわずかな方法でのみ分岐することが理想的です。 接頭辞の構文は、発散の程度によって異なります（たとえば、 foo awaitは、 foo@ようないくつかの印章よりも発散が少ない）が、接頭辞が待つよりもすべて発散しています。
• また、 !使用しない構文を安定させることも好みます。 async / awaitを扱うすべてのユーザーは、なぜawaitが通常の制御フロー構造ではなくマクロであるのか疑問に思うでしょう。ここでの話は本質的に「良い構文を理解できなかったので、落ち着いた」と思います。マクロのように見せます。」 これは説得力のある答えではありません。 !と制御フローの関連付けは、この構文を正当化するのに十分ではないと思います。 !は、かなり具体的にはマクロの拡張を意味すると思いますが、そうではありません。
• 私は一般的にpostfixawaitの利点について少し疑わしいです（完全ではなく、ただの種類です）。 待機はよりコストのかかる操作であるため、バランスは?とは少し異なると思います（分岐して1回戻るだけでなく、準備ができるまでループで譲ります）。 私は、1つの式で2〜3回待機するコードに疑いを持っています。 これらを独自のletバインディングに引き出す必要があると言っても問題ないようです。 したがって、 try!と?トレードオフは、ここではそれほど強くはありません。 しかしまた、私は人々が実際にレットに引き出されるべきではないと考えているコードサンプルを受け入れ、メソッドチェーンとしてより明確になります。

そうは言っても、 foo awaitは、これまでに見た中で最も実行可能な後置構文です。

• 後置構文については比較的よく知られています。 あなたが学ばなければならないのは、awaitは、大幅に異なる構文ではなく、Rustの式の前ではなく、式の後にあるということです。
• これにより、これまでの優先順位の問題が明確に解決されます。
• メソッドチェーンでうまく機能しないという事実は、以前に触れた理由から、デメリットではなく、ほとんどメリットのように思えます。 fooではなくawaitにメソッドが（無意味に）適用されていると本当に感じているという理由だけで、 foo await.method()を防ぐ文法規則があれば、もっとやむを得ないかもしれません（興味深いことに） foo await?ではそうは思わない）。

私はまだプレフィックス構文に傾倒していますが、 awaitは、私にとって本物のショットを持っているように感じる最初のポストフィックス構文だと思います。

補足：優先順位を明確にするために括弧を使用することは常に可能です：

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

これは必ずしも理想的ではありませんが、1行にたくさん詰め込もうとしていることを考えると、合理的だと思います。

そして、 @ earthengineが前に述べたように、複数行バージョンは非常に合理的です（余分な括弧はありません）：

let x = x.do_something() await
         .do_another_thing() await;

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

• サーフェスレベルのasync / await構文は、JavaScript、Python、またはC＃からのユーザーにできるだけ馴染みがあることが理想的です。

try { .. }場合、他の言語に精通していることを考慮に入れました。 ただし、Rustとの内部整合性のあるPOVからの正しい設計でもありました。 したがって、これらの他の言語に敬意を表して、Rustの内部整合性はより重要であるように思われ、プレフィックス構文は優先順位またはAPIの構造のいずれの点でもRustに適合するとは思いません。

• また、 !使用しない構文を安定させることも好みます。 async / awaitを扱うすべてのユーザーは、なぜawaitが通常の制御フロー構造ではなくマクロであるのか疑問に思うでしょう。ここでの話は本質的に「良い構文を理解できなかったので、落ち着いた」と思います。マクロのように見せます。」 これは説得力のある答えではありません。

私はこの感情に同意します、 .await!()はファーストクラスに十分に見えません。

• 私は一般的にpostfixawaitの利点に疑問を持っています（完全にではなく、_sort of_だけです）。 待機はよりコストのかかる操作であるため、バランスは?とは少し異なると思います（分岐して1回戻るだけでなく、準備ができるまでループで譲ります）。

letバインディングに物事を抽出することと費用がどのように関係しているかわかりません。 メソッドチェーンは高額になる可能性があり、場合によっては高額になることもあります。 letバインディングの利点は、a）読みやすさを向上させるのに意味のある名前を十分に大きい部分に付けること、b）同じ計算値を複数回参照できること（たとえば、 &xまたはタイプがコピー可能な場合）。

私は、1つの式で2〜3回待機するコードに疑いを持っています。 これらを独自のletバインディングに引き出す必要があると言っても問題ないようです。

それらが独自のletバインディングに引き出されるべきだと感じた場合でも、postfix await使用してその選択を行うことができます。

let temporary = some_computation() await?;

メソッドチェーンに同意せず、好む人のために、接尾辞await選択できます。 また、postfixは、ここでは左から右への読み取りとデータフローの順序に従う方が適切だと思います。したがって、 letバインディングに抽出する場合でも、postfixを使用することをお勧めします。

また、postfix awaitが役立つようになるまで、2、3回待つ必要はないと思います。 たとえば、（これはrustfmtの結果です）を考えてみましょう。

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

しかしまた、私は人々が実際にレットに引き出されるべきではないと考えているコードサンプルを受け入れ、メソッドチェーンとしてより明確になります。

私が読んだフクシアコードのほとんどは、 letバインディングに抽出され、 let binding = await!(...)?;と、不自然に感じられました。

• 後置構文については比較的よく知られています。 あなたが学ばなければならないのは、awaitは、大幅に異なる構文ではなく、Rustの式の前ではなく、式の後にあるということです。

ここでのfoo.await好みは、主に、優れたオートコンプリートとドットのパワーが得られるためです。 それほど根本的な違いも感じません。 foo.await.method()書くと、 .method()がfoo.await適用されることも明確になります。 したがって、それはその懸念を解決します。

• これにより、これまでの優先順位の問題が明確に解決されます。

いいえ、それは優先順位だけではありません。 メソッドチェーンも同様に重要です。

• メソッドチェーンでうまく機能しないという事実は、以前に触れた理由から、デメリットではなく、ほとんどメリットのように思えます。

メソッドチェーンでうまく機能しない理由がわかりません。

fooではなくawaitにメソッドが（無意味に）適用されていると本当に感じているという理由だけで、 foo await.method()を防ぐ文法規則があれば、もっとやむを得ないかもしれません（興味深いことに） foo await?ではそうは思わない）。

一方、意図的なデザインペーパーカットを導入し、接尾辞await構文を使用してメソッドの連鎖を防止した場合、 foo await必要はありません。

すべてのオプションに欠点があり、それでもそのうちの1つが選択されることを認める... foo.awaitについて私を悩ませていることの1つは、文字通り誤解されないと仮定しても、それです。構造体フィールドでも、構造体フィールドにアクセスしているように見えます。 フィールドアクセスの意味は、特に影響のあるものは何も起こっていないということです。これは、Rustで最も効果の低い操作の1つです。 一方待っては、ほとんど副作用のいずれかの操作性の高いインパクトである（それはI / O操作は、将来的に構築し、制御フロー効果を有するの両方を行います）。 したがって、 foo.await.method()を読んだとき、脳は.awaitをスキップするように言っています。これは比較的面白くないので、注意と努力を払ってその本能を手動で無効にする必要があります。

それでも、構造体フィールドにアクセスしているように見えます。

@glaebhoerlあなたは良い点を作ります。 しかし、構文の強調表示は、それがどのように見えるか、そしてあなたの脳が物事を処理する方法に影響を与えない/不十分ですか？ 少なくとも私にとっては、コードを読むときに色と大胆さが非常に重要なので、他のものとは異なる色の.awaitをスキップすることはありません。

フィールドアクセスの意味は、特に影響のあるものは何も起こっていないということです。これは、Rustで最も効果の低い操作の1つです。 一方、待機は非常に影響力があり、最も副作用のある操作の1つです（将来構築されるI / O操作を実行し、制御フロー効果があります）。

私はこれに強く同意します。 awaitは、 breakやreturnような制御フロー操作であり、明示的である必要があります。 提案された接尾辞表記は、Pythonのifのように不自然に感じます： if c { e1 } else { e2 }をe1 if c else e2と比較してください。 最後に演算子が表示されると、構文の強調表示に関係なく、ダブルテイクを実行できます。

また、 e.awaitがawait!(e)やawait eよりもRust構文とどのように一致しているかわかりません。 他にpostfixキーワードはありません。また、そのアイデアの1つはパーサーで特殊なケースにすることだったので、それが一貫性のある証拠ではないと思います。

@withoutboatsが言及した親しみやすさの問題もあります。 いくつかの素晴らしい利点がある場合は、奇妙で素晴らしい構文を選択できます。 しかし、接尾辞awaitはそれらがありますか？

構文の強調表示は、それがどのように見えるか、そしてあなたの脳が物事を処理する方法に影響を与えない/不十分ですか？

（良い質問ですが、ある程度の影響があると思いますが、実際に試してみないと、どれだけ推測するのは難しいです（そして、別のキーワードに置き換えることは、これまでのところしか得られません）。私が言及した前に私は、構文の強調表示は、制御フロー効果を持つすべての演算子を（ハイライトすべきだと思うことをreturn 、 break 、 continue 、 ?今...とawait ）特別な特別な色で表示されますが、私は構文の強調表示を担当しておらず、誰かが実際にこれを行っているかどうかはわかりません。）

私はこれに強く同意します。 awaitは、 breakやreturnような制御フロー操作であり、明示的である必要があります。

賛成です。 表記foo.await 、 foo await 、 foo# 、...は明示的です。 暗黙の待機はありません。

また、 e.awaitがawait!(e)やawait eよりもRust構文とどのように一致しているかわかりません。

構文e.await自体はRust構文と一致していませんが、postfixは一般的に?とRust APIの構造によく適合します（メソッドは無料の関数よりも優先されます）。

await e?構文は、 (await e)?として関連付けられている場合、 breakとreturn関連付け方法と完全に矛盾しています。 await!(e)も一貫性がありません。これは、制御フロー用のマクロがなく、他のプレフィックスメソッドと同じ問題があるためです。

他にpostfixキーワードはありません。また、そのアイデアの1つはパーサーで特殊なケースにすることだったので、それが一貫性のある証拠ではないと思います。

すでにフィールド操作として処理されているはずなので、実際にlibsyntaxを.awaitに変更する必要はないと思います。 ロジックは、resolveまたはHIRで処理され、特別な構成に変換されます。

いくつかの素晴らしい利点がある場合は、奇妙で素晴らしい構文を選択できます。 しかし、接尾辞awaitはそれらがありますか？

前述のように、メソッドの連鎖とRustのメソッド呼び出しの好みが原因であると私は主張します。

.awaitはすでにフィールド操作として処理されているはずなので、実際にはlibsyntaxを変更する必要はないと思います。

これは楽しいです。
したがって、アイデアはself / super / ...のアプローチを再利用することですが、パスセグメントではなくフィールドに使用します。

これにより、 awaitは事実上パスセグメントキーワードになります（解決されるため）。そのため、生の識別子を

#[derive(Default)]
struct S {
    r#await: u8
}

fn main() {
    let s = ;
    let z = S::default().await; //  Hmmm...
}

暗黙の待機はありません。

このアイデアは、このスレッドで数回出てきました（「暗黙の待機」提案）。

制御フロー用のマクロはありません

try! （これはその目的をかなりうまく果たしました）とおそらく非推奨のselect!ます。 awaitはreturnよりも「強力」であるため、コードで?のreturnよりも表示されることを期待するのは不合理ではありません。

私は、メソッドの連鎖とRustのメソッド呼び出しの好みが原因であると主張します。

また、プレフィックス制御フロー演算子の（より目立つ）設定もあります。

待ってますか？ 構文、（eを待つ）として関連付けられている場合？ ブレークアンドリターンアソシエートの方法と完全に矛盾しています。

私はawait!(e)? 、 await { e }?あるいはおそらく{ await e }?を好みます-後者が議論されているのを見たことがないと思います、そしてそれがうまくいくかどうかはわかりません。

私は左から右へのバイアスがあるかもしれないことを認めます。 _ノート_

これについての私の意見は、悪魔の代弁者を自分自身に演じているかのように、問題を見るたびに変わるようです。 その一部は、私が自分の先物やステートマシンを書くことに慣れているからです。 pollのカスタムフューチャーは完全に正常です。

おそらく、これは別の方法で考える必要があります。

私にとって、Rustのゼロコストの抽象化とは、実行時のゼロコストと、より重要な精神的なゼロコストの2つを指します。

先物を含むRustのほとんどの抽象化については、単なるステートマシンであるため、非常に簡単に推論できます。

この目的のために、ユーザーにほとんど魔法を導入しない単純な解決策が存在する必要があります。 彼らは不必要に魔法を感じるので、印章は特に悪い考えです。 これには、 .await魔法のフィールドが含まれます。

おそらく最良の解決策は、最も簡単なもの、元のawait!マクロです。

したがって、これらの他の言語に敬意を表して、Rustの内部整合性はより重要であるように思われ、プレフィックス構文は優先順位またはAPIの構造のいずれの点でもRustに適合するとは思いません。

どうしていいのかわからない…？ await(foo)? / await { foo }?は、演算子の優先順位とRustでのAPIの構造の点で完全に問題ないようです。その欠点は、括弧の冗長性と（視点によっては）連鎖であり、前例を壊したり、紛らわしい。

try! （これはその目的をかなりうまく果たしました）とおそらく非推奨のselect!ます。

ここでの有効な単語は非推奨だと思います。 使用してtry!(...)錆2018年にハードエラーである私たちはより良い、ファーストクラス、および接尾辞の構文を導入しているため今はハードエラーです。

awaitはreturnよりも「強力」であるため、コードで?のreturnよりも表示されることを期待するのは不合理ではありません。

?演算子も同様に（ Result以外の実装を通じて）副作用があり、制御フローを実行するため、非常に「強力」です。 それが議論されたとき、 ?は「リターンを隠している」と見落とされやすいと非難されました。 予測は完全に実現できなかったと思います。 状況再。 awaitは私とよく似ているようです。

また、プレフィックス制御フロー演算子の（より目立つ）設定もあります。

これらのプレフィックス制御フロー演算子は、 !タイプで入力されます。 一方、コンテキストimpl Try<Ok = T, ...>を受け取り、 ? Tは後置です。

どうしていいのかわからない…？ await(foo)? / await { foo }?は、演算子の優先順位とRustでのAPIの構造の点でまったく問題ないようです-

await(foo)構文は、前者に括弧が必要で後者に括弧が必要な場合、 await fooと同じではありません。 前者は前例のないものであり、後者には優先順位の問題があります。 ?ここで、ボートのブログ投稿、およびDiscordで説明しました。 await { foo }構文は、他の理由で問題があります（https://github.com/rust-lang/rust/issues/50547#issuecomment-454313611を参照）。

その欠点は、前例を壊したり混乱させたりしない、括弧と（あなたの視点に応じて）連鎖の言葉遣いです。

これが「APIは構造化されている」という意味です。 Rustでは、メソッドとメソッドチェーンが一般的で慣用的だと思います。 プレフィックスとブロックの構文は、それらと?うまく構成されていません。

私はこの意見で少数派かもしれません、もしそうなら、私を無視してください：

prefix-vs-postfixのディスカッションを内部スレッドに移動してから、結果をここに戻すのは公平でしょうか？ そうすれば、追跡の問題を維持して機能のステータスを

@seanmonstarええ、私は追跡の問題に関する議論を制限したいという願望に強く共感し、実際には単なるステータスの更新である問題を抱えています。 これは、RFCプロセスと一般的な問題の管理方法のいくつかの改訂で取り組むことができると私が望んでいる問題の1つです。 今のところ、私はここで新しい問題を開いて、議論に使用できるようにしました。

すべてにとって重要：さらにawait構文の議論はここに行くべき

await構文に関する今後の議論が適切な問題で行われるように、一時的に1日ロックします。

2019年1月15日火曜日、07：10：3​​2AM -0800に、Pauanは次のように書いています。

補足：優先順位を明確にするために括弧を使用することは常に可能です：

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

これは、postfixawaitの主な利点を打ち負かします。
書き込み/読み取り」。postfix ?ように、postfix awaitは、制御フローを許可します。
左から右に移動し続けるには：

foo().await!()?.bar().await!()

await!がプレフィックスだった場合、またはtry!がプレフィックスだった場合、または
括弧で囲むには、の左側に戻る必要があります
書き込みまたは読み取り時の式。

編集：私は電子メールで最初から最後までコメントを読んでいましたが、このメールを送信するまで「会話を他の問題に移動する」コメントは表示されませんでした。

リンクの更新： https ： https://github.com/rust-lang/rust/issues/53447が閉じられたようです。 https://github.com/rust-lang-nursery/futures-rs/issues/1199はhttps://github.com/rust-lang/rust/issues/53548に移動されたようです。

Async-awaitステータスレポート：

http://smallcultfollowing.com/babysteps/blog/2019/03/01/async-await-status-report/

async-awaitのステータスに関する簡単な更新を投稿したかった
努力。 短いバージョンは、私たちがホームストレッチにいるということです
ある種の安定化がありますが、いくつかの重要な点が残っています
克服すべき質問。

実装ワーキンググループの発表

このプッシュの一環として、私たちは
async-await実装ワーキンググループ。 このワーキンググループ
async-awaitの取り組み全体の一部ですが、
実装であり、コンパイラチームの一部です。 あなたがしたい場合
非同期を取得するのに役立ちます-フィニッシュラインを待ってください、私たちは問題のリストを持っています
私たちが間違いなく助けを求めているところ（続きを読む）。

ご興味のある方は「営業時間」をご用意しております。火曜日に予定されています（[コンパイラチームのカレンダー]を参照） -
[Zulip]に表示できるので、理想的です。 （しかし、そうでない場合は、いずれかをポップインするだけです
時間。）

..。

https://github.com/rust-lang/rust/issues/59001

std::future::Futureはいつ安定しますか？ async awaitを待つ必要がありますか？ とても素敵なデザインだと思います。コードの移植を始めたいと思います。 （厩舎で使用するシムはありますか？）

@ryは、新しい追跡の問題を参照してください： //github.com/rust-lang/rust/issues/59113

async / awaitの別のコンパイラの問題： https ：

また、上部の投稿のhttps://github.com/rust-lang-nursery/futures-rs/issues/1199が修正されたため、チェックオフできることにも注意して

HRLBと非同期クロージャに問題があるようです： //github.com/rust-lang/rust/issues/59337。 （ただし、RFCを再スキミングしても、非同期クロージャが非同期関数と同じ引数ライフタイムキャプチャの対象になることは実際には指定されていません）。

ええ、非同期クロージャにはたくさんの問題があり、安定化の最初のラウンドに含めるべきではありません。 現在の動作はclosure + asyncブロックでエミュレートできます。将来的には、返されたfutureからクロージャーのupvarsを参照できるバージョンを確認したいと思います。

現在await!(fut)ではfutがUnpin必要があることに気づきました： https ：

それは期待されていますか？ RFCに含まれていないようです。

エラーを与えるawait!はない@Ekleog 、 await!概念的に渡された先物をスタックピン留めして、 !Unpin先物を使用できるようにします（簡単な遊び場の例）。 このエラーは、 impl Future for Box<impl Future + Unpin>の制約に起因します。これにより、次のような操作を停止するには、futureがUnpinである必要があります。

// where Foo: Future + !Unpin
let mut foo: Box<Foo> = ...;
Pin::new(&mut foo).poll(cx);
let mut foo = Box::new(*foo);
Pin::new(&mut foo).poll(cx);

BoxはUnpinあり、そこから値を移動できるため、1つのヒープの場所で未来を一度ポーリングしてから、ボックスから未来を移動して新しいヒープの場所に配置し、ポーリングすることができます。もう一度。

awaitは、将来を消費するため、 Box<dyn Future>を許可するために特別な場合が必要になる可能性があります

たぶんIntoFuture特性はawait!で復活する必要がありますか？ Box<dyn Future>は、 Pin<Box<dyn Future>>変換することでそれを実装できます。

これがasync / awaitの次のバグです： async fnの戻り型の型パラメーターに関連付けられた型を使用すると推論が壊れます： //github.com/rust-lang/rust/問題/ 60414

トップポストのリストに＃60414を追加する可能性があることに加えて（まだ使用されているかどうかわからない-githubラベルを指す方が良いかもしれませんか？）、「rust-lang /の解決策」と思います。 IIRCのFuture特性が最近安定したため、rfcs＃2418」にチェックマークを付けることができます。

私はRedditの投稿から来たばかりで、postfix構文はまったく好きではないと言わざるを得ません。 そして、Redditの大多数もそれを気に入らないようです。

私はむしろ書く

let x = (await future)?

その奇妙な構文を受け入れるよりも。

チェーンに関しては、コードをリファクタリングして、 awaitを超えないようにすることができます。

また、将来のJavaScriptはこれを行うことができます（スマートパイプライン提案）：

const x = promise
  |> await #
  |> x => x.foo
  |> await #
  |> x => x.bar

プレフィックスawaitが実装されている場合、それはawaitをチェーンできないことを意味しません。

@KSXGitHubこれは実際にはこの議論の場ではありませんが、ロジックはここに概説されており、多くの人々によって何ヶ月にますhttps://boats.gitlab.io/blog/post / await-decision /

@KSXGitHub私も、最終的な構文を嫌いますが、それは広く、＃57640で議論されてきたhttps://internals.rust-lang.org/t/await-syntax-discussion-summary/ 、 HTTPS：//internals.rust- lang.org/t/a-final-proposal-for-await-syntax/ 、および他のさまざまな場所。 多くの人々がそこで彼らの好みを表明しました、そしてあなたは主題に新しい議論をもたらしていません。

ここで設計上の決定について議論しないでください。この明確な目的のためのスレッドがあります

そこでコメントする予定がある場合は、議論がすでにかなり行われていることを覚えておいてください。実質的な発言があることを確認し、スレッドで以前に発言されていないことを確認してください。

@withoutboatsは、最終的な構文がすでに合意されていることを理解しています。おそらく、それを完了としてマークするときですか？ ：赤面：

7月4日の次のベータカットに間に合うように安定させる意図はありますか、それともブロックバグを解決するには別のサイクルが必要ですか？ A-async-awaitタグの下には未解決の問題がたくさんありますが、どれだけが重要かはわかりません。

ああ、それを無視して、私はちょうどました。

こんにちは！ この機能の安定したリリースを期待する必要があるのはいつですか？ そして、それをナイトリービルドでどのように使用できますか？

@MehrdadKhnzd https://github.com/rust-lang/rust/issues/62149には、リリース予定日などに関する情報が含まれています

async fnによって生成される先物にUnpinを自動的に実装する計画はありますか？

具体的には、生成されたFutureコード自体が原因で、Unpinが自動的に使用できないのか、それとも参照を引数として使用できるのか、疑問に思っています。

@DoumanAsh非同期fnがyieldポイントでアクティブな自己参照を持たない場合、生成されたFutureはおそらく

「_this_borrowのためにUnpinはない」という非常に役立つエラーメッセージと「代わりにこの未来をボックス化できる」というヒントを伴う必要があると思います。

＃63209の安定化PRは、「すべてのブロッカーが閉じられました」と述べています。 そして8月20日に毎晩上陸したため、今週後半にベータカットに向かいました。 8月20日以降、いくつかの新しいブロッキングの問題が報告されていることは注目に値します（AsyncAwait-Blockingタグによって追跡されます）。 これらのうちの2つ（＃63710、＃64130）は、実際には安定化を妨げない便利な機能のように見えますが、他に3つの問題（＃64391、＃64433、＃64477）について説明する価値があるようです。 これらの後者の3つの問題は関連しており、それらはすべてAsyncAwait-Blocking問題＃63832に対処するために上陸したPR＃64292が原因で発生します。 PR＃64584は、問題の大部分に対処するためにすでに着陸していますが、3つの問題は今のところ未解決のままです。

銀色の裏打ちは、3つの深刻なオープンブロッカーが、コンパイルする必要があるコードに関係しているように見えるが、現在はコンパイルされていないことです。 その意味で、async / awaitのベータ化と最終的な安定化を妨げることなく、後で土地の修正と下位互換性があります。 しかし、私はその非同期を示唆するのに十分な懸念されるLANGチームから誰もがここでその何かを考えているかどうかを思ったんだけど/のawaitはそれが聞こえるかもしれ不快として、迅速なリリーススケジュールの点である、（別のサイクルのために毎晩に焼く必要があります結局）。

@bstrie 「AsyncAwait-Blocking」を再利用しているのは、「高優先度」としてそれらを示すためのより良いラベルがないためです。実際にはブロックしていません。 混乱を少なくするために、ラベル付けシステムをすぐに刷新する必要があります、cc @ nikomatsakis。

...良くありません... async-awaitを期待して1.38を逃しました。 カウントされなかったいくつかの「問題」のために、1.39を待たなければなりません...

@earthengineそれは状況の公正な評価ではないと思います。 発生した問題はすべて真剣に取り組む価値があります。 人々が実際にそれを使おうとしてこれらの問題に遭遇するのを待つだけで非同期に着陸するのは良くありません:)