C#が新unsafeでメモリ安全に Rust/Swiftへの言及も

Improving C# Memory Safety
https://devblogs.microsoft.com/dotnet/improving-csharp-memory-safety/

C# 16、メモリ安全性を強化する新たなunsafeモデルを導入へ
https://codezine.jp/news/detail/24314

>>80
Rustにそんな制約はない
引数で受け取った参照は常に関数で返すことができる

>>80
おまえあちこちのスレで暴れているようだがRustを使ったことないんだな
そのような制約はないぞ

>>81
はい、はっきりデマ
なんでバレないと思ったのかわからないが、ライフタイム注釈が必要なケースだぞ

>>82
鏡見て喋ってんのか？
お前がRust使ったことない側だぞｗ

まあ、実を言うと「なんでバレないと思ったのか」じゃなくて「やったことないから知らない」なのはバレてるけどな
一生懸命ID二つ使って抵抗してるとこ悪いけど、普通にここまで無知を露呈したらごまかしきかないからあきらめた方がいいぞ

>>83
ライフタイム注釈は省略可能
そんなことも知らないならコード書いてことないんだな

ライフタイム注釈の有無に関係なくID:/b2uC2Vrが間違ってるでしょ
関数の引数で受け取った参照は関数の返り値として返せるという当たり前の話をID:/b2uC2Vrは否定しているのだから

>>86
そんなことは書いてないが
妄想と現実の区別くらいつけろよ

>>85
省略できるケースがあることと全部省略できることの区別もつかない奴はコード書いてない

つまりお前な

「Rustはメモリ管理する必要ないし普通の言語みたいに参照できる」とかいうバカげた主張をしたのが悪いのに、無理に自分が正しいと言い張るために相手の発言を捏造し始める、そういうところやぞと

>>86
「ライフタイムの制約を受ける」を「返せない」と言った時点で控えめに見積もってもRustを書いたことがないのはわかりきってるから、もう二度とこの話に口を出さない方がいい

The Bookくらいは読んでから話せって話よな
ライフタイムなんて中盤で出てくる程度の要素だぞ

だよな
>>80はアホや
Rustは関数が引数で受け取った参照を常に関数の返り値として返すことができる
ライフタイムによる制約はない

>>91
なんでわざわざもう一回バカ晒しに来たんだ？

ライフタイムで参照を検証する - The Rust Programming Language 日本語版
https://doc.rust-jp.rs/book-ja/ch10-03-lifetime-syntax.html

このタイトル、読める？ｗ

> ライフタイム省略
> 全参照にはライフタイムがあり、参照を使用する関数や構造体にはライフタイム引数を指定する必要があることを学びました。

まだわかんない？ｗｗ

どう考えてもバカにされてるのは「ライフタイムの制約を受ける」を「返せない」と解釈するお前だぞｗ

引数で受け取った参照がどんなライフタイムだったとしても関数は常にその参照や派生参照を返すことができるのよ
だからRustプログラマーが困ることはないです

>>94
また嘘が飛び出したな

「Rustはメモリ安全を保証するので、参照の寿命は本体のそれを超えない」
↑ これの意味がわからないレベルなら、Rust どころか C / C++ すらまともに書いたことがないのがバレます

再度繰り返すが、Rustはメモリ安全を保証するので、参照の寿命は本体のそれを超えない
なので、
> どんなライフタイムだったとしても関数は常にその参照や派生参照を返すことができる
は大嘘で、'static でないと返せない関数も普通に発生する

Rustプログラマにとって最も難所となるのがこの参照のライフタイムであって、マルチスレッド設計が難しい理由である
また、RcやArcなどの参照カウント式の管理が、標準ライブラリに組み込まれている理由でもある

……ここまでのことは、Rustを書いていればThe Bookにも書いてある「常識」なのだが、これがわからない自称「Rustプログラマー」は何を書いてきたんだろうね？

>>95
君が間違ってる
Rustはあらゆる寿命の参照について
引数として受け取った関数はそれを常に安全に返すことができる
反例を出せなければ君の間違いが確定
もちろん常に成り立つため反例はない

>>96
ずっと言ってるけどはっきり否定できる、とてもわかりやすい間違い
パッと思いついただけでも複数の参照を受け取る関数や、コールバック関数などは参照をそのまま返すことはできないし、他のスレッドに行く場合も当然無理だね

> Rustはメモリ安全を保証するので、参照の寿命は本体のそれを超えない
ここからは、これがわからない Rust / C++ / C などの未経験者向けの解説

