安定化レポートテンプレート
これは何か?
これは、言語機能の安定化レポート用のテンプレートです。各質問は、最も頻繁に必要とされる詳細を引き出すことを目的としています。これらの詳細は、レビュー担当者が潜在的な問題を事前に特定するのに役立ちます。テンプレートのすべての部分が、すべての安定化に当てはまるわけではありません。質問が当てはまらない場合は、その理由を簡潔に説明してください。
区切り線より後ろをすべてコピーし、Markdownとして編集してください。各TODOをあなたの回答に置き換えてください。
安定化レポート
概要
この機能が何であり、どのような価値を提供するのかを思い出させてください。この安定化に至るまでの経緯を説明してください。
例として、以下を参照してください。
TODO
追跡:
- TODO(追跡issueへのリンク。)
Reference PR:
- TODO(Reference PRへのリンク。)
cc @rust-lang/lang @rust-lang/lang-advisors
安定化されるもの
安定化される各挙動を説明し、今後受理されるようになるコードの短い例を示してください。
#![allow(unused)]
fn main() {
todo!()
}
安定化されないもの
安定化されない機能の部分を説明してください。今後何を行いたい可能性があるのか、またそのためにどのような扉を開いたままにしているのかについて述べてください。安定化しない内容がユーザーに驚きをもたらす可能性がある場合は、特にその点について述べてください。
設計
Reference
Referenceにどのような更新が必要ですか?各PRにリンクしてください。Referenceにこの機能を説明するために必要な内容が欠けている場合は、その点を議論してください。
- TODO
RFCの履歴
この機能について、どのRFCが受理されていますか?
- TODO
未解決の質問への回答
RFCによって未解決のまま残された質問は何ですか?それらにはどのように回答されましたか?関連するlangの決定があればリンクしてください。
TODO
RFC後の変更
RFCが受理されて以降、その他にどのようなユーザーから見える変更が発生しましたか?langチームが受理した変更(およびそれらの決定へのリンク)と、この安定化レポートで初めてチームに提示される変更の両方を説明してください。
TODO
重要なポイント
どの決定が最も困難で、安定化される挙動のうちどれが最も議論を呼びましたか?すべての立場における主要な主張を要約し、以前の文書や議論にリンクしてください。
TODO
Nightly拡張
この機能には、まだ不安定なまま残っている拡張がありますか?私たちがそれらに誤ってコミットしていないことを、どのように確認していますか?
TODO
閉じられる扉
この安定化によって、言語に対する将来の変更について、どのような扉が閉じられますか?たとえば、この安定化によって、他のRFC、lang実験、または進行中であることが知られている提案を後で実施することがより困難または不可能になりますか?
フィードバック
テストの呼びかけ
「テストの呼びかけ」は行われましたか?行われた場合、どのようなフィードバックが得られましたか?
TODO
Nightlyでの使用
既知のnightlyユーザーはこの機能を使用していますか?GitHub上でgrepを使って
#![feature(FEATURE_NAME)]のインスタンス数を数えると参考になるかもしれません。
TODO
実装
主要部分
実装の主要部分を要約し、コード内の該当箇所や関連するPRへのリンクを示してください。
例として、async closuresの主要部分についての次の内訳を参照してください。
TODO
カバレッジ
この機能のテストカバレッジを要約してください。
この機能の「境界」がどこにあるかを考慮してください。私たちは特に、近接するもののうち正確に何を安定化しないのかについて確信を与えるテストを見ることに関心があります。もちろん、テストはこの機能が機能することを包括的に実証するべきです。よくある間違いが行われた場合や機能が誤って使用された場合に見られる診断を実証することも考えてください。
各テスト内では、テストの目的と、それが実証しようとする不変条件の集合を説明するコメントを先頭に含めてください。これは私たちのレビューにとって大いに助けになります。
テストカバレッジにおける既知または意図的なギャップを説明してください。
テストフォルダおよび個々のテストへのリンクを示し、文脈を説明してください。
TODO
未解決のバグ
この機能に関係する未解決のバグは何ですか?それらを列挙してください。そのいずれかが安定化をブロックするべきですか?その理由、またはそうでない理由を議論してください。
TODO
- TODO
- TODO
- TODO
未解決のFIXME
その機能に関して、コード内にまだどのようなFIXMEが残っており、それらを残しておいて問題ないのはなぜですか?
TODO
ツールの変更
この機能をサポートするために、他のツールにどのような変更を加える必要がありますか。この作業は完了していますか?関連するPRやissueがあればリンクしてください。
- rustfmt
- TODO
- rust-analyzer
- TODO
- rustdoc(JSONとHTMLの両方)
- TODO
- cargo
- TODO
- clippy
- TODO
- rustup
- TODO
- docs.rs
- TODO
TODO
破壊的変更
この安定化が既知の破壊的変更を表す場合は、craterレポート、craterレポートの分析、およびこの破壊的変更の影響を受けるエコシステムプロジェクトに対して私たちが作成したすべてのPRにリンクしてください。把握または修正できることの制限について議論してください。
TODO
Craterレポート:
- TODO
Crater分析:
- TODO
影響を受けるcrateへのPR:
- TODO
- TODO
- TODO
型システム、opsem
コンパイル時チェック
未定義動作を防ぐために必要な、どのようなコンパイル時チェックが行われますか?
これらのチェックが行われていることを実証するテストにリンクしてください。
TODO
- TODO
- TODO
- TODO
型システムのルール
この機能ではどのような型システムのルールが強制され、それぞれの目的は何ですか?
TODO
デフォルトで健全か?
この機能の実装は、UBを防ぐために特定のチェックを必要としますか?それともデフォルトで健全であり、危険な操作やunsafeな操作を実行するには特定のオプトインが必要ですか?デフォルトで健全でない場合、その根拠は何ですか?
TODO
AMを破るか?
ユーザーはこの機能を使用して未定義動作を導入できますか?または、この機能を使用してRustの抽象化を破り、基礎となるアセンブリレベルの実装を露出させることができますか?該当する場合はその点を説明してください。
TODO
一般的な相互作用
一時値
この機能は、一時値を生成できる新しい式を導入しますか?それらの一時値のスコープは何ですか?
TODO
Drop順序
この機能は、値をどの順序でdropすべきかについて疑問を生じさせますか?ここで行われた決定と、それらが以前の決定とどのように一貫しているかについて述べてください。
TODO
展開前 / 展開後
この機能は、展開前(例:
#[cfg(false)]で覆われたコード内)に何を受理すべきかと、展開後に何を受理すべきかについて疑問を生じさせますか?これについてどのような決定が行われましたか?
TODO
Edition hygiene
この機能がeditionでゲートされている場合、トークンのedition hygieneの文脈で、コードを受理するか拒否するかをどのように判断しますか?たとえば、判断にはどのトークンを使用しますか?
TODO
SemVerへの影響
この機能は、ライブラリ作者がマイナーバージョンリリースを行う際に、下流を壊さないよう注意しなければならない新たな方法を生み出しますか?それらを説明してください。これらの新たな危険性は、RFC 1105 に照らして「メジャー」ですか、それとも「マイナー」ですか?
TODO
他の機能の露出
この機能によって、他の不安定な機能の挙動が何らかの形で露出する可能性はありますか?その中で最もリスクが高い機能は何ですか?
TODO
履歴
ここに至った経緯を理解するうえで重要な issue と PR を列挙してください。
- TODO
- TODO
- TODO
謝辞
表彰のため、またそれらの人々に安定化について通知されるように、この機能への貢献者を名前で要約してください。この作業に関わった人の中で、これを今すぐ安定化すべきではないと考えている人はいますか?もしそうであれば、その点について知らせてください。
TODO
未解決項目
まだ完了しておらず、これが安定化される前に完了すべき既知の項目を列挙してください。
- TODO
- TODO
- TODO