Rust part25

**デフォルトの名無しさん** · 2024/07/31(水) 00:46:26.17

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

公式ドキュメント
https://www.rust-lang.org/learn

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

※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/

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

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

ﾜｯﾁｮｲスレ
プログラミング言語 Rust 4【ﾜｯﾁｮｲ】
https://mevius.5ch.net/test/read.cgi/tech/1514107621/

**デフォルトの名無しさん** · 2024/07/31(水) 00:47:02.26

**デフォルトの名無しさん** · 2024/07/31(水) 00:47:20.93

Rust Reference Book
https://doc.rust-lang.org/reference/
Rust Standard Library
https://doc.rust-lang.org/std/
Rust rustc Book
https://doc.rust-lang.org/rustc/
Rust rustdoc Book
https://doc.rust-lang.org/rustdoc/
Rust rustup Book
https://rust-lang.github.io/rustup/
Rust Cargo Book
https://doc.rust-lang.org/cargo/
Rust unstable Book
https://doc.rust-lang.org/nightly/unstable-book/
Rust macro Book
https://danielkeep.github.io/tlborm/book/
Rust CLI (Command Line Interface) apps Book
https://rust-cli.github.io/book/
Rust Future Book
https://cfsamson.github.io/books-futures-explained/
Rust async-std Book
https://book.async.rs/
Rust tokio Book
https://tokio.rs/tokio/tutorial
Rust serde Book
https://serde.rs/

**デフォルトの名無しさん** · 2024/08/01(木) 16:24:10.41

>>1
乙

**デフォルトの名無しさん** · 2024/08/01(木) 18:56:40.59

https://prcdn.freetls.fastly.net/release_image/22017/53/22017-53-0b7b835a46293a3a03b057104ef0d96b-2440x1394.png

**デフォルトの名無しさん** · 2024/08/01(木) 23:55:38.74

「The Rust Foundation」は、人命や財産に関わるような安全性が決定的に重要になるシステムのために、
Rust言語を責任を持ってサポートするためのコンソーシアム「Safety-Critical Rust Consortium」の設立を発表しました。
設立には日本からWoven by Toyotaが参加

**デフォルトの名無しさん** · 2024/08/03(土) 23:20:11.39

今日調べたけど、RustでVecを拡張するときのサイズは前の2倍
JavaとRubyは1.5倍
Pythonはややこしくて約112.5%
Goはまず2倍だけど要素数が256を超えたら1.25倍におさえる

Rustはメモリ大目に使いがちかも

**デフォルトの名無しさん** · 2024/08/03(土) 23:47:40.31

Note that the exponential growth is important.
On each reallocation, we have to copy twice as much, but then it takes twice as long to fill up again.
These factors cancel out and we get (on average) constant-time .push().

**デフォルトの名無しさん** · 2024/08/04(日) 09:23:44.30

>>7
そのレートを利用者側で調整出来れば最強だった

**デフォルトの名無しさん** · 2024/08/04(日) 12:21:30.93

要らない
設定できてしまうと、測定もせずに小さなレートを設定してかえって遅くなるか、
神経質な人やチームなら必要もないのにいちいち測定する羽目になって生産性爆下がりするかの二択になる
本当に調整する価値のある状況ならちゃんと測定して決めるはずだし、その手間に比べたら自前で適宜リサイズするくらい全く問題にならない手間だろう

**デフォルトの名無しさん** · 2024/08/04(日) 12:26:21.94

>>7
それらGC言語は言語によってはメモリ管理上で仕方ない場合もあるのかもしれないが
C++やRustでは全く問題がないように作られているためパフォーマンスの良い2倍にしている
重要な点はキャパシティを2倍にしても実メモリ割り当ては2倍の消費をせずにその後ベクタを使用した長さ分だけに限られること

**デフォルトの名無しさん** · 2024/08/04(日) 12:30:08.75

んなわけあるかい
いつのまにか勝手に他に割り当てられたらキャパシティの意味ないでしょ

**デフォルトの名無しさん** · 2024/08/04(日) 12:37:16.12

>>12
実メモリ割り当てと仮想メモリ割り当ての違いを学ぼう
C++でもRustでもベクタのキャパ内の未使用エリアにアクセスしない
そのため未使用分の実メモリ割り当ては発生せずメモリ使用量の問題が起きない

