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/10(金) 19:05:14.63

>>508
唐突に発狂されても意味不明
反論があるなら技術的な話でお願いします

**デフォルトの名無しさん** · 2023/02/10(金) 19:06:54.13

>>520
関数みたいなブロックを作ればいいんじゃない？
あるいはブロックみたいな関数とか。

**デフォルトの名無しさん** · 2023/02/10(金) 19:07:09.08

>>520
関数みたいなブロックを作ればいいんじゃない？
あるいはブロックみたいな関数とか。

**デフォルトの名無しさん** · 2023/02/10(金) 19:24:57.65

>>520
Rustには何年も前からラベル付breakがあります
今さら文句をつけている人はRustを知らずイチャモンを付けたいだけだとバレていますよ

メジャーなプログラミング言語の大半がラベル付breakを備えています
JavaでもSwiftにもGoもJavaScriptすらラベル付breakを持っています
プログラミングにおいて必須の機能だからです

逆にラベル付breakを持っていない代表的な言語がC/C++です
今回のRust叩きをしている犯人はいつもと同じ人だと分かります

**デフォルトの名無しさん** · 2023/02/10(金) 19:52:12.29

breakに対してジャンプだとかgotoだとかトンデモ発言が出ていたのはそういうことか
C/C++しか知らないと多重ループすらgotoで抜けるしかないもんな
そういう貧弱な世界しか知らない視野の狭い人だから必死にRustを叩いていたわけか

**デフォルトの名無しさん** · 2023/02/10(金) 21:33:52.77

前から常駐してるアンチRustのやつだろ
ばればれだがアンチとばれないように装いつつRustの色んな点を批判してきた
特にRustならではの機能とか新たな機能とかRustらしい書き方とかを嫌う

**デフォルトの名無しさん** · 2023/02/10(金) 22:57:01.58

同じことしか言わないから自演丸分かりやんww

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

>>524
大半の言語が備えてるラベル付breakはループから抜けるものでブロックから抜けるものじゃないぞ

**デフォルトの名無しさん** · 2023/02/10(金) 23:14:34.63

swiftがdo statementでブロックスコープから抜ける機能を用意してるがtry/catchなしの形では誰も使ってない

**デフォルトの名無しさん** · 2023/02/10(金) 23:16:17.28

