Rust part14

**デフォルトの名無しさん** · 2022/02/12(土) 01:24:16.59

公式
https://www.rust-lang.org/
https://blog.rust-lang.org/
https://github.com/rust-lang/rust

Web上の実行環境
https://play.rust-lang.org

日本語の情報
https://rust-jp.rs/

※Rustを学びたい人はまず最初に公式のThe Bookを読むこと
https://doc.rust-lang.org/book/

※Rustを学ぶ際に犯しがちな12の過ち
https://dystroy.org/blog/how-not-to-learn-rust

※Rustのasyncについて知りたければ「async-book」は必読
https://rust-lang.github.io/async-book/

※C++との比較は専用スレへ
C++ vs Rust
https://mevius.5ch.net/test/read.cgi/tech/1619219089/

※次スレは原則>>980が立てること

前スレ
Rust part13
https://mevius.5ch.net/test/read.cgi/tech/1636247099/

**デフォルトの名無しさん** · 2022/03/28(月) 18:04:16.18

まずはif let試してみたら？

if let Ok(v) = r {v使ったほにゃらら}
if let Some(v) = o {v使ったほにゃらら}

**デフォルトの名無しさん** · 2022/03/28(月) 18:35:07.91

>>549
エラーなどの分岐が発生しうる時に
必ず正常値だと確信できる場合、もしくは、正常値でなければpanic終了してよい場合に
unwrap()を用いる

逆に言えば上記の場合でなければ
unwrap()を用いてはいけない

エラーなどの有無による分岐処理が必要とされている場面なのだから
if letやmatchや?オペレータ(=エラー時に即return)を用いなければならない

**デフォルトの名無しさん** · 2022/03/28(月) 18:50:10.35

>>549
そのコードを晒せば識者が添削してくれるんじゃね？

**デフォルトの名無しさん** · 2022/03/28(月) 18:52:11.66

rustでCのライブラリラップしてるけどまじでわからんこと起こりまくってて泣きそう
構造体に保持したはずのハンドラが不可解なタイミングで消えてつらい
Cにも疎いからしんどすぎる

**デフォルトの名無しさん** · 2022/03/28(月) 20:40:56.66

>>554
それはさすがにCでのメモリ管理とRustでのメモリ管理とそれらの違いを把握できていることが最低条件

**デフォルトの名無しさん** · 2022/03/28(月) 23:00:56.50

このスレに識者がいるという錯覚ｗｗｗｗ

# Run cargo-geiger!
# 💀💀💀☢☢☢☢💀💀💀 !!!! Rust is ☢UNSAFE☢ !!!! 💀💀💀☢☢☢☢💀💀💀

**デフォルトの名無しさん** · 2022/03/28(月) 23:06:14.30

>>556
C/C++/Rustスレでも次世代言語Rustスレでも暴れ回って嫌われてるようですねガイガーくん
ここRust本スレには来ないでもらえますか？

**デフォルトの名無しさん** · 2022/03/28(月) 23:21:53.41

>>553
それがいいね
対処方法はコード次第だから一部でも晒さないと一般的なアドバイスに留まってしまう

**デフォルトの名無しさん** · 2022/03/29(火) 08:06:04.87

>>555
ラップ用のライブラリて無いの？

**デフォルトの名無しさん** · 2022/03/29(火) 10:43:23.37

>>559
うまくラッピングしてあってもCライブラリの内部の参照とかのあたりがうまくRustの所有権システムに乗らなくてしんどいことが多々あるから仕方ないことな気がする

**デフォルトの名無しさん** · 2022/03/29(火) 13:05:38.54

ハンドラのトラブルで思い浮かぶのはDropで解放する機能を実装したのにCopy可能になってるケースかな
数値型で表現される場合が多いからCopy不可の型で包まないとCopy先で解放されたりして事故りやすい
基本的にDropトレイトとCopyトレイトを混ぜるのはNG

**デフォルトの名無しさん** · 2022/03/29(火) 22:26:38.54

>>561
CopyとDropの両立は出来なくなっているのでその問題は発生しない

https://doc.rust-lang.org/std/ops/trait.Drop.html#copy-and-drop-are-exclusive
| [Copy and Drop are exclusive]
| You cannot implement both Copy and Drop on the same type.

**デフォルトの名無しさん** · 2022/03/29(火) 22:49:23.99

