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/

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

そもそも複おじって、IDコロコロ変えてしょうもない自演で戦ってスレを無駄に伸ばしてるとされる人のことを言ってたんだし
それでいうと一人で50レス＆この流れはまさに・・・

そうなの？
所有権の複製とかいう謎概念を言い始めたから複おじって呼ばれてるんだと思ってたけど

Rustは最高言語😸

おじいちゃんお昼寝タイム❓🌚

仮におじ本人だとしたら、往事に比べてもだいぶ壊れてるよな
さすがに彼といえどもRustを書けること自体には何の価値もなくなったことを理解し、
Rust戦士としてのアイデンティティが崩壊しちゃったんだろうか

Rustは最高だけどrust-analyzerは必須だなぁ
コンパイルエラーがてんこ盛りだから

>>351
最近はラストアナライザーは切ってるな
勝手に裏でコンパイルして評価されるのが鬱陶しくて
俺が書き終わってから評価してくれと！

で、書き終わってからclippy すりゃいいことに気づいた

###結論
「書くときは書くことに集中し、チェックするときはチェックに集中する」というこのスタイルは、実は非常に効率的なフローだと思います。やはり、道具に使われるのではなく、自分のリズムで道具を使うのが一番ですよね。

RLS
rust-analyzer

くだらないLSPで終わっちゃったね、また

最近のラスアナはエラーコード書き換えても前のエラー参照してずっと表示してくる

>>355
それがラストの穴だから

>>345
どう考えてもアンチなわけないから同一人物なの笑う
やっぱりお前が複おじやんけｗ

>>344-350
複おじ一人でイライラだなｗ

>>352
コンパイルはされてないぞ

まあ、Rustアンチの複おじは thread::spawn() という反例に何も反論できなかったんだから何でもいいよｗ
thread::spawn() を出すなんてRustアンチだ！は流石に笑っちゃうけどなｗ

複おじ理論「thread::spawn() を使う奴はRustアンチ！」

rust-analyzerは必須
でも今時LSPなしで書ける言語も少ないよな

それはそう

おデブanalyzer

C++ を書くときにエディタのリアルタイム支援を有効にはしているけど昔は無しでやっててそんなに不満には思ってなかったからな。
Rust も慣れれば割と言語サーバ無しでもなんとかなるんじゃないの。

>>359
コンパイルは間違いだったな
rustcにコード差分をチェックさせてる！だったわ
コンパイラーに仕事させてるけどコンパイルはしてないね

>>365
まあRustの場合はどうせコンパイラが丁寧に検証して教えてくれるから、コンパイルしてみれば済む話ではあるな
C++の方がコンパイラは場所を教えにくいからLSPの価値がありそう

でもrustcは厳しいからエディタ段階で気付いておかないとコンパイルが通らない地獄にはなりそう

Emacs使いだけどlsp-modeをeglotに替えたら実用的になった　しばらくこれで行こう

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

複おじの存在ってunsafeだよな

Rustのおかげで開発のストレスがだいぶ減ったな
あるのはcloneしなきゃいけないときのストレスだけ

気兼ねなくcloneできるようになったら初心者卒業

>>370
複おじ理論「thread::spawn() を使う奴はRustアンチ！」

.clone() は必要かどうかはよく考えるべきだが必要ならガンガン使うべき

例えばどういう状況？

>>376
複製が必要な状況

複製が必要な状況とは？

>>378
色々あるけど元の値を保持しつつ値を書き変えたい場合なんかそうなるよね

複製が必要な設計になったら複製は必要だよな
流石に多岐に渡りすぎてて列挙することはできんくらいどこでもやってる

>>375
これ
コンパイラに勧められるがままに追加してたらめちゃくちゃになる

>>380
プログラムの本質はどこかからどこかへのコピーだとも言われてるからな

spawn_uncheckedなら複おじ理論でも「どんな寿命の参照でも、それを関数の引数で受け取ったら」という条件に合致する

でもspawn_uncheckedは「その参照や一部の参照を、関数から必ず返せる」には合致しない
必ず返せるわけではないから

結局「コンパイルが通れば」という追加条件や「Safetyルールを守ったコードを書いていれば」という追加条件が必須
つまり全く自由ではない

thread::spawnの場合でももちろん成り立っている

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

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

ここまで自演までしてRustを盛り上げようとしなきゃいけない理由って？

民家への飛び込み営業って、営業になりたがるような陽キャでもすぐ精神病むような過酷な仕事だけど
宗教の信者はそれを無報酬で喜んでやるわけじゃん？

>>385-386
イミフ

アンチはアンチスレ行こうね

Rustアンチスレ
https://mevius.5ch.io/test/read.cgi/tech/1509028624/

>>386
飛び込んできてるのはお前らアンチじゃ

>>384
もうそんなこと言ってなかったバレてる主張の曲解はやめた方がいいよ