そんなことよりさっさとif let Some(c) = chars.next(); c.is_whitespace() {とかって書けるようになってほしい

**デフォルトの名無しさん** · 2023/02/10(金) 23:22:50.62

ブロックは「必ず1回で終了するループ」と解釈可能なのでループからのラベル指定breakがあるならブロックからもbreakで抜けられる方が自然

**デフォルトの名無しさん** · 2023/02/10(金) 23:24:33.98

Javaも文法的にはループ以外でもラベル付きブレイク使えるけど絶対使わないな

**デフォルトの名無しさん** · 2023/02/10(金) 23:32:27.37

>>531
その理屈でいけばラベルなしブロックからもbreakで抜けられないとおかしくない？

**デフォルトの名無しさん** · 2023/02/10(金) 23:37:03.68

RFCの例を4パターンで書いてみたけどラベル付きbreakは無いな
1か2のパターンに収まる形にリファクタリングする
大半の人がラベル付きbreakを選びたくなるようなサンプルはないのかな？

1. 関数化
2. Optionコンビネータ
3. クロージャ
4. ラベル付きbreak

https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=e365b15243be65f5fc2d09a94324317e

**デフォルトの名無しさん** · 2023/02/10(金) 23:46:57.14

流れと一切関係ないけど
rubyは一時期tapとbreakで値を返す文化？あったな
foo.tap {|x| bar} // selfつまりfooを返す
foo.tap {|x| break bar} // breakでbarを返す
foo.then {|x| bar} // ブロックの結果つまりbarを返す。今はthen使うのが素直。

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

>>530
セミコロンじゃなくて&&だよね
stableになるのは半年後くらいじゃない

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

>>534
再利用しない前提ならクロージャを変数に束縛してしまえば3.も視野に入ると思うんだ
https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=3159733485aa1a7ee3a1838637a3a097

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

異なる種類のエラーを返す関数が絡んできたとき、ラベル指定breakのみエラーの合成を?演算子で関数境界に押し込められる
関数やクロージャだと「ブロック内のエラーを合成した型」を明示的に取り扱うことになって二度手間

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

>>535
tapでbreakなんて初めて知ったわ
イテレータのメソッドチェーンの途中経過を出力する時にしか使ったことなかった

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

>>537
これは同意

>>538
サンプルコード書いてみてよ

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

すまんがRustlingsでまたちょっと教えてほしいんだけどさ
これ↓のListing 8-8の&mutって、一体どういう意味があるの？？？
https://doc.rust-lang.org/book/ch08-01-vectors.html
Rustlingsをやっていて、似たような場面で&mutなしでも動いちゃうように見えるけど・・・・状況が似て非なるものなんだろか・・・・・
https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=b4a253142ce1e394ba13bb0c2fc58f11

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

>>541
詳細はトレイトとか Deref とか IntoIterator とか関連型とかその章ではまだ出て来てない概念が色々絡むが

for item in v の v に対して
Vec<T> を渡したら item はＴになって所有権ごと持ってく
&Vec<T> を渡したら item は &T になって不変参照のイテレーションになる
&mut Vec<T> を渡したら item は &mut T になって可変参照のイテレーションになる

Vec<T>は DerefMut<Target=[T]> を実装しているから &mut Vec<T> は暗黙のうちに deref_mut のメソッドを通して &mut [T] に変換されて
その &mut [T] が IntoIterator<Item=&mut T> を実装しているからfor文で &mut T のイテレーションができる

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

>>534
その程度ならば型宣言で冗長になる関数化をするまでもないからブロック式でも十分かな
使い分けできるようにブロック式の不備を整備したRustの方針は正しいと思うよ

>>541
所有権を渡すのは消費尽くすときだけでその後も使いたい時は参照&か可変参照&mutを渡す
そのコードのv.iter_mut()の方に見かけ上&mutが見当たらないのはメソッド定義にそれがあるから
メソッドでは所有権を渡すか参照を渡すか可変参照を渡すかをその定義でselfか&selfか&mut selfか指定することでメソッド使用時に毎回指定しなくて済むようになっている

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

>>541
vがVec<T>の場合
for i in &mut v {…} と
for i in v.iter_mut() {…} は同じ

前者は&mut Vec<T>のIntoIteratorトレイトのinto_iter()が呼ばれる
その中身はself.iter_mut()なので後者と同じになる

for loopはiterable(IntoIteratorを実装してるもの)を受け取って
そのinto_iter()を呼び出してからイテレートする仕組み
https://doc.rust-lang.org/std/iter/index.html#for-loops-and-intoiterator

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

>>542
>&mut Vec<T> は暗黙のうちに deref_mut のメソッドを通して &mut [T] に変換されて

細かいけどここちょっと気になった
for loopに渡されたタイミングでDeref Coercionが発生するんじゃなくて
まず最初に渡された値の型でIntoIterator::into_iterが呼ばれて
その中のself.iter_mutのようなメソッド呼び出し時にVecに該当メソッドがないから
Deref Coercionが発生してslice::iter_mutが呼ばれるという処理順だと思う

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

>>537
処理に名前を与えることがいかに重要かよく分かるいい例だな

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

なるほど
処理名をラベル名として付与するとラベル付ブロックが非常にわかりやすくなった
関数化と異なり無駄な引数宣言と型宣言が不要となり可読性が増した
もちろん関数化した方が適してる場合もあるだろうから上手く使い分けると良さそう

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

さすが汚コーダー！
可読性や保守性になんて目もくれない！
保守なんてやらないもの！

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

>>516
それな!(Noneでこんな感じにしちゃったんだろう、コール側がこうである必然性があまりない);

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

1回しか使わない小さな関数in関数は関数名付きブロックで十分やね

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

外側の関数で既に変数定義してるのに、再び内側の関数の引数で宣言するのが二度手間だったから、ブロック化いいかも。
特に参照している変数が多いと連れ回しと、型宣言が大変だった。

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

オジループw

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

IIFEとかいう💩よりはラベル指定ブロックの方がいいのは間違いない

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

色んな有名クレートのソース見てると
let result = (|| {
…
})();
の形も多いね

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

>>552
承認欲求を満たしてあげないとbreakしない
嘘でいいから同意して差し上げろ

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

try_blocksが安定化されればここまでの話全部吹っ飛ぶんだけど
それまでのつなぎでしかないコードでここまで議論を紛糾させる必要なんてないのよ

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

>>556
もちろん代替として今は>>554の形で使ってるよ

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

こんどはそれでラベルbreakでええやんって議論が巻き起こるんでしょ

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

>>558
一部だけ用途は重なるけど互いにできないことがあるからtry blockとlabeled blockは併用になる

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

>>556
try ブロックとラベル指定ブロックて用途違うんじゃね

let result = 'found: {
　for i in 0..100 {
　　if f(i) {
　　　break 'found foo(i)?;
　　}
　}
　bar()?;
};

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

途中送信

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

途中送信
>>560 のケースで
foo(i) が Result<i32, FooError>
bar() が Result<i32, BarError>
を返すとして、ここでFooErrorとBarErrorの合成を考えなくても関数境界にエラー合成を押し付けて、
result の型を i32 にできるのがラベル付きブロック

クロージャとかは?演算子のスコープを作ってしまうので一旦Resultの型を明示しなきゃいけなくて、
FooErrorとBarErrorの合成をロジックの途中に挟むことになってうれしくない

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

bar()?
のセミコロンいらねえわ

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

>>556
それはエラーの早期離脱のためだから、普通の値の早期離脱には使えない。
break可能なブロックは必要でしょう。

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

>>562
従来のif式やmatch式と同様に、tryでないblock式では？を通過してくれるところが嬉しいポイントかな。
一方でtry block式はTry実装のResult型などになってしまい別物。

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

