Rust part29

**デフォルトの名無しさん** · 2025/05/03(土) 00:47:30.13

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

ﾜｯﾁｮｲスレ
プログラミング言語 Rust 4【ﾜｯﾁｮｲ】
https://mevius.5ch.net/test/read.cgi/tech/1514107621/

**デフォルトの名無しさん** · 2025/05/03(土) 11:28:41.74

この流れは流石に重箱の隅をつつきすぎじゃないの？
Rustのビルダーはオプショナルな動作を指定するパターンでしかないし、これが最適化されないと困る場面もそんなに無い
せいぜい、ヒープを使うデータについてビルダーを消費するか、中身を clone するかを検討するくらいでしょ

コピー動作が問題になるとしたら、例えば数十万とかの要素を持つ配列の for ループ内でビルダーを使う場合が考えられるけど、それならビルダーを1度だけ作ってそれを使いまわせばいいし

「Rustにも他の言語のオプション引数やキーワード引数があると嬉しいよね」という話なら同意だけど、ビルダーのパフォーマンスはそんなに重要な話でないというか

**デフォルトの名無しさん** · 2025/05/03(土) 11:29:53.96

ストローマン論法

**デフォルトの名無しさん** · 2025/05/03(土) 11:53:45.69

匿名の藁人形は作れない
作れるのは名指しできる個人や団体だけ
だから実名のSNSは嫌なんだよね

**デフォルトの名無しさん** · 2025/05/03(土) 12:04:07.72

>>10
一理ある

**デフォルトの名無しさん** · 2025/05/03(土) 12:39:00.21

RustやC++のゼロオーバーヘッドが意味するところは結局「俺達のコードがどのように処理系によって最適化されるかを俺達は知っている」ということであって、
どのような最適化がなされるかについて一定の透明性があり結果が自明であることが重要
その点で、コピーの最適化を前提にするってのはかなり微妙

**デフォルトの名無しさん** · 2025/05/03(土) 13:47:12.37

「かいたとおりにうごく」が最適化では成り立たないからなぁ

**デフォルトの名無しさん** · 2025/05/03(土) 13:55:18.67

昔ある言語でcontinueがないぞと散々言われて、gotoが実装されたことがあった
何もしないのと比較すればcontinueの提案は優れていたかもしれないが
それは比較対象との相性が良かっただけ

**デフォルトの名無しさん** · 2025/05/03(土) 14:13:59.39

数年前に読んだ書籍にcontinueは使うべきでないと書かれていて驚いた

**デフォルトの名無しさん** · 2025/05/03(土) 14:41:11.34

>>10
安易に clone すべきでないのは所有権管理の話で、実行コストの話とはレイヤが違う。

**デフォルトの名無しさん** · 2025/05/03(土) 18:56:47.80

スマホとPCの作業を効率化したい--「Copilot Vision」の便利な8つの活用例
2025-05-03 07:00
https://japan.zdnet.com/article/35232549/

1 プログらまーまこれを改造してるので上記以外の状態でも使用できるようにしている

2 すでにプログラムがあるので１～コードを作成する必要が無い

ボイス・トォ・スカルの本態が一般パソコンにまで来たのでつい買い捨てができるようになった
マネーロンダリング談合インサイダーなどがはかどるといわれる

**デフォルトの名無しさん** · 2025/05/03(土) 23:51:30.72

>>3
それらは最適化ですべて消えて最終的な初期化構造体のみになった
イテレータメソッドチェーンなどの時と同じ原理
それはもっと極端で各イテレータ毎にいくつ構造体があろうと縮約したりレジスタ化されたりして各構造体は消えていく

**デフォルトの名無しさん** · 2025/05/04(日) 01:14:00.32

複オジ脳やべぇな
視野が狭すぎる

**デフォルトの名無しさん** · 2025/05/04(日) 09:21:09.35

>>19
cloneして意図通りに動作しなくなるならそりゃ普通にcloneの実装もしくは利用者側のバグだろ。作法の問題ではない。
そんな中身を理解しないままコピペしてるバカみたいな低次元のことは誰も問題にしていないでしょ。

**デフォルトの名無しさん** · 2025/05/04(日) 09:55:20.90

>>10
区別できないバカなのか？
ムーブの時などを含めて実態がコピーになるといってもコピー元は二度と使われないのだから最適化できる

