Rust part37

公式
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 part36
https://mevius.5ch.io/test/read.cgi/tech/1779974768/

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

>>549
成り立たないコードが示されてるのに勝手に成り立つコードに書き換えて「どんなケースでも成り立つ！」は嘘吐きすぎる

>>550
なぜ元の>>159を混ぜるんだよ

>>552
参照を返せないコードはどれですか？

unsafeのspawn_unchecked()でも参照を返せることを>>524で示した
このケースでも反例はない

>>554
勝手に寿命変えたら返せて当たり前だろ
スコープを壊さずに返せよ無能

>>555
また嘘吐きか

「どんな寿命の参照でも」「どんな値でも」「他の関数から返ってきたものでも」「関数から必ず返せる」 (>>159)
↓
「スコープで寿命が変わってるから返せないんだ！　こんなのは反例にならない！」

もう嘘しか吐いてない

>>556
handleが外スコープにあるから
内スコープにあるものの参照を返さないのは当たり前
スコープ則を学びなさい

Rustでは以下が常に成立する
ここまでに反例なし

【前提】どんな寿命の参照でも、それを関数の引数で受け取ったら、
【恒真】その参照や一部の参照を、関数から必ず返せる

>>159
>>どんな寿命の参照でも、それを関数の引数で受け取ったら、その参照や一部の参照を、関数から必ず返せる

「どんな寿命の参照でも」「どんな値でも」「他の関数から返ってきたものでも」「関数から必ず返せる」 (>>159)
「任意のライフタイムで必ず成立する」(>>183)
「Rustでは付加条件なく必ず成り立ちます」(>>214)
↓
thread::spawn() はクロージャ越しに受け取ってるから引数だけど違うよね……やっぱなし！
クロージャが返してるからセーフ……これもなし！
↓
実は関数の引数で受け取るコードがコンパイル通ったらってことでした！　ほら、rustcでコンパイルが通ったら成り立ってるでしょ！
あ、あとunsafeは別だから！
↓
やっぱり標準ライブラリの関数が勝手に「使えるけど使えなくしまーす」って意地悪で言ってるんです！
コンパイル通ったらって条件も残ってます！
↓
そんなことないです！　固有の事情があるんです！　そう、固有の事情です！
受け取る参照を制限しているから、受け取ったら返せるんです！
↓
スコープで寿命が変わってるから返せないんだ！　こんなのは反例にならない！

早くこれに納得いく説明をしてくれよｗｗ

>>560
×ここまでに反例なし
○ここまでにID:GVCMKu1fの主張の証拠なし

>>560
「ここまでに反例なし」じゃなくて「ここまでに僕が聞きたい降伏宣言なし」だろｗｗ
お前がやってることは反例に対して「僕が思ってたのと違う！！」って発狂しただけ

日付変わったからID変わるし逃げるチャンスだぞｗ

鳩に餌をあげないでください

>>562-563
これだな

すっげー伸びてるじゃん
友達ができてよかったね複くん

RustとPythonってみんなどっちが書きやすいんだろ
個人的には断然Rustなんだが

コンパイルエラーとフォーマッタに依存しきった書き方してるからクレートあるものに関してはRustかなー
pythonのインデント調整を筆頭に色々とめんどくさいん、でもBlender関連は諦めてpythonで拡張してるし、obsidian関連はtypescriptで拡張してる

https://atmarkit.itmedia.co.jp/ait/spv/2605/08/news038.html
図1　プログラミング言語の案件別平均年収ランキング
1位　Rust　月額84万　年収1008万円

Pythonは軽く書くにはいいけど数百行でつらくなるからなあ
それ以上書くならRustだなあ

>>568
パイソンいいよ
書き味がC#に似てる

>>571
他人のコード渡されても安心なのがラスト
他人のコードでランタイムエラーになってキレそうになるのがパイソン

Rustに移ったら実行時エラー実行時デバッグが激減した

>>574
ちょっとわかる
パイソンのときだと修正加えた瞬間に動いたような気がしたけど、細かい条件分岐に入ってランタイムエラーとかあるよねー
テストしろ！って怒られるのは覚悟の投稿

糞つまんねーサッカーやっと終わった
仕事サボってサッカーの話ばっかしてる派遣プログラマーは今月で契約終了
こいつに月50万も払って割に合わねーわ

rustがスペインでclangがアルゼンチン

ひとりで書く → Python
みんなで書く → Rust

※但し１か月前の自分は他人とする

Rustアンチが複おじに負けてて草

ウザくなってきたらissue#25860って言っとけば死ぬよ
延々関係ない方向で突っ走ってるけど>>159結局そういうことやろ

確かにrust案件爆増中だが、GUI絡むとそうでもなかんべ？
汎用というにはまだほど遠い。
スペシャリストの世界。

おじ(111)がいなくなると、あれだけ無尽蔵に人が湧いてきて
おじのテーマに沿ってレスバしてたのが嘘のようだな

