[Rust] チュートリアル②　モジュール〜ライフタイムまで

# はじめに
Rustのチュートリアルのメモ②です。


# リンク集

[C++入門](https://amzn.to/2Nf1ntW)
[プログラミングRust (日本語) ](https://amzn.to/2Bs7vvS)
[プログラミング言語Rust入門](https://amzn.to/2BkGP0n)
[実践Rust入門](https://amzn.to/2zRbu4W)

[std::検索](https://doc.rust-lang.org/stable/std/)



# モジュール

Rustには、コードの再利用を体系化された形で行うこができる

mod : モジュールを宣言
pub : 名前空間の外からも見えるようになる
use : モジュールやモジュール内の定義をスコープに入れる


fooという名前のモジュールにサブモジュールがなければ、fooの定義は、 foo.rsというファイルに書くべきです。

communicator
 ├── network
 └── client

mod network {
    fn connect() {
    }
}

mod client {
    fn connect() {
    }
}


fooというモジュールに本当にサブモジュールがあったら、fooの定義は、 foo/mod.rsというファイルに書くべきです

```
└── src
    ├── client.rs
    ├── lib.rs
    └── network
        ├── mod.rs
        └── server.rs
```

```rust

// [src/client.rs]

fn connect() {
}


// [src/lib.rs]

mod client;

mod network;



// [src/network/mod.rs]

fn connect() {
}

mod server;



// [src/network/server.rs]

fn connect() {}
```



## pubで公開するか制御する

- 要素が公開なら、どの親モジュールを通してもアクセス可能

- 要素が非公開なら、直接の親モジュールとその親モジュールのみアクセス可能

extern crate コマンドを使用して、communicatorライブラリクレートをスコープに導入する

Cargoは、src/main.rsをバイナリクレートのルートファイルとして扱い、これはルートファイルがsrc/lib.rsになる既存のライブラリクレートとは区別される

このパターンは、実行形式プロジェクトで一般的

ほとんどの機能はライブラリクレートにあり、バイナリクレートはそれを使用する

結果として、他のプログラムもライブラリクレートを使用でき、良い責任の分離になる

src/lib.rsに記述するモジュールはルートモジュール

### 関数を公開にする

バイナリクレートで関数をしようするには関数名の前にpubをつける

```
pub mod client; // 使用できる
mod network; // 使用できない
```

ルートモジュールをpubにしても、関数が非公開の場合

```
// src/client.rs

pub fn connect(){}
```

## プライバシー


```rust
mod outermost {
    pub fn middle_function() {} // ライブラリ内

    fn middle_secret_function() {} // 親モジュール内

    mod inside {
        pub fn inner_function() {} // 親モジュール内

        fn secret_function() {} //  // サブモジュール内
    }
}

fn try_me() {
    outermost::middle_function();
    outermost::middle_secret_function(); // エラー
    outermost::inside::inner_function();  // エラー
    outermost::inside::secret_function(); // エラー
}
```

## 異なるモジュールの名前を参照する


### useキーワードで名前をスコープに導入する


```rust
pub mod a {
	pub mod series {
		pub mod of {
			pub fn nested_modules() {}
		}
	}
}

use a::series::of; 
use a::series::of::nested_modules;

fn main() {
	a::series::of::nested_modules(); // フルパスを指定する
	of::nested_modules(); // useキーワードで名前をスコープに導入
	nested_modules(); // 関数を直接参照
}
```


### enumにもuseキーワードを使用する

```rust
enum TrafficLight {
	Red,
	Yellow,
	Green,
}

use TrafficLight::{Red, Yellow};
use TrafficLight::*;  // Globで全ての名前をスコープに導入

fn main() {
	let red = Red;
	let yellow = Yellow;
	let green = Green;
}
```


## superを使用して親モジュールにアクセスする

パスは常に現在のモジュールに対して相対的になり、ここではtestsモジュールになっている

ライブラリクレート内にいる場合にいて、クレート内のモジュールをテストする場合は、superを使って階層を１つ上げてパスを合わせる

```rust
pub mod client;
pub mod network;

#[cfg(test)]
mod tests {
	#[test]
	fn it_works() {
		
		// testsモジュールは、clientモジュールがスコープに存在する必要がある
		client::connect(); 	// エラー

		// superで階層を１つあげる
		super::client::connect(); 	// OK 

	} 
}
```


# 一般的なコレクション

コレクションは複数の値を含むことができる
組み込みの配列とタプル型とは異なり、これらのコレクションが指すデータはヒープに確保され、データ量はコンパイル時にわかる必要はなく、プログラムの実行にあわせて、伸縮可能になる

- ベクタ型: 可変長の値を並べて保持できる
- 文字列: 文字のコレクション
- ハッシュマップ: 値を特定のキーと紐付ける


## ベクタ  Vec<T>

ベクタはメモリ上に値を隣り合わせに並べる単独のデータ構造に２つ以上の値を保持させる

ベクタには、同じ型の値しか保持できない

要素のリストがある場合に有用

```rust
// 新しいベクタを生成
let v: Vec<i32> = Vec::new();

// 初期値のあるVec<T>を生成
let v = vec![1,2,3];

// ベクタを更新
let mut v = Vec::new();

v.push(5);
v.push(6);
v.push(7);

println!("{:?}", v);

// output
[5,6,7];
```


## もちろん、スコープを抜ければVecも解放される

```rust
{
	let v2 = vec![5,6,7,8];
}
```

## ベクタの要素を読む

```rust
	let v = vec![1, 2, 3, 4];

	// --------------------------------
	// レンジ外を要素にアクセスした時
	// --------------------------------

	// プログラムがパニックを起こす
	// パニックになると、コンパイルはRunningとなりコンパイルは完了しない
	let third: &i32 = &v[200]; // 200番目の要素にアクセス

    // Noneを返す
	let third: Option<&i32> = v.get(200); // 200番目の要素にアクセス
```


## 要素への参照を保持しつつ、ベクタに要素を追加しようとするとエラーとなる　

新規要素をベクタの終端に追加すると、ベクタが現在存在する位置に隣り合って要素入れるだけの領域がなかった場合に、メモリの新規確保をして古い要素を新しいスペースにコピーする必要があるかもしれないから

その場合、最初の要素を指す参照は、開放されたメモリを指すことになる

借用規則により、そのような場面に陥らないよう回避される

```rust
let mut v = vec![1, 2, 3, 4, 5];

let first = &v[0];

v.push(6)
```

## ベクタの値を走査する

```rust
let mut v = vec![1, 2, 3, 4, 5];

	// ベクタ要素への可変な参照を走査する
	for i in &mut v {
		*i += 1;
	}
```

## enumを使って複数の方を保持する

```rust
enum SpredsheetCell {
	Int(i32),
	Float(f64),
	Text(String),
}

fn main() {
	let row = vec![
		SpredsheetCell::Int(3),
		SpredsheetCell::Text(String::from("blue")),
		SpredsheetCell::Float(10.12),
	];
}
```

## 文字列でUTF-8エンコードされたテキストを保持する

3つの概念の組み合わせにより、文字列でよく行き詰まる
Rustのありうるエラーを晒す性質、多くのプログラマが思っている以上に文字列が複雑なデータ構造である

### 文字列

文字列リテラル　: let data = "hello";
String : let data = String::form("hello"); // ""内は文字列リテラル

Rustには、言語の各として１種類しか文字列型が存在しない
文字列スライスのstrで、通常借用された携帯&strで見かける

String型は、言語の各として組み込まれるのではなく
Rustの標準ライブラリで提供されており、伸縮可能、可変、所有権のあるUTF-8エンコードされた文字列型


### 新規文字列を生成する

```rust
let data = "initial contents";
let s = data.to_string();
let s = String::from("initial contents");
```

Stirng::from関数を使っても、文字列リテラルをto_stringメソッドは、全く同じことをしている

文字列はUTF-8エンコードされていればどんな言語でも使用できる


### 文字列を更新する

```rust
let mut s = Stirng::from("foo");
s.push_str("bar"); // fooのあとにbarを追加

let s2 = "bar";
s.push_str(s2); // 上と同じ
```

### +演算子、またはformat!マクロで連結

+演算子はaddメソッドを使用している

```rust
// addメソッドのシグネチャ
fn add(self, s: &str) -> String{}


// add関数がs1の所有権をムーブし、s2の中身のコピーを追記し、結果の所有権を返す

// 実装は単純にコピーするよりも効率的

let s1 = String::from("Hello, ");
let s2 = String::from("World!");
let s3 = s1 + &s2;
println!("s3: {}", s3);
println!("s2: {}", s2);


// format!マクロで連結する

let s1 = String::from("tic");
let s2 = String::from("tac");
let s3 = String::from("toe");

let s = format!("{}-{}-{}", s1, s2, s3);
println!("{}", s);
```


### 文字列を操作するメソッド

```rust
// char型に分ける
for c in "hello".chars() { }

// バイトに分ける
for b in "hello".bytes() { }

// output
h
e
l
l
o
104
101
108
108
111
```


## ハッシュマップに紐付いたキーを格納する

HashMapをuseする
vec!のような組み込みマクロがない

ベクタとまったく同様に、ハッシュマップはデータをヒープに保持する

ハッシュマップは均質。キーは全て同じ型で、値も全て同じ型。

```rust
use std::collections::HashMap;

let mut scores = HashMap::new();

scores.insert(String::from("Blue"), 10);
scores.insert(String::from("Yellow"), 50);


// タプルのベクタに対してcollectメソッドを使用する

let teams = vec![String::from("Blue"), String::from("Red")];
let initial_scores = vec![10, 50];

let scores: HashMap<_, _> = teams.iter().zip(initial_scores.iter()).collect();

println!("{:?}", scores);

// output
{"Blue": 10, "Red": 50}
```


### ハッシュマップと所有権

i32のようなCopyトレイトを実装する方について、値はハッシュマップにコピーされる

Stringのような所有権のある値なら、値はムーブされ、ハッシュマップはそれらの値の所有者になる

```rust
let field_name = String::from("Favorite color");
let field_value = String::from("Blue");

let mut map = HashMap::new();

// mapに所有権がムーブするため、ここでfield_nameとfield_valueは使えなくなる
map.insert(field_name, field_value); 
```


### ハッシュマップの値にアクセスする

```rust
let mut scores = HashMap::new();

scores.insert(String::from("Blue"), 10);
scores.insert(String::from("Yellow"), 50);

let team_name = String::from("Blue");

// scoresの"Blue"チームの値にアクセスする
let score = scores.get(&team_name);

// forループでハッシュマップのキーと値のペアを走査する
for (key, value) in &scores {
	println!("{}: {}", key, value);
}
```

## ハッシュマップを更新する

```rust
let mut scores = HashMap::new();

scores.insert(String::from("Blue"), 10);
scores.insert(String::from("Blue"), 25);

println!("{:?}", scores);

// output
{"Blue": 25}
```

## キーに値がなかった時のみ値を挿入する

存在しないかどうかを確認するのにentryと呼ばれるAPIを使う
返り値はenumのEntry

```rust
scores.insert(String::from("Blue"), 10);
scores.insert(String::from("Yellow"), 50);

// entryメソッドでキーに値があるか確かめてから挿入する
scores.entry(String::from("Red")).or_insert(30); // 新しく挿入される
scores.entry(String::from("Blue")).or_insert(30); // すでに存在するので挿入されない

println!("{:?}", scores);

// output
{
	Blue: 10
	Yellow: 50
	Red: 30
}
```


## 古い値に基づいて値を更新する

ハッシュマップの別の一般的なユースケースは、キーの値を探し、古い値に基づいてそれを更新する

```rust
// 各単語があるテキストに何回出現するかを数え上げる

let text = "hello world wonderful world";

let mut map = HashMap::new();

for word in text.split_whitespace() {
	// キーに値がなければ0
	let count = map.entry(word).or_insert(0);
	// キーの値をプラス１ 
	*count += 1;
	println!("{}", word);
}

println!("{:?}", map);
```

# エラー処理

Rustの信頼性への傾倒は、エラー処理のも及ぶ
ソフトウェアにおいて、エラーは生きている証
Rustには何かがおかしくなる場面を扱う機能がたくさんある
多くの場合で、コンパイラは、プログラマにエラーの可能性を知り、コードのコンパイルが通るまでに何かしらの対応を行うことを要求してくる
この要求により、エラーを発見し、コードを実用に供する前に適切に対処していることを確認することでプログラムを頑健なものにしてくれる

Rustでは、エラーは大きく２つに分類される
回復可能と回復不能なエラー
ファイルが見つからないなどの回復可能なエラーには、問題をユーザに報告し、処理を再試行することが合理的になる
回復不能なエラーは、常にバグの兆候
例えば、配列の境界を超えた箇所にアクセスしようとするなど


## バックトレース

自分のフィアルではないファイルが原因でエラーが発生した場合にエラーが起こるまでの全関数の呼び出しの一覧を表示する

cargoコマンドの前にRUST_BACKTRACE=1

```
RUST_BACKTRACE=1 cargo run 
```

```rust
## Resultで回復可能なエラー

enum Result<T, E> {
	OK(T),
	Err(E),
}

use std::fs::File;

fn main() {
	// 	File::openが成功した場合、変数fの値はファイルハンドルを含むOKインスタンスになる
	// 失敗した場合には、発生したエラーの樹類に関する情報をより多く含むErrインスタンスがfの値になる

    let f = File::open("hello.txt");
}


fn main() {
    let f = File::open("hello.txt");

    let f = match f {
        Ok(file) => file,
        Err(error) => {
            // ファイルを開く際に問題がありました
            panic!("There was a problem opening the file: {:?}", error)
        },
    };
}
```

結果がOkの時に、Ok列挙子から中身のfile値を返すように指示し、それからそのファイルハンドル値を変数fに代入している
matchの後には、ファイルハンドルを使用して読み込んだり書き込むことができる

matchのもう１つのアームは、File::openからErr値が得られたケースを処理


## 色々なエラーにマッチする

```rust
use std::fs::File;
use std::io::ErrorKind;

fn main() {
    let f = File::open("hello.txt");

    let f = match f {
        Ok(file) => file,

		// [ マッチガード ]
	 	// アームのパターンを更に洗練する
		// パターンのrefは、errorがガード条件式にムーブされないように必要で、単にガード式に参照される
		// &は参照にマッチし、その値を返す
		// refは値にマッチし、それへの参照を返す

		// マッチガードで精査したい条件は、error.kind()による返り値が、ErrorKind enumのNotFoud列挙子であるかどうか

		// もしそうなら、File::createでファイル作成を試みる

		// ところが、File::createも失敗する可能性があるので、内部にもmatch式を追加する必要がある

        Err(ref error) if error.kind() == ErrorKind::NotFound => {
            match File::create("hello.txt") {
                Ok(fc) => fc,
                Err(e) => {
                    panic!(
                        //ファイルを作成しようとしましたが、問題がありました
                        "Tried to create file but there was a problem: {:?}",
                        e
                    )
                },
            }
        },
        Err(error) => {
            panic!(
                "There was a problem opening the file: {:?}",
                error
            )
        },
    };
}
```


## エラー時にパニックするショートカット

matchの使用は、いささか冗長になり得る上、必ずしも意図を良く伝えるとは限らない
Result<T,E>型には、いろいろな作業をするヘルパーメソッドが多く定義されている　

```rust
// [ unwrap ]
// File::openのmatch式の短縮メソッド
// 失敗するとpanic!メソッドが呼び出される

let f = File::open("hello.rc").unwrap();

// [ expect ]
// パニックの原因をたどりやすくするメソッド

let f = File::open("hello.rc").expect("Failed to open hello.txt");
```


## エラーを委譲する

戻り値型がResult<T, E>型
ジェネリック引数のTは具体型String、Eは具体型io::Error
成功すればOk値を受け取る、


```rust
use std::io;
use std::io::Read;
use std::fs::File;

fn read_username_from_file() -> Result<String, io::Error> {
    let f = File::open("hello.txt");

    let mut f = match f {
        Ok(file) => file,
        Err(e) => return Err(e),
    };

    let mut s = String::new();

    match f.read_to_string(&mut s) {
        Ok(_) => Ok(s),
        Err(e) => Err(e),
    }
}
```


## エラー委譲のショートカット ?演算子

エラーであれば?でエラー値が、成功であればOk内の値が返される

```rust
use std::io;
use std::io::Read;
use std::fs::File;

fn read_username_from_file() -> Result<String, io::Error> {
    let mut f = File::open("hello.txt")?; // エラーであればここで終了
    let mut s = String::new();
    f.read_to_string(&mut s)?; // エラーならここで終了
    Ok(s) // 成功ならsを出力
}
```


## ?演算子は、Resultを返す関数でしか使用できない

```rust
use std::fs::File;

fn main() {
    let f = File::open("hello.txt")?; // エラー
}
```


## panic!かResultか

panicしたら、回復する手段はない

Resultは、場面に合わせて回復を試みることを決定したり、Err値を回復不能と断定して、panic!を呼び出し、回復可能だったエラーを回復不能に変換することもできる
故に、Resultを返却することは、失敗する可能性のある関数を定義する際には、いい第一選択肢になる


### プロトタイプコード、テスト

例を記述してから何らかの概念を具現化している時、頑健な処理コードも例に含むことは、例の明瞭さを欠くことになりかねない

unwrapなどのパニックする可能性のあるメソッド呼び出しは、アプリケーションにエラーを処理してほしい方法へのプレースホルダーを意味していると理解され、これは残りのコードがしていることによって異なる可能性がある

つまり、エラーの処理方法を決定する準備ができる前、プロトタイプの段階では、非常に便利
それらにより、コードにプログラムをより頑健にするときの明らかなマーカーが残される

メソッド呼び出しがテスト内で失敗したら、そのメソッドがテスト下に置かれた機能ではなかったとしても、テスト全体が失敗してほしい
panic!が、テストが失敗と印づけらえる手段なので、unwrapやexpectの呼び出しはズバリ起こるべきこと


## エラー処理のガイドライン

- 悪い状態がときに起こるときは予想されないとき
- この時点以降、この悪い状態にないことを頼りにコードが書かれている時
- 使用している方にこの情報をコード化するいい手段がないとき


## 検証のために独自の方を作る

```rust
pub struct Guess {
    value: u32,
}

impl Guess {
    pub fn new(value: u32) -> Guess {
        if value < 1 || value > 100 {
            // 予想の値は1から100の範囲でなければなりませんが、{}でした
            panic!("Guess value must be between 1 and 100, got {}.", value);
        }

        Guess {
            value
        }
    }

    pub fn value(&self) -> u32 {
        self.value
    }
}
```


# ジェネリック型、トレイト、ライフタイム

## ジェネリック

### 関数にジェネリック

同じコードの重複を減らすために定義する

```rust: 変更前
fn largest_i32(list: &[i32]) -> i32 {
    let mut largest = list[0];

    for &item in list.iter() {
        if item > largest {
            largest = item;
        }
    }

    largest
}

fn largest_char(list: &[char]) -> char {
    let mut largest = list[0];

    for &item in list.iter() {
        if item > largest {
            largest = item;
        }
    }

    largest
}
```

```rust
fn largest<T>(list: &[T]) -> T {
    let mut largest = list[0];

    for &item in list.iter() {
        if item > largest {
            largest = item;
        }
    }

    largest
}
```

### 構造体にジェネリック

```rust

// 複数の型にたいしてジェネリックな型引数を使用できる
// xがT型で、yがU型

struct Point<T, U> {
    x: T,
    y: U,
}

fn main() {
    let both_integer = Point { x: 5, y: 10 };
    let both_float = Point { x: 1.0, y: 4.0 };
    let integer_and_float = Point { x: 5, y: 4.0 };
}
```

### enum定義にジェネリック

```rust
enum Result<T,E>{
	Ok(T),
	Err(E),
}
```


### メソッド定義にジェネリック

struct Point<T, U> {
	x: T,
	y: U,
}

// mixupメソッドでは、新しいPoint構造体を作成
// xは元のxの値、yは新しく渡されたPoint構造体のyの値

// したがって、返り値は元のPoint構造体と引数として渡されたPoint構造体のシグネチャと違う可能性がある

// p1 : i32, f64
// p2 : String, char
// p3 : i32, char

impl<T, U> Point<T, U> {
	fn mixup<V, W>(self, other: Point<V, W>) -> Point<T, W> {
		Point {
			x: self.x,  // 元のx
			y: other.y, // 渡されたyの値
		}
	}
}

fn main() {
	let p1 = Point { x: 5, y: 10.4 };
	let p2 = Point { x: "Hello", y: 'c' };

	let p3 = p1.mixup(p2);

	println!("p3.x={}, p3.y={}", p3.x, p3.y);
}


### ジェネリクスを使用したコードのパフォーマンス

Rustでは、ジェネリクスを、具体的な型があるコードよりの実行速度と同じになるように実装してある

```rust

// このコードをコンパイルすると、単相化を行う
その過程で、コンパイラはOption<T>のインスタンスに使用された値を読み取り、２種類のOption<T>を識別する

// ジェネリックな定義を特定の定義に置き換える

let integer = Some(5); // Option_i32に展開
let float = Some(5.0); // Option_f64に展開
```


## トレイト

トレイトにより、Rustコンパイラに特定の型に存在し、他の型と共有できる機能について知らせる

トレイトを使用して共通の振る舞いを抽象的に定義できる

トレイト境界を使用して、あるジェネリックが特定の振る舞いのあるあらゆる型になり得ることを指定できる


### 型にトレイトを実装する

```rust:SummaryトレイトをNewsArticleとTweet型に実装
pub trait Summary {
    fn summarize(&self) -> String;
}

pub struct NewsArticle {
    pub headline: String,
    pub location: String,
    pub author: String,
    pub content: String,
}

impl Summary for NewsArticle {
    fn summarize(&self) -> String {
        format!("{}, by {} ({})", self.headline, self.author, self.location)
    }
}

pub struct Tweet {
    pub username: String,
    pub content: String,
    pub reply: bool,
    pub retweet: bool,
}

impl Summary for Tweet {
    fn summarize(&self) -> String {
        format!("{}: {}", self.username, self.content)
    }
}

fn main() {
	let tweet = Tweet {
		username: String::from("horse_ebooks"),
		// もちろん、ご存知かもしれないようにね、みなさん
		content: String::from("of course, as you probably already know, people"),
		reply: false,
		retweet: false,
	};

	println!("1 new tweet: {}", tweet.summarize());
}
```

### デフォルト実装

メソッドシグニチャだけを定義するのではなく、デフォルトの文字列を指定する方法もある


```rust

// デフォルト実装
pub trait Summary {
	fn summarize(&self) -> String {
		String::from("(Read more...)")
	}
}

pub struct NewsArticle {
	pub headline: String,
	pub location: String,
	pub author: String,
	pub content: String,
}

// NewsArticleのSummaryの空にする 
impl Summary for NewsArticle {}

pub struct Tweet {
	pub username: String,
	pub content: String,
	pub reply: bool,
	pub retweet: bool,
}

// こっちのTweetのSummaryの実装に影響が及ばない
// 理由は、デフォルト実装をオーバーライドする記法がデフォルト実装のないトレイトメソッドを実装する記法と同じだから 
impl Summary for Tweet {
	fn summarize(&self) -> String {
		format!("{}: {}", self.username, self.content)
	}
}

impl Summary for NewsArticle {}

fn main() {
	let article = NewsArticle {
		headline: String::from(""),
		location: String::from(""),
		author: String::from(""),
		content: String::from(""),
	};

	println!("New article available! {}", article.summarize());

	let tweet = Tweet {
		username: String::from("horse_ebooks"),
		// もちろん、ご存知かもしれないようにね、みなさん
		content: String::from("of course, as you probably already know, people"),
		reply: false,
		retweet: false, 
	};

	println!("1 new tweet:{}", tweet.summarize());
}

```

### トレイト境界

トレイト境界を使用してジェネリックな型を制限し、型が特定のトレイトや振る舞いを実装するものに制限されることを保証する


```rust
/// 上記、省略

// 引数itemに対してsummarizeメソッドを呼び出す関数notifyを定義でき、この引数はジェネリックな型T

// itemのsummarizeを呼ぶ時にジェネリックな型Tがメソッドsummarizeを実装してないというエラーが出ないように、Tのトレイト境界を使ってitemがSummaryトレイトを実装する型でなければならないと指定できる

pub fn notify<T: Summary>(item: T) {
	println!("Breaking news! {}", item.summarize());
}

fn main() {
	let tweet = Tweet {
		username: String::from("horse_ebooks"),
		// もちろん、ご存知かもしれないようにね、みなさん
		content: String::from("of course, as you probably already know, people"),
		reply: false,
		retweet: false,
	};

	println!("{:?}", notify(tweet));
}
```

#### トレイト境界が多すぎる時

```rust

// 多すぎてよくわからない
fn some_function<T: Display + Clone, U: Clone + Debug>(t: T, u: U) -> i32 {

// where節をつかって、読みやすくする
fn some_function<T, U>(t: T, u: U) -> i32
    where T: Display + Clone,
          U: Clone + Debug
{
```

#### トレイト境界でlargest関数を修正する

ジェネリックがないlargest関数では、最大i32かcharを探そうとするだけ

i32やcharのようなプリミティブ(既知のサイズ型)は、スタックに格納できるので、Copyトレイトを実装している

しかし、largest関数をジェネリクスにすると、list引数がCopyトレイトを実装しない型を含む可能性もでてきた

結果として、list[0]から値をlargestにムーブできず、エラーになった

```rust

// Tのトレイト境界にPartialOrdとCopyを追加することで対処する
fn largest<T: PartialOrd + Copy>(list: &[T]) -> T {
    let mut largest = list[0];

    for &item in list.iter() {
        if item > largest {
            largest = item;
        }
    }

    largest
}

fn main() {
    let number_list = vec![34, 50, 25, 100, 65];

    let result = largest(&number_list);
    println!("The largest number is {}", result);

    let char_list = vec!['y', 'm', 'a', 'q'];

    let result = largest(&char_list);
    println!("The largest char is {}", result);
}
```


### トレイト境界を使用して、メソッド実装を条件分けする

ジェネリックな型引数を持つimplブロッグにトレイト境界を与えることで、特定のトレイトを実装する型に対するメソッド実装を条件分けできる

```rust
use std::fmt::Display;

struct Pair<T> {
	x: T,
	y: T,
}

impl<T> Pair<T> {
	fn new(x: T, y: T) -> Self {
		Self { x, y }
	}
}

impl<T: Display + PartialOrd> Pair<T> {
	fn cmp_display(&self) {
		if self.x >= self.y {
			println!("The largest nember is x = {}", self.x);
		} else {
			println!("The largest number is y ={}", self.y);
		}
	}
}

fn main() {
	let v = Pair::new(vec![1, 2, 3], vec![4, 5, 6]);
	let n = Pair::new(1, 2);
	v.cmp_display(); // エラー
	n.cmp_display(); // OK
}
```


## ライフタイム

### ライフタイムで参照を検証する

Rustにおいては参照は全てライフタイムを保持する
ライフタイムとは、参照が有効になるスコープを名前を付けて明示する。
多くの場合、型が推論されるように、大体の場合、ライフタイムも暗黙的に推論される


### 借用精査機

Rustコンパイラには、スコープを比較して全ての借用が有効であるかを決定する借用チェッカーがある

```rust
{
    let r;                // ---------+-- 'a
                          //          |
    {                     //          |
        let x = 5;        // -+-- 'b  | w
        r = &x;           //  |       |
    }                     // -+       |
                          //          |
    println!("r: {}", r); //          |
}                         // ---------+
```

これから分かることは、'bのライフタイムは'aのライフタイムより短いのでプログラムは拒否をする

```rust

'b > 'a なのでプログラムは受け入れる
{
    let x = 5;            // ----------+-- 'b
                          //           |
    let r = &x;           // --+-- 'a  |
                          //   |       |
    println!("r: {}", r); //   |       |
                          // --+       |
}  
```

### 関数のジェネリックなライフタイム

```rust

// 戻り値の型はジェネリックなライフタイム引数である必要がある
// なぜなら、返している参照がxかyのどちらを参照しているか、コンパイラにはわからないため

fn longest(x: &str, y: &str) -> &str {
	if x.len() > y.len() {
		x
	} else {
		y
	}
}
```


1. Aはあるリソースへのハンドルを取得した  
2. AはBにリソースへの参照を付与する
3. Aはリソースを使い終わり、それを解放することを
4. Bはリソースを使おうとする! (解放後の使用 or 段グリングポインタ)



①   リソース  参照       解放
A     ◯
B 



②  リソース  参照       解放
A     ◯
B             ◯



③  リソース  参照       解放
A                         ◯
B             ◯ A


BはAの参照を持っているが、Aはすでにリソースを解放しているためにリソースを呼び出すことができない!

このようなことが絶対に起こらないようにする必要がある
Rustはライフタイムと呼ばれる概念を通じてこれを防ぐ
それは、参照の有効なスコープを明示的に記述するもの


```rust
// 黙示的に
fn foo(x: &i32) {
}

// 明示的に
fn bar<'a>(x: &'a i32){
}
```


'aを「ライフタイムa」と読む

技術的には参照はすべてそれに関するライフタイムを持つが、一般的な場合にはコンパイラがそれらを省略してもよいように計らってくれる

関数は関数名の後の<>に「ジェネリックパラメータ」を持つことができ、ライフタイムはその一種

&mut i32 と &'a mut i32 は同じ
&mut i32 はライフタイム、「i32のミュータブルな参照」
&'a mut i32 は、「ライフタイム'aを持つi32へのミュータブルな参照」


### 関数シグニチャにおけるライフタイム注釈

```rust

// この関数シグニチャは、何らかのライフタイム'aに対して、どちらの引数も同じライフタイム'aと同じだけ生き残る文字列スライスであるとコンパイラに教えている　

fn longest<'a>(x: &'a str, y: &'a str) -> &'a str {
	if x.len() > y.len() {
		x
	} else {
		y
	}
}
```

```rust: ライフタイムが違うとエラー
fn main() {
    let string1 = String::from("long string is long");
    let result;
    {
        let string2 = String::from("xyz");
        result = longest(string1.as_str(), string2.as_str());
    }
    println!("The longest string is {}", result);
}

// output
error[E0597]: `string2` does not live long enough
```


### ライフタイムの観点で思考する

究極的にライフタイム記法は、関数のいろんな引数と戻り値のライフタイムを接続することに関する。一旦、つながりが出来たら、メモリ安全な処理を許可するのに十分な情報がコンパイラにはあり、ダングリングポインタを生成するであろう処理を不許可し、さもなくばメモリ安全を侵害する

```rust
// yのライフタイムは指定していないがエラーにならない
// なぜならyのライフタイムはxや戻り値のライフタイムとは何の関係もないから

fn longest<'a>(x: &'a str, y: &str) -> &'a str {
    x
}
```

```rust

// 戻り値型にライフタイム'aを指定していても、戻り地のライフタイムは、引数のライフタイムと全く関係がないので、この実装はコンパイルできない

fn longest<'a>(x: &str, y: &str) -> &'a str {
    // 本当に長い文字列
    let result = String::from("really long string");
    result.as_str()
}
`