@rfcbotfcpマージ

チームメンバー@withoutboatsはこれをマージすることを提案しました。 次のステップは、タグ付けされた残りのチームメンバーによるレビューです。

• [x] @Centril
• [x] @cramertj
• [x] @eddyb
• [x] @joshtriplett
• [x] @nikomatsakis
• [] @pnkfelix
• [x] @scottmcm
• [x] @withoutboats

懸念：

• https://github.com/rust-lang/rust/issues/62149#issuecomment-517418610によって解決されたimplementation-work-blocking-stabilization

レビューアの過半数が承認すると（そして最大2つの承認が未解決になると）、これが最終コメント期間に入ります。 このプロセスのどの時点でも提起されていない大きな問題を見つけた場合は、声を上げてください。

タグ付けされたチームメンバーが私に与えることができるコマンドについては、このドキュメントを参照してください。

（上記のレポートに既存のブロッカーを登録して、スリップしないようにしてください）

@rfcbotは実装-作業-ブロック-安定化に関係します

チームメンバー...これをマージすることを提案

Githubの問題（プルリクエストではない）をどのようにマージできますか？

@viボットは少し

うわー、包括的な要約をありがとう！ 私は接線方向にしかフォローしていませんが、あなたがすべての上にいると完全に確信しています。

@rfcbotレビュー

「トリアージAsyncAwait-不明な問題」を安定化ブロッカーに明示的に追加する（および/またはその懸念を登録する）ことは可能でしょうか？

私はhttps://github.com/rust-lang/rust/issues/60414が重要だと思います（明らかに、それは私のバグです：p）、少なくとも安定化の前に明示的に延期したいと思います:)

Rustチームがこの機能に注力してくれたコミュニティに感謝の意を表したいと思います。 多くの設計、議論、およびコミュニケーションのいくつかの故障がありましたが、少なくとも私、そして願わくば他の多くの人は、それを通して私たちがRustのために可能な最良の解決策を見つけたと確信しています。 ：多田：

（とはいえ、将来の可能性として、完了ベースの非同期キャンセルシステムAPIへのブリッジングに関する問題について言及したいと思います。TL; DRまだ所有されているバッファーを渡す必要があります。これはライブラリの問題ですが、1つです。言及して。）

また、完了ベースのAPIの問題についても言及したいと思います。 （コンテキストについては、この内部スレッドを参照してください）IOCPとio_uring導入を考えると、Linuxでの非同期IOの方法になる可能性があるため、それらを処理するための明確な方法を用意することが重要だと思います。 IIUCの仮想非同期ドロップのアイデアは安全に実装できず、所有バッファを渡すことは利便性が低下し、パフォーマンスが低下する可能性があります（たとえば、ローカリティが悪化したり、コピーが追加されたりするため）。

@newpavlov Fuchsiaにも同様のことを実装しましたが、非同期ドロップなしで実行することは完全に可能です。 これを行うには、いくつかの異なるルートがあります。たとえば、リソースの取得で古いリソースのクリーンアップ作業が完了するまで待機する必要があるリソースプーリングを使用する場合などです。 現在のfuturesAPIは、本番システムでこれらの問題を効果的に解決するために使用でき、使用されてきました。

ただし、この問題は、すでに安定している先物API設計と直交するasync / awaitの安定化に関するものです。 さらに質問をするか、先物-rsレポに関する議論のために問題を開いてください。

@Ekleog

「トリアージAsyncAwait-不明な問題」を安定化ブロッカーに明示的に追加する（および/またはその懸念を登録する）ことは可能でしょうか？

うん、それは私たちが毎週やっていることです。 その特定の問題（＃60414）をWRTすると、それは重要であり、修正されることを望んでいると思いますが、特に-> impl Traitすでに観察可能であるため、安定化をブロックする必要があるかどうかはまだ決定できていません

@cramertjありがとうございます！ ＃60414の問題は基本的に「エラーはすぐに発生する可能性がある」と思いますが、 -> impl Traitすると、これまで誰も気づかなかったように見えます。とにかく延期されても問題ありません。いくつかの問題があります。 :)（FWIW、それは私が両方を返す関数の中で自然なコードで発生した必要があります()場所とでT::Assoc IIRCはそれをコンパイルするために取得する私はできない作られた別の、 -ただし、＃60414を開いてからコードをチェックしていないので、私の記憶が間違っている可能性があります）

@Ekleogうん、それは理にかなっている！ なぜそれが苦痛になるのかははっきりとわかります。その特定の問題をさらに掘り下げるためにた。

編集：気にしないでください、私は1.38ターゲットを逃しました。

@cramertj