GUIは発展してるでしょ
無駄な装飾がなくて結構

eguiて(笑)

>>581
何を言ってるんだこいつは……
ブラウザなんかGUIの最たるものだろ

>>580
未定義動作と言語仕様の差がわかってないの笑う

どうせそういう変なこと言ってる奴は荒らしたいだけでまともな話したいわけじゃないからスルーした方がいい

>>578
結局メンテするならRustってことか

>>582
本人は自演がばれてないと思ってるっぽい

「どんな寿命の参照でも」って表現がまず曖昧でこれ単独じゃ何の意味も取れないんだけど
複おじとそのお友達はお互い何か意味のあることを言っていると思って、連休の2/3と数百レスを費やした挙句何の理解も得られてないってのはだいぶおもろいかもしれん

>>590
後世の人がたまたま過去ログが詰まったハードディスク拾ってこのスレのログ見つけたとき、一体何をレスバしてたのか解読に苦しみそうだな
ロゼッタストーン並みに難解と言われそう

>>590
関数が参照を受け取った時
それが任意のライフタイムであっても関数から返せる
という当たり前の原則に見えたが

新しいスレ住人のみんなはこれでご理解いただけたであろうか？
不毛？　徒労感？
これが複おじの提供する機能である
認知のゆがみがある人との対話が無駄に終わることを学べただろうか？

こいつはしょっぱなから「所有権の複製」とかいうアホ概念について
長きにわたり同じようなやりとりを既にやってるのである

オレなら不毛な議論をせずに一発で証明できる

fn foo1<'a, T>(x: &'a T) -> &'a T {
x
}

fn foo2<'a, T>(x: &'a mut T) -> &'a mut T {
x
}

ライフタイムがどんなに短くても長くても受け取った関数にとっては中立

それだけですか？
それだけなんだろうな

ライフタイムについて真面目に勉強したい人向け資料

https://github.com/pretzelhammer/rust-blog/blob/master/posts/translations/jp/common-rust-lifetime-misconceptions.md

>>585
Rust製ブラウザとかあったっけ？

Rust製ブラウザと言えばServo
そもそもRust自体がFirefoxを改善するために生まれた言語

>>592
>>594
複おじまだいたのか

>>597
FirefoxにもChromiumにも入ってるよｗ
FirefoxなんかもろCSSのレンダリングに使ってる

アンチはやたら「100%RustじゃなかったらRustの意味はない」ってゼロヒャクを言いたがるよな

>>594
Rustの言語仕様として受け取った参照を返すことができるのはもちろん正しい
一方で論争になっていたのはこちら
「なぜ関数が受け取る引数には型やライフタイムに制約があるものが存在するのか？」
結局これは関数が提供したい機能に依って受け取れる型やライフタイムに制約が生じる
こちらはRustの言語仕様とは関係ない

>>594
これで何かを証明したつもりになっているらしい草

>>602みたいな主語抜けアスペ文で誰かに何かが伝わると思ってるほうが草だよ

>>602
まあそうなんだけど
'staticしか受け取らない関数なんて無数にあるのにspawnに固執してた人いたな

もうみんなclone()して幸せになろう

Linux全面AI推進へ

リーナス・トーバルズが「LinuxはアンチAIではない」「気に入らないならフォークすればいい」などLinuxカーネル開発におけるAI利用について意見を述べる
https://gigazine.net/news/20260717-linux-linus-torvalds-ai/

貼る場所ちがくね

>>605
まだやってんのか
「ライフタイムの制約はない」とかほざいてる奴がいただけだろ

>>607
AI全面推進なんて書いてないしRustの話でもないし無茶苦茶

>>602
提供したい機能によってライフタイムの制約が生じるというのは間違ってないけど、言語仕様と関係ないというのは間違いだね
提供したい機能を言語仕様の制限の中で提供するにあたって、ライフタイムの制約を受けているので

>>611
それは言語機能による制約ではない
特殊な機能を提供するための各関数の固有の制約

>>612
じゃあ言語仕様の制約はどの言語にも一切ないって主張になるな
そんな前提をぶち壊すラディカルな話をしろって言ってるわけじゃない

> 各関数の固有の制約

Rustにライフタイムの制約がないのに各関数が勝手にそれをつけてるって、流石にそんな嫌がらせはしないと思うが

>>611
これよな

>>612の理屈をC言語の標準ライブラリで考えるとおかしさがわかりやすくて、malloc() で確保した領域を free() で解放しなきゃいけないのは標準ライブラリの仕様ではなくそれを使うコードのせい、みたいな話になってるんだよな
当然そんなわけはなくて、malloc() を使うことまではそのコードの問題だけど、free() を使う必要があるのは標準ライブラリの仕様に縛られているから

同じように、'static しか受け取れない機能を作ることまではその関数の問題であったとして、'static しか受け取れないという仕様の原因になっているのはライフタイムの制約を言語側が仕様として定めているからに他ならない