**デフォルトの名無しさん** · 2024/08/04(日) 13:05:57.09

まーた複オジの嘘がはじまったね

**デフォルトの名無しさん** · 2024/08/04(日) 14:52:31.44

ユーザ空間の話してるときにカーネルの話混ぜないでよ

**デフォルトの名無しさん** · 2024/08/04(日) 15:19:59.12

仮想メモリと実メモリの話はそもそもGoやJavaやRubyでも同じだろ
「他の言語では必ず実メモリから取られるから物理メモリ以上の量のデータを確保できない、だからこれらの言語では動的配列の確保を2倍よりも小さい値ずつにしている」とでも言いたいのか？

**デフォルトの名無しさん** · 2024/08/04(日) 16:16:53.81

2倍にしていけば累積コピー回数を平均1回台に抑えられるメリットがあって
これは1+2+4+8+...+2^(n-2)+2^(n-1)=2^n-1で累積と同じになるからで
そのためC++(gccやclang)やRustは2倍を採用している状況

別問題として
2倍にしていくのはメモリがもったいなくね？があるけど
OSの仮想メモリ管理により実際に使われるまでは実メモリが使われることはないのでだいじょうぶ

さらに自らv.reserve(size)とサイズを指定する手段も用意されていて
size以下の間はお引っ越しコピーを避けることができるので見積もれる時は推奨だよ

**デフォルトの名無しさん** · 2024/08/04(日) 17:23:30.18

reallocationなんてパフォーマンス落ちるだけだし
with_capacityで自分でコントロールした方が良いと思う

**デフォルトの名無しさん** · 2024/08/04(日) 17:51:55.81

>>17
仮想メモリは消費しないのか？
32bit OSだと何もしなければ仮想メモリ4GBくらいしか無い気がするが。

**デフォルトの名無しさん** · 2024/08/04(日) 18:11:52.52

大きなサイズに育っていくならコピー回数が少なくなる毎回2倍が有利
仮想メモリが足りるか足りないかの限界状況で用いるならwith_capacity()やreserve()を最初から用いる

**デフォルトの名無しさん** · 2024/08/04(日) 18:28:12.58

フラグメンテーションの問題とかもあるから教科書通りの2倍固定よりも
Goのようにサイズが大きくなるにつれGrowth Factorも小さくしていくモデルのほうが一般的には良さそうだね

**デフォルトの名無しさん** · 2024/08/04(日) 18:43:06.42

gccでもclangでもC++のvectorは2倍にしていくから
これはRustの話ではなくて
2倍にしていくのが好ましいという長年の確立された知見が存在しているんだよ

**デフォルトの名無しさん** · 2024/08/04(日) 18:44:03.04

一方でガベージコレクション依存言語は内部のメモリ管理方式が全く異なるから
各言語個別の事情があるかもしれないけどこのスレの話題ではないね

**デフォルトの名無しさん** · 2024/08/04(日) 19:01:06.46

>>16
それらの言語は仮想メモリを持たない環境のことも考慮しての増加率なんだろうな

**デフォルトの名無しさん** · 2024/08/04(日) 19:12:09.84

仮想メモリを持たない環境でGC言語www

**デフォルトの名無しさん** · 2024/08/04(日) 19:40:14.37

思い込みの激しい人だこと

**デフォルトの名無しさん** · 2024/08/04(日) 19:41:13.70

Vecのアロケート戦略なんて標準ライブラリの実装レベルの話でしかないし、言語の特徴や優劣のような話でもないだろ
GoやJavaが2倍でも、逆にRustがより小さい値だったとしても、GCの有無とかの話に比べればずっと些細な話でしかないし
マジでなにいってるんだこいつとしか思えない

**デフォルトの名無しさん** · 2024/08/04(日) 19:48:10.28

>>25
Javaなんかはもともと組み込みをターゲットに開発された言語だね。
GCの有無と仮想メモリには何の関係もない。

**デフォルトの名無しさん** · 2024/08/04(日) 20:16:30.17

この議論
元々メモリ無駄食いのGC依存言語は無視してよくて、
Rustと同じジャンルのC++で長年議論されてきて2倍という結論が出ている。
どうしても2倍を批判したいならまずはgccやclangのC++に対して行なうとよいかと。

