Rust part19

**デフォルトの名無しさん** · 2023/01/17(火) 12:41:32.25

公式
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 part18
https://mevius.5ch.net/test/read.cgi/tech/1670663822/

**デフォルトの名無しさん** · 2023/02/19(日) 00:45:12.81

100行関数の時代の反動で5行の処理でも関数切り出しする時代からのさらに揺り戻しで
最近はむしろ型推論に任せて明示的に型を書かないために全体が一望できる程度の30行ぐらいの関数は増えているので
breakもcontinueも普通によく見かける

**デフォルトの名無しさん** · 2023/02/19(日) 00:45:16.79

?はunwrap or return (Err/None)
.unwrapはunwrap or panic
欲しかったのはこれらと同じように使える
unwrap or breakとunwrap or continue

でも出来たのは新しい構文のlet elseでしたとさ

**デフォルトの名無しさん** · 2023/02/19(日) 01:10:22.21

https://rust-lang.github.io/rfcs/3137-let-else.html#examples
RFCのExamplesなんてbeforeもafterもlet else以前の問題
typestate使ってtry_fromとnewを用意するというrustのidiomを使えば良いだけなのに

実施して当然のリファクタリングもやってないようなコードを前提に議論が進んでるのを見ると悲しいね

**デフォルトの名無しさん** · 2023/02/19(日) 06:25:34.88

>>692
それはRFCつまり単なる叩き台
無意味に長いサンプルだからThe Rust Referenceでは短く書き換わっている
typestateは適用できないケース、不向きなケース、向いているがそこまでやらなくてもいいと判断するケースがあり
それ以前にlet elseとは無関係だから持ち出して批判するのは揚げ足取りにしか見えない

**デフォルトの名無しさん** · 2023/02/19(日) 07:06:24.11

>>686
稀と言ってるだけ
確かに俺はアルゴリズム博士じゃないね

**デフォルトの名無しさん** · 2023/02/19(日) 08:40:02.37

特定のサンプルに対してこう書けるから要らないと主張したり、
自分は使わないから要らないと主張したり、
それらの主張は何の意味もないことにそろそろ気付かないと

**デフォルトの名無しさん** · 2023/02/19(日) 09:32:40.87

関数の「切り出し」とか行数で語ってるのとかまだまだ幼いなってオモタｗ
最近の流れじゃあ>>689サンだけ一個上のレベルにおるな

**デフォルトの名無しさん** · 2023/02/19(日) 10:03:16.21

>>685
> デストラクタがあればgotoの少なくとも一部は許されないことが確定する
ならtry〜throw〜catchで

**デフォルトの名無しさん** · 2023/02/19(日) 10:56:50.58

>>696
君はまだ参照の持ち回りや明示的に型を書くことのデメリットを理解せずになんでもかんでも関数にするレベルにいるんだね

**デフォルトの名無しさん** · 2023/02/19(日) 11:10:19.79

相手すんなよ、どう見ても>>689の自演だろ

**デフォルトの名無しさん** · 2023/02/19(日) 11:13:57.20

>>693
最終的なRFCはたたき台じゃないよ
RFCは議論の進行とともに更新された上で提案された機能を採用するどうかを判断するための公式ドキュメントとなる
採用決定後に書かれるリファレンスとは全く役割が違う

**デフォルトの名無しさん** · 2023/02/19(日) 11:21:38.84

>>689
関数切り出しでは出来ないこともあれば無駄な記述が増えることを含
めて様々なデメリットもあるから、
それらをクリアできて上回るメリットがある時に絞って使い分けるとよい
あと関数切り出しすれば何でもcontinueやbreakという制御構造を無くせるわけでもない
そして君の使い方だと出番がないからそれらが不要だとの主張には何の意味もない

**デフォルトの名無しさん** · 2023/02/19(日) 11:30:31.86

>>700
だから議論中はたたき台だろ
会社の提案資料とか書いたことないのか？

**デフォルトの名無しさん** · 2023/02/19(日) 13:11:23.57