こういう区別のつく人間って希少なんだよな……

>>612
その区別が重要だな

###なぜ 'static やライフタイムの制約が存在するのか？

​Rustには**「ガベージコレクタ（GC）を持たずに、メモリ安全性と高いパフォーマンスを両立する」**という根本的な設計思想があります。これをコンパイル時の静的解析だけで実現するために編み出されたのが、ライフタイムのシステムです。

>>620
GC言語でGC対象はヒープ領域に格納されるのに対して
Rustはスタック領域にある関数ローカル変数に値を置いたままそこへの参照を安全に使うことができる点が大きい
取り扱う参照がスタック領域を指しているかヒープ領域を指しているか区別することなく全く同様に扱えるようになった
つまりGC言語と比べてRustは自由を得た

>>619
区別ついてない側なの笑う

>>621
×取り扱う参照がスタック領域を指しているかヒープ領域を指しているか区別することなく全く同様に扱えるようになった
別に参照はこれまでの言語でもどちらの領域を指すか区別して用いるものではない
また、変数自体はスタック領域を指しているかヒープ領域を指しているか区別して扱う必要がある

>>620
まあ、せやな

Goで書き直されたTypeScript 7.0が正式リリースされてるね
自由度高くて安全で高速なGo実装を簡単にRustに移植出来たら良いのに

>>623
嘘つくな
区別して扱う必要ない

###なぜGoなのか
Rustの厳格な所有権や借用規則の世界へいきなりジャンプしようとすると、その「TS寄りの複雑な構造」そのものを根本から完全再設計しなければならず、難易度が跳ね上がってしまいます。
​つまり、移行元のコードベースの性質や、プロジェクトを現実的な期間でゴールさせるための「距離感」として、Goがちょうどよかったということですね。

>>626
じゃあスタックに巨大構造体置きまくっても安心だな！

>>625
常に動き続けるホットパスでもないし、Rustである意味がないからなあ

>>628
草

>>626はVecと配列の使い分けとかわかってなさそう
「どうしてサイズが決まってるのにVec使うんだ！」とか怒るのかなｗ

wasmあるのにうんこスクリプトとかどうでもよくね

>>623
逆だよ
スタック領域を指しているかヒープ領域を指しているか区別して扱わなくても安全になったのがRust

>>633
スタックとヒープの区別を free() するかどうかだけだと思ってそう

えっ、違うんですか！？

>>632
うーむ...🤔

Rustではスタック領域/ヒープ領域に正式な名称がないはずだから、Cの自動記憶域/割り当て記憶域って言葉を使うけど、自動記憶域は関数に入る時に関数の戻り先アドレス、引数、ローカル変数などをスタックフレームに積むプログラム自身の管理のための機能になってる
だから変数を置く領域の広さはそこまでなくて、OSによって違うけどデスクトップやモバイルなら1MiB〜8MiBくらいしかない
したがって、大きなデータは割り当て記憶域に置く必要があるので、たとえばさっきの配列とVecの例なら、大きな配列はサイズが固定されていても割り当て記憶域を確保するVecで作りましょう、という使い分けが必要になる

最後のここはおかしい

>>623
>>また、変数自体はスタック領域を指しているかヒープ領域を指しているか区別して扱う必要がある

>>638
この書き方あの荒らしじゃん
めちゃくちゃなこと言って反論が来たら大喜びで荒らすだけの奴だからスルーでいい

>>637
それはスタックに置くかヒープに置くかの使い分け
そちらは使い分けすること

>>637
なるほどー

>>640
区別せずに使い分けるのか
面白いこと言うねｗ

>>639
どこが荒らしだよ

>>623は間違っている
>>637は正しい

荒らしはスルー、これ基本

間違えたことを書いた>>637が俺を荒らし扱いかよ

そもそもチェリーピックの連鎖だから読んでない😅

>>637
話の本筋からはそれるけど、Cでは自動記憶域がスタックじゃない可能性ってあるけど、Rustだとどうなんだろう
どっちみちスタック領域って言葉だと混同するから自動記憶域でいいとは思うんだけど

ごめん
>>645はミス
間違えたことを書いてるのは>>623

どうやったらケチつけられるかだけ考えてる荒らしもいるってだけ
相手にしなければ消える

###まとめてみると
「意識する必要がない」というのは**
「メモリリークや解放漏れ、ポインターの不正参照の心配をコンパイラが肩代わりしてくれるため、安全かつ自動で処理される」**という意味において非常に正確です。

​ただし、パフォーマンスの観点からは、**「データのコピーコスト（スタック）」と「ヒープアロケーションのコスト（動的確保のオーバーヘッド）」**の違いを理解しておくことが、高速なコードを書く上で重要になる場面もあります。

>>647
Rustではローカル変数(local variable)と呼ぶ

>>651
ローカル変数のある領域の話をしているのでは？