一方でclone()などはコピー元をその後も使うためにコピーしている
コピー元を二度と使わないならclone()の必要がない
そしてコピー元をその後も使うから最適化の前提さえ成立しない

**デフォルトの名無しさん** · 2025/05/04(日) 11:20:50.74

それは少なくともbuilderの最適化の文脈においては明確に誤り
実際、derive_builderはcloneが最適化されることに依存している

**デフォルトの名無しさん** · 2025/05/04(日) 12:05:36.94

RustやC++のムーブも同じで一次的にはコピーをして元を使わないため最適化できる場合が多い
一方でプログラマがコピーやクローンを明示的にした場合は元が生きていて全く異なる
そもそも元も後で使いたいからコピーしているわけだ
だからムーブとは異なり最適化でコピーが消えることはない
もちろん後で使いたい場合はコピーして渡すのではなく参照を渡すのが正解だ
したがってプログラマはコピーを可能な限り避けるべきである
暗黙のコピーが行われるプログラミング言語では意識せずコピーしてしまう
プログラムを見ただけですぐにコピーしてあることがわかる方が望ましい
RustではCopyトレイト実装した型のみ暗黙のコピーが起きる
前述のように数値などはその方が有利なので最初からCopy実装されている
ヒープを用いない型ならばプログラマは自由にCopy実装できるがコード上でそれが明示され読む側は気付ける
サイズが大きく参照で扱った方がよい型をCopy実装していればおかしいことがわかる
一方でヒープを用いていればCopy実装はできないがClone実装はできる
これはコード上でfoo.clone()とコピーすることを明示的に記述する必要がある
したがって参照を使えばよいのに無駄なコピーをしていればすぐにわかる

**デフォルトの名無しさん** · 2025/05/04(日) 13:33:55.47

無駄をなくそうとしたらコンパイルが通らなくなった
っていう質問を処理するコストが高いよね
実行時のコストではなく

**デフォルトの名無しさん** · 2025/05/04(日) 13:35:26.53

読む気が失せる分だけど読んだ
ところが間違ってるというか言い過ぎだと思う

**デフォルトの名無しさん** · 2025/05/04(日) 13:38:00.38

クソデカ長文とかどこでも現れる辺りRustとRubyって似てるなーと思った次第である

**デフォルトの名無しさん** · 2025/05/04(日) 13:41:35.32

この程度で長文扱いって普段どれだけ文章を読まないんだよ。

**デフォルトの名無しさん** · 2025/05/04(日) 13:43:24.90

暗黙のコピーが行われるプログラミング言語は大体値のコピーを行っている
値はこの場合参照なのでコストは限りなく低い

暗黙でポインターをコピーしてそれがコストが掛かると言う人はいないだろ

**デフォルトの名無しさん** · 2025/05/04(日) 13:44:23.89

>>30
読む気が失せるのは文章が下手くそだからであって長いことは関係ない
そしてボロボロと誤りと言うか独断に基づいた誤りがたくさん入っている

**デフォルトの名無しさん** · 2025/05/04(日) 13:47:16.56

複おじはAIに下書きを食わせて推敲してもらうべきだと思う

**デフォルトの名無しさん** · 2025/05/04(日) 13:53:19.75

むしろAIに生成させてるんじゃないかと思われる
同じことを何度も何度もダラダラ箇条書きに
眠くなるわ

**デフォルトの名無しさん** · 2025/05/04(日) 13:57:45.80

見たい所だけ切り取ればいいんだよ
切り取りや編集の責任をトリクルダウンするために、書く側は編集をしないという戦術だろうけど
それはどうでもいい

**デフォルトの名無しさん** · 2025/05/04(日) 13:59:33.25

AIではないよ
小論文など書くときに指摘されるけど、考えをまとめないでずらずらと続く文章は修正しろと言われる

一部の行頭だけ切りだすと以下のように前の文章とつなげて書いてるから読み手にはわかりにくい
↓これが連続して使われているので読み手への負担になっている

一方で
そもそも
だから
もちろん
したがって

**デフォルトの名無しさん** · 2025/05/04(日) 14:05:10.05

人間の脳もスタック状になってるんでドンドン文が接続されていくと脳内にスタックが作られてスタックがチェーンして肥大化して理解が苦しくなる
これは当たり前

**デフォルトの名無しさん** · 2025/05/04(日) 14:21:14.87