これを行うには、いくつかの異なるルートがあります。たとえば、リソースの取得で古いリソースのクリーンアップ作業が完了するまで待機する必要があるリソースプーリングを使用する場合などです。

将来の状態の一部としてバッファーを保持する場合と比較して、効率が低下しませんか？ 私の主な懸念は、現在の設計がゼロコストではなく（ async抽象化を削除することでより効率的なコードを作成できるという意味で）、完了ベースのAPIでは人間工学的ではないということです。それを修正する明確な方法はありません。 決して目立たないものではありませんが、そのようなデザインの欠陥を忘れないことが重要だと思いますので、OPで言及していただきたいと思います。

@theduke

もちろん、langチームはこれを私よりもよく判断できますが、安定した実装を確保するために1.38に遅らせることは、はるかに賢明なように思われます。

この問題は1.38を対象としています。説明の最初の行を参照してください。

@huxiありがとう、私はそれを逃した。 コメントを編集しました。

@newpavlov

将来の状態の一部としてバッファーを保持する場合と比較して、効率が低下しませんか？ 私の主な懸念は、現在の設計がゼロコストではなく（非同期抽象化を削除することでより効率的なコードを作成できるという意味で）、完了ベースのAPIで人間工学的ではなく、修正する明確な方法がないことです。それ。 決して目立たないものではありませんが、そのようなデザインの欠陥を忘れないことが重要だと思いますので、OPで言及していただきたいと思います。

いいえ、必ずしもそうとは限りませんが、async / awaitの安定化とは関係がないため、このディスカッションを別のスレッドの問題に移しましょう。

（とはいえ、将来の可能性として、完了ベースの非同期キャンセルシステムAPIへのブリッジングに関する問題について言及したいと思います。TL; DRまだ所有されているバッファーを渡す必要があります。これはライブラリの問題ですが、1つです。言及して。）

また、完了ベースのAPIの問題についても言及したいと思います。 （コンテキストについては、この内部スレッドを参照してください）Linuxでの非同期IOの方法になる可能性のあるIOCPとio_uringの導入を考慮すると、それらを処理するための明確な方法を用意することが重要だと思います。

この問題空間でのAPI設計の議論はトピックから外れるというテイラーに同意しますが、非同期/安定化待ちに関連するこれらのコメントの1つの特定の側面（および一般的なio_uringに関するこの議論）に対処したいと思います。タイミング。

io_uringは、2019年にLinuxに登場するインターフェースです。Rustプロジェクトは、4年前の2015年から先物の抽象化に取り組んでいます。 完了ベースのAPIよりもポーリングベースを優先するという基本的な選択は、2015年と2016年に行われました。2015年のRustCampで、 Carl Lercheは、基礎となるIO抽象化であるmioでその選択を行った理由について話しました。 2016年のこのブログ投稿で、 Aaron Turonは、より高いレベルの抽象化を作成することの利点について話しました。 これらの決定はずっと前に行われたものであり、私たちはそれらがなければ今のところに到達することはできませんでした。

基礎となる先物モデルを再検討する必要があるという提案は、3〜4年前の状態に戻して、その時点からやり直す必要があるという提案です。 アーロンが説明したように、より高いレベルのプリミティブにオーバーヘッドを導入することなく、完了ベースのIOモデルをカバーできるのはどのような抽象化ですか？ そのモデルを、ユーザーがasync / awaitのように「通常のRust +マイナーアノテーション」を記述できる構文にどのようにマッピングしますか？ これらのステートマシンでピンを使用して行ったように、それをメモリモデルに統合する方法をどのように処理できるでしょうか。 これらの質問への回答を提供しようとすることは、このスレッドではトピックから外れます。 重要なのは、それらに答え、正しい答えを証明することが仕事であるということです。 これまでのところ、さまざまな貢献者の間で10年間の労働年数に相当するものは、もう一度やり直す必要があります。

錆の目標は、人々が使用できる製品、そして我々が出荷しなければならないことを意味を出荷することです。 来年大事になるかもしれない将来を見据えて、それを取り入れるために設計プロセスを再開することを常に止められるわけではありません。 私たちは自分たちが置かれている状況に基づいて最善を尽くします。明らかに、大きなことをほとんど見逃していないように感じるのはイライラするかもしれませんが、現状では、a）最良の結果についての全体像もありません。 io_uringを処理するためには、b）エコシステム全体でio_uringがどれほど重要になるか。 これに基づいて4年間の作業を元に戻すことはできません。

