Rust はコストのかかるコードを書くのが苦痛になるようにデザインされている(？)

Rust は「コストのかかるコードは書くのが苦痛であるべき」という思想のもとデザインされている気がする。
というのも Rust を書いていると「意図的にショートカットが用意されていない」と思える場面があるからだ。

いくつか例を挙げてみようと思う。

文字列の連結

String 型の変数 s を所有しているときに、s の 後ろに 文字列リテラルを連結するのは簡単だ。+ 演算子で文字列の連結ができる。

let mut s = String::from("hello");
s = s + ", world";
println!("{}", s);  // => hello, world

一方で s の 前に 連結するには一手間必要になる。

let mut s = String::from("world");
s = "hello, ".to_string() + &s;
println!("{}", s);  // => hello, world

+ 演算子の左オペランドは String でなければいけないので "hello, " をそのまま置くことはできない。.to_string() メソッドで String 型に変換している。¹
右オペランドは &str 型でなければいけないので &s として &str に変換している。

文字列の連結がなぜこんなにも左右非対称なのか、実装を追ってみよう。

+ 演算子の挙動は Add trait を実装することで定義される。

doc.rust-jp.rs

Rust では Add<&str> for String が定義済みなので + 演算子を使って String 型と &str 型が連結できる。
他方で Add for &str は未定義なので、&str 型と String 型の連結はできない。²

これによって String 型の変数 s を後ろに伸ばしていくのは簡単で、前に伸ばしていくためには冗長な記述が必要という非対称性が生まれている。

このような状況はおそらく意図的で。&str + String がシンプルに書けないのは &str + String を実行するのにコストが大きいからだ。

Rust の String 型は内部的に Vec として実装されている。Vec は「8ビット非負整数の可変長配列」だ。

Vec はデータを前から詰めて保持するために、後ろに伸ばすのは容易で前に伸ばすのにはコストがかかる。String 内部的には Vec なので同じ制約下にあるはずだ。

ちなみにここで言う「前に伸ばすのにはコストがかかる」というのは、連結後の文字列が収まるメモリを別の場所に確保してから連結後の文字列を配置し直す必要があるということだ。
String + &str はあらかじめ確保していたメモリに連結後の文字列が収まらなかったときだけ再配置すればいい一方で、&str + String は 毎回かならず メモリの再配置が必要になる。

そういう都合で String + &str は簡単に書けて、&str + String には意図的にショートカットが用意されていないんじゃないだろうか。

ユーザー定義型は (可能であっても) 自動的には Copy にならない

2つめの例は値の複製について。

Rust には言わずと知れた所有権システムがある。*1
Rust の基本戦略は値を所有している変数を一つだけに制限して、できるだけ借用 (参照) で間に合わせるというものだ。

そのため Rust の代入は基本的に所有権を移動 (ムーブ) させる。

let x = vec![1, 2, 3];
let y = x;  // ここでムーブが発生し x は所有権を失う
println!("{:?}", x);
//               ^ エラー: ムーブ済みの値を借用しようとしている

この制限を回避する方法はいくつかある。

1. 変数を .clone() する
2. 型を Copy にしておく
3. Rc などの型で包む

いちばんよく使われるのは 1. だろう。
Rust の多くの型は .clone() メソッドを実装していて、値を複製して別の変数に渡すことができる。

let x = vec![1, 2, 3];
let y = x.clone();  // x を複製して値の所有権を y に渡す
println!("{:?}", x);  // => [1, 2, 3] 
//              ^ OK: x の所有権は失われていない

.clone() はお手軽だが、所有権がムーブする箇所で一々 .clone() をタイプするのは面倒でもある。もし型が Copy trait を実装していれば .clone() を省略できる。
Copy trait を実装した型は所有権がムーブするタイミングで自動的に値が複製される。元の変数が所有権を失うことはない。

let x = 42;  // 42: u8 は Copy trait を実装している
let y = x;   // .clone() を書かなくても自動的に複製される
println!("{:?}", x);  => 42
//              ^ OK: x の所有権は失われていない

char, bool, u8 などが Copy になっている。
さらに Copy な型を組み合わせたタプルもまた Copy になる。例えば (char, bool, u8) は Copy だ。

