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

>>50
RAIIはプログラマーが指定して用いるけど、それはプログラマーの意思と無関係に必ず自動的に実行されると言えると？
deferなんかも自動管理と認識してる人？

少なくともRustのRAIIにプログラマーの指定箇所はないね
完全自動になってる

>>52
RustのRAIIも所有権やライフタイムを明示的に扱わないと機能しないね

>>53
RustでもRAIIはそれらと一切無関係に動作しますよ

>>54
そうなんだ！すごいね！ｗ
ホントにそう思うなら一回Rust書いてみろよｗｗ

やったことないから無関係だと信じてられるんだよｗ
流石に笑っちまうわｗｗ

C→C++になってRAIIが導入されて更に手動でunique_ptrを指定すれぱ自動解放できるようになった
ただし参照が残っていればそれは解放後にダングリング参照になってしまう危険なリスクはそのまま

C++→RustになってRAIIにより常に自動解放されるようになった
参照が残らないことも保証されるため安全に自動解放されるようになった

>>57
Rustはあくまでコンパイラがコードに問題がないことを保証することと、RAIIを標準にすることをやっているだけで、メモリの管理は相変わらずプログラマがやらなくてはいけないことに変わりはないので

>>58
RAIIで自動解放してくれるから楽だよ
しかも速くて省メモリ

>>59
話が逸れてる

RAIIが自動管理は草
RAIIなんかプログラマがシコシコメモリ管理するのを何とかデストラクタ使って頑張ってるだけのこと

RAIIを自動管理だと思ってる奴、deferも自動管理だと思ってそう
メモリ管理ちゃんと意識したことないんだろうな

プログラマーが明示的に指定しなければいけないと手動管理
プログラマが指定する必要がないと自動管理

deferは手動管理
C++のRAIIは手動管理
RustのRAIIは自動管理

>>63
少なくともRustは書いたことないってことはわかった
プログラマが明示的にメモリの管理をしないとRustは正常にコンパイルもできないよ

日常RustメインだがRustは自動解放だから楽勝
管理なんてなくて普通の言語と同じ
関数に引き数として渡すか永続変数に入れておくかの二択しかない

>>65
線形リスト作ってみいや

>>65
ゴミのようなコードが見える見える

線形リストが使われなくなった理由は他のデータ構造を用いる方が速いとはっきりしたから
辿ること自体が遅いのに加えてメモリキャッシュを活かせないことが敗因
売りポイントの挿入削除もその地点を探すのにO(n)かかって不利でその地点が既知なら他のデータ構造が速い

唯一生き残っている線形リストの使われ方はマルチスレッドにおけるキュー管理で唯一ロックフリーにすることができる
複雑に改良が積み重ねられてきた歴史があるためライブラリの助けを借りるのが良い
というわけで専門家以外が線形リストをプログラミングすることはなくなった

ブロックチェーンという双方向リストで息をふきかえした
線形リストはデータ構造へと昇華したのだ

ブロックチェーンで線形リストは使われない
巨大なチェーンを一つずつ辿っていたら遅すぎて実用にならないためハッシュマップが使われている

>>67
それ以外の方法があるなら具体的に述べなさい

>>71
他の言語と同じ管理しかしてないならムーブも可変参照も使えないんだが、そこがわかっていないのだろうか

>>68
線形リストが使われる場所はあるよ、単にデスクトップやモバイルなどスペックが有り余ってるコンピュータでそんなカツカツの管理は必要ないだけで

>>72
Rustに詳しくない様だから教えてあげるね
Rustはムーブが基本なのよ
例えばaからbへの代入文 b = a があった時
言語によってはディープコピーするもの
シャローコピーするもの
特に一番浅い参照コピーするもの
それらが状況や型によって変わるもの
など多種多様なのはご存知よね
Rustはそれが基本動作としてムーブになるというだけよ
そして数値などプリミティブな型はコピー属性を持っていてムーブの文脈で代わりにコピーになるのよ
これらの基本動作は自然に行われるから安心してね

>>72
可変参照と不変参照の区別がある言語は増えているけど管理とはなんの話だろう

>>73
わかってないのはお前なｗ
Rustはメモリ管理しないと参照が使えない設計になってるって話をしてるんだわ
君の見てるところの3段階くらい上にいるから早くおいでｗ

>>73
Rust書いたことないのはわかった

>>75の
下の>>73は>>74のミス

>>74
そもそも不変参照と可変参照の差ならC++の時代からあるわ
何を言っとるんだこのアホは

>>75
嘘はよくない

Rustは非常にシンプルにできている
関数で作ったものは値を返せる
関数で引数としてもらった参照は参照を返せる
という当たり前のルールしかない

別に当たり前ではないたろ
線型論理は別に唯一の論理ではない

>>78
それこそ嘘はよくない
参照を受け取って参照を返す時にはライフタイムの強い制約を受ける

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