参照とはそもそも、ここに本体はなく本体の場所や型などの情報だけを受け取っておいて、実際にはその本体を読み書きする、いわば「Windowsのショートカットファイル」のような存在と言える
これを使うのは、本体を都度コピーしていてはメモリも無駄に使うし遅くなる、それに本体を共有すればコピーと違って値が見る者によって変わってしまう心配がないという特徴があるからだ

さて、Rustの大きな特徴である「メモリ安全」の一部分として、「『もう本体がなくなった後の場所を読み書きする』ことの禁止」というものがある
しかし、参照は本体を読み書きするためのものなので、当然本体より長生きすることがあれば「もう本体がなくなった後の場所を読み書きする」ことになってしまう
なので、Rustには「ライフタイム」という概念があって、参照の寿命が本体のそれを超えていないか、確認する仕組みになっているんだね

だから、ある関数に参照を渡して、その関数がまた参照を返すといったような動きをした場合、この返された参照のライフタイムが問題になる
当然、この返された参照は、この関数の中の変数は指していない
なぜなら、この関数が終わった時点でこの関数の中の変数は解放されてしまうから、それが返せてしまうと「もう本体がなくなった後の場所を読み書きする」ことになるからなんだ

じゃあ、ある関数が返す参照は、受け取った参照であるということになる
その時、たとえば関数が複数の参照を受け取っていたとして、Rustのコンパイラは関数の境界で追跡を止めるようになっているから、呼び出している側からは渡したどの参照が返ってきているのかわからない

しかし、複数の本体のライフタイムは必ずしも一致しているとは限らない（他の関数から借りている参照かもしれないし、一部の変数だけ drop() されてしまうかもしれない）ので、どの参照が返ってきているのかわからないということは、そのまま返ってきた参照のライフタイムがわからないことを意味してしまう
これがわからないままでは、「『もう本体がなくなった後の場所を読み書きする』こと」が防げなくなってしまうので、メモリ安全ではなくなってしまうんだ

だから、これはライフタイム注釈をつけてあげないと返せないことになっているし、そのライフタイムを超えて生き残る可能性がある関数には、渡すことができないことも決まっているんだ
つまり、Rustの参照は全て、ライフタイムの制約を受けているんだね

C / C++ などにはこの「ライフタイム」というシステムがないので、参照（Cであればポインタが指すアドレス）がいつまで生きているか、検証のしようがないんだ
これが「ダングリングポインタ」と呼ばれるもので、プログラムをクラッシュさせたり、データを破壊したり、場合によっては脆弱性の原因にもなってしまうんだね
だから、C / C++ から Rust に移行しよう、という話になっているんだよ

正しい事実はこれ
「Rustはあらゆる寿命の参照について
引数として受け取った関数はそれを常に安全に返すことができる」
反例を出せない初心者クンID:tqJQMSogの間違いが確定

どうだったかな
Rustの参照は安全のためにライフタイムの制約を受けること、これがない C / C++ ではダングリングポインタの危険性があること
たぶん、プログラミングの経験がある程度あれば、Rust / C++ / C を書いたことがなくても、わかったんじゃないかな


……なので、

> Rustは関数が引数で受け取った参照を常に関数の返り値として返すことができる
> ライフタイムによる制約はない

> Rustはあらゆる寿命の参照について
> 引数として受け取った関数はそれを常に安全に返すことができる

というのは大間違いなんだね！

>>101
反例は >>97 に書いた通り「パッと思いついただけでも複数の参照を受け取る関数や、コールバック関数などは参照をそのまま返すことはできないし、他のスレッドに行く場合も当然無理」だが
お前がこれを何一つ否定できてない時点で、「反例を出せない初心者クン」「間違いが確定」はID:cwi1cuXm（ID:86x3Bz3M, ID:Ue5AUbKn, ID:iZ1BaTzv, ID:Mw+1/AR/, ID://w25X3S）だよｗ
コロコロID変えるせいでどこまで同一人物かはわからんが、少なくとも前半は口調が完全に一致してるから同一人物だな

「反例を出せない初心者クン」「間違いが確定」のID:cwi1cuXm（ID:86x3Bz3M, ID:Ue5AUbKn, ID:iZ1BaTzv, ID:Mw+1/AR/, ID://w25X3S）は、>>98-100 >>102 を読んで学ぼうねｗ
Rustどころか C / C++ すら書いたことないみたいだしｗ

C / C++ を書いていれば、

メモリ安全
→ ダングリングポインタは禁止
→ 参照は無条件では返せない