>>557
え？なんで？ｗ
# Run cargo-geiger!
# 💀💀💀☢☢☢☢💀💀💀 !!!! Rust is ☢UNSAFE☢ !!!! 💀💀💀☢☢☢☢💀💀💀

**デフォルトの名無しさん** · 2022/04/03(日) 01:32:58.40

https://github.com/diesel-rs/diesel/blob/v1.4.4/examples/postgres/getting_started_step_1/src/schema.rs
（https://diesel.rs/guides/getting-started.htmlの一部分）
このアロー演算子みたいなのが並んでいる部分って、どういう意味の文法なんですか？
一見してセッターかクロージャーなのかと思いきや、全然違うようで！？・・・・これは一体何なんですか？？？？

**デフォルトの名無しさん** · 2022/04/03(日) 01:41:18.67

>>564
マクロの呼び出し

**デフォルトの名無しさん** · 2022/04/03(日) 02:40:58.52

>>565
マクロはわかんなかった、ありがとう！
ゆっくり調べてくる！

**デフォルトの名無しさん** · 2022/04/04(月) 15:56:50.90

こういうのがエラーになるんだが、なんで？
エラーメッセージは Sized が満たされてないとか出るんだけど
dyn とか Box ってこういう使い方をするもんじゃないの？

let mut foo = Box::<dyn Fn() -> usize>::new(|| 1);
foo = Box::<dyn Fn() -> usize>::new(|| 2);

**デフォルトの名無しさん** · 2022/04/04(月) 16:47:46.89

>>56
現状のrustではBox::newの引数に渡すのはコンパイル時にサイズが決まる型でないといけないから
dyn Fn() -> usize 型の値は渡せない

以下みたいに Box::new() で作った Box<T> 型の値を Box<dyn ...> にキャストするとやりたいことできると思う

https://play.rust-lang.org/?version=stable&;mode=debug&edition=2021&gist=e02762a4d2df4aed2c5396251cd0a07c

**デフォルトの名無しさん** · 2022/04/04(月) 16:48:14.52

>>568 は >>567 宛て

**デフォルトの名無しさん** · 2022/04/04(月) 16:57:22.99

>>568
ありがとう。

**デフォルトの名無しさん** · 2022/04/04(月) 23:27:32.81

let mut foo: Box<dyn Fn() -> usize> = Box::new(|| 1);
foo = Box::new(|| 2);
// ↓ このケースならばFn()使わずともfn()で行ける
let mut foo: Box<fn() -> usize> = Box::new(|| 1);
foo = Box::new(|| 2);
// ↓ さらにBoxも不要となる
let mut foo: fn() -> usize = || 1;
foo = || 2;

**デフォルトの名無しさん** · 2022/04/04(月) 23:30:29.31

unwrapじゃなく;がunwrapの代わりになったらよかったのに、構文解析に;なんてもう使ってないでしょうに

**デフォルトの名無しさん** · 2022/04/04(月) 23:41:54.63

>>572
なぜ？
>>552にもあるけどunwrapなんて非常に特殊な時のみ使うもの
論理的にNoneやErrではないと保証できる場合は使うべきだが頻度も限られる
残りはNoneやErrの時にpanic終了という簡易エラー処理の場合でしかunwrapは使われない
その簡易エラー処理をしたい場合でも？オペレータでエラーを最上位に集めて1カ所だけエラー表示を設けるとpanic unwrapを無くせる

**デフォルトの名無しさん** · 2022/04/05(火) 04:14:10.02

>>572
文は式と区別するため必ず「;」を伴う
例えば関数やブロックの最後(＝「}」の直前)に
「;」があると文となり返り値が()となる
「;」がないとその式の値が返り値となる
そしてブロックやif-elseやloopはその値の式なので文を形成する最後に登場する時は「}」の直後に「;」が来る
このように他のプログラミング言語とは異なりRustでは「;」の存在は重要である

**デフォルトの名無しさん** · 2022/04/05(火) 07:02:36.93

ブロックの最後の式がブロックの評価値になるのはRubyもそうだよ
だからと言って;にunwrap割り当てろとは思わないけど

**はちみつ餃子** ◆8X2XSCHEME · 2022/04/05(火) 11:45:54.41

unwrap はそれなりに目立つべきだろう。
一文字でどうにかするのはよろしくない。

**デフォルトの名無しさん** · 2022/04/05(火) 15:21:06.80