>>560
書き直せばいい
let result = match (0..100).find(f) {
Some(i) => foo(i)?,
None => bar()?,
};

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

>>566
その人じゃないけど
tryとの違いを示してる簡素な例にその反論は意味ない
そして多重forの一般形となるだけでそのやり方は破綻

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

>>567
なんで破綻するのかよくわからない
コードで示してくれ

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

破綻するかどうかは別として
多重forの中で種類の異なるエラーを返すような処理を直接書くことにはすごく疑問を感じるから
本当にそういうやり方が必要な状況があるなら見てみたいね

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

>>566
アスペ

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

単なる多重forショートカットの話だよ
とりあえずエラーや可変長や可変参照問題は抜きにシンプルで
let n = 'calc: {
　for i in 0..100 {
　　if f(i) {
　　　break 'calc ff(i);
　　}
　　for j in 0..100 {
　　　if g(i, j) {
　　　　break 'calc gg(i, j);
　　　}
　　}
　}
　0
};

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

ラベル付きブロック式は特に新しい挙動は導入していない
早期脱出と?のエスカレーションの併用が可能になっただけ

関数:
〇変数、ライフタイムのスコープ
×環境のキャプチャ
〇早期脱出
×?演算子のエスカレーション

クロージャ
〇変数、ライフタイムのスコープ
〇環境のキャプチャ
〇早期脱出
×?演算子のエスカレーション

無名ブロック式:
〇変数、ライフタイムのスコープ
〇環境のキャプチャ
×早期脱出
〇?演算子のエスカレーション

ラベル付きブロック式:
〇変数、ライフタイムのスコープ
〇環境のキャプチャ
〇早期脱出
〇?演算子のエスカレーション

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

>>571
?使わないならクロージャでいいパターンでは？
あとそろそろfやggじゃ抽象的すぎてきついから実戦で使いそうなパターンの例を頼むわ

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

むしろこの用途でクロージャでIIFEする方がラベル指定breakより糞だよ

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

ラベル指定breakについては今更5chでギャオっても無駄
https://internals.rust-lang.org/t/use-iife-not-break-from-labeled-blocks/17684

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

>>573
クロージャ即時実行だとできないこともある

>>575
なるほど
引用

>ラベル付きブレークはループ構造にすでに存在していたため、これは独自の新機能ではなく、既存の機能の一般化でした。
>さらに、クロージャは、ネストして外側のクロージャからブレークしたり、包含関数から戻ったりすることができないため、ラベル付きブレークほど強力ではありません。
>いずれにせよ、この機能は安定しており、削除されることはありません。

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

>>572
ラベル付ブロック式が優秀すぎだな

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

>>571
これ書いててアンチパターンだと感じないの？

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

機能的な差異(できることの違い)を示すためのサンプルコードにアンチパターンがどうのとか一生言ってる奴はこの世のすべてのコードから大域脱出を排除してきて

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

>>578
正しいアルゴリズムをぜひ知りたい
コードを出して

**はちみつ餃子** ◆8X2XSCHEME · 2023/02/12(日) 11:47:23.89

大域脱出自体がアンチパターンではあるが
それでも必要になったときのために比較的マシな方法があったほうがよいというのは両立する話なんだよな。

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

短絡評価の&&と||がResultやOptionで使えるようになればtryブロックはともかくlabeled breakは使われなくなるよ

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

短絡でブロック式がすべて死滅するとは思えないからラベル指定breakも死滅しないだろうな
ブロック式が途中で抜けられるようになっただけなんだし、ブロック式書いてて途中で式の値を確定したくなったらラベル指定breakの出番

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

>>582
それらを使えると>>571の例はどんな風に書き換えられるの？

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

50行や100行を超えるような関数を書いても何も感じない流派の人と
10行以下でもリファクタリングの要否を検討するような流派の人とでは
審美眼というか根本的な価値観が違うから
お互いスタンスの違いを認識しないと話が噛み合わないよ

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

数ヵ月前にstabledに入ってる機能とRFCすらマージされてないプロポーザルを比較するのって
捕らぬ狸の皮算用って奴じゃないですかね

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

>>581
例えば>>571って大域脱出なのか？
無駄なループを回らないために早期離脱しているだけに見える
それがアンチパターンだと主張するならばどうやって無駄なループを回避するんだ？

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

>>580
let ij = (0..100)
.cartesian_product(-1..100)
.find(|&(i, j)| if j == -1 { f(i) } else { g(i, j) });
match ij {
Some((i, -1)) => ff(i),
Some((i, j)) => gg(i, j),
_ => 0,
}

結局やってることはfindして結果に関数適用してるだけだよね

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

>>588
>>571 の方が遥かにマシで草

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

>>588
それ動くけど
イテレータをi依存にされたり
判定方法を変えられたらすぐに破綻しちゃうな
さらに可読性がない上に保守性もない
そのコードは失格

**デフォルトの名無しさん** · 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
代替策を示さずにアンチパターンだと主張するのをそろそろ辞めにしようぜ
まずは代わりのコードを示すべきだ