ここまではRustを書いた経験がなくてもわかるよねｗ

この程度のことすらわからない時点で、ID:cwi1cuXm（ID:86x3Bz3M, ID:Ue5AUbKn, ID:iZ1BaTzv, ID:Mw+1/AR/, ID://w25X3S）は
* システムプログラミング
* メモリ安全
* Rust
* 借用
* ライフタイム
のどれもわかっていないことが確定しました

Rustプログラマーなら誰でもわかる常識をID:tqJQMSogが言い掛かり付けてる理由を知りたい

>> 「Rustはあらゆる寿命の参照について
>> 引数として受け取った関数はそれを常に安全に返すことができる」

これは誰が見ても当たり前で正しいとわかるじゃん

> Rustはメモリ安全を保証するので、参照の寿命は本体のそれを超えない
ここからは、これがわからない Rust / C++ / C などの未経験者向けの解説

参照とはそもそも、ここに本体はなく本体の場所や型などの情報だけを受け取っておいて、実際にはその本体を読み書きする、いわば「Windowsのショートカットファイル」のような存在と言える
これを使うのは、本体を都度コピーしていてはメモリも無駄に使うし遅くなる、それに本体を共有すればコピーと違って値が見る者によって変わってしまう心配がないという特徴があるからだ

さて、Rustの大きな特徴である「メモリ安全」の一部分として、「『もう本体がなくなった後の場所を読み書きする』ことの禁止」というものがある
しかし、参照は本体を読み書きするためのものなので、当然本体より長生きすることがあれば「もう本体がなくなった後の場所を読み書きする」ことになってしまう
なので、Rustには「ライフタイム」という概念があって、参照の寿命が本体のそれを超えていないか、確認する仕組みになっているんだね

だから、ある関数に参照を渡して、その関数がまた参照を返すといったような動きをした場合、この返された参照のライフタイムが問題になる
当然、この返された参照は、この関数の中の変数は指していない
なぜなら、この関数が終わった時点でこの関数の中の変数は解放されてしまうから、それが返せてしまうと「もう本体がなくなった後の場所を読み書きする」ことになるからなんだ

じゃあ、ある関数が返す参照は、受け取った参照であるということになる
その時、たとえば関数が複数の参照を受け取っていたとして、Rustのコンパイラは関数の境界で追跡を止めるようになっているから、呼び出している側からは渡したどの参照が返ってきているのかわからない

しかし、複数の本体のライフタイムは必ずしも一致しているとは限らない（他の関数から借りている参照かもしれないし、一部の変数だけ drop() されてしまうかもしれない）ので、どの参照が返ってきているのかわからないということは、そのまま返ってきた参照のライフタイムがわからないことを意味してしまう
これがわからないままでは、「『もう本体がなくなった後の場所を読み書きする』こと」が防げなくなってしまうので、メモリ安全ではなくなってしまうんだ

だから、これはライフタイム注釈をつけてあげないと返せないことになっているし、そのライフタイムを超えて生き残る可能性がある関数には、渡すことができないことも決まっているんだ
つまり、Rustの参照は全て、ライフタイムの制約を受けているんだね

C / C++ などにはこの「ライフタイム」というシステムがないので、参照（Cであればポインタが指すアドレス）がいつまで生きているか、検証のしようがないんだ
これが「ダングリングポインタ」と呼ばれるもので、プログラムをクラッシュさせたり、データを破壊したり、場合によっては脆弱性の原因にもなってしまうんだね
だから、C / C++ から Rust に移行しよう、という話になっているんだよ

どうだったかな
Rustの参照は安全のためにライフタイムの制約を受けること、これがない C / C++ ではダングリングポインタの危険性があること
たぶん、プログラミングの経験がある程度あれば、Rust / C++ / C を書いたことがなくても、わかったんじゃないかな


……なので、

> Rustは関数が引数で受け取った参照を常に関数の返り値として返すことができる
> ライフタイムによる制約はない

> Rustはあらゆる寿命の参照について
> 引数として受け取った関数はそれを常に安全に返すことができる

というのは大間違いなんだね！

途中でぶった切った上にまともに読めないアホのために再掲

>>107
一目で間違ってるとわかることを、
> 誰が見ても当たり前で正しいとわかるじゃん
と言ってしまうのは流石にアホすぎる
Rust書いてないのはわかったから自慢しなくていいよ

>>107
なんでこれができないのか、>>108-109 で書いているので読んでみるといいよ
Rustを書いたことがない君にもわかりやすく書いたつもりだ