unwrap連打することもあるんだからないな
他の言語みたいにunwrapを!で書けるようにするほうがマシ

**デフォルトの名無しさん** · 2022/04/05(火) 16:32:58.11

むしろunwrap_or_dieとかにして欲しいくらいだな

**デフォルトの名無しさん** · 2022/04/05(火) 17:27:14.20

使いにくく書きにくくさせることで
馬鹿に知らず識らずマナーを強いてるんだよ

だからJavaでアクセッサ書くのダルいと怒ってるのと
rustでmutってタイプするのダルいと怒ってるのと
unwrapってタイプするのダルいと怒ってるのと

言ってる人はみなおなじバカ
ちなみに馬鹿に迎合してプロパティを準備してみせたウルトラバカ言語がC#

**デフォルトの名無しさん** · 2022/04/05(火) 17:46:43.00

>>578
これすき

**デフォルトの名無しさん** · 2022/04/05(火) 18:59:43.74

だったらfnなんて短さ、どうなん？とは思うけどな。

**デフォルトの名無しさん** · 2022/04/05(火) 19:10:52.07

予約語と比較してどうする

**デフォルトの名無しさん** · 2022/04/05(火) 19:39:53.86

unwrap()は論理的に安全に剥がせると明確になる特殊な場合のみ使うべきもの
見てすぐ明確でない時はコメントを付けること推奨

**はちみつ餃子** ◆8X2XSCHEME · 2022/04/05(火) 20:30:38.50

エラーメッセージ中で便宜上のライフタイム (?) として '1 というのが出てくることがあるけど、
これは一個目の引数のライフタイムという解釈でいいのかな？

**デフォルトの名無しさん** · 2022/04/05(火) 20:31:56.58

unwrap()はリリースビルドでコンパイルエラーにして欲しい
Elmみたいにデバッグビルドでのみ使えるって感じで

**デフォルトの名無しさん** · 2022/04/05(火) 20:33:43.79

unwrapでpanic起こしたら死刑

**デフォルトの名無しさん** · 2022/04/05(火) 20:45:42.53

>>585
論理的に剥がして安全なことをコンパイラが追いかけてくれるならそれもありだけど
現状で全面unwrap禁止は無理

**デフォルトの名無しさん** · 2022/04/05(火) 20:52:13.73

書き捨てのコードでいちいち例外処理書かされるの面倒だからunwrapは必要

**はちみつ餃子** ◆8X2XSCHEME · 2022/04/05(火) 20:54:37.54

unwrap を排除したらそれぞれで unwrap みたいなものを定義して使うようになっちゃうのがオチだよ。

**デフォルトの名無しさん** · 2022/04/05(火) 20:56:22.37

>>583
コメントつけるならexpectでpanic時メッセージ出した方が良いのでは

**デフォルトの名無しさん** · 2022/04/05(火) 21:09:00.11

>>590
論理的に起きない場合にexpectは単なるコードの無駄
エラー発生時にパニック終了していいプログラムで補完エラーメッセージとしてexpectを使う

**デフォルトの名無しさん** · 2022/04/05(火) 21:21:53.89

>>591
趣味の問題な気がするけどその理屈だと論理的に起きない場合はコメントの無駄とならない？
それともコミュニティーで広く普及してる慣例があるのかしら

**デフォルトの名無しさん** · 2022/04/05(火) 21:39:41.29

一般的に、論理的に正しいがコードを見てすぐに把握できない可能性がある場合は、コメントを付ける慣例

**デフォルトの名無しさん** · 2022/04/05(火) 21:55:10.17

>>591
コードの無駄というのは正確には何が無駄なのだろう
文字列分の領域？

**デフォルトの名無しさん** · 2022/04/06(水) 00:04:36.01

>>578
Javaっぽいですね

**デフォルトの名無しさん** · 2022/04/06(水) 00:19:00.36

>>575
Null条件演算子とか他言語には一般的になって来てるけど、ライブラリでしかないはずのOption,Resultが言語の中核みたいになってるRustが
採用するとは思えない。Option条件演算子？

**デフォルトの名無しさん** · 2022/04/06(水) 00:29:51.46

他でのNull合体演算子つまりNull時にデフォルト値とする演算はRustではunwrap_or
もちろんそれら他の言語ではT型そのものにNullがありミスを防げないが
RustではT型とOption<T>型に分かれているためミスが起きない

