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/12(日) 12:48:00.42

他の書き方があるって主張は不要論になってないんだよな
ラベルbreakってシンタックスシュガーでしかないから
もともと実現方法があるのは当然

ある処理においてよりシンプルで学習コストが低い記法があれば
その処理では不要と言える

**デフォルトの名無しさん** · 2023/02/12(日) 12:48:51.92

f, g, ff, gg の要求する型がu8で上限値が128だったら

**デフォルトの名無しさん** · 2023/02/12(日) 12:52:28.45

>>590
判定方法変わらなくても>>592で終了

自然数しか出てこないコードに突然勝手に負数を導入し出すあたりJS畑から来たのかな

**はちみつ餃子** ◆8X2XSCHEME · 2023/02/12(日) 12:56:01.59

>>587
・パターンとして分類するとアンチパターンの範疇に入る
・しかし必要な場面もある (からマシな方法としてラベル付きブレークが導入された)

**デフォルトの名無しさん** · 2023/02/12(日) 13:07:40.20

適材適所を無視して何でもイテレータメソッドチェーンにしようとする人たちはたまにいるけど
多重ループで条件により早期で抜けたり何段かまとめて抜けたりする時は>>571のように素直に多重forまたはloopが分かりやすい
loop式だとそれ自体もbreakで値を返せるようになるがどの段のloopを抜けるかでラベル指定breakは今までも使われてきた
だからラベル付きブロック式にも違和感ないが拒否反応を示してる人は技術的ではなく感情的になっているだけではないかと思われる

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

>>594
多重ループを早期で抜けるのがアンチパターンとは聞いたことがない
最近の多くの言語が持っているラベル付きbreakがC/C++は持っていないため多段抜けが出来なくてやむを得ずに状態変数管理することはあるが
それはC/C++言語の制約であり言語仕様が弱いだけなのでそこでの習慣に引っ張られてはいけない

**デフォルトの名無しさん** · 2023/02/12(日) 13:46:03.52

論点1(578)：>>571はアンチパターンなのか？
論点2(587)：>>571って大域脱出なのか？
論点3(589)：>>588 vs >>571 どっちがマシか？

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

そんなに拘るのにID変わりやすい環境ならコテつけて

**デフォルトの名無しさん** · 2023/02/12(日) 14:40:41.70

>>585
どちらかというと
What中心でコードを構成する人と
How中心でコードを構成する人の考え方の違いじゃないか？

**はちみつ餃子** ◆8X2XSCHEME · 2023/02/12(日) 14:52:22.89

>>596
私が >>581 で述べている「両立する」ってところを無視しないでくれ。
(形式としては) 多重ループからの脱出が大域脱出でありアンチパターンであることと
ラベル付きブレークが (回りくどいフラグ管理や goto より) マシな解決方法であるというのは両立すると言ってるんだ。

**デフォルトの名無しさん** · 2023/02/12(日) 15:03:13.37

>>600
代替策を示さずにアンチパターンだと唱えるのをそろそろ辞めにしよう
多重ループから脱出しないコードを示してくれ

**はちみつ餃子** ◆8X2XSCHEME · 2023/02/12(日) 15:09:50.74

>>601
「形式として」と念押ししてるんだから実態はそうではないというニュアンスを読み取ってくれ。

**デフォルトの名無しさん** · 2023/02/12(日) 15:11:42.38

そもそも大域脱出とやらの定義はどこに示されてるの？

https://www.gnu.org/software/libc/manual/html_node/Non_002dLocal-Exits.html
> 23 Non-Local Exits
> Sometimes when your program detects an unusual situation inside a deeply nested set of function calls,
> you would like to be able to immediately return to an outer level of control.
> This section describes how you can do such non-local exits using the setjmp and longjmp functions.

GNUの文書では単にネストした関数から一気に脱出することだけど？
このスレの文脈としては何か別の特別な定義を参照してるの？