他のスペースでは、Rustにはすでに同様の、おそらくさらに深刻な制限があります。 去年の秋にニック・フィッツジェラルドと一緒に見たもの、wasmGC統合を強調したいと思います。 wasmで管理対象オブジェクトを処理する計画は、基本的にメモリスペースをセグメント化して、管理対象外オブジェクトとは別のアドレス空間に存在するようにすることです（実際、いつかは多くの個別のアドレス空間に存在します）。 Rustのメモリモデルは、個別のアドレススペースを処理するように設計されていないだけであり、今日のヒープメモリを処理する安全でないコードは、アドレススペースが1つしかないことを前提としています。 破壊的な解決策と技術的に破壊的ではないが非常に破壊的な技術的解決策の両方をスケッチしましたが、Rustの制限に対処しているため、wasmGCストーリーが完全に最適ではない可能性があることを受け入れることが最も可能性の高い方法です。それが存在します。

ここで安定している興味深い側面は、安全なコードから自己参照構造体を利用できるようにしていることです。 これを面白くしているのは、 Pin<&mut SelfReferentialGenerator> 、ジェネレーターの状態全体を指す可変参照（ Pinフィールドとして格納されている）があり、その状態内にポインターがあることです。状態の別の部分に。 その内部ポインタは、可変参照でエイリアスします！

私の知る限り、可変参照は、別のフィールドへのポインタが指すメモリの部分に実際にアクセスするために使用されません。 （特に、自己参照以外のポインターを使用してポインター先フィールドを読み取るcloneメソッドなどはありません。）それでも、これは、コアエコシステムの他の何よりも、特にrustc自体に付属しているもの。 ここで乗っている「線」は非常に細くなっているので、可変参照に基づいて実行したいこれらの優れた最適化をすべて失わないように注意する必要があります。

特にPinはすでに安定しているため、現時点でできることはおそらくほとんどありませんが、エイリアシングが許可されているルールが最終的にどのようなものであっても、これはことを指摘する価値があります。そうではありません。 Stacked Borrowsが複雑だと思った場合は、事態が悪化することに備えてください。

Cc https://github.com/rust-lang/unsafe-code-guidelines/issues/148

私の知る限り、可変参照は、別のフィールドへのポインタが指すメモリの部分に実際にアクセスするために使用されません。

これらすべてのコルーチンタイプにDebug実装させることについて人々は話しましたが、その会話では、安全でないコードガイドラインを統合して、印刷をデバッグしても安全かどうかを確認する必要があるようです。

人々はこれらすべてのコルーチンタイプにデバッグを実装させることについて話しましたが、その会話は安全でないコードガイドラインも統合して、何が安全にデバッグできるかを確認する必要があるようです。

それはそう。 このようなDebug実装は、自己参照フィールドを出力する場合、ジェネレーター内でのMIRレベルの参照ベースの最適化を禁止する可能性があります。

ブロッカーに関する更新：

2つの高レベルブロッカーは両方とも大きな進歩を遂げており、実際には両方とも終了する可能性があります（？）。 これに関する@ cramertj @ tmandryと@nikomatsakisからの詳細情報は素晴らしいでしょう：

• 複数のライフタイムの問題は＃61775で修正されているはずです
• サイズの問題はよりあいまいです。 やるべき最適化は常にもっとありますが、明らかな指数関数的増加のフットガンを回避するという低い成果はほとんど解決されたと思いますか？

これにより、この機能を安定させる上での主要な障害として、ドキュメントとテストが残ります。 @Centrilは、機能が十分にテストまたは洗練されていないという懸念を一貫して表明しています。 @Centrilは、この機能を安定させるためにチェックオフできる特定の懸念事項を列挙した場所はありますか？

誰かがドキュメントを運転しているかどうかはわかりません。 本やリファレンスなどのツリー内のドキュメントの改善に集中したい人は誰でも素晴らしいサービスを提供するでしょう！ 先物レポやareweasyncyetのようなツリー外のドキュメントには、少し余分な時間があります。

今日の時点で、ベータ版がカットされるまで6週間あるので、これらの作業を完了するために4週間（8月1日まで）があるとしましょう。1.38をスリップしないと確信しています。

サイズの問題はよりあいまいです。 やるべき最適化は常にもっとありますが、明らかな指数関数的増加のフットガンを回避するという低い成果はほとんど解決されたと思いますか？

私はそう信じています、そして他のいくつかも最近閉鎖されました。 しかし、他にもブロッキングの問題が

@Centrilは、この機能を安定させるためにチェックオフできる特定の懸念事項を列挙した場所はありますか？

テストしたいもののリストが記載されたドロップボックスペーパーがあり、 https：//github.com/rust-lang/rust/issues/62121があり

本やリファレンスなどのツリー内のドキュメントの改善に集中したい人は誰でも素晴らしいサービスを提供するでしょう！

それはそう; 参考までにPRを確認させていただきます。 また、cc @ ehuss。

