Rust の lifetime に関しての質問

2025/04/01 03:44

以下と類似の問題に見えますメンバ変数への参照は推奨されないようです同様の状態と解釈されるのでしょう https://qiita.com/tagawa0525/questions/b879138858e2a3fe73a3

2025/04/01 06:04

いろいろ考察をしてくださって、ありがとうございます。教えてくださったコードを見てみてましたが、掲載されているものは、当然にコンパイルが通っていはいけないコードです。Vec の中の要素への参照を保持しようとしていますが、Vec は可変ですので、工夫もなく Vec 内への参照を保持してはいけません。ダングリングポインタが生まれる可能性のあることをしています。該当記事を書いた方は気付いていないようですが、論理エラーがあるプログラムですので、コンパイラがエラーを出すのも当然だと思われます。

2025/04/01 06:30

言葉足らずですみません。Vec が可変というのは、いわゆる可変参照などではなくて、メモリ内での移動を含めてです。いわゆる自己参照をメンバ変数に持つときには注意が必要、ということを考えていました。

2025/04/01 08:01 編集

(質問の意味を勘違いしていたので削除します)

行動規範の内容に同意します

回答2件

ベストアンサー

fn f<'a>(s: &'a mut S<'a>) とすると、本来別々であるはずの

S の中の ref_val: &mut i32 のライフタイム(つまりは &mut val のライフタイム)と
引数 &mut s のライフタイム

が同じという宣言なので、本来なら関数が終わったら不要になる &mut s の参照が解放されず、次の関数で可変参照が取れずエラーになるのではないでしょうか。

次のように異なるライフタイムを割り当ててやればエラーは出ないです。

rust
1fn f<'a, 'b>(s: &'b mut S<'a>) where 'a: 'b {
2	*s.ref_val += 1;
3}

追記

このあたり変性(Variance)に関わってくると思います。
うまく説明できるほど理解できていないのでリンクを紹介します。(本質問と同じことが説明されています)
https://qiita.com/maueki/items/b5df36e92561450938dd

&'a mut TはTに対してinvariant(不変)なので、&'a mut Foo<'a> では前側(&'a ...)のライフタイムが、後側(Foo<'a>) のライフタイムに引っ張られるようなイメージなのかなと思います。
リンク先に書かれていますが、アンチパターンなんだと思います。

投稿2025/04/01 08:16

編集2025/04/01 23:39

総合スコア4899

2025/04/01 14:18

実際にコードを書いて試してみてくださって、大変ありがとうございます！まったく指摘してくださっている通りで、本来は別々のライフタイムを持つもので、実は、投稿したコードには含まれていないのですが、`g4<'a, 'b>(s: &'b mut S<'a>)` というシグネチャも試していて、where 句がなくても、コンパイラがライフタイムの長短を自動的に判定してくれて、エラーが出ないことは確認しています。ただ、興味本位でちょっと条件を狭くしたつもりの `f<'a>(s: &'a mut S<'a>)` が、なぜコンパイルできないのかな？と悩んでいます。 bsdfan さんがおっしゃってる通り、今はライフタイムの問題ではなく、参照が解放されず、所有権でのエラーになってるのかな、と考えています。（エラーメッセージも所有権について言っていますし、、、）ただ、なぜ参照が解放されないのでしょうか。関数 f が実行を終えた時点で、参照は解放されるように思うのですが、、、。やはり、`S<'a>` への参照のライフタイムが `'a` となる、という設定がおかしいのでしょうか。すみません、もう少し何かヒントがあれば教えてくださると、とてもありがたいです。

2025/04/02 01:00 編集

本文追記しました。 > bsdfan さんがおっしゃってる通り、今はライフタイムの問題ではなく、参照が解放されず、所有権でのエラーになってるのかな、と考えています。（エラーメッセージも所有権について言っていますし、、、）所有権でのエラーではなく、ライフタイムの問題です。コンパイラが、f()の引数にマッチするようにライフタイムを推測した結果、仮引数の参照のライフタイム(というより変数スコープなのかも?)が関数呼び出し時点で終わらないように引き延ばされているということだと思います。

2025/04/02 05:34 編集

解説を追記して下さって、とても感謝しています！こういう思考実験を一人でやっていると行き詰ることが多いのですが、助言をいただけることによって、思考が進んで大変助かります。まだ、完全な理解ではないかもしれませんが、かなり納得できるようになりました。Rust の lifetime はスコープを表すこと、また、借用チェックはスコープによって行われること、この２点を考えることによって納得できるようになりました。 bsdfan がおっしゃっていることは、以下のようなことで正しいでしょうか？自分としては、スコープは以下のようなものを想定。 ``` 'x: { let mut val = 0; let mut s = S<'x>::new(&mut val); <- S.ref_val の生存範囲は 'x 'y1: { f(&mut s); <- &mut s の生存範囲は 'y1（と間違えて考えている） } 'y2: { g1(&mut s); <- &mut s の生存範囲は 'y2 } ... } ``` しかし、私が f のシグネチャを f<'a>(s: &'a mut S<'a>) としたことによって、'y1 のスコープが 'x にまで拡大されて、その結果、スコープ 'y2 において借用チェックに引っかかるようになるんじゃないかと。助言をいただけることによって、かなり納得できるようになりました。大変ありがとうございます！もし、考え方に間違いがあれば、お忙しいところ申し訳ないのですが、助言をくださると大変嬉しいです。大変ありがとうございました。

2025/04/02 05:34

はい。私の理解も同じです。うまく説明できませんでしたが、理解いただけたようでよかったです。

行動規範の内容に同意します

ふと「仮引数に所有権が束縛されているのが原因じゃないか」と思い立ち少し修正してみました

警告付きですが通るみたいです

struct S<'a> {
	ref_val: &'a mut i32,
}

