Rust言語で使えてunsafeの外側ではRcが提供してくれるような保証を提供するトレーシングGCのスマートポインタを作るのは難しいという人々の談がいくつかあって、いつか眠たくないときに紹介したいと思っています

やりましょう。そして「Rustって型安全性とメモリ安全性は細かくチェックしてくれるけれど、プログラムの他の側面はやっぱりテストコード書かなきゃいけないんだよな……」と思い始めたらF*（FStar）やりましょう

この両方とも事前に考えたのだけれども、先に現れる引数の識別子を特別扱いするというのが良い設計なのか疑問が残る、「出力のlifetimeはsとtのlifetimeの和」と「出力のlifetimeとsのlifetimeとtのlifetimeは同じ」は検査アルゴリズム上異なるような気がする、という反論がそれぞれあって採用しなかった

ここでは、入力sのlifetimeと入力tのlifetimeはともに出力のlifetimeと同じでなければならないという関係

入力のlifetimeに関係がある場合というのは書きたかったものが
fn frob<'a>(s: &'a str, t: &'a str) -> &'a str;
だったという場合です

これは入力のlifetimeに関係があったりするとどうするんだというのがあり、あまり良くはなさそう

fn frob(s: &str, t: &str) -> &str;（lifetime省略不能）
を
fn frob<'a, 'b>(s: &'a str, t: &'b str) -> &'a str;
と書く代わりに
fn frob(s: str, t: str) -> &'s str;
みたいに書けたらどうか、ということでしょうか

複数の参照が存在しうる後始末が必要なリソースを受け渡す機能が必要なときに、

・人がチェックして運用でカバーしたり、
・トレーシングGCで不要になったリソースをその内後始末したり、
・参照カウンタ（これもGC）で参照状況を都度書き留めることで不要になり次第後始末したり、

するのだけれども、GCでランタイムに状況監視せずともコードから静的に「このリソースが必要なのはこの範囲」と特定できる状況がある。
そこで、その限られた状況において、人手にも頼らずランタイムに状況監視するコストも払わず、後始末が無事つつがなく終わることを確かにするのがlifetime、という認識。

Lifetime elision - The Rust Reference https://doc.rust-lang.org/reference/lifetime-elision.html

lifetimeの省略

lifetimeをimplicitにしすぎるとかえって「この引数のlifetimeが短くてコンパイルが通らないがなぜそうなるのかわからない」という状況が増えるので、ある種の明らかな条件下でのみlifetimeを推論するようになっていると理解している