>>688
フフッ、奴らはRust魔術師なんて名乗ってるが所詮は、正確な儀式魔法陣の設計と、正確で美しい呪文の詠唱にこだわる愚物よ！
それで発動するのが初級のファイヤーボールたるファイル検索とか笑えるだろ？
無詠唱でループで取り囲まれている敵陣真っただ中に転移ジャンプすることすら叶わぬのだッ！

**デフォルトの名無しさん** · 2023/02/19(日) 14:21:00.44

>>702
ユーザーマニュアルと開発時の要件定義書や設計書の違いだよ
承認された最終版の要件定義書や設計書をたたき台と呼んでる会社なのかな？

提案資料と捉えても別に構わないとは思うが
採用判断の妥当性を確かめるために参照するのは間違ってもユーザーマニュアルではない

**デフォルトの名無しさん** · 2023/02/19(日) 14:23:05.09

実装は正確に、商談はいい加減にやればいいのに
消費税込み0円で物々交換することすら叶わぬのだ

**デフォルトの名無しさん** · 2023/02/19(日) 14:26:53.65

>>673
Option,Resultならunwrapで良いけど、任意のenumから同じように中身を取り出す方法ある？

**デフォルトの名無しさん** · 2023/02/19(日) 14:33:14.38

if letとlet elseがmatchのsyntax sugarなのは自明だから
RFCのサンプルという特定の例に対して別の書き換えが可能だと主張しても何の意味もない
if/let/elseという既存の概念と既存のキーワードの組み合わせによりmatchより短く書けて利便性も良いと総合的に判断されてRustに導入された

**デフォルトの名無しさん** · 2023/02/19(日) 14:44:02.93

>>704
> 承認された最終版の要件定義書や設計書をたたき台と呼んでる会社なのかな？
お前さんが
>> だから議論中は
という簡単な文章すら理解できないことはよくわかった

**デフォルトの名無しさん** · 2023/02/19(日) 15:44:36.19

RFCは叩き台だと思う

たたき‐だい【×叩き台】
読み方：たたきだい

批判・検討などを加えて、よりよい案を得るための原案。

**デフォルトの名無しさん** · 2023/02/19(日) 15:53:32.74

>>708
じゃlet elseのRFCは議論中じゃないからたたき台じゃない
>>693の認識が間違い

**デフォルトの名無しさん** · 2023/02/19(日) 16:00:16.45

単なる叩き台wに従って仕様が変わる言語w

**デフォルトの名無しさん** · 2023/02/19(日) 16:00:56.96

RFCに議論の過程もなぜ導入しようとしたのかもメリットも書いてるのに
サンプルコードが別の書き方できるってもう重箱隅つつきたいだけでしょ
せめてRFCテキスト一文に対する反論なり書いてれば議論になるんだろうけど

**デフォルトの名無しさん** · 2023/02/19(日) 16:07:55.43

IDコロコロしてレベルの低いこと連投する複オジ

**デフォルトの名無しさん** · 2023/02/19(日) 16:09:05.87

let elseの話ならばもはやRFCの段階ではなく、
既に正式にlet文の一部として位置付けられて取り込まれており、
公式Referenceにもletの機能として必要な条件などが記載されている段階

**デフォルトの名無しさん** · 2023/02/19(日) 16:26:24.12

RFC (request for comment)はもちろんその名の通り『叩き台』で合ってる
ただしlet elseについては既に結論が出ているので、
RFCのtracking issueと合わせて過去の経緯と議論を見るための存在へと変わっている
今はRust公式Referenceを見るだけで十分

**デフォルトの名無しさん** · 2023/02/19(日) 16:39:11.76

複オジさんの役に立たない自演珍説言い訳レスはもうお腹いっぱい

**デフォルトの名無しさん** · 2023/02/19(日) 17:04:26.59