具体的な書き方やルールを知りたい場合は

ライフタイムで参照を検証する - The Rust Programming Language 日本語版
https://doc.rust-jp.rs/book-ja/ch10-03-lifetime-syntax.html

を読むといいよ
なお、ここにも普通に

> ライフタイム省略
> 全参照にはライフタイムがあり、参照を使用する関数や構造体にはライフタイム引数を指定する必要があることを学びました。

って書いてるね

いやいや、これはどんな場合でも成立するよ

>> 「Rustはあらゆる寿命の参照について
>> 引数として受け取った関数はそれを常に安全に返すことができる」

>>114
じゃあ「パッと思いついただけでも複数の参照を受け取る関数や、コールバック関数などは参照をそのまま返すことはできないし、他のスレッドに行く場合も当然無理」を覆す新説を持ってきてくれｗ
この条件で、実際にライフタイム注釈なしにコンパイルが通るコードを出してくれたら信じるよｗｗ

まあ、The Rust Programming Languageの著者

●Steve Klabnik:Mozilla勤務。Rustドキュメンテーションチームのリーダーであり、Rustの核となる開発者の一人。
●Carol Nichols:Rustコアチームのメンバー。Rust Belt Rust Conferenceを管理している。

が

> ライフタイム省略
> 全参照にはライフタイムがあり、参照を使用する関数や構造体にはライフタイム引数を指定する必要があることを学びました。

って書いてるから、参照にライフタイムがないと主張するなら、少なくともRustコアチームよりRustに詳しい自信があるということになってしまうけどねｗ

ライフタイムはあるけど参照に寿命はない、なんてバカげたことは言うなよｗ

他の人は、なぜ >>107 >>114 がおかしいかは >>108-109 を読んだらわかるよ
ID:+qjQFMRoは自説を否定されたくないから、読まないことにしたみたいだけどね

ライフタイム注釈は、より強い制約を与えることも可能な場合があるためにある
それゆえライフタイム注釈に関わらず、以下は常に成立する

>> 「Rustはあらゆる寿命の参照について
>> 引数として受け取った関数はそれを常に安全に返すことができる」

まあ、このスレってRustの専門スレじゃないから仕方ないっちゃないのかもしれないけど、ID:+qjQFMRo, ID:cwi1cuXm, ID:86x3Bz3M, ID:Ue5AUbKn, ID:iZ1BaTzv, ID:Mw+1/AR/, ID://w25X3S とRustを書いたことがあればしない間違いを全く同じようにしてる奴がこれだけいるというのは、知ったかぶりが過ぎるなあ

ID:tqJQMSog氏は、参照を返せない具体的なコード例を示してごらん
そんなコードは作れなくて、以下は正しいとわかるから

>> 「Rustはあらゆる寿命の参照について
>> 引数として受け取った関数はそれを常に安全に返すことができる」

>>119
念仏を唱えるように繰り返しても、残念ながら事実は変わらないんですよｗ
>>115 >>108-109 を見直してねｗｗ


それに、ライフタイム注釈は「注釈」なので、何かを与えることを示すものではないですよｗ
さっき貼ったThe Bookのページにもちゃんと

> ライフタイム注釈記法
> ライフタイム注釈は、いかなる参照の生存期間も変えることはありません。むしろ、ライフタイムに影響することなく、複数の参照のライフタイムのお互いの関係を記述します。

と明記されているのに、自説を否定する事実が書いてあるからって読まないから、また間違いを繰り返してしまう

>>121
こっちが書く前にまた間違いを増やしてるし


fn main() {
let string1 = String::from("abcd");
let string2 = "xyz";

let result = longest(string1.as_str(), string2);

// 最長の文字列は、{}です
println!("The longest string is {}", result);
}


fn longest(x: &str, y: &str) -> &str {
if x.len() > y.len() {
x
} else {
y
}
}



はい、そのままさっきのThe Bookのページのコードね

このコードはコンパイルエラーになる
その理由は何度も言ったように >>108-109 に書いてあります

>>123
その続きを読め
その関数例も返したい参照を返せる

>>123
それRustはそのような場合でも引数として渡ってきた参照を安全に返せるという例だよ
ライフタイム注釈を理解できてないのかな
参照を返さない例になっていない

>>125-126
私は「ライフタイムの制約を受ける」と言っているのであって、「無条件に返せる」なるバカ発言を否定してるだけだぞ
「無条件に返せない」なんていつ言ったのか、捏造はやめてもらいたい