**はちみつ餃子** ◆8X2XSCHEME · 2023/02/12(日) 15:14:46.65

言い換えると、
形式としてアンチパターンであるが故にアンチパターンと同等の書き方を強いられていたことに
対する解決 (のひとつ) がラベル付きブレークだろうってこと。

**デフォルトの名無しさん** · 2023/02/12(日) 15:17:29.13

>>602
多重ループからの脱出を形式として優れていると主張するならばわかるが
良き代替策もないのにアンチパターンだと主張するのは意味不明でありそんな主張はほかでも聞いたことがない

**デフォルトの名無しさん** · 2023/02/12(日) 15:21:15.66

アンチパターンなのに解決方法とか自分で言ってて違和感感じないの？
それともアンチパターンだけど必要悪とでも言うのかな？

**デフォルトの名無しさん** · 2023/02/12(日) 15:35:28.40

アンチパターンとなりうる大域脱出とは、関数呼び出しの奥深く、すなわちスタックレベルの異なる位置からの脱出を指す
一方で、ループやブロックのbreakは同じスタックレベルの出来事であり、当然ながらアンチパターンには該当しない

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

アンチパターンの定義も大域脱出の定義もどうでもいいけど
-1を特別なダミー値として-1だったら条件変えてfindとかいうゴミカスクソコードよりは多重ループとbreakの方が遥かにマシなのは間違いない

**デフォルトの名無しさん** · 2023/02/12(日) 16:27:13.73

>>592
>>608
気になるならOption<u8>に変えればいいし、それで大した差なんてないよ
ちょっとRangeで楽できなくなるだけ
それくらいすぐ分かってくれ

**デフォルトの名無しさん** · 2023/02/12(日) 16:30:50.77

そういうやりとりしなきゃいかん時点でもうラベルブレークのほうがマシやん

**はちみつ餃子** ◆8X2XSCHEME · 2023/02/12(日) 16:39:36.79

>>606
「パターンとして分類すると」「形式としては」アンチパターンに当てはまるだろう (実態はそうではない) と言ってる。
要するにアンチパターンではないと言ってるつもりなんだけど。

**デフォルトの名無しさん** · 2023/02/12(日) 16:40:20.30

>>609
どんどんコードがガチャガチャ読みにくくなっていくので素直に多重ループとbreakしますね

**デフォルトの名無しさん** · 2023/02/12(日) 16:58:29.66

>>611
自分が
>>581 > 大域脱出自体がアンチパターンではあるが
と書いたことも忘れたのか？
そもそも形式的とかオレオレ定義の用語で語られても困るし

**デフォルトの名無しさん** · 2023/02/12(日) 17:20:45.22

デバッガにかけることを考えたらたかが十数行に収まる二重ループを直積という抽象化で隠蔽するより二重ループのまま見せた方がいいよね
直積として宣言的に書こうが結局プログラムは手続きとして実行されるので、過度な抽象化は手続きに展開する思考コストがかかるだけ

**デフォルトの名無しさん** · 2023/02/12(日) 17:28:15.80

> 大域脱出自体がアンチパターン

制御フローの代わりに例外使っちゃなんね！
ばっちゃが言ってた！
しかし彼女は大域脱出すべてについてではなく
その用法について言及したにすぎないのであった

**デフォルトの名無しさん** · 2023/02/12(日) 18:31:37.86

「アンチパターン」に反応して急にレス増えすぎ

>>571がアンチパターンなのは多重ループから大域脱出してるからじゃない
多重ループを使った探索と探索で見つからなかった場合の処理を分離できてないからアンチパターンなんだよ

ブロックのラベル付きbreakを無理矢理使おうとした創作コードだからそうなる

**デフォルトの名無しさん** · 2023/02/12(日) 18:44:46.39

>>616
forの中から帰るときは見つかった場合の処理で、
見つからずにfor文抜けたらデフォルト値を返すなんて処理プロダクトレベルで1億万回使われてるけど

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