3ヶ月も前にstableに導入されたlet elseやラベル付ブロックbreakを今になって自分は使わないからその機能は不要だと主張している人は何をしたいのだろう？
時期的にも不明であるし執拗に不要だと言い続けている意図も不明だ
同時に導入されたGATも使わないから不要と言い出しそうだな

**デフォルトの名無しさん** · 2023/02/19(日) 17:10:07.16

>>717
ようわからんけどお前の発言の意図も不明だぞｗ

**デフォルトの名無しさん** · 2023/02/19(日) 17:58:31.87

そもそも要らん機能だと言い張るならRustフォークして削除した版作って勝手にやってりゃいいと思う

**デフォルトの名無しさん** · 2023/02/19(日) 19:36:27.82

うむ

**デフォルトの名無しさん** · 2023/02/19(日) 20:00:19.52

まぁCのgotoも使う人にとっては要る機能だしね

**デフォルトの名無しさん** · 2023/02/19(日) 20:04:13.68

有意義ではないとは言ってない
使うのは稀だと言ってるだけ
稀で済むからRustを使ってるの

**デフォルトの名無しさん** · 2023/02/19(日) 20:21:42.49

Cの時代にはgotoは普通に要る機能だったからな
コンパイラも今ほど賢くないし

**デフォルトの名無しさん** · 2023/02/19(日) 21:42:05.73

gotoなんてベーシックしか使ってことない初心者しか使ってなかっただろ

**デフォルトの名無しさん** · 2023/02/19(日) 21:45:08.41

gotoがメモリ消費量や実行性能の関係で最適になるケースがあった
コンパイラの最適化も今ほど優秀でなかった

**デフォルトの名無しさん** · 2023/02/19(日) 22:08:56.75

C/C++でもラベル付break/continueをサポートすればgotoを廃止できるけど
過去のgoto文があるために手を付けれないだけでなくwarning化することもなく
ラベル指定break/continueも導入せずにgotoのままでいいやと怠慢かなあ
どうしてもgoto避けたいなら無駄にフラグ変数利用

**デフォルトの名無しさん** · 2023/02/19(日) 23:43:41.66

let elseはErrにアクセスできたなら
Option/Result系の早期離脱はlet elseに統一できてよかったんだけどね

それができないから?オペレータが使えないbreak/continueか
Errにアクセスする必要のないOption::ok_or_else + ?の代替

**デフォルトの名無しさん** · 2023/02/19(日) 23:55:22.19

>>706
任意のenumから中身を取り出すのは抽象化すれば結局はOptionになる

**デフォルトの名無しさん** · 2023/02/20(月) 00:29:43.00

>>727
if letとlet elseは対であり対称な存在だから
「Errにアクセスできたら」なんて意味不明なことを言い出してる時点でif letも理解できていない
まずはif letが適していることとできないことを勉強し直しなさい

**デフォルトの名無しさん** · 2023/02/20(月) 00:33:09.85

じゃあ任意のUnionは？

**デフォルトの名無しさん** · 2023/02/20(月) 00:39:36.85

>>729
それはものすごく一面的な見方
内部実装だけみてユースケースを見てない

**デフォルトの名無しさん** · 2023/02/20(月) 00:47:31.51

>>728
中身を取り出す方法を具体的に尋ねられているのに「抽象化すれば」では答えになっていない

**デフォルトの名無しさん** · 2023/02/20(月) 01:16:24.28

>>731
既存コードをlet elseへと適しているのを置き換えたから把握している

Err(e)値も処理したいときに
if let Ok(v) = ...と書かないのと同様に
let Ok(v) = ... elseも同じく使わないのは当たり前
それはどちらもmatchやResultメソッドを使うべきケース

もしf()がResult<enum, Error>を返す場合ならば
if let Xxx(v) = f()? ...とErrだけ逃がすことができるし
let Xxx(v) = f()? ... elseとErrだけ逃がすことができる点も同じ

**デフォルトの名無しさん** · 2023/02/20(月) 02:35:55.57

>>731
糖衣構文の実装ありきでユースケースベースの検討を疎かにしたRFCと同じだねぇ