あと、またIDをコロコロ変えてるなｗ

ID:dDECB2A7, ID:j/d0+3d7, ID:+qjQFMRo, ID:cwi1cuXm, ID:86x3Bz3M, ID:Ue5AUbKn, ID:iZ1BaTzv, ID:Mw+1/AR/, ID://w25X3S と、必死こいて「ライフタイムの制約を受ける」を「無条件に返せない」に捏造して、「ライフタイム関係なく無条件に返せる」なるバカ発言をした自分が勝てると勘違いしてるみたいだなｗ

全部文字記録として残ってるのに、どうしてその場の発言みたいに軽々捏造できると勘違いしたんだかｗｗ

>>123の例もライフタイムの制約を受けずに参照を返せる
引数xと引数yが異なるライフタイムであっても同じライフタイム注釈を与えてやればxとyどちらになろうと返り値として返せる

>>130
ライフタイム注釈をつけているのはなぜか考えない素晴らしい思考停止だなｗ
ライフタイム注釈はコンパイラに参照のライフタイムを教え、これで問題がないか検証させるための仕組みだぞ
つまり、ゴリッゴリにライフタイムの制約を受けている

>>131
ライフタイム制約を受けない
任意のライフタイムの参照をその関数に与えて使うことができる

> ライフタイム省略
> 全参照にはライフタイムがあり、参照を使用する関数や構造体にはライフタイム引数を指定する必要があることを学びました。

> ライフタイム注釈記法
> ライフタイム注釈は、いかなる参照の生存期間も変えることはありません。むしろ、ライフタイムに影響することなく、複数の参照のライフタイムのお互いの関係を記述します。

なんで全部書いてあるのに誰も読めないんですかね
ここまで日本語ができないとなると、義務教育からやり直した方がいい

>>132
明確に嘘っすね
他のスレッドで生まれた参照を渡してみよう、そのスレッドが先に死ぬかもなｗ

参照を返すということはつまり、その戻り値を受け取った関数のスコープが閉じるまで参照が生きながらえることを保証するってことだからなｗ
そうじゃないとメモリ安全ではない（>>108-109参照）

>>134の書き込みを見てわかった
ID:eJfcvx1BはRustのプログラミングをしたことがない

>>136
何言ってんだこいつ
マルチスレッドって言葉知らないの？ｗ
プログラミングをしたことがないのはお前だよｗｗ

スレッドと参照を出しただけの短文で
> 書き込みを見てわかった
> Rustのプログラミングをしたことがない
ってことは、スレッドを掲示板のスレッドとでも思ったんだろうなｗｗ

流石にバカ発言すぎて笑いが止まらんわｗ
掲示板のスレッドの話してると思ってたのお前ｗｗｗ

まあ、真面目な話何も読まずに「僕ちゃんが否定されちゃ！　こいつはプログラミングをしたことがないんだ！　バカだ！　僕が偉いんだああああああああああ！！！！！」って発狂しちゃっただけなのはわかるけどｗｗ
それにしてもこりゃひどいｗｗｗｗｗｗ

> ライフタイム省略
> 全参照にはライフタイムがあり、参照を使用する関数や構造体にはライフタイム引数を指定する必要があることを学びました。

> ライフタイム省略
> 全参照にはライフタイムがあり、参照を使用する関数や構造体にはライフタイム引数を指定する必要があることを学びました。

> ライフタイム省略
> 全参照にはライフタイムがあり、参照を使用する関数や構造体にはライフタイム引数を指定する必要があることを学びました。

> ライフタイム省略
> 全参照にはライフタイムがあり、参照を使用する関数や構造体にはライフタイム引数を指定する必要があることを学びました。

> ライフタイム省略
> 全参照にはライフタイムがあり、参照を使用する関数や構造体にはライフタイム引数を指定する必要があることを学びました。

これくらい書けばちょっとは読めるかな？ｗｗ

> 全参照にはライフタイムがあり、参照を使用する関数や構造体にはライフタイム引数を指定する必要がある

> 全参照にはライフタイムがあり、参照を使用する関数や構造体にはライフタイム引数を指定する必要がある

> 全参照にはライフタイムがあり、参照を使用する関数や構造体にはライフタイム引数を指定する必要がある

> 全参照にはライフタイムがあり、参照を使用する関数や構造体にはライフタイム引数を指定する必要がある

> 全参照にはライフタイムがあり、参照を使用する関数や構造体にはライフタイム引数を指定する必要がある

> 全参照にはライフタイムがあり、参照を使用する関数や構造体にはライフタイム引数を指定する必要がある