また、 async unsafe fn MVPから独自の機能ゲートに移動したいと思います。a）ほとんど使用されていない、b）特に十分にテストされていない、c）表面上、 .awaitポイントは、 unsafe { ... }を書く場所ではありません。これは、「リーク実装POV」からは理解できますが、エフェクトPOVからはそれほど理解できません。d）議論がほとんど見られず、RFCに含まれていませんでした。また、このレポート、およびe） const fnを使用してこれを実行したところ、正常に機能しました。 （機能ゲーティングPRを書くことができます）

async unsafe fnを不安定にすることは問題ありませんが、現在のデザインとは異なるデザインになってしまうことに懐疑的です。 しかし、それを理解する時間を与えるのは賢明なようです！

async unsafe fnを別の機能ゲートに移動するためのhttps://github.com/rust-lang/rust/issues/62500を作成し、ブロッカーとしてリストしました。 おそらく、適切な追跡の問題も作成する必要があると思います。

async unsafe fn別の設計に到達することに非常に懐疑的であり、安定化の最初のラウンドにそれを含めないという決定に驚いています。 安全ではないasync fnいくつか書いたので、それらをasync fn really_this_function_is_unsafe()か何かにするでしょう。 これは、呼び出しにunsafe { ... }を必要とする関数を定義できるという点で、Rustユーザーが持っている基本的な期待の回帰のようです。 さらに別の機能ゲートは、 async / awaitが未完成であるという印象に貢献します。

@cramertjは私たちが議論すべきだと思われます！ この追跡の問題が過負荷にならないようにするために、

将来のサイズに関しては、すべてのawaitポイントに影響するケースが最適化されます。 私が知っている最後の残りの問題は＃59087です。ここでは、待つ前に未来を借りると、その未来に割り当てられたサイズが2倍になる可能性があります。 これはかなり残念なことですが、それでも以前よりもかなり良くなっています。

私はその問題を修正する方法を考えていますが、これが私が理解しているよりもはるかに一般的でない限り、安定したMVPの妨げになるべきではありません。

そうは言っても、これらの最適化がフクシアに与える影響を調べる必要があります（しばらくの間ブロックされていましたが、今日または明日は解消されるはずです）。 より多くのケースを発見する可能性は十分にあり、それらのいずれかをブロックする必要があるかどうかを判断する必要があります。

@cramertj （リマインダー：私はasync / awaitを使用し、async unsafeを安定させるためではなく、async / awaitの安定化を遅らせるための議論のように聞こえます。

特にRFCに含まれていなかったため、この方法で強制された場合、別の「引数の位置に暗黙の特性」のシットストームが発生する可能性があります。

[ここで実際に議論する価値のない補足：「さらに別の機能ゲートは、async / awaitが未完成であるという印象を与える」ため、async / awaitを使用すると、数時間ごとにバグが見つかり、少数の人に広がっています。 rustcチームがそれらを修正するために合法的に必要な月数であり、それは私にそれが未完成であると言わせるものです。 最後のものは数日前に修正されました。新しいrustcでコードをコンパイルしようとしたときに、別のものが見つからないことを本当に望んでいますが…]

あなたの議論は、適切な実験と思考なしに今のところ安全でない非同期を安定させるためではなく、非同期/待機の安定化を遅らせるための議論のように聞こえます。

いいえ、それはそのための議論ではありません。 async unsafe準備ができていると思いますが、他のデザインは想像できません。 この最初のリリースにそれを含めないことには、マイナスの結果しかないと思います。 async / await全体、特にasync unsafeを遅らせることで、より良い結果が得られるとは思いません。

他のデザインは想像できません

代替設計ですが、複雑な拡張が確実に必要です。 async unsafe fnは.awaitではなく、 unsafeから.await call()です。 この背後にある理由は、 async fnが呼び出されてimpl Future作成された時点で、「安全でないことは何ことです。 そのステップが行うのは、データを構造体に詰め込むことだけです（実際、すべてのasync fnは呼び出すconstです）。 安全でない実際のポイントは、 poll未来を前進させることです。

（つまり、 unsafeが即時の場合は、 unsafe async fn方が理にかなっており、 unsafeが遅れている場合は、 async unsafe fn方が理にかなっています。）

もちろん、私たちは決して言って方法を取得しない場合は例えばunsafe FutureのすべてのメソッドどこFuture 、その後、「巻き上げ」、呼び出すことが安全ではないunsafeの作成にimpl Future 、そしてそのunsafeの契約は、結果として生じる未来を安全な方法で使用することです。 しかし、これは、 asyncブロックに手動で「脱糖」するだけでunsafe async fnなしでほぼ​​簡単に行うこともできます： unsafe fn os_stuff() -> impl Future { async { .. } } 。