>>571 の分岐構造
f(i) がtrueならff(i)
g(i, j)がtrueならgg(i)
それ以外は0

>>588 の分岐構造
jが-1ならf(i)がtrueなら Some(i, -1)
jが-1以外でg(i, j)がtrueなら Some(i, j) ただし j != -1
jが-1以外でg(i, j)がfalseなら None
↓
Some で j が-1 なら ff(i)
Some で j が -1 以外なら gg(i)
None なら 0

(^^;;

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

論点578：>>571はアンチパターンなのか？
論点587：571って大域脱出なのか？
論点589：>>588 vs 571 どっちがマシか？
論点607：ループやブロックのbreakは大域脱出ではないし当然アンチパターンでもない
論点614：588 は過度な抽象化は手続きに展開する思考コストがかかるだけ
論点618：588 の分岐構造の煩雑さ(^^;;

**デフォルトの名無しさん** · 2023/02/12(日) 20:39:11.84

>>616
代替策を示さずにアンチパターンだと主張するのをそろそろ辞めにしようぜ
まずは代わりのコードを示すべきだ

**デフォルトの名無しさん** · 2023/02/12(日) 22:47:32.75

let result = collection.find_foo().unwrap_or(bar);

find_fooの中で多重ループ使おうがイテレータ使おうがそれは状況に合わせて使い分ければいい
大事なのは適切な単位で処理に意味ある名前をつけて”意図”を伝えるコードを書くこと

特に多重ループで大域脱出させるような処理に名前も付けずダラダラ書くスタイルはRustのような言語では基本的にやっちゃダメ

**デフォルトの名無しさん** · 2023/02/12(日) 22:50:21.83

オジがわかってなさそうだから補足しておくと
見つかった場合と見つからなかった場合を明確に分けられてないのは>>571も>>588も同じだからね

**デフォルトの名無しさん** · 2023/02/12(日) 23:10:06.96

>>616
機能分離の粒度や方法は決まった正確が一つあるものではなく、状況に応じて基準も変わるし、複数の解があり選べることも多い
したがって、処理を分離したコードの方が明らかに望ましいと誰もが思う場合でないと、アンチパターンと言い切るのは過度だと言える

今回の>>571を、探索(＝インデックスを得る)機能部分のみに分離できるのはご指摘の通りだが、コードはこうなる
let (i, j) = 'i_j: {
　for i in 0..100 {
　　if f(i) {
　　　break 'i_j (Some(i), None)
　　}
　　for j in 0.100 {
　　　if g(i, j) {
　　　　break 'i_j (Some(i), Some(j))
　　　}
　　}
　}
　(None, None)
};
元のコードと比べると、構造も行数も変わっておらず、さらに加えてこの後にmatch (i, j)の処理コードが必要となる
したがって、今回のケースで機能分離するかどうかは好みの範囲であり、元のコードに問題はないと言える

**デフォルトの名無しさん** · 2023/02/13(月) 10:01:54.27

>>621
＞処理に意味ある名前をつけて”意図”を伝えるコードを書くこと
つまりラベル付きブロックでいいよね
現代的なエディタならブロックは折り畳めばいいし、ラベルで名前もつけられるし
何より型推論と?演算子に任せれば済むような非本質的なエラー型の合成というノイズをメインロジックから分離できて"意図"が伝わりやすくなるので

**デフォルトの名無しさん** · 2023/02/13(月) 12:37:14.05

>>572の比較表に付け加えるとこんな感じか

関数化:
〇機能名の明示　(関数名)
×利用する変数(値)と結果の型推論
〇変数、ライフタイムのスコープ
×環境(変数)のキャプチャ
〇早期脱出
×?演算子のエスカレーション・合成

ラベル付きブロック式:
〇機能名の明示　(ラベル名)
〇利用する変数(値)と結果の型推論
〇変数、ライフタイムのスコープ
〇環境(変数)のキャプチャ
〇早期脱出
〇?演算子のエスカレーション・合成

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

関数の特徴としては、
○コード記述箇所と実行箇所の分離
○再入可能性
というのがあるな。

まぁ、ブロックは記述箇所と密接に関係しているから当然の話だけど。

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

ブロック式はその場でしか呼ばれないから再入可能性はそもそも必要ないね
そしてブロック式がある関数として再入可能性を保証でいいわけだから

**デフォルトの名無しさん** · 2023/02/13(月) 16:19:13.75

>>623
そういうループを使う現実的なユースケースは
通常の多次元データではなくフォルダとファイルのようなCompositeデータを扱うときだけなので
インナーループから返す値にはiを必要とせずSome(j)で十分になるように作る
もしそれができない場合でも(Some(i), None)はSome(i)に(Some(i), Some(j)はSome(f(i,j))に変換できるようにする

**デフォルトの名無しさん** · 2023/02/13(月) 16:27:32.48

>>628
勝手に様々な特殊なケースのみに限定して話をしても全く意味がない
さらに二次元インデックスi,jをjだけに折り畳めるという特殊な仮定を持ち出すのも意味がない
そしてインデックスを返す機能の話をしているのにf(i,j)を持ち出すのも意味不明すぎる

**デフォルトの名無しさん** · 2023/02/13(月) 16:46:00.57

>>624
let message = 'get_latest_unread_message {
…
break 'get_latest_unread_message Some(Foo::foo_bar(result)
…
};
とか書くわけ？

**デフォルトの名無しさん** · 2023/02/13(月) 16:47:27.73

>>629
具体的なユースケース出せないなら話にならないよ

**デフォルトの名無しさん** · 2023/02/13(月) 16:53:40.18

>>631
いくらでも様々なデータ処理があるだろ
狭い範囲の仕事しかしていないから
>>628のような何重もの特殊な仮定だらけになるのだろう
そして我々がしている議題はRustの言語機能の話がメインでそこでの例として汎用的なサンプルコードが出ている

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

そもそもラベルいらんよね？（構文上必要なんだろうけど？）
ブロックに区別が必要ない場合は

>>630を例に取ると
let latest_unread_message = 'b { // 変数名がブロックが返す値を表現
break 'b Some(Foo::foo_bar(result)) // 具体例はbreak以降に表現
};