文章がダラダラと接続されているものは、まともに推敲されていないので、基本的に読むコストに比べて得られるものが少ない
雰囲気で書かれているので間にも間違いや矛盾が含まれている

読み手に対して読みやすさが考慮されていないのでふつーに読まなくても良い

**デフォルトの名無しさん** · 2025/05/04(日) 14:36:43.37

ここでようやくchatGPTに聞いてみた

✅ 読みにくさの主な原因

1.接続詞やつなぎ言葉の多用による文の長文化

「一方で」「だから」「そもそも」「もちろん」「したがって」などの論理接続語が多く使われ、それぞれの文が長くなりがちです。
　
結果として、読者は一文ごとの意味の切れ目を捉えづらくなります。

2.
文構造が複雑で、主語と述語の対応が曖昧

「コピーして渡すのではなく参照を渡すのが正解だ」のように、主語が省略されていて読み手が文脈を補う必要があります。

3.抽象的な話が続き、具体例や対比が乏しい

例えば「ムーブはコピーと違う」と言いつつ、具体的にどう違うのかの明示がないため、読者が前提知識を持っていないと理解しにくいです。

4.
視点の切り替えが頻繁

ムーブとコピー、CopyとClone、参照と値渡しなど、話題が細かく切り替わっているが、その都度明確な導入がないため混乱を招きます。

**デフォルトの名無しさん** · 2025/05/04(日) 14:42:19.99

もっと詳しく書け、とAIが言っている
みんなAIに騙されてる

**デフォルトの名無しさん** · 2025/05/04(日) 14:51:46.05

さっき書いた部分は連続で接続されている

A 一方で　B　=　C（文意）
C　そもそも　D = E（文意）
E だから　F　= G（文意）
略
Y　したがって　Z

Zを理解するためにAから後を状態や文意を含めて全部覚えておかないといけない

読み手を疲弊させるには接続を多用したらいいとも言える

**デフォルトの名無しさん** · 2025/05/04(日) 15:48:20.78

みんな読みやすい文を書いて良い大学、良い企業に入りたいとか
読みやすい文を書いて本を出版して売りたいとか
金の為に文を書いているからな
文なんて記号に過ぎない意味が伝わればいいのよ

**デフォルトの名無しさん** · 2025/05/04(日) 15:53:36.21

意味が伝わればいいとか言ってるやつが書いた文章はたいてい伝わってねーから。
プロが推敲したってきちんと伝えるのは難しいのにそれ以下の質ならそれ以下にしか伝わらないよ。

**デフォルトの名無しさん** · 2025/05/04(日) 16:11:44.87

国語の天才が推敲すると数学も理科も社会も意味がわかるようになるなら
学校で国語だけ教えてればいいだけだろボケ

**デフォルトの名無しさん** · 2025/05/04(日) 16:24:07.39

確率扁微分方程式を国語で説明してくれ

三行でよろぴく

**デフォルトの名無しさん** · 2025/05/04(日) 16:27:43.19

教
科
書読め

**デフォルトの名無しさん** · 2025/05/04(日) 16:34:02.19

もちろんでNGしとけ

**デフォルトの名無しさん** · 2025/05/04(日) 16:43:31.57

AIにコードを生成させるならもうRustはいらない子だよね

**デフォルトの名無しさん** · 2025/05/04(日) 17:06:18.99

>>48
こういうのはビッグウェーブに乗る力であって国語力ではないね

**デフォルトの名無しさん** · 2025/05/04(日) 17:29:04.69

他人に自分の主張を理解してもらいたいなら、少なくともわかりやすく書く必要がある

いつも例の人の文章を読んでると念仏を聞いてるような気分になる
誰かが眠くなると書いてたけど自分もその印象が強い

言葉を吐くマシーンの様で理解してもらおうなどと思ってないんだろうなと

**デフォルトの名無しさん** · 2025/05/04(日) 18:03:43.43

理解されるためならなんでもしますという意志はたいして重要ではない気がする
なんでもするって言わせたい人にとって重要なだけだろう

**デフォルトの名無しさん** · 2025/05/04(日) 18:15:26.35

文章の読みやすさを意識しないプログラマのコード品質って大丈夫なのか？

**デフォルトの名無しさん** · 2025/05/04(日) 18:50:12.49