**デフォルトの名無しさん** · 2022/04/06(水) 03:59:22.01

いや言語的な特性のこと言ってるわけじゃねーからｗいちいち知識疲労で解説しなくていいからｗ

**デフォルトの名無しさん** · 2022/04/06(水) 08:23:07.29

ルビー君と同じ病気だよね
しかも間違ってるし

**デフォルトの名無しさん** · 2022/04/06(水) 09:21:37.82

>>596
rust の場合 try {} 構文が対応するものかな
try { a?.b?.c }
みたいに書ける

**デフォルトの名無しさん** · 2022/04/06(水) 10:07:13.82

>>600
try構文使わずとも書けるよね

fn main() {
let a = Some([[1, 11], [2, 22], [3, 33]]);
let x = (|| Some(a?.last()?.first()? * 100))();
assert_eq!(x, Some(300));
}

**デフォルトの名無しさん** · 2022/04/06(水) 10:33:16.53

>>596が言ってるのはnull条件演算子
>>597が言ってるのはnull合体演算子

そりゃ話が通じるわけない

**デフォルトの名無しさん** · 2022/04/06(水) 11:49:10.11

>>597
C#とかSwiftとかKotlinとかNull safetyを備えてる言語も勉強してね
ちょっと恥ずかしいよ

**デフォルトの名無しさん** · 2022/04/06(水) 17:06:15.48

>>601
なるほど、クロージャにすれば?使えるって発想なかったわ

**デフォルトの名無しさん** · 2022/04/06(水) 18:11:52.43

なるほどじゃねーよwww

**デフォルトの名無しさん** · 2022/04/07(木) 04:17:47.69

stableでどうしてもtryっぽく書きたい場合の苦肉の策でしかないな

**デフォルトの名無しさん** · 2022/04/07(木) 07:08:56.80

クロージャ(ラムダ)の即時実行は他の色々な言語でも行なう頻出パターン
Rustでは他にもforやwhileから値を返したい時などにもクロージャの即時実行で行なう

**デフォルトの名無しさん** · 2022/04/07(木) 07:19:00.45

これって、公開するメソッドのの数だけディスパッチャメソッドが増えてく感じなの？
https://tourofrust.com/81_ja.html
結構めんどくさいような気もするんだけど・・・・こういうのってエディタの拡張とかが勝手やってくれたりとか、支援みたいなのあるの？？？

**デフォルトの名無しさん** · 2022/04/07(木) 07:36:57.92

>>608
プログラマーは全く何もしなくてよい
dyn Traitの場合はメソッド数分の関数ポインタを持つディスパッチ用テーブルが各使用型毎に自動的に生成されて実行時に自動的に適用される
impl Traitの場合は使用メソッドの関数がモノモーフィゼーションすなわち各使用型毎にコンパイル時に展開される
逆にプログラマーが自分で分岐処理する第三の方法としてenumに各使用形を収容してmatchによる分岐処理があってこの方法が有利になるケースもある

**デフォルトの名無しさん** · 2022/04/07(木) 10:32:38.29

C++ だと静的な多相はテンプレートで、動的な多相は仮想関数 (抽象クラス) でやってるわけだけど、
Rust だと dyn だけで切り替えられるってわけだな。

**デフォルトの名無しさん** · 2022/04/07(木) 12:45:48.26

>>608
tour of rustでRustに入門するのはやめたほうがいいぞ
中身が更新されてないしGoと違ってtourから始めるのは害にしかならないから

**デフォルトの名無しさん** · 2022/04/07(木) 13:22:38.91

わかる。
Rust の型システム・所有権システムは理屈が分かってないと慣れでどうにかなるもんではない。
理解した上でなら手を動かしてみるのは悪くないと思うけど。

**デフォルトの名無しさん** · 2022/04/07(木) 15:06:14.55

>>612
それはどんな言語も多かれ少なかれありそう
Cのポインタもそうだしね

**デフォルトの名無しさん** · 2022/04/07(木) 18:17:40.12

>>607
クロージャの即時呼び出しは基本的に言語機能が足りない場合のワークアラウンドでしょ

**デフォルトの名無しさん** · 2022/04/07(木) 18:20:36.61

クロージャは引数と戻り値を推論してくれるからこそだね
関数でも、なんかの条件付きでもいいから推論してほしいわ

**デフォルトの名無しさん** · 2022/04/07(木) 18:21:01.63