ブロックが二重三重になってるときだけそれを区別したいだけであって？

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

型推論のおかげで>>626の機能を諦めれば記述量を大幅に減らせるってことなのかな？

>>630
これに、breakで一番内側の名前付きブロック名を省略する記法があれば、こんな感じに出来て、エディターで表示補完も出来るな

let message = 'get_latest_unread_message {
…
break '' Some(Foo::foo_bar(result)
…
};

**デフォルトの名無しさん** · 2023/02/13(月) 18:03:44.02

>>634
ブロックは関数と異なりリエントラントの必要性も概念もない
ブロックは関数内のその場所で呼ばれるだけだから他から不意打ちで呼ばれる対策も必要ない
ブロックが所属する関数がリエントラントを保証しているから大丈夫

そしてブロックのメリットは環境変数をそのままキャプチャできて型宣言は必要なくブロック式の結果も型推論されること
さらに？オペレータがifやmatchやループの時と同様にブロックを飛び越えてくれるからResultを気にせずに値だけの型に専念できる

**デフォルトの名無しさん** · 2023/02/13(月) 18:08:53.41

>>633
なるほどね
いっそラベルをretとかにしてしまえばクロージャっぽく見えるのか

let latest_unread_message = 'ret {
break 'ret Some(Foo::foo_bar(result))
};

**デフォルトの名無しさん** · 2023/02/13(月) 22:41:07.13

うーん、それは....ちょっと

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

>>633
ラベルは必要
ラベルが付いてるブロック内でのみラベル指定breakができる