**デフォルトの名無しさん** · 2023/02/20(月) 08:12:59.13

RFCの段階での議論に敗北して採用されちゃったからって5chでギャオってるの見苦しすぎるだろ

**デフォルトの名無しさん** · 2023/02/20(月) 08:32:05.17

機能追加は自分の思いつくことを解決する、または大幅な改善をする
銀の弾丸でなければならないって思ってそうだ

**デフォルトの名無しさん** · 2023/02/20(月) 10:59:06.46

条件つき確率を信じない人のような印象
条件が成立しなければ普通の弾丸だから

**デフォルトの名無しさん** · 2023/02/20(月) 11:30:01.73

(ФωФ)

**デフォルトの名無しさん** · 2023/02/20(月) 13:36:11.72

「と言い出しそうだな」「って思ってそうだ」「な印象」

関心事がけっきょくは発言者の人格なんでつねえｗ

**デフォルトの名無しさん** · 2023/02/20(月) 17:13:31.56

5chの隅っこでとにかくマウント取りたいだけの人だから

**デフォルトの名無しさん** · 2023/02/20(月) 18:04:32.79

ただ文句をつけたいだけなのか
とにかく嫌いなだけなのか
ブロックラベル指定breakについてもlet elseについても反対してる人から一貫性や理性を感じられない面はある

例えばlet elseについて不要との主張の理由がこれまで3つ挙げられているが
「自分は使わないから不要」は論外として
「他の書き方ができるから不要」も特定の例にしか適用できない代替策だったり当然if letとlet elseはmatchに代替できる原点の視点を欠いている
「Err(e)値を扱えないから不便で不要」も同様でif letとlet elseはそれを扱わない構文だと理解できていない
もしif letも不要だと開き直るならばそれはそれで主張が一貫しているのであろうが

**デフォルトの名無しさん** · 2023/02/20(月) 18:35:32.36

ぱっと見の印象ほど便利でもないな
と言われてるだけのような気がするが

**デフォルトの名無しさん** · 2023/02/20(月) 18:38:50.78

理性と一貫性が一番欠落してるオジが何か言ってるぞwww

**デフォルトの名無しさん** · 2023/02/20(月) 18:59:27.30

冷静な技術的議論にならない原因が誰にあるかは一目瞭然なんだから相手にしないこと

分かりやすい煽りよりも技術的議論に見せかけたマウンティング行為にこそ高いスルー力が求められる

**デフォルトの名無しさん** · 2023/02/20(月) 19:34:52.06

煽りこそ要らない
技術的な議論なら歓迎
マウンティングとか興味ないためそんな発想も感覚も出て来ないので感じている人はたぶんそれ鏡の自分自身

**デフォルトの名無しさん** · 2023/02/20(月) 19:56:45.86

技術的論議とか不要やん
売れるシステム作ったもんの勝ちや

でもって世の中で売れてるシステムって意外とクソ技術

**デフォルトの名無しさん** · 2023/02/20(月) 20:36:10.20

>>746はきっとこの業界長いなｗ
昼間書き込んでる学生や無職どもとは面構えが違う

**デフォルトの名無しさん** · 2023/02/20(月) 20:50:17.61

>>746
ここはプログラミング言語Rustのスレ
興味がないならば別スレへどうぞ

>>747
昼間に書き込んでるIDを見たらあんたやでｗ

**デフォルトの名無しさん** · 2023/02/20(月) 20:55:08.90

>>748
勘違いしちゃいけない
言語には興味があるが今行われてる議論には興味も無いし意味もない

**デフォルトの名無しさん** · 2023/02/20(月) 21:14:07.07

何年も前からRFC出てて昨年stabled入りした機能に要るも要らねえもねえからな

**デフォルトの名無しさん** · 2023/02/20(月) 21:18:07.99

stableになった11月に不要だと暴れるならともかく
今になって不要だと暴れてるのも不思議だよな

**デフォルトの名無しさん** · 2023/02/20(月) 21:21:42.34