impl<'a> S<'a> {
	fn new(ref_val: &'a mut i32) -> Self {
		S {
			ref_val,
		}
	}
}

//戻り値を追加
fn f<'a>(s: &'a mut S<'a>) ->&mut S<'a>{
	*s.ref_val += 1;
	s
}

fn g1<'a>(s: &'a mut S) {
	*s.ref_val += 1;
}

fn g2<'a>(s: &mut S<'a>) {
	*s.ref_val += 1;
}

fn g3(s: &mut S) {
	*s.ref_val += 1;
}

fn test_1() {
	let mut val: i32 = 0;
	let mut s = S::new(&mut val);
	
	let mut ss=&mut f(&mut s); //ポインタの所有権を移動
	g1(ss);
	g2(ss);
	g3(ss);
	println!("Ok!");
}

fn main(){
	test_1();
}

warning: variable does not need to be mutable
  --> compiler.rs:34:6
   |
34 |     let mut ss=&mut f(&mut s);
   |         ----^^
   |         |
   |         help: remove this `mut`
   |
   = note: `#[warn(unused_mut)]` on by default

warning: 1 warning emitted

Ok!

投稿2025/04/01 05:17

総合スコア103

2025/04/01 06:20

コンパイルして検討して下さって、大変ありがとうございます！実は、自分ながらにこういうことではないか？と思い当たることはあるのですが、確証がなく困っているところです。その前に、せっかくコードを書いてくださったので、まずは、その警告が出ないようにしてみました。 f の戻り値を少し変更して `->&'a mut S<'a>`とします。そして、f の戻り値をそのまま受け取ってください。 `let ss = f(&mut s);` 上記のようにすれば、警告が出なくなるので良いと思います。私が今思っているのは、コンパイラは、スコープ内での最小の lifetime を採用すると「思う」（私が勝手に思っているだけです、、、）ので、`f(&mut s)` を実行した時点で、s が持つ lifetime が、`&mut s` にまで短縮されて、それで、f の実行を終えて次の実行に移る前に、`&mut s` の消滅とともに、s の lifetime も消滅するのかな？と。そんなことあるのかなー？と思っているところです。ですので、戻り値として、渡した `&mut s` をもう一度受け取って、その lifetime が残りスコープに延長されれば、s も消滅せずに生き残るのかな？と。どんなものでしょうか？？、、、

2025/04/01 15:26

こちらを読む限り、ライフタイムを縮小する機能は無さそうです https://doc.rust-jp.rs/rust-nomicon-ja/lifetimes.html これは想像ですが、関数宣言によって新たに作られたライフタイムを取得しているのではないかと思います &mutで実引数を受け取る場合、専用のスコープが生成されるとあるので、このスコープをライフタイムとして明示的に仮引数へ渡す時に、引数がこのライフタイムに制限されるものと思われます関数を抜ける場合、このスコープ内で&mutも消化されるため、これを受け取る変数が必要と考えられますまたフィールドのライフタイムはインスタンスのそれに縛られるので、&mut valが広域のスコープに属していることを踏まえると、関数が受け取る局所的なスコープは、この広域スコープを包括しなければなりません参照を代入する場合、その変数のライフタイムは参照元よりも狭くなりますつまりは普段はライフタイムを推論するものの、それが明示的に指定された場合にライフタイムが一致するシンボルが必要になるものと考えられます

2025/04/02 05:30

追記の助言をくださって、大変ありがとうございます！ Manabu さんが助言してくださっていることも、bsdfan さんと同じことを指摘して下さっているのだと思います。 Manabu さんの助言も大変ありがたく、ベストアンサーとしたいのですが、いままで Variance について調べようと思いつつ（他言語でも必要な概念ですし、、、）調べてこなかったので、その点を考える良い機会となったと思ったので、bsdfan さんの方を僭越ながらベストアンサーとさせていただきました。時間をかけて回答を書いてくださって、大変ありがとうございます。すみませんが、また何かの機会がありましたら、声を掛けてくださると大変嬉しいです。