理解されないなら主張としては存在しないのと変わらない
公共の場にただのデカいゴミがあってみんな邪魔だなって思うだけ

**デフォルトの名無しさん** · 2025/05/04(日) 19:37:09.88

derive_builderのドキュメント見てみた
Rustはこれらのclone呼び出しも最適化して賢いと書かれている

https://docs.rs/derive_builder/latest/derive_builder/#-performance-considerations

Performance Considerations

Luckily Rust is clever enough to optimize these clone-calls away in release builds for your every-day use cases. Thats quite a safe bet - we checked this for you. ;-) Switching to consuming signatures (=self) is unlikely to give you any performance gain, but very likely to restrict your API for non-chained use cases.

**デフォルトの名無しさん** · 2025/05/04(日) 20:04:32.38

derive_builderはRustのセマンティクス的には割と非効率な実装を採用していて、
常に一度のbuildだけの使い捨てに特化したバージョンも提供するなど制約を強めることで更にセマンティクス上効率的な実装もありうる
でもそうしないのは実際最適化で変わんなくなるんだろう
コンパイラの解析に委ねる前にセマンティクス上の最適を目指すのがRustの大きなコンセプトだと個人的には思っているが、その観点ではあまり理想的とは言えないやり方だし、
Rustの言語側にも改善の余地があるかもしれない

**デフォルトの名無しさん** · 2025/05/04(日) 20:20:39.66

#[builder(pattern = "owned")]だと使い捨てになるんでしょ
こっちをデフォルトにした方がいい気もするけど１回しかbuildしない場合は最適化されて同じになるらしい

**デフォルトの名無しさん** · 2025/05/04(日) 20:38:30.13

さらに限定したケースでRustコードの段階で最適化できる可能性もあるかもしれない
この初期化ビルダーがプログラム全体のネックになる時が来たらチャレンジするかな

現実には誤差の範囲内なのでこのderive_builder利用で十分と思う
初期化関数を自分で用意せずとも構造体への属性修飾だけでよい利便性は他のプログラミング言語と比べてもベスト

**デフォルトの名無しさん** · 2025/05/04(日) 21:23:32.91

でもビルダーパターンは潜在的にバグ発生の要因をはらんでいる

**デフォルトの名無しさん** · 2025/05/04(日) 21:31:29.80

>>58
あらゆるパターンが潜在的にバグ発生の要因をはらんでいるから意味のない発言
具体的にderive_builderでバグ発生の要因があるなら指摘して

**デフォルトの名無しさん** · 2025/05/04(日) 21:32:02.50

IDEのサポートを受けた元で初期化関数を使うのがベスト
単純にビルダーパターンで起こる記述漏れ、順序の間違い、重複指定バグが減る

**デフォルトの名無しさん** · 2025/05/04(日) 21:33:14.08

>>59
前スレで書いたけど複おじは反論不能だったみたいでスルーしてたな
複おじ論破されて草だった

**デフォルトの名無しさん** · 2025/05/04(日) 21:36:49.89

>>60
手動で初期化関数を作るのは面倒かつバグの入る余地もあり劣ってる
derive_builderは利便性も良いからこれより優れているものを持ってこないと話にならないかと

**デフォルトの名無しさん** · 2025/05/04(日) 21:39:37.45

>>61
「おじ」使いのキチガイの人かよ
具体的にderive_builderでバグ発生の要因があるなら指摘しなさい

**デフォルトの名無しさん** · 2025/05/04(日) 21:39:44.02

>>62
そんなもんテストでわかるでしょう

テストしないところでビルダーパターンはバグを起こす可能性が高い
人間がビルダーパターンのメソッドに注視して思考してパラメーターを指定する場合は問題が比較的起こりにくい
それをコピペや思い込みで書くとヒューマンエラーが入り込む余地がある

ビルダーパターンで複数行でメソッドを記述した場合には列レベルで記述が抜けることが考えられる
行で記述しても対応ミスなどが起こる

複おじは問題点をわざと見ないふりをしている

**デフォルトの名無しさん** · 2025/05/04(日) 21:40:04.11

>>63
前スレ見ろ
おじいちゃん

**デフォルトの名無しさん** · 2025/05/04(日) 21:45:21.35

>>64
わざわざ手動で初期化関数を作ってテストするってか
面倒なだけでメリットが全くない
利便性も良いderive_builderより優れているものを持って来なされ

