Rust APIのunsafe_codeをallowにする
#773
Conversation
unsafe_codeをallowにするunsafe_codeをallowにする
|
恩恵で言えば、個人的には率直に言って今となってはゼロに近いと思っています。unsafeなコードは厳重に扱われるべきであるし数も減らすべきですが、それに対して 例として、あるクレート内に次のコードがあるとします。 unsafe {
external_c_function();
}このクレート全体に +#[allow(unsafe_code)]
unsafe {
external_c_function();
}この unsafeコードを記述する敷居を高くしたいのであれば、このようなコメントを書く文化がRustにはあります。こういうコメントを書く方に倒した方がよいと思います。 unsafe {
+ // SAFETY: This is safe because:
+ // 1. …
+ // 2. …
external_c_function();
}#175 の当時は今で言うcrates/voicevox_core_c_apiの部分がcrates/voicevox_core内に含まれており、 ちなみにですが
個人的には明確かつ正しい内容のsafetyコメントが本当に書けて、かつUnsafe Rustに手を出す妥当な理由が存在するのであれば、unsafeなコードを含むプルリクを受け付けてもよいと思っています。その判断はむしろレビューの段階の方がよいのではないかと。最終的にunsafeなコードを拒否することになるにせよ、建設的な議論の末にそうなると信じています。 以上は短時間でざっと書いたものなので、必要であれば追加の補足をしたいと思います。 |
|
なるほどです、詳しくありがとうございます！！ 説明かコメントを求める方向が良いのかなと思いました！ クレート分離もなるほどです。 unsafeな理由と、それでも大丈夫な理由はコメントに書く文化、取り入れていきたいなと感じました。 |
OS毎というよりは、Linux版の実装と一緒にVOICEVOX/gpu-list-rsみたいな感じで分離という形がちょうどいいかなと思っています。
問題になることがあるなら、極端なケースだと「次のC++コードをRustに翻訳してください」みたいな指示をもとにChatGPTかCopilotが生成したコードをそのままPRとしてお出しされたときですかね？そういう場合にも確かにガイドラインは効きそうではありますね。 書くとしたら、「unsafeをそこまで忌避している訳では無い。ただし一般的なRustのプロジェクトと同様、本当に必要な時に限る。とりあえずRustonomiconとTwo Kinds of Invariantsは読め。話はそれからだ」みたいな感じがいいかなと思っています。 |
|
単純に初学者の方で、unsafeは避けるべきと知らなかったとかはありそうかもです。 |
内容
crates/voicevox_coreに対する#175を取り消します。理由は次の通りです。
#![forbid(unsafe_code)]と異なり、#![deny(unsafe_code)]は実質的に何の効力も無い関連 Issue
その他