**デフォルトの名無しさん** · 2024/08/04(日) 20:31:51.43

2倍に対して突っ込んでるんじゃなくて延々と的外れなことを書いてることに対して突っ込まれてるだけでは？
平均的なコピー回数が少ない点で2倍は妥当ではあるけど、それも「よく使われる方法」くらいの意味しかない
C++でもMSVCだと1.5倍だったと思うし (今のバージョンでもそうかは未確認)

警備員[Lv.18] · 2024/08/04(日) 21:44:51.68

先生！チャンクアロケーター沼への入水希望者がこんなに

**デフォルトの名無しさん** · 2024/08/04(日) 22:06:56.31

>>21
Goがなぜそんなやり方をしているのか
実行しながら実メモリ使用量の変化を傍らでウォッチして見た
Goの大きなsliceでcapacityが増える時に実メモリ使用量が急激に増える
C++やRustではcapacityが増えてもそんな変動は起きない
つまりGoはこの問題のため2倍ではなく1.25倍にせざるをえないと思われる

**デフォルトの名無しさん** · 2024/08/05(月) 00:28:29.24

>>16の主張が間違っていた可能性があるな
例えば世代別GC各管理領域も拡張再編などが起きるため
C++/Rustとは状況が異なり
増やしたメモリ領域への書き込みがすぐに生じて実メモリ使用量が一気に増えてしまうのかもしれない

**デフォルトの名無しさん** · 2024/08/05(月) 02:39:57.82

C++で folly::fbvector を開発したFacebookによれば
成長係数2は最悪であることが数学的に証明されてるらしい
結論は1.5

https://github.com/facebook/folly/blob/main/folly/docs/FBVector.md

https://medium.com/smucs/fbvector-a-possible-replacement-for-std-vector-e46bb31b8a56

**デフォルトの名無しさん** · 2024/08/05(月) 05:37:35.60

>>34
読んでみたが色々とおかしい
まず1.5倍がベストな理由が書かれていない
次に2倍が悪い理由の説明と現実が合っていない

書かれている2倍が悪い理由を具体的な数字で書いてみると
例えばベクタの使用メモリサイズが育っていって1GBになっている時に
過去に使った半分の512MBの空きが抜け殻としてあり
さらにその前の分として半分の256MBの空きもありそれが過去に繰り返されていて
512MB + 256MB + 128MB + 64MB + ...
= 1GB未満のの再利用できていないメモリがあることになる
つまり再利用ができていないために合わせて約2GBのメモリを確保しているにも関わらず使っているのは半分の1GBなってしまう

という2倍が悪い理由が書かれている
しかしこれは現実と異なる
実際にベクタをゼロから地道にプッシュしていきそのサイズが1GBになった時
確保しているメモリサイズを調べると1GBである
再利用できていない昔の抜け殻が計1GB弱残るという話が現実と合っていない

**デフォルトの名無しさん** · 2024/08/05(月) 07:22:04.78

mmap/munmapでOSにメモリを返却できるから古い抜け殻は残らない
さらにmremapで実コピーをせずに利用可能サイズを増やすことができる
それらを呼び出すコストがかかるためその頻度が1.x倍より少なくなる2倍が好ましい

**デフォルトの名無しさん** · 2024/08/05(月) 12:04:08.00

話が難しいから何を言っているかじゃなくて誰が言ってるかでしか判断出来ねえ
そして5chをソースにfollyのreadmeを否定する意見を信じることも出来ねえ

**デフォルトの名無しさん** · 2024/08/05(月) 12:25:55.60

話は聞かせてもらった
最適な比率は2でも1.5でもなく黄金比1.618だな
こういう問題は大体フィボナッチ数列が正解になる
僕は数学に詳しいんだ

**デフォルトの名無しさん** · 2024/08/05(月) 12:37:42.98

>>37
わかる
もうちょいライトなユーザ向けのスレも欲しいかも

**デフォルトの名無しさん** · 2024/08/05(月) 12:46:25.51

>>37
むしろ彼しか問題にしてないだろ
g++とclang++のvectorとrustcのVecは2倍にしていく
もし2倍が致命的なら大論争になり変更されるはずだ
現実には実用面も含めて問題となっていない

**デフォルトの名無しさん** · 2024/08/05(月) 13:06:57.87