ただし、それに加えて、作成時に保持する必要のないpoll ingが開始されたら、保持する必要のある不変条件を実際に存在させる方法が存在するかどうかという問題があります。 Rustでは、安全な型にunsafeコンストラクターを使用するのが一般的なパターンです（例： Vec::from_raw_parts ）。 しかし、重要なのは、構築後、タイプを誤用することは_できない_ということです。 unsafeスコープは終了しました。 この安全性の範囲は、Rustの保証の鍵です。 ポーリングの方法とタイミングの要件を備えた安全なimpl Futureを作成するunsafe async fnを導入し、それを安全なコードに渡すと、その安全なコードは突然安全でない障壁の内側になります。 そして、これは、外部コンビネータを通過する可能性が高いため、この未来をすぐに待つ以外の方法で使用するとすぐに発生する可能性があります。

これのTL; DRは、安定させる前に適切に議論する必要があるasync unsafe fnコーナーが間違いなくあることだと思います。特に、 const Traitの方向性が導入される可能性があります（ドラフトブログがあります）これを「弱い」効果システムに一般化することについての投稿（ fn -modifyingキーワード）。 ただし、 unsafe async fnは、実際には、安定するためにunsafeの「順序付け」/「配置」について十分に明確である可能性があります。

エフェクトベースのunsafe Future特性は、今日の言語やコンパイラで表現する方法を知っているものの手の届かないところにあるだけでなく、追加のエフェクトのために最終的にはより悪い設計になると思います-コンビネータが必要とする多型。

async fnが呼び出され、impl Futureが作成される時点では、安全でないことは何もできません。 そのステップが行うのは、データを構造体に詰め込むことだけです（事実上、すべてのasync fnはconstを呼び出します）。 安全でない実際のポイントは、世論調査で未来を前進させることです。

これは、以来、事実だasync fn前にあることにすべてのユーザーコードを実行することはできません.await編をするまで、すべての未定義の動作が可能性が遅れることになる.await呼ばれました。 ただし、UBのポイントとunsafe tyのポイントには重要な違いがあると思います。 unsafe tyの実際のポイントは、API作成者が、静的に検証できない不変条件のセットが満たされることをユーザーが約束する必要があると判断した場合、それらの不変条件に違反した結果がUBを引き起こさない場合でもです。後で他の安全なコードで。 この一般的な例の1つは、安全なメソッド（正確にはこれが何であるか）を使用してトレイトを実装する値を作成するunsafe関数です。 これは、たとえば、実装がunsafe不変条件に依存するVisitor -trait-implementing型を、型を構築するためにunsafeを要求することにより、適切に使用できるようにするために使用されます。 他の例には、 slice::from_raw_partsようなものが含まれます。これ自体はUBを引き起こしませんが（型の有効性の不変条件は別として）、結果のスライスへのアクセスは引き起こします。

async unsafe fnがここでユニークで興味深いケースを表しているとは思いません。これは、 unsafe要求することにより、安全なインターフェイスの背後でunsafe動作を実行するための確立されたパターンに従います。コンストラクタ。

@cramertjあなたがこれについて議論しなければならないという事実（そして私は現在の解決策が悪いものだと思う、または私がより良い考えを持っていると私は示唆していません）は、私にとって、この議論はさびを気にする人が従うべき場所：RFCリポジトリ。

念のため、Readmeからの引用：

次の場合は、このプロセスに従う必要があります[...]：

• バグ修正ではない言語へのセマンティックまたは構文の変更。
• [...そして引用されていないもの]

現在のデザインに変更が生じると言っているわけではありません。 実は、数分考えてみると、思いつく限り最高のデザインだと思います。 しかし、プロセスは私たちの信念がRustにとって危険になるのを避けることを可能にするものであり、RFCリポジトリをフォローしているが、ここでのプロセスに従わないことによってすべての問題を読んでいない多くの人々の知恵を失っています。

プロセスに従わないことが理にかなっている場合があります。 ここでは、2週間のFCP遅延を回避するためだけに、プロセスを無視する必要がある緊急性は見当たりません。

ですから、錆がコミュニティに正直に言って、それが独自のreadmeで与える約束について正直に言ってください。そして、少なくとも受け入れられたRFCがあり、できれば実際にそれがさらに使用されるまで、その機能を機能ゲートの下に置いてください。 それがasync / await機能ゲート全体であろうと、安全でない非同期機能ゲートだけであろうと、私は気にしませんが、（AFAIK）async-wgを超えてほとんど使用されておらず、コミュニティ全体。