🦀

みんながインターネットで争ってばかりいるので、Ferrisくんは踊るのをやめてしまいました
お前のせいです
あ～あ

**デフォルトの名無しさん** · 2023/02/20(月) 21:31:44.32

RFCに特攻しないだけマシなのでは
いや公式に真正面からお伺いたてたほうがマシなのか

**デフォルトの名無しさん** · 2023/02/20(月) 21:53:45.15

暴れてる、ってのが被害妄想的表現やわ
俺には誰一人暴れてるようには見えない
このスレで暴れてたのは所有権の複製のあの人だけ

**デフォルトの名無しさん** · 2023/02/20(月) 22:53:31.02

繰り返し同じ主張をしても誰も同意してくれないから
自分の意見に同意してくれないやつらは全員暴れてるということにして無意識に自我を守ろうとしてるんだよ

自己愛的防衛とか躁的防衛というやつ

**デフォルトの名無しさん** · 2023/02/20(月) 23:30:32.01

>>754
所有権の複製ってもう5年くらい前だろ
そんな昔のことをいまだに引きずってるとは病んでね？
何の記事に書いてあった話かも忘れた

**デフォルトの名無しさん** · 2023/02/21(火) 00:09:04.47

自演オジ

**デフォルトの名無しさん** · 2023/02/21(火) 01:55:16.33

頭が良くなれば解決することを、性格や健康の問題だと思わないほうがいい気がする
頭が良くなりたいのは色々解決するからだ
マウントしたいからではない

**デフォルトの名無しさん** · 2023/02/21(火) 02:05:43.32

俺たちが興味あるのは技術の話題であって他人じゃねーもんな
誰がどうしたとか妄想に取り憑かれているとしか思えん
ところで標準ライブラリがflumeではなくcrossbeamを取り込んだのはなんでだ？

**デフォルトの名無しさん** · 2023/02/21(火) 10:55:47.93

https://github.com/rust-lang/rust/pull/93563
> crossbeam-channel has become the most popular alternative on crates.io

これ以上の深い理由はなさそう

**デフォルトの名無しさん** · 2023/02/21(火) 13:28:03.06

cargo check --doc-tests
　　　　　　　　欲しい！

**デフォルトの名無しさん** · 2023/02/21(火) 21:08:16.69

std::sync::mpscの実装が5年くらい放置されてた
その間に効率的な実装のcrossbeamが広まり更に効率の良いflumeも登場して性能と人気を競っている
放置されてた標準ライブラリを今回は実績のあるcrossbeam実装ベースへ変更したが状況は変わらないだろう
Rustは最小限の標準ライブラリに様々なクレートが競い合ってより良いものを生み出していく文化であるからだ

**デフォルトの名無しさん** · 2023/02/21(火) 21:14:33.40

ひとりごとおじさん

**デフォルトの名無しさん** · 2023/02/21(火) 22:02:42.80

自分の発言が炎上するかしないかを自分で判定できそう
失言おじさんにはそれができない

**デフォルトの名無しさん** · 2023/02/21(火) 22:06:41.15

ずっとおじさんおじさん言ってる「おじさん」おじさんの方が正直こわい

**デフォルトの名無しさん** · 2023/02/21(火) 22:08:33.85

分かってんなら触れんなっての

**デフォルトの名無しさん** · 2023/02/21(火) 22:20:06.54

オジおじ言ってる人は相手にしちゃいけないアンタッチャブル

**デフォルトの名無しさん** · 2023/02/21(火) 22:28:06.23

「所有権の複製」とかいうアホな用語を使って
ここのみんなにバカにされて涙目で敗走していったおじさんがおるんよ
その可愛そうな子が複オジ

**デフォルトの名無しさん** · 2023/02/21(火) 22:48:33.95

主語が小さいのは良い
長期戦すぎるのが悪い

**デフォルトの名無しさん** · 2023/02/21(火) 23:07:04.37