**デフォルトの名無しさん** · 2025/05/04(日) 21:46:26.28

>>66
前スレで問題点を指摘されて論破されて何もできないで誤魔化してるんでしょ
みっともない

**デフォルトの名無しさん** · 2025/05/04(日) 21:49:41.13

>>67
誤魔化してるのは君だ
derive_builderに問題点があるなら指摘しなされ
derive_builderよりも利便性の高い方法があるなら持ってきなされ

**デフォルトの名無しさん** · 2025/05/04(日) 21:52:48.22

>>68
ストローマン論法だな

自分の主な主張はで前スレで書いたようにビルダーパターンは複雑なオブジェクト生成で使われるべきで
普通のオブジェクト生成ではコンストラクタなどの初期化関数を使うべきと言うもの

理由はビルダーパターンはヒューマンエラーが入り込む余地が非常に大きいから
初期化関数はIDEの補助があるのでビルダーパターンで起こる問題が発生しにくいか発生しない

**デフォルトの名無しさん** · 2025/05/04(日) 21:56:47.92

それにしても「～しなされ」って言われたのは人生で初じゃないかな

ガチおじいちゃんじゃん　複おじいちゃん

**デフォルトの名無しさん** · 2025/05/04(日) 22:01:03.15

>>69
詭弁はよろしくない
derive_builderは自分で初期化関数を書く必要がない
他の方法では初期化関数を書く必要がありヒューマンエラーが入り込む余地があるのはその通りだ
利便性も良くてその問題が生じないderive_builderが優れている

**デフォルトの名無しさん** · 2025/05/04(日) 22:02:35.26

>>71
ストローマン論法だな

こちらの主張していない内容を勝手に作り出してそれで話を続けている

**デフォルトの名無しさん** · 2025/05/04(日) 22:08:16.17

初期化関数はビルダーパターンのメソッドの適用ミスで容易に起こりうる　重複、順序ミス、記述漏れに対して有用
初期化関数自体は一回書くだけ

各所で必要になる単純なオブジェク生成の場面ではビルダーパターンはヒューマンエラーが入り込む恐れがある
それを初期化関数で行えばIDEの補助を得られるのでミスが減る

**デフォルトの名無しさん** · 2025/05/04(日) 22:21:31.66

>>73
先ほどから主張しているderive_builderを使わなければIDEの補助が得られるからミスが減るの意味がわからない
derive_builderを使えば初期化関数の用意はお任せなので提供側のミスはない
利用側はデフォルト値以外の値指定をしたい時にそのメソッド候補がIDEなどで補助があるのでミスが起きようがない
derive_builderを使った方が提供側も利用側もよいのではないか

**デフォルトの名無しさん** · 2025/05/04(日) 22:24:30.81

まだバグを起こす前の時期に、バグを起こしやすい習慣をやめない、まつもとなかいがいたとする
その時点で彼らをどのように処分したいのかね

**デフォルトの名無しさん** · 2025/05/04(日) 22:33:13.89

>>74
ストローマン論法をやめなされ

