Rustの文字列の長さがi32やi64ではなくusizeである理由

Question

Rustのlen()の戻り値がusizeの理由がわかりません。
i32やi64ではいけないのでしょうか？

該当のソースコード

fn calculate_length(s: &String) -> i64 {
    s.len()
}

Answer 1

註記：この回答には何点か誤りを含む記述があります（本文の修正は加えていません）．本文中の「註記」箇所について，詳しくはコメント欄を参照してください．

コンパイルが通るまで

まず，問題文のコードについて見てみます．

fn main() {
    let s = "This is a string.".to_string();
    calculate_length(&s);
}

fn calculate_length(s: &String) -> i64 {
    s.len()
}

例えばこういった内容に補完してコンパイルすると，確かにコンパイルエラーになります．

~/workspace/sandbox/teratail-311153
$ cargo build
   Compiling teratail-311153 v0.1.0 (/Users/gemmaro/workspace/sandbox/teratail-311153)
error[E0308]: mismatched types
 --> src/main.rs:7:5
  |
6 | fn calculate_length(s: &String) -> i64 {
  |                                    --- expected `i64` because of return type
7 |     s.len()
  |     ^^^^^^^ expected `i64`, found `usize`
  |
help: you can convert an `usize` to `i64` and panic if the converted value wouldn't fit
  |
7 |     s.len().try_into().unwrap()
  |

error: aborting due to previous error

For more information about this error, try `rustc --explain E0308`.
error: could not compile `teratail-311153`

To learn more, run the command again with --verbose.

• s.len() の部分は usize 型
• calculate_length の返り値の型は i64

なので矛盾しているのですね．
help にあるように修正してみるとこうなります．

fn main() {
    let s = "This is a string.".to_string();
    calculate_length(&s);
}

fn calculate_length(s: &String) -> i64 {
    s.len().try_into().unwrap()
}

再度コンパイルしてみましょう．

~/workspace/sandbox/teratail-311153
$ cargo build
   Compiling teratail-311153 v0.1.0 (/Users/gemmaro/workspace/sandbox/teratail-311153)
error[E0599]: no method named `try_into` found for type `usize` in the current scope
 --> src/main.rs:7:13
  |
7 |     s.len().try_into().unwrap()
  |             ^^^^^^^^ method not found in `usize`
  |
  = help: items from traits can only be used if the trait is in scope
help: the following trait is implemented but not in scope; perhaps add a `use` for it:
  |
1 | use std::convert::TryInto;
  |

error: aborting due to previous error

For more information about this error, try `rustc --explain E0599`.
error: could not compile `teratail-311153`

To learn more, run the command again with --verbose.

今度は別のエラーが出ました． help によると， usize が実装している std::convert::TryInto トレイトから try_into() が提供されているけれども，そのトレイトが宣言されていません． TryInto を使うことを宣言しましょう．

use std::convert::TryInto;

fn main() {
    let s = "This is a string.".to_string();
    calculate_length(&s);
}

fn calculate_length(s: &String) -> i64 {
    s.len().try_into().unwrap()
}

~/workspace/sandbox/teratail-311153
$ cargo build
   Compiling teratail-311153 v0.1.0 (/Users/gemmaro/workspace/sandbox/teratail-311153)
    Finished dev [unoptimized + debuginfo] target(s) in 1.59s

これでコンパイルが通りました．

どこで len が usize を返すことを調べられるか

質問文に

Rustの len() の戻り値が usize の理由がわかりません。

とありますが，Rust の全ての len() が usize を返すとは限りません．
ここでは String 型の値について value.len() するときを考えます．

Rust の標準ライブラリのドキュメントはオンラインでも読めますし，もし rustup がインストールされているパソコンであれば， $ rustup doc --std としてもドキュメントのページを開くことができます．
String を調べてみましょう．

左の "Methods" の一覧の中に len がありますので選択します．

pub fn len(&self) -> usize とありますが，これが len() の型シグネチャです．
返り値が usize であることはこのようにして調べることができます．

ところで，

Returns the length of this String, in bytes, not chars or graphemes. In other words, it may not be what a human considers the length of the string.

とありますね．
注意すべき点なのですが，「日常的に使われる意味での文字列長」を得るときには， s.len() は使えないのです．
例にも示されている通り， s.chars().count() のようにします．
ここで s は String 型の値が束縛されている変数です．

註記：文字数の扱いに関して不正確な記述です．

なぜ std::string::String の len は usize を返すのか

註記：この節では usize が多倍長整数であるかのような言い回しをしていますが，これは誤りです．

ここまで，Rust言語で「どのようになっているか」を見てきました．
しかし，「なぜそうなっているのか」を考えてはきませんでした．
ここからは質問に対する私の予想を書いています．

私が len を実装する立場にある状況を想像します．
一般に文字列の長さには制限がありません．
（したがって，文字列長を表す整数型に範囲の制限があると，面倒なことになりそうだと薄々気付いています．）

例えば， len が i32 を返すものと決めたとします．

pub fn len(&self) -> i32

i32 にも上限があり，その数はたったの (?) 2147483647 です．

あるとき，文字列長 2147483648 ( = 2147483647 + 1 ) の文字列が与えられたとしましょう．
このとき， len は何を返すべきでしょうか．

let t: i32 = s.len(); //=> ???

表現できる整数型の範囲を超えてしまっているので，長すぎる文字列に対しては実行時にパニックを起こすようにしましょうか．
でも，それだと安心してプログラミングできませんよね．

このような「失敗しうる計算」については Option 型（もしくは Result 型）を返すようにするのも手です．
さきほどの型シグネチャを変更して次のようにしてみます．

pub fn len(&self) -> Option<i32>

これはまだありそうな感じがします．
実際に使うときはこんな感じになります．

let t: Option<i32> = s.len();

match t {
  Some(u) => {
    // t を使うなんらかの処理
  }
  None => {
    // s の文字列長が大きすぎたときの処理
  }
}

よさそうです．
しかし，「文字列長が i32 の上限超え i64 の上限以下の文字列」の文字列長を扱いたくなるときがきたらどうしましょうか．
先程実装した len だと， i32 の上限を超えるものについては一律 None を返すことにしていて使えません．
それでは， Option<i64> を返すように変更しましょうか．
でも， i64 の上限を超えたときはどうしましょう．
実は i128 があって……
将来的にコンピュータの仕様が激変して i256, i512, ... が出てきたらどうしましょうか．いちいち返り値の型を変更しなくてはいけないのでしょうか．
どうしても溢れてしまう計算結果は，諦めるよりないのでしょうか．

ここまでの想像をもとに考えると，範囲に制限のない usize みたいな整数型があれば，それを返したほうがよさそうです．
そして， usize はもちろん実在します．

usize を返すように設計したくなりませんか？

よりよいコードを考える

冒頭でコンパイルを通すまでを辿りましたが，実はあれで完成ではありません．再掲します．

use std::convert::TryInto;

fn main() {
    let s = "This is a string.".to_string();
    calculate_length(&s);
}

fn calculate_length(s: &String) -> i64 {
    s.len().try_into().unwrap()
}

calculate_length 中で unwrap を使っている点が気になります．
このままだと， s によってはパニックしてしまいます．
あまり現実的ではないですが，例えば i64 の上限を超える文字列長の s が与えられたら，一律で 42 を返すような挙動であるとします．
それは，次のように書くことができます．

use std::convert::TryInto;

fn main() {
    let s = "This is a string.".to_string();
    calculate_length(&s);
}

fn calculate_length(s: &String) -> i64 {
    let t: Result<i64, _> = s.len().try_into();

    t.unwrap_or(42)
}

try_into で usize を変換して， Result に包まれた i64 値を t に束縛しています．
その後， t が Err の場合のみ（つまり i64 への変換が失敗するとき） 42 として返しています．

型推論があるので，少し簡単にします．

use std::convert::TryInto;

fn main() {
    let s = "This is a string.".to_string();
    calculate_length(&s);
}

fn calculate_length(s: &String) -> i64 {
    let t = s.len().try_into();

    t.unwrap_or(42)
}

ここで calculate_length の返り値を i32 や u32 や u64 に変更することは，関数の中身の書き換えを求めません．
これも， len が usize を返すからですね．
そして， s のあらゆるケースに対応したコードを書くことができました．

また， unwrap は基本的に避けるべきであるということも述べたかったのです．
（もちろん例外はあります．例外だけに．）

もう全部あいつ (usize) 一人でいいんじゃないかな

残念ながら，良くないです．
もし，取り得る範囲がわかっているのであれば， i32 のような整数型を使うべきです．
範囲が決まっているということは，整数を表現するバイト数をコンパイル時に決めることができる，ということです．
これはパフォーマンスの向上に繋がります．
ただし，この辺りの話題については私の専門ではなく，また元の質問から離れつつあるため，コンパイラ関連の文献などを研究されますと幸甚です．

文字列以外の len

他にも Vec の len も usize を返します．
なぜこのようになっているのか，想像を巡らせてみるのも一興かと存じます．

Comments

[gemmaro]

補足：途中で `chars().count()` に言及したあとで `len` の場合を述べ続けていますが，`chars().count()` を使うべき場合はそちらを使うようにしてください．後半の議論は `chars().count()` にも敷衍できます．

[TS01]

ご回答ありがとうございました。
丁寧な解説、とても参考になりました。

ドキュメントの索引方法についても、とても助かりました。

[mosh]

重箱の隅をつついておくと`usize`に範囲の制限がないというのは多倍長整数を想起させて語弊のある表現だと思いました
あと日常的に使われてる文字数の概念はcharじゃなくgrapheneのほうが近いと思います。そこまで踏み込むのは教育的でない気もしますが

[gemmaro]

ご指摘ありがとうございます．
* usizeは https://doc.rust-lang.org/std/primitive.usize.html で "For example, on a 32 bit target, this is 4 bytes and on a 64 bit target, this is 8 bytes." とあり，確かに多倍長整数ではありません．私が勘違いしていました．
* grapheme については https://doc.rust-lang.org/book/ch08-02-strings.html#bytes-and-scalar-values-and-grapheme-clusters-oh-my を忘れていました．こちらも注意が必要ですね．

Answer 2

1. i32やi64の範囲に含まれる負数になる事がありえない
2. コンパイルするアーキテクチャによって扱える桁数が可変にできる方が効率が良い

Comments

[TS01]

回答ありがとうございました。

しかし、疑問点は残っています。
そもそもこのコードでコンパイルエラーになることが理解できません。
len()メソッドでは、負数になること自体が有り得ないように思うので、i32やi64も許容すべきではないのか、と思えてしまいます。。

加えて、実行するアーキテクチャによって扱える桁数を可にできる方が良いのは、全ての数値に言えることではないのでしょうか？

例えば
let i: usize = 1;

など、普段使う数値がusizeでないことと、文字列の長さを返却するメソッドの戻り値がusizeである理由が一致しないことに釈然としません。。

もしよろしければそのあたりも教えていただければと思います。

[gentaro]

コンパイルエラーになることが理解できないのが理解できません。
静的型付け言語であればどんな言語でも型が違えばエラーになるのが自然で、そうでない場合というのは暗黙的な型変換が発生するケースだけです。

後段の疑問も使用する目的に応じて適切な型を使えばいいだけの話だと思いますが、何を疑問に思っているのか全くわかりません。

[TS01]

ご回答ありがとうございました。