let x = ('🦀', true, 42);  // (char, bool, u8) は Copy になる
let y = x;                 // .clone() を書かなくても自動的に複製される
println!("{:?}", x); // => ('🦀', true, 42)
//              ^ OK: x の所有権は失われていない

Copy な型はいわば .clone() を免除されているわけだ。
これは「Copy な型が占有するメモリ」が「それの参照が占有するメモリ」に比べて充分に小さいからだ。

Rust において char は4バイト, bool は1バイト, u8 は1バイトだ。一方それらの参照である Box, Box, Bool のサイズはどれも1バイトだ。
u8 な値を二つの変数に持たせるのに、値そのものを持たせるのも片方に参照を持たせるのもメモリサイズは変わらない。
参照を持たせることで節約にはならないし、暗黙に .clone() したとしても無駄遣いにはならない。

というわけで Copy な型は手動で .clone() する必要がなく、代入時に値が自動的に複製される。

さて「Copy のタプルも Copy になる」ということを踏まえてユーザー定義型について見てみよう。
Copy な型だけを含む struct や enum は Copy に なれる 。#[derive(Clone, Copy)] で修飾すればいい。

#[derive(Clone, Copy)]
struct Foo { val: u8 }

let foo = Foo { val: 42 };
let bar = foo;
println!("{}", foo.val); // => 42

なんとも簡単だが 自動的に Copy になる訳ではない。

ユーザー定義型が (可能であっても) 自動的に Copy にならない理由は「将来的に拡張されて Copy でない型を含むようになったときに困るから」と説明されている。
Copy でない型を含む型はどうがんばっても Copy になれない。将来的にも Copy な型しか持たせないことを心に決めたうえで、実装者が責任を持って #[derive(Clone, Copy)] をタイプする必要がある。

というわけで実はユーザー定義型を安易に Copy にするべきではないのだ。現実的なユースケースではムーブを回避したいときには一々 .clone() することになる。

そういう意味で Rust は 一々 .clone() をタイプさせるように デザインされていると言える。

プログラマが .clone() をタイプするときデータが複製されている様を意識せずにはいられない。複製元の値と同じだけメモリが消費されてる様を意識するというストレスがかかるわけだ。
そういう少しのストレスによって Rust はプログラマに極力 .clone() せずに済むコードを書くように仕向ける。

一々 .clone() をタイプするのは苦痛で。ストレスが無いのは一つの値を一つの変数だけが所有しているコードだ。
苦痛から逃れるコードを書こうとすると、自然に「値の複製」も「ガベージコレクション」も必要のないコードになっていく。

所有権システムの制約も Copy な型の制約も、理想的なコードを書かせるための意図したデザインと思えてくる。

Vec が map() メソッドを持たない

Rust の Vec は便利だ。色々なメソッドがあり、ほとんどが安全だ。
が、とある不思議なことに気づく。Vec には .map() メソッドが無い。

.map() メソッドは Iterator に定義されている。
Vec の中の値を変換しようとしたら、

1. まず Vec を Iterator に変換し
2. .map() して
3. 結果の Iterator を再び Vec に変換する

という手順を踏む必要がある。

とはいえこれらの手順はどれも簡単だ。
Vec から Iterator を作るには .into_iter() メソッドを呼び出すだけでいい。
Iterator から Vec の変換は .collect() メソッドがやってくれる。

let vec = vec![1, 2, 3];

let iter = vec.into_iter();
let iter = iter.map(|n| n * n);
let vec: Vec<u8> = iter.collect();

println!("{:?}", vec);  // => [1, 4, 9]

簡単ではあるが、いかにも冗長だ。

いちいち変数に格納せずともメソッドチェーンで書くこともできる。そうするといくらかスッキリする。

let vec = vec![1, 2, 3];

let vec: Vec<u8> = vec.into_iter().map(|n| n * n).collect();

println!("{:?}", vec);  // => [1, 4, 9]

が、やはり冗長じゃないか？

Vec が .map() を持たない背景には遅延評価的な思想がある気がしている。
ここでいったん脇道に逸れて Iterator の .map() メソッドについて見てみよう。

Iterator の .map() は Iterator が持つ値を変換するメソッド ではない 。

.map() は std::iter::Map を返すように実装されている。std::iter::Map は別の Iterator と「値を変換する関数 f」を内包した構造体だ。
こんな感じの実装になっている。