私は本の参考資料で最初のパスを書いています。 途中で、async-await RFCが、 ?演算子の動作がまだ決定されていないと言っていることに気づきました。 それでも、非同期ブロック（遊び場）では正常に機能しているようです。 それを別の機能ゲートに移動する必要がありますか？ それとも、それはある時点で解決されましたか？ 安定化レポートには表示されませんでしたが、見落とした可能性があります。

（私はZulipでもこの質問を

はい、 return 、 break 、 continueの動作とともに議論および解決されました。 al。 これらはすべて「唯一可能なこと」を実行し、クロージャ内での動作と同じように動作します。

let f = unsafe { || {...} };も安全に呼び出すことができ、IIRCはunsafeをクロージャーの内側に移動するのと同じです。
unsafe fn foo() -> impl Fn() { || {...} }についても同じです。

これは、私にとって、「 unsafeスコープを離れた後に危険なことが起こる」ための十分な前例です。

同じことが他の場所にも当てはまります。 以前に指摘したように、 unsafeは、潜在的なUBが存在する場所であるとは限りません。 例：

    let mut vec: Vec<u32> = Vec::new();

    unsafe { vec.set_len(100); }      // <- unsafe

    let val = vec.get(5).unwrap();     // <- UB
    println!("{}", val);

私には安全ではないという誤解のように思えます。安全ではないということは、「ここで安全でない操作が発生した」ということではなく、「ここで必要な不変条件を支持していることを保証している」ということです。 待機ポイントで不変条件を支持している可能性がありますが、変数パラメーターが含まれていないため、不変条件を支持していることを確認するための非常に明白なサイトではありません。 呼び出しサイトで不変条件を維持することを保証することは、はるかに理にかなっており、安全でないすべての抽象化がどのように機能するかとはるかに一貫しています。

これは、安全でないことを効果として考えることが不正確な直感につながる理由に関連しています（ラルフが昨年そのアイデアが最初に提起されたときに主張したように）。 安全性は、具体的には、意図的に、感染性ではありません。 他の安全でない関数を呼び出し、その不変条件を呼び出しスタックに転送するだけの安全でない関数を作成することはできますが、これは安全でない関数が使用される通常の方法ではなく、実際には、値のコントラクトを定義して手動でチェックするために使用される構文マーカーです。あなたはそれらを支持します。

したがって、すべての設計決定にRFC全体が必要なわけではありませんが、決定がどのように行われるかについて、より明確で構造を提供するように取り組んできました。 この号の冒頭の主要な決定点のリストはその一例です。 私たちが利用できるツールを使用して、安全でない非同期fnsのこの問題に関する構造化されたコンセンサスポイントを突き刺したいので、これは世論調査を含む要約投稿です。

async unsafe fn

async unsafe fnsは、安全でないブロック内でのみ呼び出すことができる非同期関数です。 彼らの体の中は危険なスコープとして扱われます。 主な代替設計は、非同期安全ではないFNS危険な待つのではなく、への呼び出しを行うことであろう。 呼び出すのが安全でない設計を好む確かな理由はいくつかあります。

1. これは、呼び出すのも安全ではない非同期の安全でないfnsの動作と構文的に一致しています。
2. これは、一般的に安全でないことがどのように機能するかとより一致しています。 安全でない関数は、呼び出し元によって支持されているいくつかの不変条件に依存する抽象化です。 つまり、「安全でない操作が発生する場所」をマークすることではなく、「不変条件が維持されることが保証される場所」をマークすることについてです。 引数が選択されて検証されたときとは別に、待機サイトよりも、引数が実際に指定されている呼び出しサイトで不変条件が支持されていることを確認する方がはるかに賢明です。 これは一般的に安全でない関数ではごく普通のことであり、他の安全な関数が正しいと期待する状態を決定することがよくあります。
3. これは、async fnシグニチャの脱糖の概念とより一貫性があり、async修飾子を削除して、将来的に戻り型をラップするのと同等のシグニチャをモデル化できます。
4. 代替案は、短期的または中期的（数年を意味する）で実施することは実行可能ではありません。 現在設計されているRust言語でポーリングするのが安全でない未来を作成する方法はありません。 ある種の「効果としての安全でない」は、広範囲にわたる影響を及ぼし、現在すでに存在する安全でないものとの下位互換性（通常の安全でない関数やブロックなど）に対処する必要がある大きな変更になります。 非同期の安全でないfnsを追加しても、その状況は大きく変わりませんが、現在の安全ではないという解釈の下での非同期の安全でないfnsには、短期および中期的に実際の実用的なユースケースがあります。

@rfcbot ask lang「安定化非同期安全でないfnを、呼び出すのが安全でない非同期fnとして受け入れますか？」