例えばforの中でmatchでアーム右辺が無名ブロックで無名breakしている既存のコードはそのブロックをbreakせずforをbreakする
しかしそれら全体がラベル付ブロックに覆われていてラベル付breakしていればラベル付ブロックをbreakできる

既存コードと互換性があり曖昧さもなく良い構文となっている
既存のloop構文からloopキーワードを抜いただけの構文である点からも自然な受け入れやすい構文拡張となっている

**デフォルトの名無しさん** · 2023/02/15(水) 22:09:51.65

同時に導入されたlet elseも便利やな
それまではif letするたびにネストがどんどん深くなっていって困るかそれを回避するために
let xxx = if let Some(xxx) = foo() { xxx } else ...と三度も変数名を書かされて悲惨だった

**デフォルトの名無しさん** · 2023/02/15(水) 23:56:03.48

どちらも長年Rustで構文的に残っていた不便な点だったから解決してうれしい

**デフォルトの名無しさん** · 2023/02/16(木) 09:41:25.47

>>639
早速テストコードに使ったら、ifを除去出来て大変満足

**デフォルトの名無しさん** · 2023/02/16(木) 10:43:33.51

>>639
unwrap_orじゃダメなのか？

**デフォルトの名無しさん** · 2023/02/16(木) 11:19:26.94

>>642
え？！
elseの後の型は！じゃないとlet else使えないよ

**デフォルトの名無しさん** · 2023/02/16(木) 12:55:00.75

>>642
例えばこれは深さ3段だからギリだけど
どんどん深くなるのを早期continueしたい時にどうする？って話
環境問題などで別関数化も無しでね
for x in iter {
　if let Some(boo) = get_boo(x) {
　　if let Some(foo) = get_foo(x) {
　　　if let Some(woo) =get_woo(x) {
　　　　let pigs = three(boo, foo, woo);
　　　　...
　　　}
　　}
　}
}

**デフォルトの名無しさん** · 2023/02/16(木) 14:44:50.54

>>644
関数化無しの前提を置かないといけない状況を改善した方がいいのでは？
その例も普通ならxを受け取ってOptionを返す関数に簡単に抽出できるよね？

**デフォルトの名無しさん** · 2023/02/16(木) 14:59:14.48

>>645
それは無理
実際のコードだと全部揃ってから処理ではなく途中で処理しつつになる
さらにbreakによるfor抜けも入ったりする
さらに使う環境が多くてその別関数へ参照渡しまくりになる
さらに途中でエラーも返るから別関数はOptionではなくResult返しになる
つまり?はOptionに対して直接使えない

**デフォルトの名無しさん** · 2023/02/16(木) 15:15:34.23

goto >>459;

**デフォルトの名無しさん** · 2023/02/16(木) 16:37:34.02

関数を分けると?を逃がすことが出来なくなる点など含めて
ラベル付ブロック式の時と同じ話だな
いずれにせよ関数化は愚策でありlet elseによりcontinueするのが正解

**デフォルトの名無しさん** · 2023/02/16(木) 17:21:40.49

無限ループってこわくね？

**デフォルトの名無しさん** · 2023/02/16(木) 17:31:08.98

continueはforでnext()に進んで無限ループじゃないぞ

**デフォルトの名無しさん** · 2023/02/16(木) 18:48:57.26

ちゃんとしたプログラマーは無限ループになりそうなところはブレークMAXカウンターやシグナルブレイク出来るように書いてるから大丈夫ですYO！

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

サーバーやデーモンなどは同じことを繰り返せるように敢えて無限ループにプログラミングする

**デフォルトの名無しさん** · 2023/02/16(木) 22:57:51.48

>>646
なるほどResult<Option<T>>でOptionだけハンドリングしたいパターンならif let使えばネストしていくわな

普通にmatch使えばいい場面だと思うんだが何かlet else使うメリットがあるの？