初期化関数を使うと指定の重複、順序ミス、記述漏れが起こりにくいのは事実だろう
まず単純な初期化関数で指定の重複が起こるのか？
func( a,b,c,d....にたいしてaを重複指定させられるのか？
これすら判らないなら話すだけ無駄

**デフォルトの名無しさん** · 2025/05/04(日) 22:35:21.33

「～しなされ」っていうのって少なくとも80歳以上じゃないかと

**デフォルトの名無しさん** · 2025/05/04(日) 22:42:41.94

>>76
derive_builderで提供された場合も問題は起きないよね
仮にそのaを重複指定してしまい
.a(123)
.a(123)
と書いてもバグは起きない
可読性もよいからそれ自体を起こさないね

derive_builderは提供側も利用側もデメリットがなく最も良い方法にみえる
もっと良い方がある？

**デフォルトの名無しさん** · 2025/05/04(日) 22:44:40.17

>>78
.a(123)
.a(321)

で始めの123が正しい場合問題になる

**デフォルトの名無しさん** · 2025/05/04(日) 22:50:43.73

>>79
aを123で初期化したいなら前者しか起きようがない
aを321で初期化したいなら後者しか起きようがない
そんなナンセンスな指摘しかデメリットらしきものを見つけることが出来なかったということは
derive_builderが最も良い方法であることを認めたと理解してよろしいか

**デフォルトの名無しさん** · 2025/05/04(日) 22:50:51.74

the bookによるとnewtypeパターンってのがあって
traitをimplすることが目的みたいだけど
どうにかすれば名前つき引数にも使えそうなんだよね

**デフォルトの名無しさん** · 2025/05/04(日) 22:51:05.55

順序ミスについて
これは前スレでも書いたのを再掲

.G(p[0]).R(p[1]).B(p[2]).build()
のところを容易に
.R(p[0]).G(p[1]).B(p[2]).build()と間違えて
さらに
.R(p[0]).R(p[1]).B(p[2]).build()と間違える

色指定でよく目にするのはRGB方式だけどコンピュータービジョンなどではBRGがよく使われる
最初にGRBとして覚えていても実際各段階になるとRGBと混同することがある

初期化関数では
func(P[0],P[1],P[2],...
等で考えなくても書き間違える可能性が低い　それにIDEの補助でパラメーターについてポップアップが出るのでそれでも間違いは減る
バグに気が付いて書き直す際に2か所の書き換えをしないで
.R(p[0]).R(p[1]).B(p[2]).build()　と言う間違いも入り込みやすい

**デフォルトの名無しさん** · 2025/05/04(日) 22:53:00.11

書いてるそばから間違えている
BGRが正しい

**デフォルトの名無しさん** · 2025/05/04(日) 22:55:04.07

>>80　の疑問については
>>82　で書いたようなミスで重複と記述漏れが発生する

そういうところまで考えたことないだろ？コーディングしてる？

**デフォルトの名無しさん** · 2025/05/04(日) 22:57:59.52

>>82
その比較はおかしい
デフォルト値以外のみを指定して初期化する話なのだから
それは✕　func(P[0], P[1], P[2],...
これが○　func(R=P[0], G=P[1], B=P[2], ...

**デフォルトの名無しさん** · 2025/05/04(日) 23:00:32.68

記述漏れについては
n個パラメーターを指定しないといけないのにn-1個しか記述していない場合
目で見てn個すべて指定したのかn-1個指定したのかなんて数が多くなると判らない

これは初期化関数では基本的に起こらない
数が多いとやはり大変だけどIDEの補助があったりコンパイル時にエラーがでる

ビルダーパターンでは実行時エラーや思った挙動にならない時点でしかミスに気が付かない

**デフォルトの名無しさん** · 2025/05/04(日) 23:01:35.79

>>85
誰もそんな縛りは指定していない
普通に初期化関数使えばよい

**デフォルトの名無しさん** · 2025/05/04(日) 23:05:28.74

これ以降ストローマン論法禁止

**デフォルトの名無しさん** · 2025/05/04(日) 23:05:37.33

オプション値の初期化の話だもんな
必須値の初期化の話ならRustでも
fn foo(red: Type, green: Type, blue: Type)
とするだけなのでderive_builderは使わない
だから>>82の指摘は間違ってる

**デフォルトの名無しさん** · 2025/05/04(日) 23:09:07.67

>>89
それはお爺さんにもわかりやすいように簡易化して書いているからだろ

ビルダーパターンは上にあげたようなヒューマンエラーを誘発する仕組みなので基本的に使わない方が良い

**デフォルトの名無しさん** · 2025/05/04(日) 23:11:26.83

生成に柔軟性があり複雑な場合にはビルダーパターンを適用するのは良い
一般的なオブジェクト生成に対してはヒューマンエラーに弱くアンチパターン

**デフォルトの名無しさん** · 2025/05/04(日) 23:13:07.88

>>87
プログラミングの基本的なことを理解していないのかい？
derive_builderを使うようなオプションで必要な項目だけ値を指定して初期化するケースを1つの初期化関数を単体で済ませようとすると
どんなプログラミング言語でもキーワード付きオプション引数を使うことになる
具体的にはf(1, 2, 3, option1=111, option5=222)などの指定方式になる
option5など名前を指定しないとどの項目を指定しているのか区別がつかないためだ

**デフォルトの名無しさん** · 2025/05/04(日) 23:15:31.49

>>92
その指定だとしても重複は大体の言語ではエラーになる
ビルダーパターンは重複を検知しないのでヒューマンエラーが入り込む

**デフォルトの名無しさん** · 2025/05/04(日) 23:20:45.80

>>91
オプション初期化のない一般的なオブジェクト生成でderive_builderを使う人はそりゃいないよ
それは普通にRustでも引数固定の初期化関数でおしまい

前スレを読んだけど最初から特定項目だけオプション初期化する話
だからderive_builderが最も優れているという結論になってる

**デフォルトの名無しさん** · 2025/05/04(日) 23:21:18.11

>>94
重複すら検知できないのに？

**デフォルトの名無しさん** · 2025/05/04(日) 23:26:47.62

重複を検知するには内部にフラグを持たなくてはならない
もちろんこれは実行時エラーになる

**デフォルトの名無しさん** · 2025/05/04(日) 23:30:18.53

実行時エラーを検出するにはテストで網羅しなくてはならない

**デフォルトの名無しさん** · 2025/05/04(日) 23:40:27.55

我々はコンパイル時にエラーが検出されるのを利点としてRustを使っている
それなのに実行時エラーに頼らざるを得ないビルダーパターンは劣っている

**デフォルトの名無しさん** · 2025/05/04(日) 23:45:58.01

結局、話をまとめると
ビルダーパターンで
foo()
　.item1(value1)
　.item3(value3)
　.item7(value7)
と書くか

名前付きオプション引数で
foo(
　item1=value1,
　item3=value3,
　item7=value7,
)
と書くか

これだけの違いだよな
どちらも変わらん慣れだけの問題
どちらも見た通りなので指定ミスや重複ミスなど起きようがない

あとはそれらを提供するライブラリ側だ
いずれも普通は初期化関数を自分で書かなければならない
Rustでderive_builderを使えば構造体に属性を付けるだけで済みシンプルかつミスも起きない
少なくとも現状でderive_builderに欠点は見つかっておらず最善な方法であるといえる

**デフォルトの名無しさん** · 2025/05/04(日) 23:55:20.08

>>99
結局何も見なかった利かなかったふりして自分のいいように矮小化し続けてるな
呆れるよ
80代になると何も感じなくなるのだろうか

**デフォルトの名無しさん** · 2025/05/04(日) 23:58:47.69

的外れな言いがかりでスレを荒らしてる人は
derive_builderより良い方法を具体的にコードで示せ

**デフォルトの名無しさん** · 2025/05/04(日) 23:59:41.54

精神論で間違いは発生しないと言うのは容易
間違えたら間違えた人間が悪いと言う

ビルダーパターンには結局ヒューマンエラーを防ぐように十分な対策がなされていないだろ
わかっていながら無視をする
c++精神だね

**デフォルトの名無しさん** · 2025/05/05(月) 00:00:40.76

>>101
ファクトリーパターンなどを使えばよい
メソッドの種類を充実させるだけだ

**デフォルトの名無しさん** · 2025/05/05(月) 00:03:11.76

ビルダーパターンはヒューマンエラーに弱い
毎回論理的構造を構築しなければならないがそこにバグが紛れ込む可能性がある

それよりも初期化のための関数を作るべき

**デフォルトの名無しさん** · 2025/05/05(月) 00:03:28.63

derive_builderは全自動だからミス起きなくね？
derive_builderより好いのがあるならコードを出して

**デフォルトの名無しさん** · 2025/05/05(月) 00:05:02.99

おじいちゃんは乱心して同じことを何度も書いて来る
普通の人間にはすでに書かれた内容で理解出来るのに知らないふりして実行時エラーやバグを許容している

**デフォルトの名無しさん** · 2025/05/05(月) 00:06:42.46

これも相手の疲労を狙ってくるくだらないやり口なんだろうと思うが

**デフォルトの名無しさん** · 2025/05/05(月) 00:07:25.49

>>104
そんな方法は存在しないよ
>>99が挙げてる二つの方法しかない
もしあるなら同様のコード例を示そう

**デフォルトの名無しさん** · 2025/05/05(月) 00:08:38.62

他のスレでもでもおじいちゃん的書き込みを見ることがある
それに対して80代ではと書くと100%反論される

今回は反論されないところを見るとやはり80代以上なんだろうなと

**デフォルトの名無しさん** · 2025/05/05(月) 00:09:40.80

>>108
＞　それよりも初期化のための関数を作るべき
これが全てだろう？
いくら何でも馬鹿すぎるだろう？判らないの？