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

>>29
それはRAIIの理解不足
RAIIはブロックなどのローカルスコープで宣言したものはそのスコープを抜ける時にも存在していれば自動的にそのリソースが解放される自動管理の仕組み
ただしそこへの参照が残っていれば自動解放されるとダングリンク参照になってしまい危険
Rustはコンパイラが参照連鎖も静的にチェックするため必ずそれを防いでくれるため実用的な自動管理になった

一方でそれらの機構のないGC言語ではローカルスコープを抜けても自動的にそのリソースを解放していいのかわからない
そこへの参照が残っているのか実行前に静的にコンパイル時点で判断できないためだ
だから定期的に参照連鎖を実行時に動的にチェックするガベージコレクション(GC)が必要になる
そして実行時に参照連鎖を追えるようにするためのコストの高いメモリ管理をせざるを得ない
それゆえGC言語は実行が遅くなるだけでなくGC発動まで無駄にメモリを占有してしまう

>>31
やっぱり自動管理の意味がわかってないじゃん
コンピュータが最終的な処理をやるから自動だと言ってるなら手動管理なんか存在しないからお前の言ってることはおかしいし、そうじゃないなら自動管理だから自動管理なんだ！って言ってるだけでただ自分の決めつけを押し付けたいだけ
GCがリソースの解放を静的に判断できないという点だけは正しいが、だからランタイムが自動解放するという点を理解してないので後半の説明も片手落ち

>>30
MTとATの話はしていない
ATのどこに監視用のランタイムがあって、メインの処理を停止してゆっくり呑気にチェックを始める設計があるのか

>>32
関数やブロックを抜けると自動解放されるRAIIは自動管理そのもの
自動解放タイミングも明瞭かつ直ちに行われて分かりやすく省メモリ
GCも自動解放だがタイミングが不明瞭で遅延が大きく分かりにくくメモリ使用量肥大

>>34
それを自動管理と言うなら「free()があれば自動解放されるC言語は自動管理そのもの」ということになる

>>35
free()はプログラマの意思で解放位置を決めてそこに置くから手動管理だな
RAIIやGCはプログラマの意思と関係なく解放されるから自動管理だな

>>36
ああ、RAIIに触れたことがないのはわかったよ
RAIIはプログラマの意思で設定するもんだ

ついでに言えば、所有権システムもプログラマが自らの意思で矛盾なく設計しなければ成立しない

RAIIはプログラマの意思と関係なく自動的に行われる
スコープを抜ける時にプログラマの意思と関係なく自動的にデストラクタが呼ばれる

同じ自動管理でも発動時期が読めないGCより即座に実行されるRAIIが優れているね

自動管理の言葉の定義で争う無能達

>>39
そのデストラクタをスコープを抜けた際に動くように設定するからRAIIなんだぞ
プログラマの意思で呼んでいるのだということに注意がいる

>>40
RAIIが必ずしも優れているとは言えないし、それは手動で管理しなければならないから

>>41
根本的に理解が足りてないんだろうね

RAIIで自動的にメモリが解放されるRustは両者どちらの定義でも自動管理になるよ

>>43
一番の無能が話しかけないでくれるかな？

>>42
RAIIは直後に自動
GCは時期不明の自動

>>44
ならない
どちらの定義でもと言いながら見てないのがよくわかる

>>45
一番の無能はお前定期
悪口は言えても自説も主張できなければ反論もできない

>>46
RAIIとARCの区別がついていないんじゃないか？

>>29 >>31 これはt5kHx157の勝ちだわ
31は「RAIIの理解不足」とか言っときながらt5kHx157の主張を1つも否定できてないし、IDをコロコロ変えてごまかしてる

めっちゃ話は単純
RAIIやGCのようにプログラマーの意思と無関係に必ず自動的に実行されると自動管理
free()のようにプログラマの意思で行なうと手動管理

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