**デフォルトの名無しさん** · 2023/02/16(木) 23:01:01.44

>>653
matchとif letは同じ
コード書けば分かる

**デフォルトの名無しさん** · 2023/02/16(木) 23:07:53.84

ああif letの結果を受けるように書くからってことね
それ普通は使わないよね

**デフォルトの名無しさん** · 2023/02/16(木) 23:15:48.94

let foo = match get_foo(x)? { Some(x) => x, None => continue} が
let Some(foo) = get_foo(x)? else { continue };になると行数が短くなってうれしいということ？

**デフォルトの名無しさん** · 2023/02/16(木) 23:15:53.10

matchを使おうが元の問題これ何も解決しなくね？
>> let xxx = if let Some(xxx) = foo() { xxx } else ...と三度も変数名を書かされて悲惨だった

**デフォルトの名無しさん** · 2023/02/16(木) 23:17:38.28

Someの中の文字は何でもいいんだから短いスコープなら同じ名前を律儀に書く必要ない

**デフォルトの名無しさん** · 2023/02/16(木) 23:29:57.12

変数名短くしても結局3度も書かされるのは異常で改善の余地あり
それが1度で済むようになってようやく正常化した

**デフォルトの名無しさん** · 2023/02/17(金) 00:34:38.77

swiftのようにguard let ~ elseとしてくれれば
行頭見るだけでguardだとわかって良かったのにな
少し複雑なパターンマッチだとelseが埋もれてしまう

**デフォルトの名無しさん** · 2023/02/17(金) 07:21:19.98

冒頭だけで分かるよ
let x = ... ←通常
let Some(x) = ... ←elseあり

**デフォルトの名無しさん** · 2023/02/17(金) 08:35:50.31

if let って可読性悪くない？

**デフォルトの名無しさん** · 2023/02/17(金) 08:45:48.10

>>662
両方の観点から分かりやすい
普通のletではなく、ifにより条件付きだと分かる
普通のifではなく、letにより新たな変数定義付きだと分かる

**デフォルトの名無しさん** · 2023/02/17(金) 10:34:35.45