rfcbotで投票する方法がわかりませんが、少なくとも指名しました。

チームメンバー@withoutboatsがチームに質問しました：T-lang、コンセンサスのために：

「安定化非同期安全でないfnを、呼び出すのが安全でない非同期fnとして受け入れますか？」

• [x] @Centril
• [x] @cramertj
• [x] @eddyb
• [] @joshtriplett
• [x] @nikomatsakis
• [] @pnkfelix
• [] @scottmcm
• [x] @withoutboats

@withoutboats

安全でない非同期fnsのこの問題に関する構造化されたコンセンサスポイントを突き刺したいので、これは投票付きの要約投稿です。

記事をありがとう。 議論の結果、今日は毎晩機能するasync unsafe fnが正しく動作することを確信しました。 （まばらに見えたので、おそらくいくつかのテストを追加する必要があります。）また、レポートの一部とasync unsafe fn動作の説明を使用して、レポートの上部を修正してください。

これは、一般的に安全でないことがどのように機能するかとより一致しています。 安全でない関数は、呼び出し元によって支持されているいくつかの不変条件に依存する抽象化です。 つまり、「安全でない操作が発生する場所」をマークすることではなく、「不変条件が維持されることが保証される場所」をマークすることについてです。 引数が選択されて検証されたときとは別に、待機サイトよりも、引数が実際に指定されている呼び出しサイトで不変条件が支持されていることを確認する方がはるかに賢明です。 これは一般的に安全でない関数ではごく普通のことであり、他の安全な関数が正しいと期待する状態を決定することがよくあります。

あまり注意を払っていない人として、私は同意し、ここでの解決策は優れたドキュメントだと思います。

私はここでマークから外れているかもしれませんが、それを考えると

• 先物は本質的に組み合わせであり、構成可能であることが基本です。
• 将来の実装内の待機ポイントは、通常、目に見えない実装の詳細です。
• 将来は実行コンテキストから非常に離れており、実際のユーザーはルートではなく中間にある可能性があります。

特定の待機中の使用法/動作に依存する不変条件は、悪い考えと安全であると判断することは不可能の間のどこかにあるように私には思えます。

待機中の出力値が不変条件の維持に関係している場合がある場合、将来は、次のように、安全でないアクセスを必要とするラッパーである出力を持つ可能性があると思います。

struct UnsafeOutput<T>(T);
impl<T> UnsafeOutput<T> {
    unsafe fn unwrap(self) -> T { self.0 }
}

この「初期の安全ではない」のunsafeネスがasyncネスの前にあることを考えると、修飾子の順序がasync unsafe fnよりもunsafe async fn方がはるかに幸せです。 async unsafe fn 、 unsafe (async fn)は、 async (unsafe fn)よりも明らかにその動作にマッピングされるためです。

どちらも喜んで受け入れますが、ここで公開されているラッピングの順序は外側にunsafeがあると強く感じており、修飾子の順序がこれを明確にするのに役立ちます。 （ unsafeの改質剤であるasync fn 、ではないasyncに修飾子unsafe fn ）。

どちらも喜んで受け入れますが、ここで公開されているラッピングの順序は外側にunsafeがあると強く感じており、修飾子の順序がこれを明確にするのに役立ちます。 （ unsafeの改質剤であるasync fn 、ではないasyncに修飾子unsafe fn ）。

私はあなたの最後の括弧で囲まれたポイントまであなたと一緒にいました。 @withoutboatsの記事は、安全性がコールサイトで処理された場合、実際に持っているのはunsafe fn （非同期コンテキストで呼び出される）であることを私にはっきりと示しています。

バイクシェッドasync unsafe fnをペイントすると思います。

async unsafe fn方が理にかなっていると思いますが、非同期、安全でない、定数の間の任意の順序を文法的に受け入れる必要があるとも思います。 しかし、 async unsafe fnは、非同期を削除し、戻りタイプを「脱糖」に変更するという概念で、私にはより理にかなっています。

代替案は、短期的または中期的（数年を意味する）で実施することは実行可能ではありません。 現在設計されているRust言語でポーリングするのが安全でない未来を作成する方法はありません。

FWIW unsafe fn内のクロージャと関数特性に関して、 unsafe async fnが安全なpollメソッドでFuture unsafe async fnを返すとは思っていませんでしたが、代わりにunsafe UnsafeFutureを返しました。ポーリングメソッド。 （*） unsafe { }ブロック内で使用されている場合、 .awaitをUnsafeFuture .awaitでも機能させることができますが、それ以外の場合は機能しません。