「致命的」に後退しちゃったねｗ

**デフォルトの名無しさん** · 2024/08/05(月) 13:12:56.68

Linux などのメモリ管理戦略ではアロケータは空いてる番地を返すだけで
アクセスするまで実メモリの割り当てをしない。 (割り当てを遅延させる。)

vector を極端に伸ばしたり縮めたりするなら話は別だが、
徐々に伸びていって最後に捨てる一般的なユースケースなら
倍率はテキトーでも理論的な効率はそんなに差はない。

**デフォルトの名無しさん** · 2024/08/05(月) 13:21:17.66

rustやc++では再割り当てが行われると参照が無効になるから2倍にして頻度を下げるのかも

**デフォルトの名無しさん** · 2024/08/05(月) 14:50:20.61

https://github.com/rust-lang/rust/issues/29931
これだね
2015年から議論されてるけど、結局1.5倍がいいという結論には至ってないし
実際1.5倍を試してみた結果パフォーマンスが落ちてるから単純に1.5倍にするのはダメそう
もし1.X倍でパフォーマンス上がる方法があるならそのissueに報告すれば採用されるかもよ

**デフォルトの名無しさん** · 2024/08/05(月) 15:01:05.36

>>44
rustcがベンチマークのネタに適してないんじゃないの？

**デフォルトの名無しさん** · 2024/08/05(月) 15:14:32.99

>>45
そう思うならrustc以外のアプリでベンチ取って提示してみれば？
少なくともパフォーマンス低下するアプリが一つ示されたんだからそれ以上のデータ出さないと話進まないでしょ

**デフォルトの名無しさん** · 2024/08/05(月) 15:48:02.67

もっと歴史の長いGCCのC++もClangのC++もvectorの再割り当ての長さ2倍を採用している
そしてGCを用いてメモリ管理する言語は各々で諸事情があるようだから参考にできない

**デフォルトの名無しさん** · 2024/08/05(月) 16:04:04.60

fbvectorの話はアロケータが確保する単位に合わせて無駄を無くすということと
Vecのリサイズによって開放されたメモリ領域を再利用しやすくするということが書いてるだけ

どっちも理にかなってる

**デフォルトの名無しさん** · 2024/08/05(月) 16:26:39.60

標準として提供する機能には平均的な性能が高いよりも
最悪の場合でもそれなりの性能が出るほうを優先するみたいな考え方もあるし
設計思想にもよるわな。

**デフォルトの名無しさん** · 2024/08/05(月) 18:42:38.74

https://medium.com/smucs/fbvector-a-possible-replacement-for-std-vector-e46bb31b8a56
C++の結果だけど結構な差が出てる
この人のコードを自分の環境でも試してみたがpush_backで5倍前後違う

単純に1.5倍固定じゃなくて真似したやつで試してみたらいいのにね

**デフォルトの名無しさん** · 2024/08/05(月) 19:15:50.62

>>50
ソース見てみたけど恣意的に10倍ずつ異なる長さで順にアロケーションを汚染していき
vectorは単発使い捨てで毎回残らないからその前の残骸の空きエリアにたまたま上手くマッチするかの勝負になっていて
現実とはかけ離れたテストになっていると思った

**デフォルトの名無しさん** · 2024/08/05(月) 23:13:48.63

>>49
速度vsメモリ効率なんかもあるしね

**デフォルトの名無しさん** · 2024/08/05(月) 23:56:18.02

>>50
こんなに違いが出るのか

**デフォルトの名無しさん** · 2024/08/06(火) 00:27:44.41

>>44を読んでると
1.5倍にすると実用なプログラムでは遅くなるのに対し
>>50の特殊なベンチな時だけ1.5倍がとても速い理由は
他のメモリ割り当てに邪魔されずに1つのベクタだけがどんどん成長していくからで
1+1.5+1.5^2+1.5^3 ＜ 1.5^4 であるため
自分が過去に用いたところを結合してそのまま使えるため速いらしい
しかし現実のプログラムは他のヒープ利用も間に起きるためその再利用はうまく行かずメリットが起こらないと

**デフォルトの名無しさん** · 2024/08/06(火) 10:36:53.30

2.71828倍が良いとおもいますん

**デフォルトの名無しさん** · 2024/08/06(火) 13:40:39.24