こっちの方がわかりやすい？ｗｗｗｗｗｗｗｗｗ

バカは文章が読めないから困る

>>134
ID:eJfcvx1BはRust初心者エアプログラマー確定
明確な尻尾を出したな

>>144
> 明確な尻尾を出したな(どこがかは言えない)
反論できないからとにかく貶める方向にシフトしたのねｗ
お疲れ様ｗｗ

Rustエアプは ID:WwJl9Mdv, ID:R+0qGLKV, ID:rgZeOBea の側な

The Bookに明確に
> 全参照にはライフタイムがあり、参照を使用する関数や構造体にはライフタイム引数を指定する必要がある
と明記されてるのに、
> ライフタイム制約を受けない
> 任意のライフタイムの参照をその関数に与えて使うことができる
とか書いちゃうｗ

しかも、
> 1種の特殊なライフタイムが'staticであり、これは影響を受ける参照がプログラムの全期間生存できることを示します
とあるように、参照がプログラムの全期間生存できることを示さないといけないケースも触れられてるのに
> 任意のライフタイムの参照をその関数に与えて使うことができる
ならこんな機能不要なんだよｗ

今日の結論
* RustエアプはURLを貼られてもThe Bookを読めない

参照を理解しているRustプログラマーなら絶対に書くことはないミスを犯している

>>134
>>他のスレッドで生まれた参照を渡してみよう、そのスレッドが先に死ぬかもなｗ

ID:eJfcvx1Bは参照を理解できていない初心者であるとバレた

バカ向けにもう一回貼っといてあげるね

ライフタイムで参照を検証する - The Rust Programming Language 日本語版
https://doc.rust-jp.rs/book-ja/ch10-03-lifetime-syntax.html

> 全参照にはライフタイムがあり、参照を使用する関数や構造体にはライフタイム引数を指定する必要がある

> 1種の特殊なライフタイムが'staticであり、これは影響を受ける参照がプログラムの全期間生存**できる**ことを示します

> ライフタイム注釈は、いかなる参照の生存期間も変えることはありません。むしろ、ライフタイムに影響することなく、複数の参照のライフタイムのお互いの関係を記述します。

>>148
あ、自分で言ったことも覚えておけないし、日本語も読めないバカだということを改めて示してて草
（お前が言うようにライフタイムの制約を受けないとしたら）他のスレッドで生まれた参照を渡してみよう、そのスレッドが先に死ぬかもなｗ
だよｗ
自分で出した前提も忘れて騒いでたんだなお前ｗｗ
ライフタイムの制約があるからコンパイルが通らないのは当たり前だろｗｗｗ

参照はライフタイムの制約を受けない！ ←これを言ってる奴は知識と知性の両方が足りない


バカ向けにもう一回貼っといてあげるね

ライフタイムで参照を検証する - The Rust Programming Language 日本語版
https://doc.rust-jp.rs/book-ja/ch10-03-lifetime-syntax.html

> 全参照にはライフタイムがあり、参照を使用する関数や構造体にはライフタイム引数を指定する必要がある

> 1種の特殊なライフタイムが'staticであり、これは影響を受ける参照がプログラムの全期間生存**できる**ことを示します

> ライフタイム注釈は、いかなる参照の生存期間も変えることはありません。むしろ、ライフタイムに影響することなく、複数の参照のライフタイムのお互いの関係を記述します。

> 全参照にはライフタイムがあり
> 参照を使用する関数や構造体にはライフタイム引数を指定する必要がある

次のレスはこれの意味がわかるようになってから書こう

参照を理解しているRustプログラマーなら絶対に書くことはないミスを犯している

>>132
> ライフタイム制約を受けない
> 任意のライフタイムの参照をその関数に与えて使うことができる

ID:WwJl9Mdv, ID:R+0qGLKV, ID:rgZeOBea は参照を理解できていない初心者であるとバレた

> 全参照にはライフタイムがあり
> 参照を使用する関数や構造体にはライフタイム引数を指定する必要がある

次のレスはこれの意味がわかるようになってから書こう

暴れてる ID:eJfcvx1B は初心者のようだから教育してあげればいいじゃん

>>134
>他のスレッドで生まれた参照を渡してみよう、そのスレッドが先に死ぬかもなｗ

まず「他のスレッドで生まれた参照」
既にこの時点でその状況がどうなっているのか状況が限られることは理解できるかな？
初心者には難しいよね