これらの2つの将来の特性は、現在の特性に関して大きな変化であり、おそらく多くの構成可能性の問題を引き起こすでしょう。 したがって、代替案を模索するための船はおそらく出航しました。 特に、これは今日のFnトレイトの動作とは異なるため（たとえば、 UnsafeFnトレイトなどがなく、 RFC2585での私の問題は、 unsafe fn内にクロージャーを作成することimpls Fn()クロージャーを返します。つまり、このクロージャーは安全でない関数を呼び出すことができますが、安全に呼び出すことができます。

「安全でない」未来や閉鎖を作成することは問題ではありません。問題は、そうすることが安全であることを証明せずにそれらを呼び出すことです。特に、彼らのタイプがこれを行う必要があると言っていない場合はそうです。

（*）すべてのFutureにUnsafeFuture包括的実装を提供できます。また、 UnsafeFutureにunsafeメソッドを提供してそれ自体を「アンラップ」することもできます。 Futureに安全であるpoll 。

これが私の2セントです：

• @cramertjの説明（https://github.com/rust-lang/rust/issues/62149#issuecomment-510166207）は、 unsafe非同期関数が正しい設計であることを私に確信させます。
• 私はキーワードunsafeとasync固定された順序を非常に好みます
• 順序付けはより論理的であるように思われるため、 unsafe async fnの順序付けを少し好みます。 「高速電気自動車」と「電気高速自動車」に似ています。 主な理由は、 async fn fn脱糖するためです。 したがって、2つのキーワードが隣り合っていることは理にかなっています。

let f = unsafe { || { ... } }はf安全にするべきであり、 UnsafeFn特性は決して導入されるべきではなく、先験的な.await ingとasync unsafe fnは安全な。 UnsafeFutureは、強力な正当化が必要です。

unsafeは明示的である必要があり、Rustはあなたを安全な土地に戻す必要があるため、これはすべて続きます。 また、このトークンによって、 fの...は安全でないブロックではなく、 https：//github.com/rust-lang/rfcs/pull/2585を採用し、 async unsafe fnは安全なボディである必要があります。

この最後の点はかなり重要だと思います。 すべてのasync unsafe fnがunsafeブロックを使用する可能性がありますが、同様にほとんどの場合、安全性分析の恩恵を受け、多くの場合、間違いを犯しやすいほど複雑に聞こえます。

特にクロージャをキャプチャするときは、ボローチェッカーをバイパスしないでください。

だからここに私のコメント： https ：//github.com/rust-lang/rust/issues/62149#issuecomment-511116357は非常に悪い考えです。

UnsafeFuture特性では、発信者は将来をポーリングするためにunsafe { }を書き込む必要がありますが、たとえばBox<dyn UnsafeFuture>を取得した場合、発信者はそこでどの義務を証明する必要があるかわかりません。 unsafe { future.poll() }安全ですか？ すべての未来のために？ わからない。 したがって、 @ rpjohnstが同様のUnsafeFn特性の不和について指摘したように、これは完全に役に立たないでしょう。

Futureを常にポーリングに対して安全であるように要求することは理にかなっており、ポーリングに対して安全でなければならないFutureを構築するプロセスは安全でない可能性があります。 それがasync unsafe fnだと思います。 ただし、その場合、 fnアイテムは、返された未来を安全にポーリングできるように、何を支持する必要があるかを文書化できます。

@rfcbotの実装-作業-ブロック-安定化

私の知る限り、まだ2つの既知の実装ブロッカーがあり（https://github.com/rust-lang/rust/issues/61949、https://github.com/rust-lang/rust/issues/62517）、それでもいくつかのテストを追加するのは良いことです。 rfcbotが時間的にブロッカーにならないようにするという懸念を解決し、代わりに実際に修正をブロックします。

@rfcbotは実装-作業-ブロック-安定化を解決します

：bell：上記のこれは現在、最終コメント期間に入っています。 ：ベル：

https://github.com/rust-lang/rust/pull/63209に安定化PRを提出しました

上記のマージする傾向のある最後のコメント期間が完了しました。

ガバナンスプロセスの自動化された代表として、著者と他のすべての貢献者に感謝します。

RFCはまもなくマージされます。

ここで安定している興味深い側面は、安全なコードから自己参照構造体を利用できるようにしていることです。 これを興味深いものにしているのは、Pin <＆mut SelfReferentialGenerator>に、ジェネレーターの状態全体を指す可変参照（Pinのフィールドとして格納されている）があり、その状態内に状態の別の部分を指すポインターがあることです。 。 その内部ポインタは、可変参照でエイリアスします！

これのフォローアップとして、 @ comexは実際に、 LLVMのnoaliasアノテーションに違反する（安全な）非同期Rustコードを、現在の方法でことに成功しました。 ただし、TLSを使用しているためと思われ、現在、誤コンパイルはありません。