Rustのnull安全性におけるunwrap(), unsafe()

Rustを勉強中の万年駆け出しエンジニアです。
日頃はTSやPHPを書いたり、PMをやっています。

先日、こちらの記事を出したのですが、
https://zenn.dev/hajimari/articles/618c900799fe90
この中でnull安全について触れている箇所があるんです。

要約すると、

Rustにはnullが存在しないため、他の言語にはない強力なnull安全を実現しています。

といった内容を書いているのですが、この記事を投稿した後にとある記事を読んで、そのコメント欄にこのような内容が書かれていました。一部を抜粋していますので、気になる方は元記事をお読みください。

Rustのnull安全を宣伝したら、「簡単にunwrapできるけどそれで安全性を保証しているの？」と言われました。メモリ安全性やスレッド安全性もunsafeを使えば簡単に壊せますが、unsafeは普段は使わないのでセーフと言えるかもしれませんが、unwrapは比較的カジュアルに使われているので、「保証」とまで言い切れるのか自信がなく、少なくとも「メモリ安全性」と比べると安全性は1段劣ってしまうのかなと感じました。

参照: Rustの実用性が理解できる図を作成してみた

確かに、Rustのunwrap()はかなりカジュアルに使用されています。
オライリーのRust本の例などでも、頻出するメソッドです。

前回投稿した記事では、Rustの表層部分についてのみ触れているので、今回はRustのnull安全性とunwrap/unsafeについて深掘りたいと思います。

null安全とは

unwrapやunsafeがnull安全に及ぼす影響を深掘る前に、「そもそもnull安全とは？」ついてもう少し詳しい定義を抑えておきます。

null値による問題（例えばnull参照エラーやnullポインタのデリファレンス）を防ぐための言語機能やプログラミング手法のことを指します。

まずはnull参照エラーについてです。
null安全を保証していないJavaScriptでの例を出します。

function getPropertyValue(obj) {
    return obj.property;
}

let obj = null;
let value = getPropertyValue(obj); // TypeError: Cannot read property 'property' of null

objはnullなのにも関わらず、その中のプロパティにアクセスしようとしてTypeErrorが発生しています。
こちらはコンパイラで検出できず、実行時にエラーが発生してプログラムがクラッシュします。

また、以下はnullポインタのデリファレンスについて、C++で例を出します。

#include <iostream>

int main() {
    int* ptr = nullptr;
    int& ref = *ptr; // 未定義動作: Nullポインタのデリファレンス
    std::cout << ref << std::endl; // この行は未定義動作の結果としてどんな挙動も起こり得る
    return 0;
}

上記の例では、C++ではnullポインタのデリファレンスを行っており、これは未定義動作（Undefined Behavior, UB）と呼ばれています。
C/C++などの言語において、"プログラムの動作が言語仕様によって定義されていない状況"のことを指します。

この場合C++のプログラムは、ここでプログラムはエラーメッセージを表示せずにクラッシュするかもしれませんし、何の問題もなく動作するように見えるかもしれません。
これはデバッグなどが困難になる原因となります。

「じゃあ、Rustにはnullが無いので最強だね、は〜い解散解散」とは問屋が卸しません。
（これは浅はかな過去の自分の姿です。戒め）

それがunwrapとunsafeの存在です。

unwrap()とは

Rustを学び始めると、高確率でこのunwrapにを見かけます。
先述しましたが、Rustのチュートリアルなどでも頻出する、かなり常連メソッドです。

エラーハンドリング周りで利用されることが多いメソッドなのですが、今回はunwrapのみに着目するためRustのエラーハンドリングについて深く言及しません。詳しくは以下の記事をお読みください。

https://qiita.com/nirasan/items/321e7cc42e0e0f238254

この記事でも取り扱っている例で説明します。

fn main() {
    let result: Result<i32, String> = Ok(2);
    println!("{:?}", result.unwrap()); //=> 2
    
    let result: Result<i32, String> = Err("error".to_string());
    println!("{:?}", result.unwrap()); //=> panic!
}

上記の例でResult.unwrap()がしていることは、Okが返却されてきた場合はOk()の中身を返却し、Errが発生した場合にはパニック^[1]を起こしてプログラムを終了させます。