1.14514倍で

**デフォルトの名無しさん** · 2024/08/06(火) 17:53:14.98

C++が1.5倍伸長のFBVectorで自分の抜け殻を上手く再利用する件
Rustはなぜ2倍伸長でもっと速いのかを調べてみた

同じように他に邪魔されず伸長していくケースだと
RustのVecは以下のように
128Kバイトまでは同じアドレスのまま移動せずにコピー無しで2倍伸長していく
256Kバイト以上ではmremap利用でアドレスは移動するがコピー無しで2倍伸長していく
そのためRustのVecは2倍伸長でもサイズが巨大になっても速いことがわかった

addr=0x5642549e6ab0 cap=8 len=1+1
addr=0x5642549e6ab0 cap=8 len=2+1
addr=0x5642549e6ab0 cap=8 len=4+1
addr=0x5642549e6ab0 cap=16 len=8+1
addr=0x5642549e6ab0 cap=32 len=16+1
(途中略) 【アドレスはずっと変わらない】
addr=0x5642549e6ab0 cap=32K len=16K+1
addr=0x5642549e6ab0 cap=64K len=32K+1
addr=0x5642549e6ab0 cap=128K len=64K+1
【ここでアドレスが変化＆mremap利用が始まる】
addr=0x7f661c06f010 cap=256K len=128K+1
addr=0x7f661bfee010 cap=512K len=256K+1
addr=0x7f661beed010 cap=1M len=512K+1
addr=0x7f661bcec010 cap=2M len=1M+1
(以降略)

**デフォルトの名無しさん** · 2024/08/06(火) 18:25:14.08

もちろんVecは2倍伸長をアロケータにリクエストするだけなので
実際に処理しているのはRust標準のGlobalアロケータ
この環境では出来たバイナリにglibcのmallocやreallocがリンクされてるので最終的にはそこに行き着くはず

**デフォルトの名無しさん** · 2024/08/06(火) 19:53:13.46

Carbon Languageに期待

**デフォルトの名無しさん** · 2024/08/06(火) 20:16:16.47

Rustの標準アロケータを使わずに
>>57をjemalloc利用でアドレス変化を調べると全く異なる結果となった

8Kバイトまではアドレスが毎回変わりコピー移動
16Kバイトから1Mバイトまではアドレスが変わらずコピー無し
2Mバイト以上はアドレスが毎回変わりmremapが使われてないためコピー移動

少なくとも今回の前提での利用の範囲内ならば
Rust標準をそのまま用いるのが最適となる

**デフォルトの名無しさん** · 2024/08/06(火) 20:54:39.49

そういや一昔前、jemallocを採用してるから
Rustは良いんだよ、って主張があったよね

**デフォルトの名無しさん** · 2024/08/06(火) 21:01:13.77

jemallocは色々と問題もあるため5年半前の2019年1月のRust1.32で標準採用しなくなった
もちろんjemallocが好ましいケースもあるのでその時は各自で簡単に使えるようにもなってる

**デフォルトの名無しさん** · 2024/08/07(水) 00:45:04.42

未だに Vec::new_in() が安定化しないRustとは対照的に
Zigはヒープ使う関数すべてで毎回毎回アロケータを引数に渡させて
毎回毎回成功したか確認させるんだね

Linuxカーネル開発にはZigの方が向いてるんじゃなかろうか？

**デフォルトの名無しさん** · 2024/08/07(水) 01:13:06.44

{C++ std::vector, C++ fbvector, Rust std::Vec} × {jemalloc, glibc malloc, LLVM libc malloc, msvc malloc, musl libc malloc} × {Linux, macOS, Windows} × {x86_64, 仮想メモリの機能を持たない何らかのアーキテクチャ}

壮大な議論になってきたなあ
これ全部検証するつもり？

そういやglibc mallocは環境変数でヒープとmmapのどっちを使うかの閾値調整できるとか
msvc mallocは_DEBUGマクロが定義されていると確保したメモリに未初期化を表すバイトを書き込むとかもあった

条件はいくらでも付け加えられそうやね

**デフォルトの名無しさん** · 2024/08/07(水) 01:28:00.75

サイズの大きなベクタは
キャパシティ拡張してもコピーが発生しないmremap利用のアロケータが有利という結論だな
サーバなどで一般的に使われるLinux環境ならRust標準でその条件を満たすから大丈夫