pub struct Map<I, F> {
    pub(crate) iter: I,
    f: F,
}

impl<B, I: Iterator, F> Iterator for Map<I, F>
where
    F: FnMut(I::Item) -> B,
{
    type Item = B;
    fn next(&mut self) -> Option<B> {
        match self.iter.next() {
            Some(v) => Some(self.f(v)),
            None => None,
        }
    }
}

std::iter::Map は値を変換可能な状態を保持しているだけで、値が必要になるまで変換は行わないのだ。
「値が必要になったとき」とは iter.next() が呼ばれたときだ。

std::iter::Map の存在を知れば .map() の見方も変わってくる。Iterator の .map() は変換可能な状態を作っているだけ。

必要になるまで変換を行わないのは、全ての値に対して変換を行わなくてもいい場合があるからだ。
例えば .skip() でいくつかの要素を読み飛ばしたり .find() で特定の要素だけをピックアップしたときには、捨てられる要素に対しての変換は省略できる。

Rust はコレクションの中に使われない値があるかもと想定しているので「必要になったときに初めて値を用意する」という処理を抽象化して用意している。それこそが Iterator だ。

というわけで Vec を .map() するときに Iterator を経由するのは使われない値があるときに備えてのことだと言える。
Vec に .map() を直接実装してしまうと、そのような効率化のための意図は消し飛んでしまう。タイプ数が減る代わりに非効率さが覆い隠される。

プログラマが vec.into_iter().map().collect() をタイプするときに思うことは、どうにかして .collect() を省けないか？ということだ。
.collect() を呼んだ時点で内部的に .next() が呼ばれて、遅延されていた std::iter::Map の処理は即座に実行されていまう。もし必要ない要素があるなら、Vec に変換することなく処理を進めるのが効率がいい。

Vec を .map() するための冗長さは裏側で起こっていることをプログラマに思い出させるためにある。

Rust はコストのかかる箇所にマークをつける

Rust を学んでいて面白いと思ったのは、Rust のデータ型はコストのかかる処理を覆い隠したりしないことだ。
むしろコストのかかる箇所が見えるように個別の型やトレイトが用意されている。

この記事では、

• 後ろ側に連結が容易な String 型
• 自動的な複製を許す Copy トレイト
• Lazy な Iterator トレイトと正格な Vec 型

を例に挙げた。

これらの型やトレイトはプログラマが見て裏側の処理の性質を知るのにも役立つし。もっと直接的に、とあるトレイトの有無を条件に制約を課すガードとしても使われている。*2

コストのかかる処理をマークするための型があることで、マークするためにわずかにタイプ数が増える。そうやってわずかにストレスを感じさせて、コストのかかる処理を避けるよう誘導しているんじゃないだろうか。

もちろんコストのかかる処理をカジュアルに書ける記法を用意することも技術的に可能だ。でも Rust はそのようにデザインされていないと感じる。むしろコストのかかる箇所が明確に見えるように、コストのかかる処理を書いていて苦痛に感じるようにデザインされている気がする。

まとめ

ここで紹介した冗長さはどれも意図的だと私は思っている。
Rust を書いていて苦痛なときは「もっと効率のいい書き方がある」というメッセージを受信しているときだ。

Rust は苦痛を型で表現しているのが面白い。
文字列連結の例では String と &str が、値の複製の例では Copy が、.map() の例では Iterator や std::iter::Map が。これらの型はコストを覆い隠すのではなく、そこにコストがあることを表明している。

この記事を読んで「いや Rust でもコストが覆い隠されているデザインはあるぞ」とか「他の言語ではこういう工夫がされているよ」とかの意見や知見があればぜひ教えてほしい。
私もこの意見に確信があるわけではなく、まだまだ考え始めたところだ。

私からは以上です。

おまけ

Rustacean の認識を聞きたい。
Rust の根底には「コストのかかる処理は書くのが苦痛であるべきだ」という思想が...、

— 今日の三井君 (@todays_mitsui) 2024年1月22日

X でアンケートを取ってみたら見事に真っ二つに割れた図

---

1. Rust では文字列リテラル "some string" は &str 型に解決される↩
2. 連結不可能というわけではなく、左オペランドを String 型に右オペランドを &str 型に変換しておく必要があるということ↩

*1:そしてガベージコレクションが無い

*2:いわゆる「トレイト境界」