推論というか、型推論ね

**デフォルトの名無しさん** · 2022/04/07(木) 18:33:18.44

関数含むモジュールレベル定義の型推論はやろうと思えばできるけど
コンパイル時間への影響がでかいのと、ドキュメント的な意味で型を書いた方がわかりやすいという理由で
敢えて対応していないとどこかで読んだ気がする

とはいえ戻り値のimpl Traitは制限された形での型推論と言えるんじゃないかな

**デフォルトの名無しさん** · 2022/04/07(木) 18:34:30.25

>>614
Rustでは型指定しなくて済む利点もあるしクロージャと関数の使い分けの一種じゃないかな
もちろん今回のケースはreturn値を取る別種のブロックがあれば済むけども
それをわざわざ導入しなくてもクロージャ即時呼び出しで十分

**デフォルトの名無しさん** · 2022/04/08(金) 04:35:42.40

Rustのコンパイルの遅さは型推論とかじゃなく、cargoという非常に悪い仕組みのせい

**デフォルトの名無しさん** · 2022/04/10(日) 02:43:45.04

そんなことないよ
cargo build --timings　いいね

**デフォルトの名無しさん** · 2022/04/10(日) 11:44:22.72

Rust 1.60来てたか

**デフォルトの名無しさん** · 2022/04/12(火) 10:03:48.28

OnceCell<T> って &'static T が取れるわけじゃないんですのん？

**デフォルトの名無しさん** · 2022/04/12(火) 10:14:36.57

まちがえた
× OnceCell<T>
○ const Lazy<T>

**デフォルトの名無しさん** · 2022/04/12(火) 10:20:45.37

getでOption<&T>が取れる
初期化してなければNone

**デフォルトの名無しさん** · 2022/04/12(火) 10:26:05.90

LazyならDerefを適用させて使う
*lazyで&Tや&mut T

**デフォルトの名無しさん** · 2022/04/12(火) 10:46:54.62

https://play.rust-lang.org/?version=nightly&;mode=debug&edition=2021&gist=22ed821be70a494615ca8a661e98b78f

ごめんこういうこと
実際使ってるとき&'staticが取れないのが原因だと思ってそう書いちゃったけど違う原因かもしれないです

**デフォルトの名無しさん** · 2022/04/12(火) 11:20:51.11

それはconstではなくstaticで宣言

**デフォルトの名無しさん** · 2022/04/12(火) 11:33:29.72

プログラム開始時点での有効性を保証できないから何となくだけどコンパイラの事情で無理そう

&'staticって↓みたいな使い方もできるからLazyだとBの参照先が初期化済みか分からない
static A: u32 = 0;
static B: &'static u32 = &A;

**デフォルトの名無しさん** · 2022/04/12(火) 11:37:37.75

nightlyのstd::lazy::Lazyではなく
stableでも使えるonce_cellを使用
そのコードと同じ例がこれで動く

use once_cell::sync::Lazy;

static LAZY: Lazy<i32> = Lazy::new(|| 92);

fn main() {
let a: &'static i32 = sub();
println!("{}", *a);
}

fn sub() -> &'static i32 {
&*LAZY
}

**デフォルトの名無しさん** · 2022/04/12(火) 11:44:54.53

あーなるほど
なぜか'staticでmutableなのがstatic、immutableなのがconstと勘違いしてました
constって使用の度に式展開するやつだったんですね
temporary valueなんて無いじゃんとか無限に悩んでた

ありがとうございます

**デフォルトの名無しさん** · 2022/04/12(火) 11:47:13.23

>>630
constはコンパイル時点で定まる定数

**デフォルトの名無しさん** · 2022/04/13(水) 09:59:43.40

こんな事も分からない触ってるだけで偉いと勘違いするゴミ言語

**デフォルトの名無しさん** · 2022/04/15(金) 00:23:00.39

>>613
プログラムのポインタ（メモリアドレスを参照するもの）は
ポインタのメタファだから元のポインタを知ってれば理解できるが、
substructural type systemはtype systemの一種でtype systemは
型理論を元にした体系的な理屈だから理屈が理解できなきゃ理解できないから全く別の話。

>>612の言う「慣れでどうにかなるもんではない」っていうのはつまり、
わかった気になってなんとなくで書いてるやつはまだ理解してないって話でしょ。

