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/

>>319
お前の書いてるRustはそうなんだろ？
そんなに怒って何が言いたいんだい？ｗ

>>319
こんなすれにまじになっちゃってどうするの

Rustアンチの人は反例を示せないままデタラメに否定してたからね
以下のRustにおける常識を

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

>>324
お前の中ではそれで正しいんだろ？
だったらもうそれでいいじゃん

ID:GVCMKu1fがただしかったってことで、いいとおもいます！

>>321
>>322
時々IDを変え忘れて同じIDのまま二度レスしてるね

>>327
単に同一人物なだけだろ
矛盾したことも言ってないし

>>327
そうだねー、いじめられてかわいそかわいそ

>>323
たけしの挑戦状で草

全ての書き込みが
ID変えての単発IDか
あるいは
ID変え忘れての二度レスで興味深い

>>331
根拠のない罵倒に連続投稿
また一昨日の荒らしか

50連投は草

>>333
連投はしてないだろ
複おじイライラで草

>>331
お前の中ではそうなんだろ
それでいいんじゃねえの

>>332
一昨日も昨日も荒らしてたのはお前だろ複おじ

君ら複おじ好きすぎるだろ

結局ID:hgCgzwLkが有能だっただけで他の奴は大差ないの笑う

もう複おじの話はいいよ

>>338
thread::spawnの場合でも受け取った参照については必ず返せる

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

つまりspawnは反例にならない

別の言語に興味を持たずに今日もRustスレを荒らすのはなぜなの
C言語なら俺に聞けスレとかでもいいのに

めちゃくちゃな主張をしてもバレにくいとでも思ってんだろ

Rustアンチは反例を出せなかったから結局バレた

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は別だから！

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