>>384
最初から「コンパイルが通ればコンパイルが通る」ってトートロジーだったなら
> spawnの引数が何なのか知らない無知な人は勉強して出直してきてね (>>211)
ここで一旦参照を受け取るって部分の条件変えて逃げようとしたのは説明できないよね
嘘吐きミッケ！

>>383
これ

複おじ理論
1. 任意のライフタイムの参照を関数の引数で受け取って必ず返せる！
2. 実は「コンパイルを通ったら」って条件がありました〜！
3. thread::spawn() を使う奴はRustアンチ！

>>384
「どんな寿命の参照でも」「どんな値でも」「他の関数から返ってきたものでも」(>>159)
「任意のライフタイムで必ず成立する」(>>183)
「Rustでは付加条件なく必ず成り立ちます」(>>214)
↓
実は関数の引数で受け取るコードがコンパイル通ったらってことでした！

これが複おじクオリティ

Rustでこれは常に成り立つ
反例はない

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

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

「コンパイル通ったらコンパイル通るんですよ」ｗ

複オジ進次郎説

>>395
> どんな寿命の参照でも、それを関数の引数で受け取ったら、
thread::spawn() が 'static 以外の参照を受け取れないのがなぜか「コンパイルが通らないから」以外に言ってみろよｗ
最初は「ライフタイムの制約なんかない」って言ってたのも忘れてねえからな荒らし野郎

複おじ理論
1. 任意のライフタイムの参照を関数の引数で受け取って必ず返せる！
2. 実は「コンパイルを通ったら」って条件がありました〜！
3. thread::spawn() を使う奴はRustアンチ！

>>398
言えば言うほど過去の悪行が掘り返されるの草

>>395
「どんな寿命の参照でも」「どんな値でも」「他の関数から返ってきたものでも」「関数から必ず返せる」 (>>159)
「任意のライフタイムで必ず成立する」(>>183)
「Rustでは付加条件なく必ず成り立ちます」(>>214)
↓
実は関数の引数で受け取るコードがコンパイル通ったらってことでした！
ほら、rustcでコンパイルが通ったら成り立ってるでしょ

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

>>398
それは明らかに違う
Safetyに明記されてるようにunsafe関数を呼び出しても安全な諸条件の一つであってそこでの特有の問題

>>395
別スレで粘着始めた頃に
> ライフタイム制約を受けない
> 任意のライフタイムの参照をその関数に与えて使うことができる
って言ってたのもバレてますよ

>>402
「どんな寿命の参照でも」「どんな値でも」「他の関数から返ってきたものでも」「関数から必ず返せる」 (>>159)
「Safetyに明記されてるようにunsafe関数を呼び出しても安全な諸条件の一つであってそこでの特有の問題」(>>402)

また例外作ってて草

こいつ無限に例外作るやんｗ
「コンパイル通ったらコンパイル通るんですよ」でも足りないのかｗｗ

>>404
例外はない
それはunsafeの問題

>>406
thread::spawn() はunsafeじゃねえよｗ

>>406
まだ「親スレッドが子スレッドよりも先に死ぬかもしれないからそうでないことを保証する必要がある」ってことがわかんないのか
ライフタイムについてThe Book読んで勉強して来いよｗ

Rustで安全が保証されてる諸事項も
unsafeを無条件に使えば当然保証されなくなる
それを「例外あるじゃん！」「付加条件が加わってるじゃん！」と叩く人はいないぞ

>>407
unsafe関数を用いてsafe関数を作り出したのがthread::spawn()
その時のSafety条件として'staticの縛りがある

>>409-410
全然違う
たとえOS側がRustで書かれていてunsafeなしでスレッドを作る機能を提供していても、「親スレッドが子スレッドよりも先に死ぬかもしれないからそうでないことを保証する必要がある」ので 'static しか渡せない

そもそもunsafe関数には渡せないなら
「どんな寿命の参照でも」「どんな値でも」「他の関数から返ってきたものでも」「関数から必ず返せる」 (>>159)
不成立だから>>409-410は本当にただ揚げ足取りできないか探ってるだけ

「どんな寿命の参照でも」「どんな値でも」「他の関数から返ってきたものでも」「関数から必ず返せる」 (>>159)
「任意のライフタイムで必ず成立する」(>>183)
「Rustでは付加条件なく必ず成り立ちます」(>>214)
↓
実は関数の引数で受け取るコードがコンパイル通ったらってことでした！
ほら、rustcでコンパイルが通ったら成り立ってるでしょ！
あ、あとunsafeは別だから！

こんなん笑うわ

最初になかった条件が無限に増えてるの草

「ライフタイムの制約なんかない
どんな寿命の参照でもどんな値でも他の関数から返ってきたものでも関数から必ず返せる」
↓
「実は関数の引数で受け取るコードがコンパイル通ったらってことでした！
ほら、rustcでコンパイルが通ったら成り立ってるでしょ！」
↓
「unsafeは別だから！」

ｗ

もう次はどんな条件が増えるのか楽しみにした方が良さそう

そうだよ
勝手に条件を増やされても困る
Rustでこれは常にこれが成り立つとしか元から書かれていない

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

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