**デフォルトの名無しさん** · 2022/04/15(金) 00:36:10.15

ソフトウエアを書くにはカテゴリー論から勉強しろということかな？

**デフォルトの名無しさん** · 2022/04/15(金) 00:46:18.85

名言もらいました
ポインタはポインタのメタファ

**デフォルトの名無しさん** · 2022/04/15(金) 00:56:52.75

>「慣れでどうにかなるもんではない」っていうのはつまり、
>わかった気になってなんとなくで書いてるやつはまだ理解してないって話でしょ。

全然違う。
型システムより先に文章を理解する訓練をした方がいいぞ。

**デフォルトの名無しさん** · 2022/04/15(金) 01:20:52.56

>>612
他の言語と同様にRustもそんな難しいことしていないから大丈夫
論理とメタ的な考え、例えば高階やジェネリクス等、ができる普通の人ならばRustの理解は容易い

**デフォルトの名無しさん** · 2022/04/15(金) 08:25:31.44

>>637
さすがにそれを「普通の人」というのは無謀。

**デフォルトの名無しさん** · 2022/04/15(金) 08:41:02.84

100点オジサンや複製オジサンみたいな自分は理解してるつもりの勘違いさんが一番迷惑

**デフォルトの名無しさん** · 2022/04/15(金) 08:59:01.96

>>638
普通のプログラマーなら他の言語でクロージャ(ラムダ等)くらいはさすがに使ったことあるから高階は大丈夫なはず
ジェネリクスもスクリプト言語などの動的型付け言語なら計らずともそのままジェネリックな関数となってる

そこでRustでのみ必要となる概念はそのジェネリックな関数内を安全な操作とするためのトレイト境界の指定
これはコンパイラがエラーとして教えてくれるため指定を忘れることがない
だから普通のプログラマーなら大丈夫じゃないかな

**デフォルトの名無しさん** · 2022/04/15(金) 10:17:08.40

相変わらず複製おじさんは不勉強でキツイな
「普通の人」は他の言語でジェネリック使ったことあるからこんな恥ずかしい長文を書かない

**デフォルトの名無しさん** · 2022/04/15(金) 10:53:34.01

そうでなくRustではtrait境界が足りなければコンパイルエラーで指摘されるからスクリプト言語から来た人でも困らないって話やろ

**デフォルトの名無しさん** · 2022/04/15(金) 11:18:53.45

そんなことよりこのエラーの意味を教えてくれ

https://play.rust-lang.org/?version=stable&;mode=debug&edition=2021&gist=21cdaa3e90ffdd6a5ef2e06302afe03b

**デフォルトの名無しさん** · 2022/04/15(金) 11:41:06.84

>>641
Rust特有の話については触れたくないんだろ
理解してないから

**デフォルトの名無しさん** · 2022/04/15(金) 12:09:57.32

おじさん使いの人はいつもそうだよな

**デフォルトの名無しさん** · 2022/04/15(金) 12:26:07.26

>>640
「クロージャ(ラムダ等)くらいはさすがに使ったことある」からといって「論理とメタ的な考え……ができる」ではないことは論理的に明らか。
全然論理的な考えができていない>640自身が反証になっているね。

**デフォルトの名無しさん** · 2022/04/15(金) 12:58:35.38

>>643
lifetime mismatchのエラーが分かりにくければ、lifetimeを省略せずに明記して確認すればいい

**デフォルトの名無しさん** · 2022/04/15(金) 13:07:01.81

あと#![feature(nll)]でビルドしても分かるはず

**デフォルトの名無しさん** · 2022/04/15(金) 13:08:53.72

>>646
むしろ論理とメタわからんプログラマーは言語関係なく向いてないっす

**デフォルトの名無しさん** · 2022/04/15(金) 13:30:54.07

理解の程度を0か1で考える人は底辺プログラマーに向いてる

**デフォルトの名無しさん** · 2022/04/15(金) 14:19:47.21

所有権でよくわからないって言えばさあ
fn asdf() -> &str{
let s = "jkl";
s
}
みたいにした時に、関数を抜ける際にstrのライフタイムが尽きちゃう訳じゃない
でも逆になぜ&strしかないのに、どうして関数を抜けるところまでstrのライフタイムが持つのか？そこら辺がよくわからねえな
&strを通じてstrを所有できているのであれば、&strをリターンできても良いような気もするのに・・・・どうなってんの？