>>155
君みたいな初心者にはわからないかもしれないが、スレッドを生み出す時に参照を渡すというのはよくある設計なんだぜｗ
素人丸出しの内容を偉そうに玄人みたいに語ってて笑っちゃったよｗｗ

あと、私は「参照はライフタイムの制約を受ける」とThe Bookに書いてあるままのことを言っているのであって、「ライフタイム関係なく無条件に参照を返せる」なんて妄言をぶつけてきたアホがいたので反論してただけだぞ

> 全参照にはライフタイムがあり
> 参照を使用する関数や構造体にはライフタイム引数を指定する必要がある

これの意味がわかればおかしなことを言っているとわかるはずなんだがなあ

>>156
スレッドに参照を渡せる、そこまでは合ってるよ
もちろん限らた状況でしか無理
その状況を理解できていればこんなアホな書き込みをすることはない

>>134
>他のスレッドで生まれた参照を渡してみよう、そのスレッドが先に死ぬかもなｗ

>>158
なんで「限られた状態でしか無理」なのか言ってみろよ
「僕がそう思うから」以外になｗ

>>158
>>150も参照

どうもバカはレスを遡れないみたいだから、バカ向けにもう一回貼っといてあげるね

ライフタイムで参照を検証する - The Rust Programming Language 日本語版
https://doc.rust-jp.rs/book-ja/ch10-03-lifetime-syntax.html

> 全参照にはライフタイムがあり、参照を使用する関数や構造体にはライフタイム引数を指定する必要がある

> 1種の特殊なライフタイムが'staticであり、これは影響を受ける参照がプログラムの全期間生存**できる**ことを示します

> ライフタイム注釈は、いかなる参照の生存期間も変えることはありません。むしろ、ライフタイムに影響することなく、複数の参照のライフタイムのお互いの関係を記述します。

私は「参照はライフタイムの制約を受ける」とThe Bookに書いてあるままのことを言っているのであって、「ライフタイム関係なく無条件に参照を返せる」なんて妄言をぶつけてきたアホがいたので反論してただけ

> 全参照にはライフタイムがあり
> 参照を使用する関数や構造体にはライフタイム引数を指定する必要がある

次のレスはこれの意味がわかるようになってから書こう

>>159
マルチスレッドを使ったことすらないのかね
初歩の常識だよ

>>163
その初歩の常識とやらをGoogleやMozillaは知らないからブラウザがこんな構造になってるんだ、と言いたいわけだな？ｗ

申し訳ないけど、「バカの常識」より「優れたコード」の方が説得力があるわ

>>164
ID:eJfcvx1Bが致命的なミス書き込みや
初心者レベルのコピペ書き込みをしてしまう理由はAI回答だったのかい

>>166
何言ってんだこいつ
せめて日本語で話せよ

>>165
では優れたコードで示せ
途中で気付くだろう
このおまえのトンデモ書き込みを後悔するぜ

>>134
>他のスレッドで生まれた参照を渡してみよう、そのスレッドが先に死ぬかもなｗ

ちなみにブラウザはCSSを高速で解析するために複数スレッドに参照を渡す設計になってるのが基本
だから
> マルチスレッドを使ったことすらないのかね
> 初歩の常識だよ
というバカ発言はGoogleやMozillaのエンジニアには初歩の常識がないって意味になる

>>168
https://github.com/chromium/chromium
https://github.com/mozilla-firefox/firefox
優れたコードで示してやったぞｗ

> >>134
> >他のスレッドで生まれた参照を渡してみよう、そのスレッドが先に死ぬかもなｗ

これを毎回最後に貼り付けてるのが最高にバカのやり方で笑う
まともに反論できないから、切り取りしてどうにか相手が狂人かのように見せかけようとする


150 デフォルトの名無しさん 2026/07/17(金) 00:34:37.40ID:eJfcvx1B
>>148
あ、自分で言ったことも覚えておけないし、日本語も読めないバカだということを改めて示してて草
（お前が言うようにライフタイムの制約を受けないとしたら）他のスレッドで生まれた参照を渡してみよう、そのスレッドが先に死ぬかもなｗ
だよｗ
自分で出した前提も忘れて騒いでたんだなお前ｗｗ
ライフタイムの制約があるからコンパイルが通らないのは当たり前だろｗｗｗ


今度からこれ毎回貼るか

どうもバカはレスを遡れないみたいだから、バカ向けにもう一回貼っといてあげるね

ライフタイムで参照を検証する - The Rust Programming Language 日本語版
https://doc.rust-jp.rs/book-ja/ch10-03-lifetime-syntax.html

