テストステ論

高テス協会会長が, テストステロンに関する情報をお届けします.

(rust report) 入出力型の設計ガイドライン

Rust Guidelines [working title]

なるものを見つけた. Rustらしいコードを書くためにどうすればよいかというガイドラインだ. 面白い項目をピックアップして紹介する.

このガイドラインのうち, 3.4.1, 3.4.2を紹介する. Rustでは所有権という概念を意識して関数のインターフェイスを設計する必要がある. これとどう付き合うかというガイドライン.

3.4.1 入力

(1) Let the client decide when to copy and where to place data.

その関数が引数の所有権がほしい時(consumerである場合), borrowしてcloneするのではなく, 所有権をもらう形にして, cloneするかどうかをクライアントに決めさせなさい. なぜならば, cloneは高コストである場合があるから.

(2) Minimize the assumptions about parameters

(i) generalization: T: Iterator<int>みたいにちゃんと抽象化しとけ
(ii) ownership: ownershipがまじで必要じゃないならばborrowしろ (というか引数はまずborrowからまず考えましょう)

(3) Prefer compound return type to out-paramters

2値返したいならばfn foo() -> (Bar, Bar)のように書け. C-likeにfn foo(output: &mut Bar) -> Barのようには書くな. Rustでは返り値もcallerのstackに確保されるしコピーもされないから, &mutを渡しても性能の得にならない. (Rustでは, インターフェイスはシンプルに設計することがベストな傾向があるように思う) この項目は出力のところに書くべきじゃないかな?

(4) Consider validating arguments, statically or dynamically

出来るだけ入力にヴァリデーションしましょう. 型を定義して型チェックしましょう. newtypeを使いましょう.

3.4.2 出力

(1) Let client choose what to throw away

(i) Return useful intermediate results

返り値は構造体なりtupleで有益な情報をいっぱい返してあげましょう. (もしクライアントが使わないならば, 生成はRustコンパイラによって排除される? <- 生成くらいは排除されそうな気もするが)

(ii) Yield back ownership

所有権をもらう場合にも, 処理が失敗した場合には返す. パーサーとか?

fn from_utf8_owned(vv: Vec<u8>) -> Result<String, Vec<u8>>

(2) ポインタ返しのつもりでBox返しはやめろ

この項目は存在しないけど, 付け足したい. 詳しくはおれのブログを読め. (rust report) コピーを省略するためにBoxを返すのは意味ない - テストステ論