[過去ﾛｸﾞ] Rust part24 (1002ﾚｽ)
上下前次1-新
抽出解除 必死ﾁｪｯｶｰ(本家) (べ) 自ID ﾚｽ栞 あぼーん
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
469(5): デフォルトの名無しさん [sage] 2024/06/29(土) 15:34:20.66 ID:KH8yb7Br(1/6) AAS
それまで参照を持たなかった構造体にメンバとして参照を持たせると、型にジェネリックライフタイムが付いて、その型の使用箇所全部でライフタイムを書く必要がある
さらに悪いことに、実際のところこれは必要ではなく、ライフタイムを書かなくても省略されていると見なされてコンパイルが通ることもある
しかしこれでは意図通りのライフタイムになっていないことが多く、その型の使用箇所を増やしたときに初めてそのことに気づくことになる
Rust特有のリファクタリングしづらさは、あるよ
474(3): デフォルトの名無しさん [sage] 2024/06/29(土) 16:52:22.95 ID:KH8yb7Br(2/6) AAS
>>471471(1): デフォルトの名無しさん [sage] 2024/06/29(土) 16:01:57.62 ID:obFhbebh(1/2) AAS
>>469
リファクタリングの作業の大きさに対して、必要なライフタイム注釈を付けるだけの些細なことが障害になったことはないな。
ライフタイム注釈が'aになるか'_になるか省略できるかは、その必要性と省略ルールに基づくだけなので、そこで問題が発生することはないだろう。
「ライフタイム注釈が'aになるか'_になるか省略できるか」は、すべての使用箇所ごとに以下を検討したうえで決まる
* 追加するライフタイムは既存のライフタイムと同じであるべきか
* 既存と同じであるべきでないなら、そのライフタイムはどこで宣言すべきか（impl? fn? トレイトや構造体?）
それで1つの型がリファクタリングできたところで、
* トレイトや構造体にジェネリックライフタイムパラメータを追加した場合、そいつにも同じ作業がいる。最初から繰り返し
ここまでのすべての作業に尋常でない集中力が必要になる
繰り返しの中でライフタイムの宣言箇所の選択が誤っていたことに後で気づいたりすると悲惨だ
「エラーのあるコードをgit commitしない方が良い」という思い込みを捨て、選択を必要とするタイミングでgitに記録するようにして、
作業効率は安定はするようになったが、それでも作業を捨てるというのは気が滅入る
「あ、この関数の引数にライフタイム追加することになるけど、後で戻り値にもライフタイム追加することになるな」なんて思っても一挙に作業してはいけない
少なくとも自分の頭では作業の段取りを崩すだけだった
そしてここまでを全集中して完了してコンパイルを通すところまで持って行けても、クレート外の使用箇所でおかしなことにならないことは保証できない
ボローチェッカーは書かれている使用法が妥当であるかどうかしか検証しないからだ
こっちは体験談として言っているんだから、机上の空論を弄するのはもうやめなさい
475(1): デフォルトの名無しさん [sage] 2024/06/29(土) 16:58:20.78 ID:KH8yb7Br(3/6) AAS
Rustはライフタイムさえ正しく書けていれば本当に有用な助けを与えてくれる
しかしライフタイムを正しく書くための助けはほとんど与えてくれないので、自分で書く必要があるときには上と同じような期待をしてはいけない
478: デフォルトの名無しさん [sage] 2024/06/29(土) 17:17:23.37 ID:KH8yb7Br(4/6) AAS
>>477477(1): デフォルトの名無しさん [sage] 2024/06/29(土) 17:06:14.07 ID:HTwQ17U9(1) AAS
>>474
>>475
それは大きな誤解をしているなあ
ライフタイムアノテーションを間違って書いて矛盾が起きていればコンパイルエラーとなるよ
コンパイルが通れば正しく書けているからプログラマーがそこで困ることはないよ
いいからこれでも読んでろ
外部ﾘﾝｸ[md]:github.com
> Rustのトレイトオブジェクトへのライフタイム省略ルールはどんな状況でも正しいというわけではない
> Rustはプログラムの意味についてプログラマよりも知っているわけではない
> Rustのコンパイラが吐くエラーメッセージでおすすめされる修正はコンパイルが通るようにするが、コンパイルが通り、 かつ プログラムへの要求をちゃんと満たしたものするわけではない
485: デフォルトの名無しさん [sage] 2024/06/29(土) 20:23:11.41 ID:KH8yb7Br(5/6) AAS
>>469
これか……
外部ﾘﾝｸ:github.com
> I think the answer here is "Alex thought it was fun to avoid RefCell and Mutex", there's no real technical motivation.
「cloneを避ける/ロックを避ける/参照カウンタのコストを避ける」みたいなゼロコスト主義も節度を持ってやれってことね
とりあえず「型のジェネリックライフタイム引数を変更するのは多大なコストがかかる」という理解は合っていると思っておくことにするか
486: デフォルトの名無しさん [sage] 2024/06/29(土) 20:23:40.20 ID:KH8yb7Br(6/6) AAS
>>481481(1): デフォルトの名無しさん [sage] 2024/06/29(土) 18:13:00.59 ID:E9RFAyQx(1) AAS
>>469
その逆のリファクタリングを影響範囲が大き過ぎて無理って話をcargoのissueで見たことある
cargoはそれ以外でも技術的負債が溜まってるけど影響範囲が大きくなるから簡単に手を入れられないってことを中の人がよくボヤいてるね
だった
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.036s