> 全参照にはライフタイムがあり、参照を使用する関数や構造体にはライフタイム引数を指定する必要がある

> 1種の特殊なライフタイムが'staticであり、これは影響を受ける参照がプログラムの全期間生存**できる**ことを示します

> ライフタイム注釈は、いかなる参照の生存期間も変えることはありません。むしろ、ライフタイムに影響することなく、複数の参照のライフタイムのお互いの関係を記述します。

私は「参照はライフタイムの制約を受ける」とThe Bookに書いてあるままのことを言っているのであって、「ライフタイム関係なく無条件に参照を返せる」なんて妄言をぶつけてきたアホがいたので反論してただけ

> 全参照にはライフタイムがあり
> 参照を使用する関数や構造体にはライフタイム引数を指定する必要がある

次のレスはこれの意味がわかるようになってから書こう




150 デフォルトの名無しさん 2026/07/17(金) 00:34:37.40ID:eJfcvx1B
>>148
あ、自分で言ったことも覚えておけないし、日本語も読めないバカだということを改めて示してて草
（お前が言うようにライフタイムの制約を受けないとしたら）他のスレッドで生まれた参照を渡してみよう、そのスレッドが先に死ぬかもなｗ
だよｗ
自分で出した前提も忘れて騒いでたんだなお前ｗｗ
ライフタイムの制約があるからコンパイルが通らないのは当たり前だろｗｗｗ

君のこの書き込みは参照とは何か理解できていないことを示すトンデモ書き込みであることが理解できたかい？

>>134
>他のスレッドで生まれた参照を渡してみよう、そのスレッドが先に死ぬかもなｗ

171 デフォルトの名無しさん 2026/07/17(金) 01:18:01.25 ID:eJfcvx1B
> >>134
> >他のスレッドで生まれた参照を渡してみよう、そのスレッドが先に死ぬかもなｗ

これを毎回最後に貼り付けてるのが最高にバカのやり方で笑う
まともに反論できないから、切り取りしてどうにか相手が狂人かのように見せかけようとする


150 デフォルトの名無しさん 2026/07/17(金) 00:34:37.40 ID:eJfcvx1B
>>148
あ、自分で言ったことも覚えておけないし、日本語も読めないバカだということを改めて示してて草
（お前が言うようにライフタイムの制約を受けないとしたら）他のスレッドで生まれた参照を渡してみよう、そのスレッドが先に死ぬかもなｗ
だよｗ
自分で出した前提も忘れて騒いでたんだなお前ｗｗ
ライフタイムの制約があるからコンパイルが通らないのは当たり前だろｗｗｗ



これをセットで貼った方がいいかな？
バカはレスを1つ遡れないようだし

>>174
それ自爆してるだけだってわからんの？
バカだなあｗｗ

158 デフォルトの名無しさん 2026/07/17(金) 00:56:40.09 ID:445eRKs4
>>156
スレッドに参照を渡せる、そこまでは合ってるよ
もちろん限らた状況でしか無理
その状況を理解できていればこんなアホな書き込みをすることはない

163 デフォルトの名無しさん 2026/07/17(金) 01:04:26.78 ID:c5gAJDF2
>>159
マルチスレッドを使ったことすらないのかね
初歩の常識だよ

168 デフォルトの名無しさん 2026/07/17(金) 01:14:13.67 ID:c5gAJDF2
>>165
では優れたコードで示せ
途中で気付くだろう
このおまえのトンデモ書き込みを後悔するぜ

169 デフォルトの名無しさん 2026/07/17(金) 01:14:27.31 ID:eJfcvx1B
ちなみにブラウザはCSSを高速で解析するために複数スレッドに参照を渡す設計になってるのが基本
だから
> マルチスレッドを使ったことすらないのかね
> 初歩の常識だよ
というバカ発言はGoogleやMozillaのエンジニアには初歩の常識がないって意味になる

170 デフォルトの名無しさん 2026/07/17(金) 01:15:51.25 ID:eJfcvx1B
>>168
https://github.com/chromium/chromium
https://github.com/mozilla-firefox/firefox
優れたコードで示してやったぞｗ


174 デフォルトの名無しさん 2026/07/17(金) 01:19:47.63 ID:c5gAJDF2
君のこの書き込みは参照とは何か理解できていないことを示すトンデモ書き込みであることが理解できたかい？

この流れで勝ってるつもりでいるの笑っちゃうわｗｗ

>>174のイキリ方がすごいよな
どこまでバカならこんなこと言えるんだｗ