>>661
let Foo { bar, baz, … } = get_woo?.map_or_else(Bar::default(), |x| …

**デフォルトの名無しさん** · 2023/02/17(金) 10:59:52.09

>>664
その観点からはRustではrefutableなのかirrefutableなのかが一番重要な概念になる
噛み砕いて言うと条件付マッチングとなるのがrefutableで無条件マッチングとなるのがirrefutable
Foo { bar, baz, … }はirrefutableパターンだから普通のlet
Some(foo)はrefutableパターンだからif letかlet else

**デフォルトの名無しさん** · 2023/02/17(金) 11:46:57.46

>>665
おおいいね
じゃこれは？
let foo::Foo { bar, baz, … } = get_woo?.map_or_else(Bar::default(), |x| …

**デフォルトの名無しさん** · 2023/02/17(金) 12:26:34.10

>>666
letについては既に説明した通り
それはFooとBarは型が異なりエラー
型の一致は必須
struct内の略は...と3つでなく..と2つ
Bar::default()の()は付けてはいけない
型の明示が必要ないならDefault::defaultでもよい
map_or_else(Default::default, |x| …)は
map(|x| …).unwrap_or_default()と書ける

**デフォルトの名無しさん** · 2023/02/17(金) 14:50:20.18

>>667
はい残念

**デフォルトの名無しさん** · 2023/02/17(金) 21:38:02.32

>>662
elseがある場合はmatchのほうが可読性いい
elseがない単純な場合はif letでも悪くない
ネストすると最悪

**デフォルトの名無しさん** · 2023/02/17(金) 21:58:40.37

let elseが需要の隙間を埋めてくれた

**デフォルトの名無しさん** · 2023/02/17(金) 22:52:21.88

letするたびにインデントが深くなる言語もあるぞ
そういう失敗を記憶しているおかげで、比較的成功した例を認識できる

**デフォルトの名無しさん** · 2023/02/17(金) 23:13:25.95

let elseはシンプルなケースじゃないと通常のletと見分けがつきにくい
でもシンプルなケースならlet chainでまとめた方が圧倒的に可読性高まるのでいらない子になりそう

**デフォルトの名無しさん** · 2023/02/18(土) 00:32:34.89

最初見たとき便利そうだな思ったけど意外と使わない let else
? とか unwrap_or_elseとかで事足りることが多い
あって困るような機能でもないけど

**デフォルトの名無しさん** · 2023/02/18(土) 08:01:02.47

論駁可能性の有無で区別つくし、elseによる処理文があるのだから、let elseが見分け付かないなんてことはない
if letと同様にlet elseはエラー値を捕獲する構文ではないため、エラー処理に用いないのは当たり前で、?を持ち出す人はその基本を理解できていない
マッチングしない時にcontinueやbreakする時などは、特にlet elseが最も適している

**デフォルトの名無しさん** · 2023/02/18(土) 11:02:32.63

たしかに
でもコンテニューやブレーク書くことが稀

**デフォルトの名無しさん** · 2023/02/18(土) 18:28:41.55

やってることは同じ早期離脱なのに
新しいバインディングを伴う場合は
breakやcontinueならlet else
returnなら主に?かlet~match
新しいバインディングを伴わない場合はifかmatch

書くのは多少楽になってもこれだけ種類があると読みにくくなる

**デフォルトの名無しさん** · 2023/02/18(土) 18:44:10.63

if letを廃止してmatchだけに統合すればすっきりする
match boolでifも廃止できる
breakとcontinueもmatch boolで括れば済むから廃止できる

**デフォルトの名無しさん** · 2023/02/18(土) 20:05:29.88

>>677
それだと'outer指定ができなくないか？

**デフォルトの名無しさん** · 2023/02/18(土) 20:16:45.16

C/C++は多重forの多重breakを持たないが状態変数などで工夫して対応できている

**デフォルトの名無しさん** · 2023/02/18(土) 20:28:10.99

状態変数とか使うぐらいならgotoの方がマシだろ

**デフォルトの名無しさん** · 2023/02/18(土) 20:45:44.21

>>679
>工夫して対応できている
これ言ったら自分の発言のブーメランになってないか？
そりゃ言語仕様に盛り込まずに工夫して対応しろってことなら、
なんだって工夫しろで終了じゃん

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

いや、工夫する方が正解という信念とかは持ってなさそう
正解なんてあるわけないという結論から逆算されたムーブじゃないか

**デフォルトの名無しさん** · 2023/02/18(土) 21:04:06.66

>>677
>>659にある3回書く問題を無視していいなら今でもmatch縛りで書けばいいよね

その方が読みやすくなる面があるのは確か

**デフォルトの名無しさん** · 2023/02/18(土) 21:04:58.48

>>680
gotoの導入いいね
loopとforも廃止してシンプルにmatchとgotoだけで見やすそう

**デフォルトの名無しさん** · 2023/02/18(土) 21:28:03.45

デストラクタがあればgotoの少なくとも一部は許されないことが確定する
なければ雰囲気で決める

**デフォルトの名無しさん** · 2023/02/18(土) 23:00:33.44

>>675
たまたま自分で使うことが稀だからといってcontinueやbreakを要らない子扱い？

**デフォルトの名無しさん** · 2023/02/18(土) 23:56:17.68

そりゃアルゴリズムは出来合いのものしか使いませんっていうならcontinueもbreakも使わんだろうな。

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

なにさ！ループの中へジャンプしたっていいじゃない！

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

昔みたいに関数を長々と書く時代じゃないから
breakやcontinueは関数抽出で不要になることが多くて出番がすごく少ないんだよ

**デフォルトの名無しさん** · 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でしたとさ