関数の引数で受け取ったら関数から必ず返せる → thread::spawn() はクロージャ越しに受け取ってるから引数だけど違う
1嘘

他の関数から返ってきたものでも → thread::spawn() はクロージャが返せるという部分だけ成り立てば thread::spawn() が返せなくてもいい
2嘘

ライフタイムの制約なんかない → ライフタイムが合わなくてコンパイル通らないもののことは言ってない
3嘘

付加条件なく必ず成り立ちます → unsafeは例外だから成り立たなくてもいい
4嘘

>>409
最初からunsafeはメモリ安全が成り立たないって言われとるわマヌケ

>>418
thread::spawn()でもこれは成立している

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

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

>>417
「どんな寿命の参照でも」「どんな値でも」「他の関数から返ってきたものでも」「関数から必ず返せる」 (>>159)
「任意のライフタイムで必ず成立する」(>>183)
「Rustでは付加条件なく必ず成り立ちます」(>>214)
↓
thread::spawn() はクロージャ越しに受け取ってるから引数だけど違うよね……やっぱなし！
実は関数の引数で受け取るコードがコンパイル通ったらってことでした！　ほら、rustcでコンパイルが通ったら成り立ってるでしょ！
あ、あとunsafeは別だから！

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

>>420
じゃあ 'static 以外の参照を渡して帰ってくる、コンパイル通るコードを出してくれるんだな？ｗ

>>420
コード楽しみにしてまーすｗｗ

>>421
違うぞ

「どんな寿命の参照でも」「どんな値でも」「他の関数から返ってきたものでも」「関数から必ず返せる」 (>>159)
「任意のライフタイムで必ず成立する」(>>183)
「Rustでは付加条件なく必ず成り立ちます」(>>214)
↓
thread::spawn() はクロージャ越しに受け取ってるから引数だけど違うよね、クロージャが返してるからセーフ……やっぱなし！
実は関数の引数で受け取るコードがコンパイル通ったらってことでした！　ほら、rustcでコンパイルが通ったら成り立ってるでしょ！
あ、あとunsafeは別だから！

だぞｗ

どんどんみっともなくなるの草

>>422
それはthread::spawn()が課している制約だろ
そしてそのthread::spawn()でも以下が成り立ってる

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

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

「どんな寿命の参照でも」「どんな値でも」「他の関数から返ってきたものでも」「関数から必ず返せる」 (>>159)
「任意のライフタイムで必ず成立する」(>>183)
「Rustでは付加条件なく必ず成り立ちます」(>>214)
↓
thread::spawn() はクロージャ越しに受け取ってるから引数だけど違うよね……やっぱなし！
クロージャが返してるからセーフ……これもなし！
実は関数の引数で受け取るコードがコンパイル通ったらってことでした！　ほら、rustcでコンパイルが通ったら成り立ってるでしょ！
あ、あとunsafeは別だから！

こうでしょ

>>426
標準ライブラリの関数が「使えるけど使えなくしまーす」って意地悪で言ってると思ってるんだ
新しすぎる発想だなｗｗ

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

今ここ

追い込まれてるからといってそんな捏造するのはよくない
unsafeの話はthread::spawnがなぜそうしているかの話の時だろ

以下はthread::spawnでもunsafe fnでもasync fnでも必ず成立する

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

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

>>426
今標準ライブラリ以外でスレッドに任意のライフタイムの参照を渡す関数が作れるって約束したな？
システムコール叩くだけなんだからお前がコード書いてきたら信じてやるよｗ

>>430
捏造してるのはずっとお前だよ
なんでバレないと思ったんだｗｗ

>>431
それに加えて戻り値で参照を返す必要もあるぞ

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

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

>>431
そんな発言はしていない
以下が任意のライフタイムでもunsafe関数であろうがasync関数であろうが成り立つ
これしか主張していない

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

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

>>430
これは確かに標準ライブラリ以外でスレッドに任意のライフタイムの参照を渡して返せる関数が作れるって言ってるな
システムコール叩くだけなら実装も楽だし、お前がコード書いてみんなを黙らせること、応援してるよ！ｗ

>>435
「実は関数の引数で受け取るコードがコンパイル通ったらってことでした！　ほら、rustcでコンパイルが通ったら成り立ってるでしょ！」ｗ

>>436
言ってもいないことを捏造するな

>>435
バカの世界ではこれで人が騙せると思われているらしい

>>439
反例を出してみろ

>>438
捏造じゃねえだろｗ
お前が「thread::spawn()が勝手に制限かけてるからできないだけ」って言ってたんじゃんｗｗ

>>440
出た！
「反例を出してもコピペで永遠に聞かないで勝利宣言してやるから反例を出してみろ！」だｗｗｗｗ

>>440
一回もお前が反例を潰せたことないだろ
いい加減にしろ荒らし野郎

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

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

>>441
勝手にではないぞ
ちゃんとそれぞれの関数の固有の理由がある