つまり、unwrapを使用すると、明示的にエラーハンドリングをスキップすることを意味します。
これは以下のコードの場合、プログラムがクラッシュします。

fn main() {
    let option: Option<i32> = None;

    // `unwrap`を使用して、`Option`の中身を取り出す。
    // この場合、`option`は`None`なので、パニックが発生する。
    let value = option.unwrap();

    println!("Value is: {}", value);
}

unsafe()とは

Rustは各種安全が保証されています。詳しくは下の記事をお読みください（宣伝）。
https://zenn.dev/hajimari/articles/618c900799fe90

ただ、unsafe()を使用すると、これらの安全装置を外した状態になります。
よって、以下のような記述が可能になってしまいます。

fn main() {
    let ptr: *const i32 = std::ptr::null();
    unsafe {
        println!("{}", *ptr); // nullポインタの参照
    }
}

上記の例だと、ptrが nullポインタであるため、*ptrの逆参照は「nullアドレスにアクセスしようとする」ことになります。

自分はここで初めて、「え！？Rustでもnull存在するやないか！」と思った訳ですが、どうやらRustのnull安全性は、「nullが存在しないから」というよりも、言語の設計によって「nullが安全に扱われるようになっている」から成り立っているようです。

つまり、let ptr: *const i32 = std::ptr::null();では、*const i32型のnullポインタが生成されています。ただし、このnullポインタを扱う場合には、unsafeを利用する必要があるため、基本的には安全、ということなのだとか。

冒頭の引用した内容について

さて、ではようやく冒頭部分で挙げた内容に戻ってきます。

Rustのnull安全を宣伝したら、「簡単にunwrapできるけどそれで安全性を保証しているの？」と言われました。メモリ安全性やスレッド安全性もunsafeを使えば簡単に壊せますが、unsafeは普段は使わないのでセーフと言えるかもしれませんが、unwrapは比較的カジュアルに使われているので、「保証」とまで言い切れるのか自信がなく、少なくとも「メモリ安全性」と比べると安全性は1段劣ってしまうのかなと感じました。

上記の部分ですね。
これを部分部分に分けて考えてみようかなと思います。

順番は前後しますが、先にunsafeについてです。

unsafeを使えば簡単に壊せますが

これはこの記事の筆者様と同じ意見で、「メモリ安全性やスレッド安全性もunsafeを使えば簡単に壊せます」。
なので、そもそもすべての安全性が、プログラマが意図して破壊しない限りは安全、といった前提があります。

安全なRustは真のRustプログラミング言語です。もしあなたが安全なRustだけでコードを書くなら、型安全やメモリ安全性などを心配する必要はないでしょう。ヌルポインタやダングリングポインタ、馬鹿げた「未定義な挙動」などに我慢する必要はないのです。

Rust 裏本より

他のメモリやスレッドなどの安全性も、安全なRust（以前コメントしてくださった方は、「safe rust」と呼んでいました）が前提のもとで成り立っているのです。

ということで、たとえunsafeがあるという理由でnull安全性を脅かすことはできないでしょう。

「簡単にunwrapできるけどそれで安全性を保証しているの？」

fn main() {
    let option: Option<i32> = None;

    // `unwrap`を使用して、`Option`の中身を取り出す。
    // この場合、`some_option`は`None`なので、パニックが発生する。
    let value = option.unwrap();

    println!("Value is: {}", value);
}

上記のコード例では、unwrap()によって結果がErrの時にパニックが発生します。その場合、valueに値は入ることなく、つまりUBは起こっていません。
valueに値が入る前に安全にクラッシュするため、C++に比べてデバッグが容易になります。

Rustではnullに相当する値としてOption::Noneを利用しますが、Option::Noneを使うことを強制しているため、unwrap()使わせてUBが発生する前にクラッシュさせているのです。

Rustのnull安全性とは

自分の記事を書いてみて、他の人の記事を見て生まれた疑問をまた記事にすることで、個人的にはより深い洞察が得られたと感じています。

このあたりの議論は、結構人によっても意見が分かれる部分だと思いますので、あくまでここに書かれているのは一個人の考えです。もし他の考えをお持ちの方は、コメントなどで教えていただけますと幸いです。