>>768
誰かが「所有権の複製」と言い出したのではなくITメディアサイトのRust入門記事に書かれていた話だな
その表現を許容できる範囲か違和感あるかで色んな意見があったのは覚えている

**デフォルトの名無しさん** · 2023/02/21(火) 23:18:12.91

複オジ必死の自演2

**デフォルトの名無しさん** · 2023/02/21(火) 23:29:58.13

Copy実装型は値が複製されて新たな所有権が生じるが正確
それをその入門記事は所有権の複製と表現してたやつだろ
許容でも不許容でもどうでもええわ

**デフォルトの名無しさん** · 2023/02/21(火) 23:35:03.71

よっぽど悔しかったんやなｗ

**デフォルトの名無しさん** · 2023/02/21(火) 23:35:15.52

ところでいったいどうやってメモリ安全なの？

**デフォルトの名無しさん** · 2023/02/21(火) 23:39:30.48

緑の文字でMって書いとけばOK

**デフォルトの名無しさん** · 2023/02/21(火) 23:44:02.70

次のかたどうぞ

**デフォルトの名無しさん** · 2023/02/21(火) 23:44:49.64

そんな昔の話をいまだに引っ張ってオジオジ言ってたのかよ
精神病んでるな

**デフォルトの名無しさん** · 2023/02/21(火) 23:54:33.49

C言語は知ってる。アセンブラも知ってる。どうやってメモリ安全なのか
サクッと説明できないの？

**デフォルトの名無しさん** · 2023/02/21(火) 23:57:49.69

文句あるならRFCとか記事サイトとかに直接言うしかないな
ここでこれ以上の議論を続けてもしょうがない

**デフォルトの名無しさん** · 2023/02/21(火) 23:59:31.91

>>778
>>1

**デフォルトの名無しさん** · 2023/02/22(水) 00:14:21.77

複製の方はググってみたらitmediaのRust入門記事だね
型に依って移動と複製の2種類あるのを教えるところだから、入門者向けの解像度として大雑把にしといて後で詳細を学べばいいでしょ

メモリ安全の方は解説記事が山ほどあるから、まずは読んで分からないところだけを質問したら？

**デフォルトの名無しさん** · 2023/02/22(水) 00:45:10.48

参照されている間はmove禁止にする
それができたらその意味で安全
どうやってそれができるのか実装依存かな

**デフォルトの名無しさん** · 2023/02/22(水) 00:59:45.76

稀に誤解する人がいるけど、moveはメモリ上の移動ではなく所有権の話だから注意ね
メモリ上の移動の禁止を保証するのはstd::pin::Pinだけど、初心者は知らなくても大丈夫

**デフォルトの名無しさん** · 2023/02/22(水) 01:45:26.03

moveを所有権の移動だと捉えてるから
copyも所有権の複製だと勘違いする
これが世に言う複製おじさん

**デフォルトの名無しさん** · 2023/02/22(水) 07:55:16.15

稀に誤解するオジ

**デフォルトの名無しさん** · 2023/02/22(水) 11:19:00.04

>>783
一応ちゃんとCopyのdocで｢It’s important to note that in these two examples, the only difference is whether you are allowed to access x after the assignment. Under the hood, both a copy and a move can result in bits being copied in memory, although this is sometimes optimized away.｣って説明されてんだよな

**デフォルトの名無しさん** · 2023/02/22(水) 12:20:22.57

所有権が移動するからその後はアクセスできなくなるんだよな

**デフォルトの名無しさん** · 2023/02/22(水) 12:56:45.35

>>784
Copy非実装型は所有権が移動するで合ってるぞ
それをmoveと呼ぶ

**デフォルトの名無しさん** · 2023/02/22(水) 16:14:06.54

メモリ安全に関しては実行時の、
すなわち実装上の工夫があるわけでは一切なく、
単にメモリの使途をコンパイラが把握できるようにして
コンパイラが厳しいチェックを入れるってだけのことなのかな
極めて有用だと思うけどつまんないね