**デフォルトの名無しさん** · 2024/08/07(水) 08:32:07.19

>>63
Zigはまぁ1.0にならないと検討の俎上にもあげられないし
Cと比べてそれほど強い保証が得られるわけでもないから
あまり導入するモチベーションもなさそう

**デフォルトの名無しさん** · 2024/08/07(水) 22:36:11.64

https://www.publickey1.jp/blog/24/rustservowebverso.html
2024年8月6日
欧州を基盤にオープンでセキュアなインターネットの実現を支援しているNLnet Foundationは、
昨年(2023年)末から、Linux Foundation傘下でRust製のクロスプラットフォーム対応Webブラウザエンジンとして開発が進められている「Servo」を用いたWebブラウザ「Verso」の開発プロジェクトの立ち上げを発表した。
また、この「Servo」をTauriの組み込みのWebViewとする方向で開発が始まっている。
Chromiumに代わるRust製

**デフォルトの名無しさん** · 2024/08/07(水) 22:38:49.83

>>67
名前がダサすぎるからダメ

**デフォルトの名無しさん** · 2024/08/08(木) 05:28:31.41

ChromiumがC++のメモリ管理ミスで度々セキュリティ脆弱性を招いてるから
対抗馬ができるのは良いこと

**デフォルトの名無しさん** · 2024/08/08(木) 06:03:12.33

まともに動くまで20年ぐらい掛かるんだろ

**デフォルトの名無しさん** · 2024/08/08(木) 13:55:28.27

Firefox先生の明日はどっちだ

**デフォルトの名無しさん** · 2024/08/09(金) 06:14:59.59

Tauri2.0 Android/iOSでマルチwebviewしたかった
この流れだとVersoになるまで出来なさそう

**デフォルトの名無しさん** · 2024/08/09(金) 10:26:33.54

タウリン実際どうなん？
実用になる？

**デフォルトの名無しさん** · 2024/08/09(金) 10:41:11.99

>>73
有用だけど場合による。

**デフォルトの名無しさん** · 2024/08/09(金) 17:08:58.86

implementation of `From` is not general enough
= note: `From<&'0 Hoge>` would have to be implemented for the type `Fuga<'_>`,
for any lifetime `'0`...
= note: ...but `From<&'1 Hoge>` is actually implemented for the type `Fuga<'1>`,
for some specific lifetime `'1`

これはどうやって解決するのが普通？

**デフォルトの名無しさん** · 2024/08/09(金) 17:13:42.47

こういう実装は書いてあります
impl<'a> From<&'a Hoge> for Fuga<'a> {
fn from(src: &'a Hoge) -> Fuga<'_> {
Fuga::from(なんかの変換(src))
}
}

**デフォルトの名無しさん** · 2024/08/09(金) 17:18:10.35

fn moge<T>(a: &str, b: &str) -> i64 where T: for<'a> From<&'a Hoge> {
中身
let m = T::from(hoge);
中身
}

みたいな関数を呼んだ(コンパイル時)ときに >>75 のエラーで止まります

**デフォルトの名無しさん** · 2024/08/09(金) 17:22:16.81

呼ぶ方は
let x = moge::<Fuga>(2, 5);
みたいに呼びたいのです

**デフォルトの名無しさん** · 2024/08/09(金) 17:22:41.31

fn mame(a: &str, b: &str) -> i64 {
中身
let m = Fuga::from(hoge);
中身
}
としたときは正常にコンパイルも動作もできました

**デフォルトの名無しさん** · 2024/08/09(金) 18:10:20.58

>>77
全体が見えないのでなんとも言えないが
>>75のエラーを解決するなら
例えば
fn moge<T>(a: &str, b: &str) -> i64 where T: for<'a> From<&'a Hoge>
↓
fn moge<'a, T: 'a>(a: &str, b: &str) -> i64 where T: From<&'a Hoge>

**デフォルトの名無しさん** · 2024/08/09(金) 19:57:46.44

`src` does not live long enough
--- argument requires that `src` is borrowed for `'a`
borrowed value does not live long enough
`src` dropped here while still borrowed

**デフォルトの名無しさん** · 2024/08/09(金) 21:05:31.98

playgroundに再現する最小限のコードを貼れよ