Rust part29

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

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

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

Builderはオプションの追加実装が破壊的な変更にならないメリットがあるな
生成関数に全部渡す方式だとパラメータが増えて破壊的になる
新しい生成関数を追加すれば破壊的にはならないけど
オプション追加する度に生成関数増やすのはあほくさい

>>103
もし暇だったら↓のRegexBuilderをFactoryで実装する場合の関数の個数を見積もってくれ
https://docs.rs/regex/latest/regex/struct.RegexBuilder.html

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

>>110
今回のようなケースで初期化のための関数は>>99が挙げてる二つの方法しかない
もし他に存在するなら同様のコード例を示そう

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

なんで自分にレスしてんの？

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

>>111
他の言語でもRegexは普通にメソッドを使って解決してるけど…
長いならregexoption構造体作って指定したらよいだろう？他ではそうしてる物もある

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

Rustしか使ったことがない前提なのかな

さすがに馬鹿の相手をするのは疲れてきた…

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

おじいちゃんは他の言語は使えないの？しょうもない雑魚レベルの質問しかしないのはなんで？

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

デフォルト値に対して必要分だけオプション指定したい場合
まともな方法はどのプログラミング言語を使って>>99のどちらかの方式になる
まともではない方法としてはオプションの有無ごとの組み合わせ数の分だけ大量の関数を用意する手もあるけど論外だ

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

何で間違ってることを繰り返すの？

macroで重複チェック可能なbuilderは書けるとか書いてこないのは意外なんだけど

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

実行時チェックの話もchatGPTの方がまともで面白い回答や提案をしてくれる

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

>>118
設定値の重複チェックとか誰も気にしないからでは
重複設定によるバグとか生成関数に渡す引数の順番を間違えるバグと同じくらい起こりにくいし

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

一部の必須値の設定を忘れるケースは普通にあるでしょ

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

>>121
必須値は様々な対応が取れるため問題は起きない
・オプションにしない
・全体の整合チェックの一貫として必須値の有無の判断を入れる
・ビルド最終メソッドで指定する　(ex. std::fs::OpenOptions::open)

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

一番オーソドックスなのが抜けてるな
RegexBuilderの場合はRegexBuilder::new()にパターン文字列を渡してる

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

>>123
先頭の「オプションにしない」が
その最初に必須値を渡す意味
わかりにくてすまん
フォローサンクス

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

名前付き引数であれば必須パラメータも名前付きで渡せるため順番の間違いによるミスが発生しづらく可読性も高い
derive_builderを使う以上は必須パラメータもメソッドで渡すしかなく実行時エラーの可能性が排除できないしチェックのために余計なランタイムコストを払う必要がある
文句はderive_builder作者に言ってきた方がいいぞ

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

狂信者には何を言っても無駄であり論理的な考えを持ち合わせていない
こちらがいくら論拠を提示してもRustが正しいderive_builderが正しいとそんなミスは起こりえないと繰り返すのみ

正しくないのはお前の頭だろう

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

ビルド方式に問題はない
既出のstd::fs::OpenOptions::open()や
regex::RegexBuilder::new()など
Rustはビルド方式でも対応しており問題になっていない

>>125
名前付き引数であろうとなかろうとバリデーションは必要でそれは実行時エラーとなる
そしてResultを返すから実行時エラーで問題ない

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

>>82
順序ミス対策なら
.rgb(p[0], p[1], .p[2]).build()
でいいんじゃね？
Rustてこういうのできないんだっけ？

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

>>127
＞　少なくとも現状でderive_builderに欠点は見つかっておらず最善な方法であるといえる

じゃなかったのか？方針変えたのか？

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

“イリヤ神”がまたやった　動画生成AI「FramePack」が革命的なワケ
2025年05月05日 07時00分更新
https://ascii.jp/elem/000/004/267/4267160/
　4月17日に登場した動画生成AIプログラム「FramePack（フレームパック）」が世界的に衝撃を与えています。PCローカル環境で動画AIを動かすには、少なくともビデオメモリー（VRAM）が12GBあるビデオカードを搭載していないと難しいというのが常識でした。ところが、VRAM 6GBでも安定的に動作させられるため、一気に動画AIの裾野を広げそうです。開発したのは、画像生成AI分野で「ControlNet」や、使いやすいツール「Fooocus」などを開発してきたことで知られる、スタンフォード大学に在籍中のIllyasviel（イリヤスフィール、以下イリヤ）さん。既存の方法論にまったく違ったアプローチでブレイクスルーを引き起こす、“イリヤ神”のアプローチに再び注目が集まっています。
中略
　AI動画を作ってみたいけれども、スペックが足りないために諦めていたという人が次々に自前の環境で試すようになってきました。既にワンパッケージでインストールできる環境も整えられているため、スタートも簡単です。様々なファイルをダウンロードしてくるため、初期設定は2時間くらいは見ておく必要があるものの、圧倒的にハードルが下がりました。

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

>>127
名前付き引数のミスは大体言語でコンパイルエラーになるので的外れ
ビルダーパターンより安全性が高いだろ

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

>>126
Rustが間違っていると主張したいなら問題点と代替策を述べればよい
本当にそれが示せるならRustはIT大手各社も用いているため世界中にインパクトを与えられるぞ
この我々の5chのやりとりすらRust製のPingoraを経由しているほどネットインフラ各所でもRustは使われている

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

>>132
何言ってるんだよ
最後の一行が全てだろ

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

本当に暇さえあれば関係ない話題で誤魔化そうとするよな
脳がストローマン論法で浸食されているんだろ

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

それよりもbuilderパターンは初期化時の情報指定漏れをコンパイルエラーにできないのがRustらしくないと思う。

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

>>128
個別パラメータとして与える必要がないからその通り
Rustの言語仕様としてはそれで制限ない
そのライブラリの仕様ならタプルにすればよい

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

>>127
なるほど、実行時に他のバリデーションするからタイプセーフでなくていいと君は考えるわけね
それはそれで一理あるが、だったら君が使うべき言語は静的型付け言語ではなくRubyなどのゆるふわ言語だな
さようなら

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

ビルダーパターンで疑似カリー化が行えるのが利点なのにタプル化するって
わざわざ手足を縛ることになるけど

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

>>135
勘違いしていないか？
必要とはされないオプションが有る時にビルダーパターンが使われる

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

>>138
それマジで言ってるならRustでプログラミングしたことがないんだな
タプルで扱うのが正解
これがわからないならfor文すら書いたことがないのだろう

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

>>139
それは一部必須パラメータが依然として存在することと矛盾しない

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

>>140
もはや話がかみ合ってないな
疑似カリー化で個々のパラメータを指定してその他のパラメータをここに設定した生成物を作れるのが利点だという意味が判らないのかな
これは重複を許容する使用法

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

>>141
必須パラメータの事例はさっき出てただろ

>> std::fs::OpenOptions::open()
>> regex::RegexBuilder::new()

これで対応できている
誰もが使っていて問題となったことはない

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

>>142
カリー化の意味すら理解できてないのか？
Rustでカリー化ならばクロージャを使う
ちなみにビルダーパターンはビルダー構造体のまま変わらずカリー化は行わない

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

>>143
だからそれはderive_builderの作者に言ってくれ
それに前から言ってるが必須パラメータの数が増えればミスが増えるし可読性も落ちる

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

>>144
ストローマン論法
疑似カリー化と書いてるだろ？

derive_builderは正しいと繰り返していたのにすでに複おじになかったことにされている

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

微妙に論点をずらしたり相手の言ってないことに対して批判したり
本当にずっとストローマン論法続けてるよなあ
複おじいさん

ストローマン論法はやめなされｗ

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

>>137
Rustは静的型付けだから常にタイプセーフだよ
それらの例は引数の型が合ってなければ当然コンパイルエラーとなる
一方で引数の値が合っているかどうかは構造体の方針だから当然コンパイルエラーにできず実行時エラーとなる

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

>>145
何を言いたいのかわからない
fsやregexの話を作者に伝える？
そんなの知ってるだろ

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

>>146
カリー化は定義もメリットもはっきりしていて幅広く使われてきているが
その疑似カリー化とやらも定義もメリットもわからない
無意味なことをしようとしていないか？

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

>>150
見ればわかるだろうｗ疑似カリー化が何を意味しているのかぐらい

そういう議論のための議論を繰り返してなんになるんだよ

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

>>151
だから疑似カリー化の定義とメリットを明確にしてくれ
少なくともこの件のrgbバラバラにするのはメリットないどころかデメリットだぞ

>>128
>> 順序ミス対策なら
>> .rgb(p[0], p[1], .p[2]).build()
>> でいいんじゃね？

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

>>152
こちらのID辿ってみたらいい

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

>>62
>>68

複おじはderive_builderを全力で支持
初期化関数は全否定していた

ところが…

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

＞ .R(p[0]).G(p[1]).B(p[2]).build()

これ3つとも指定が必要ならメソッドを分けるべきではないと思う
それ以前にRustのプログラミングしたことないのかメソッド大文字は置いとくにしても
この場合ならp[0]はRust的な使用方法ではないな
(r, g, b)もしくはRGB構造体で持つかその参照で持つのが普通
p[i]はなるべく避けてイテレータ時点でポインタを動かして参照で持つか小さいなら値で持つ
構造があるならその構造で持つ
そのためp[i]の形が出てきたらRustでは少し臭うため怪しみ避けられないか考える

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

>>75
>まつもとなかい

うby界隈のmatzとそのとりまきか？

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

>>155
> これ3つとも指定が必要ならメソッドを分けるべきではないと思う
おっ
derive_builderって必須パラメータをランタイムチェックとはいえ個別setterの形で適切に扱えるというのが重要なコンセプトなんだけど、ここにきて全否定か

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

>>128
>.rgb(p[0], p[1], .p[2]).build()

重複を主張する人の場合
.rgb(p[0], p[1], .p[2]).b(3).g(4).r(5).g(6).b(7).build()
みたいな間違いが起こるんだと思うよ

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

ボクシングには蹴り技がない
それは重要なコンセプトだと考えていた時期が俺にもありました

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

コンパイラでうまくいかないから規約で縛ると言うことだろ？ビルダーパターンを導入する意義とどんどん崩れていく

RGB各値は指定が必須とは限らない
defaltで各値が0指定されていて同じなら書く必要がないだう
初期化関数では場合によっては記述する必要があるけどそれも必須ではない

疑似カリー化で少しずつパラメーターの違う複数のオブジェクト生成を行う場合にも便利

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

f(
　red=red,
　green=green,
　blue=blue,
)

f()
　.red(red)
　.green(green)
　.blue(blue)

どちらの方式でも間違えようがないと思うんだが
ミスが起きると言ってる人はどういうミスを想定してるのだろう

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

red=p[0];　//p[0]は実際はblue
green=p[1];
blue=p[0]; // コピペの修正漏れ

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

>>161
今更そんなところを理解できてなかったのか？
greenの指定を忘れたら前者はコンパイルエラー、後者は実行時エラー

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

>>162
これの悩ましいところは後ろのコピペ修正漏れでblueに正しいp[0]が指定されているので
原因が判断しにくいところ

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

>>163
前者と後者は同じ
greenの指定をしなくてもコンパイルエラーとならない
greenは指定しなかった場合にデフォルト値となるオプション引数

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

>>165
知らんがな
俺は必須パラメータの問題を指摘している

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

>>162
p[0]やp[1]など
可読性の悪いコードを書くやつは失格
p.red p.green p.blueにしろ

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

>>167
dataと言うバイト列の中の一部だとしたら？

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

>>166
おっちょこちょいだな
直前のこれを見ろ
必須ではなくオプションパラメーターだ

>>160
> RGB各値は指定が必須とは限らない
> defaltで各値が0指定されていて同じなら書く必要がない

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

>>168
バイト列？
各8bitなのか各16bitなのかそれ以上なのかそれでは構造がわからん
ちゃんと構造体の列にするべきだ

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

>>170
また真面に回答できないから適当に話をごまかして議論のための議論しようとしてる
受信データなどのバイト列から値を取り出すのは一般的だろう
必ずしも構造体の列構造とは限らない

それと数値指定無くすならコーディング規約でこう書かないとアウトですとするのか？
blue=data[ i + blue_index_offset];
red=data[ i + red_index_offset];
green=data[ i + green_index_offset];

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

>>171
あのさ
Rustでプログラミングしたことないの？
Rust以外でもシリアライズとデシリアライズしたことないの？
まともなプログラミングしたことある人ならRustですぐにserdeにたどりつく

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

まともな人が言ったのか人形が言ったのか全然わからない時代だ
人形が言ったにすぎないなら、そんな言葉は存在しないのと同じ

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

>>172
お前はわざと議論のための議論してるだけだろ
通常のコーティングで出てくるであろう例を誤魔化している

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

p[ i+0 ],p[ i+1 ],p[i +2 ]を取り出すだけのためにどれだけコーディング量を増やして
ライブラリ依存させていくのか
本当に意味不明

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

>>175
そんな可読性が悪くてミスしやすいプログラミングは避けるべきだ
構造化と抽象化が不得手でプログラマやエンジニアに向いてないな
serdeは構造体に#[derive(Serialize, Deserialize)]など付加するだけでデシリアライズ関数などは自動生成される

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

>>176
構造体にって自分で書いてるだろ
単なるバイト列からp[ i+0 ],p[ i+1 ],p[i +2 ]を取り出すだけのために構造体などを作らないといけない

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

p[ i+0/*0=赤*/ ],p[ i+1/*1=緑*/ ],p[i +2/*2=青*/ ]
俺ならこうするよ
コメントを見れば0が赤、１が緑、２が青と見たん瞬間わかる
日本語なので英語より間違えにくい
もし間違った数字が間違ってたらコメントと比べればすぐわかる

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

（言語を強化することにより）アプリのコーディング量を減らせという話はなかなか面白い
言語の数がアプリの数より多い気がする原因はこれかもしれない

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

>>174
議論のための議論をしてるのはお前だろ
それともガチで何も意味を読み取れないインデックスアクセスが正義と思ってるわけ？
どんなみじめな経験を積んできたんだよ
害悪プログラマすぎて仕事で関わらないことを願うわ

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

議論とは関係ないけど大体の画像処理ライブラリだとRGBもBGRも扱えるように channel[0], channel[1], channel[2] のようにアクセスさせると思う
内部のデータによって channel 数は1や4 (アルファチャネル付き) もあるし

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

仕事はお金を貰ってやることだから丁寧に書いて上司に褒められる必要があるけれど
趣味とか経営者とかなら何を書いてもじゆうなんだよな

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

簡潔で見にくいコードを書くか
冗長で醜いコードを書くか
２択だな

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

>>181
これはそう
画像に限らず構造化されたバイナリデータを扱うときに一般に言えることだけど、
単純にビット列をそのまま構造体として読み替える間違いは、低水準に踏み込める言語に入門して調子乗ってる初心者がやりがち

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

上司はunsafeの箇所をチェックすればいいのに
コンパイラが自動で調べてエラーがなかった箇所を、手動で調べ直して逆張りするのが胡散臭い

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

Serdeは暗黙のCopyしがち

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

>>180
８０代のおじいさんと仕事をする機会はないかな

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

話を整理すると

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

と彼は言い出すから
それは名前付けせずにp[0]を用いていることが間違える本質的な問題という話だよな

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

さらに

>>160
> RGB各値は指定が必須とは限らない
> defaltで各値が0指定されていて同じなら書く必要がない

と彼は言ってるので
彼の好み通りにp[0]を用いるとして

名前付きオプション引数方式
foo(
　green = p[0],
　blue = p[2],
)

ビルダーメソッド方式
foo()
　.green(p[0])
　.blue(p2])

どちらの方式でも同じだな
仮にミスが起きるとしたらそれは名前を付けずにp[0]を使っていることが本質的な問題であると確定

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

構造体は
foo{green:green,blue:blue}
を
foo{green,blue}
と描ける訳で
ビルダーメソッド方式とやらも
foo().green().blue()
的に描ければ無駄が減るから改良してくれんかのぅ

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

>>189
その大量連投していた彼はRustをほぼ知らないと判明した上に他の言語の経験値も低そうなので彼自身に問題があることを理解できないと思う

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

その連投してスレを荒らしていた人が
「おじ」「複おじ」「おじいさん」「おじいちゃん」使いの人だったとはね
>>61 >>70

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

foo().(green).(blue)
でもいいな

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

RustはJavaよりも構造体リテラルの表記が強力だから
Builder使うよりOptions構造体１つで渡す方が楽かもしれんね
パターンとしてはBuilderよりマイナーだけど

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

>>190
引数なしで何を指定するのか？

>>193
メソッド名なしはエラー

どんな方式を取ろうとも大元の変数(ex. rgbやp)は指定せざるをえない
foo().green(rgb).blue(rgb)

**デフォルトの名無しさん** · 2025/05/06(火) 09:36:09.23

>オプション引数やキーワード引数については他言語が内部的にやってることをRustの場合は開発者が自分でやらなきゃいけないことになっててバカらしい

>しかも関数シグニチャに情報をまとめられないから書く方も読む方も煩雑になるだけで開発者的には何もメリットがない

これに尽きる
言語に機能が不足してるから何でもかんでもビルダーパターンにしなきゃいけなくてサードパーティのマクロに依存することになる
アホらし

**デフォルトの名無しさん** · 2025/05/06(火) 09:48:17.91

>>196
真逆だろ
キーワード付オプション引数をズラズラ並べた長い長い関数シグニチャはデメリットしかない欠陥品
しかも機能拡張したらさらにキーワード付オプション引数が増えて関数シグニチャが変わるアホらしさ

**デフォルトの名無しさん** · 2025/05/06(火) 09:51:10.91

複数IDと口調を使い分けて自分のレスに賛成するキチガイが複おじ

**デフォルトの名無しさん** · 2025/05/06(火) 09:51:38.50

Rustのダサい処は認めるべき

**デフォルトの名無しさん** · 2025/05/06(火) 09:56:28.46

>>197
ビルダーパターンは30年以上前から知られていたけどあまり有用ではないので使われていない
過去に誰かがざっくりデザインパターンを否定してたけど、その人の言うにはデザインパターンで有用なものは言語自体に取り込まれるはずだと

実際いくつかは新しい言語では取り込まれている

**デフォルトの名無しさん** · 2025/05/06(火) 09:56:50.79

マクロで解決可能なんだろ？それは「不足している」のか？
まあ標準ライブラリとして入っているべきみたいな論はあるかもしれんけど、マクロでの解決が悪くて言語機能として直接サポートするのが良いとする根拠は出てないな。

言語ユーザがそれぞれのやり方で解決できる自由さと言語の方針を強制する一貫性は両立しないがそれぞれに良さはあるし、 Rust は今のところ自由さをとりつつもデファクトな地位のライブラリはあるという状況だ。
手頃な妥協点と言えるだろ。

**デフォルトの名無しさん** · 2025/05/06(火) 10:01:33.47

些細な内容なら初期化関数を複数作ればよい話で更に多くなればオプション指定する構造体を作ればよい
mutに拘る必要が無ければさらに多くの可能性がある

わざわざ穴の多いビルダーパターンを使う必要はない

**デフォルトの名無しさん** · 2025/05/06(火) 10:08:26.28

>>200
ポールグレアムはイディオム (デザインパターン) は言語機能として持つかライブラリにまとめるべきと述べていて、考えられる様々なパターン (またはこれから登場する未知のパターン) をライブラリにまとめるには「本物のマクロ」が必要と主張してた。
そして本物のマクロを持つ実用的な言語は Common Lisp くらいしかなかったんだが、 Rust のマクロは彼の言う本物のマクロだ。

マクロで抽象化されてるならその実装がビルダーパターンでもそうでなくてもどうでもいいよ。

**デフォルトの名無しさん** · 2025/05/06(火) 10:10:04.33

>>202
初期化関数を複数作るとオプション分の組み合わせ爆発となる一番アホな方式
それならビルダー方式がよい

**デフォルトの名無しさん** · 2025/05/06(火) 10:12:49.15

>>204
他の言語では大体オーバーロードでオプション指定しているけどそれが馬鹿だとは思わないけどね

**デフォルトの名無しさん** · 2025/05/06(火) 10:15:57.89

>>205
それはオプションが増えると組み合わせ爆発が起こる馬鹿な方式

**デフォルトの名無しさん** · 2025/05/06(火) 10:17:10.44

>>206
同じ主張と文章を繰り返すやり方が複おじそっくりですね

オーバーロードの初期化関数で馬鹿らしいと思うのは型が同じで対象が違うものがある時
重複を避けるためにシグネチャの設計をしなくては成らないことは馬鹿らしいと思うよ

例えば基本的に2つだけ引数があって後はオプションがずらずら並ぶならやはりオプション内容を含む構造体渡せばいいと思う
そちらも設計が必要だけど

**デフォルトの名無しさん** · 2025/05/06(火) 10:18:50.49

>>205
それ以前にオーバーロードは欠陥機能
オーバーロードを使うとred,green,blueのオプション実装すらできない

**デフォルトの名無しさん** · 2025/05/06(火) 10:19:38.79

>Rust のマクロは彼の言う本物のマクロ

macro_rules! は偽物のマクロ
proc_macro2 が本物のマクロ

**デフォルトの名無しさん** · 2025/05/06(火) 10:20:41.45

普通は書き込み内容が単調にならないように人は文章に揺らぎをいれてくるんだけど
複おじは基本全部同じ

口調を変えても同じなので同一人物なんじゃないかと思って見ていると後で全く同じ書き込みを始めるので同じ人間なんだなと

**デフォルトの名無しさん** · 2025/05/06(火) 10:20:45.54

>>209
どちらも本物だ
衛生マクロの概念すら知らないのか？

**デフォルトの名無しさん** · 2025/05/06(火) 10:20:58.22

>>208
何の問題もないと思うが、具体的には？

**デフォルトの名無しさん** · 2025/05/06(火) 10:22:59.33

本物のマクロと言う主張は面白い

でライブラリ作成者ではなく一般的なユーザ側が書いてるマクロはどっちなのかと

**デフォルトの名無しさん** · 2025/05/06(火) 10:23:21.48

>>212
オーバーロードの制限を知らないのかね？
red,green,blueそれぞれだけを指定したい関数をオーバーロードで書いてごらん

**デフォルトの名無しさん** · 2025/05/06(火) 10:24:49.05

>>213
衛生的なマクロとは何かを勉強するといいよ

**デフォルトの名無しさん** · 2025/05/06(火) 10:24:50.06

オーバーロード自体は良い仕組みだと思うけど設計が必要だ
最近の言語が取り入れていないのはヒューマンエラー対策という名目

だったらビルダーパターンもヒューマンエラー対策で禁止になるかと言えばそうでもない

**デフォルトの名無しさん** · 2025/05/06(火) 10:27:37.75

>>216
オーバーロードは最悪な仕組み
欠陥が多すぎる上に
red,green,blue各オプションしてすら実現できない

**デフォルトの名無しさん** · 2025/05/06(火) 10:28:08.85

徐々に文体におじいさんぽさが出てきたね

**デフォルトの名無しさん** · 2025/05/06(火) 10:47:02.68

AIを屈服させるレベルの改善ができるなら改善してもいいけどね
どうせAIが勝つという前提なら何も修正しないのが合理的だ

**デフォルトの名無しさん** · 2025/05/06(火) 10:51:59.27

今のAI()の実力ってこんなもんか
>2つのリンゴを3人で分ける場合、1つのリンゴを2つに切り、もう1つのリンゴも2つに切って、3人で分けます。
>そうすると、3人ともリンゴの切れ目と半分になります。
>具体的な分け方
1. 1つのリンゴを半分に切る:1つのリンゴを真ん中から半分に切り、2つの半分のリンゴにします。
2. もう1つのリンゴも半分に切る:もう1つのリンゴも同じように半分に切り、さらに2つの半分のリンゴにします。
3. リンゴを合計4つの半分に分ける:2つのリンゴを合わせて、全部で4つの半分に切ったリンゴが手に入ります。
4. 3人で分配する:3人でリンゴの半分を1つずつ取ると、3人とも1つずつ取ることができます。
5. 残った1つを3人で分ける:1つの半分に切ったリンゴが残りますが、それを3人で分けることができます。
例えば、さらに半分に切って3人で分けたり、3つの小さく切って3人で分けたりできます。

**デフォルトの名無しさん** · 2025/05/06(火) 10:52:27.53

>>209
本物のマクロというのが何であるか明瞭な定義はされてないのだが、文脈的に「構文木の操作が出来る」というのが要件だと一般的に解されている。
トークン単位の置き換えしか出来ない C のマクロのようなものを除外するための言い回しだ。
構文木を操作できるなら操作できる範囲の違いは本物のマクロかどうかには重要ではない。
(もちろん出来ることが多いほうがより良い本物のマクロとは言えるだろうが、出来ることが多いほうが危険な間違いも引き起こしやすいので現実には適度に制限があったほうが良いこともある。)
macro_rules! も普通は本物のマクロと解される。

**デフォルトの名無しさん** · 2025/05/06(火) 11:06:32.44

リスパーはmatchを知らない

matchを知らなくても理解できるマクロが本物のマクロ

**デフォルトの名無しさん** · 2025/05/06(火) 11:11:44.35

複数ID使用おじ

別人が複おじと疑われたら自分は複おじじゃねーよと反論する
気持ち悪いから
ところが何故かしない

複おじはそういうのに反論しない仕組みになっている

**デフォルトの名無しさん** · 2025/05/06(火) 11:19:55.25

>>214
ヒント:
struct Red(u8);

**デフォルトの名無しさん** · 2025/05/06(火) 11:20:28.10

マクロ自体がただの似たような機能の概念の総称であってその中で本物だ、元祖だと言っても笑われるだけ
キーボードマクロは真のマクロではないとか衛生的ではないと言われてもそうですかと

**デフォルトの名無しさん** · 2025/05/06(火) 11:22:58.43

ID:j5CJU7Aq　　の反応待ちのawait状態です

**デフォルトの名無しさん** · 2025/05/06(火) 11:23:42.97

>>223
複OGはどうでも良いけど
5chはもう禿しく過疎ってるのにこのスレだけやけに延びてるのは不自然だと感じる

**デフォルトの名無しさん** · 2025/05/06(火) 11:31:04.25

>>225
「本物のマクロ」というのは正しさとか起源を主張しているわけではなくそういう名前の分類。
少なくとも C のマクロなどでは様々なイディオムを抽象化するには不十分だというごく当然の話をしてる。

**デフォルトの名無しさん** · 2025/05/06(火) 11:33:12.59

なお、名前付き引数での呼び出しを前提とするならばhoge(red) と hoge(green)を名前付き引数の引数名だけで呼び分けるオーバーロードは技術的には実装できない理由は特にない
しかし、多くの言語では名前付き引数の使用はオプションだしこの場合はhoge_red(val)のように機械的に名前変えりゃいいだけだから、実装コストに見合わないという判断をされているのだろう

**デフォルトの名無しさん** · 2025/05/06(火) 11:39:56.59

>>224
こうですか？わかりません

impl From<Red> for Color {...}
impl From<Green> for Color {...}
impl From<Blue> for Color {...}
impl From<(Red, Green)> for Color {...}
impl From<(Red, Blue)> for Color {...}
impl From<(Green, Blue)> for Color {...}
impl From<(Red, Green, Blue)> for Color {...}

let red = Color::from(Red(255));
let yellow = Color::from((Red(255), Green(255)));
let white = Color::from((Red(255), Green(255), Blue(255));

**デフォルトの名無しさん** · 2025/05/06(火) 11:48:34.17

メリットが不確実なだけでしょ
メリットもコストも確定していてなおかつ見合わないという話ではない

**デフォルトの名無しさん** · 2025/05/06(火) 12:18:40.67

このスレでずっと自演してる人って糖質とかなんだろうなあ

**デフォルトの名無しさん** · 2025/05/06(火) 12:28:45.22

traitで騒いでた自演と同じ人だろう

**デフォルトの名無しさん** · 2025/05/06(火) 12:40:06.43

オーバーロードはそもそもCのAPIにありがちな、後で〇〇2だの〇〇exだのが増えて格好悪くなる問題を解消するためのもの
後で引数名だけ異なるオーバーロードが増えたら名前付き引数を使っていない既存の呼び出しがエラーになるのは、互換性維持という本来の目的からすれば論外

**デフォルトの名無しさん** · 2025/05/06(火) 12:49:02.99

話題のderive_builderを使ってみた
構造体に属性を付けるだけで初期化関数を書かなくて済むのは便利だね
ドキュメント見ると今回は使ってないけど色々と機能が充実してるみたい
話題のred/green/blueはこれでいいのかな

use derive_builder::Builder;

#[derive(Default, Builder, Debug)]
struct Color {
#[builder(default = "0")]
red: u8,
#[builder(default = "0")]
green: u8,
#[builder(default = "0")]
blue: u8,
}

fn main() {
let pink = ColorBuilder::default().red(255).blue(200).build().unwrap();
println!("{pink:?}"); // Color { red: 255, green: 0, blue: 200 }
}

**デフォルトの名無しさん** · 2025/05/06(火) 12:57:12.48

>>235
よくない
散々言われている通り、必須属性の設定を忘れると実行時エラーになるという致命的な問題がある

**デフォルトの名無しさん** · 2025/05/06(火) 13:06:06.15

>>236
例えばファイル名を打ち間違えちゃったけど
まずリリースモードの前にデバッグモードの時点で実行時エラーで気付いて
直してしまえばそれ以降は大丈夫と同じじゃないのかな
特に問題ないような

**デフォルトの名無しさん** · 2025/05/06(火) 13:10:03.39

補足するとファイル名は必須項目だけど
コンパイル時にチェックできるのは型だけだから現実的にチェックできることはほとんどないよね

**デフォルトの名無しさん** · 2025/05/06(火) 13:16:05.70

お前らめちゃくちゃ暇人だな
レス多すぎ

**デフォルトの名無しさん** · 2025/05/06(火) 13:18:37.75

>>201
>マクロで解決可能なんだろ？
ビルダーパターンの手書きコード量を多少なりとも削減したいという問題は解決してるかもね
それが本当に解決したい問題だと思ってるのならそれでいいんじゃない

**デフォルトの名無しさん** · 2025/05/06(火) 13:24:33.64

ビルダー方式でも他の方式でもなんでもいいけど
初期化のための関数を自分で書くよりも>>235のように構造体への属性マクロ指定だけにするのがいいと思う
面倒がなくコードがすっきりとしてプログラミングミスも起きないから

**デフォルトの名無しさん** · 2025/05/06(火) 13:44:43.14

>>238
それはそうなのだけど、だからといってコンパイル時のチェックを安易に諦めたら、極論Cでいいだろって話になっちゃう
Rustの存在意義が問われる危険な思想

**デフォルトの名無しさん** · 2025/05/06(火) 13:46:48.63

現時点のderive_builderはFooBuilder::new()に必須項目を渡すパターンには対応してないっぽいな
全部default()でも構わないケースだと使えるけどRegexBuilder::new(pattern)みたいなケースもあるから万能ではない

**デフォルトの名無しさん** · 2025/05/06(火) 13:53:00.39

良い例があるな
https://mevius.5ch.net/test/read.cgi/tech/1643696741/33
貴方が配慮を欠いている
そのx^nつまりxのn乗を求めるにしても
例えば2^100を求めたいならば128bitがないと溢れるのでu128::pow(2, 100)となるが
2^5を求めたいだけで結果も8bitで十分ならばu8::pow(2, 5)となる
このようにメモリサイズも異なってくるので別々の関数が必要
もちろんu128::pow(x, n)があればu8::(x, n)をカバーできるが明らかに無駄である
そこで符号なし整数だけでも
u8::pow(x, n)
u16::pow(x, n)
u32::pow(x, n)
u64::pow(x, n)
u128::pow(x, n)
と5つの関数が必要となる
一方でxの型が確定しているのであればpowで再び型指定は不要なので
x.pow(n)と表記することも可能
以上は整数の場合だがxとpowの結果が小数の場合は2種類の関数が必要となる
f32::powi(x, n) 【nが整数の場合】
f32::powf(x, n) 【nも小数の場合】
もちろんnが小数のpowfだけあればpowiもカバーできるが明らかに無駄なので2種類必要となる
さらに32bit小数だけでなく64bit小数も扱う必要があるため以下も必要
f64::powi(x, n) 【nが整数の場合】
f64::powf(x, n) 【nも小数の場合】
これらもxの型が確定していれば以下のように略して書くことも可能
x.powi(n) 【nが整数の場合】
x.powf(n) 【nも小数の場合】
ちなみに「x^n」を表記するのに不自然な「pow(x, n)」よりも「x.pow(n)」の方がたまたま自然に見えるが誤差だろう
どちらでも好きな表記法を選べばよいだけにすぎない

**デフォルトの名無しさん** · 2025/05/06(火) 14:21:46.28

>>244
例えば
このように
もちろん
そこで
一方で
以上は
もちろん
さらに
これらも
ちなみに

そのx　から始まって論理的？接続で参照を握ったままで最後まで離さないな
読みにくいのは当然

**デフォルトの名無しさん** · 2025/05/06(火) 14:26:52.22

id変わってしまった

**デフォルトの名無しさん** · 2025/05/06(火) 14:30:10.65

上の強烈な接続もビルダーパターンの一種かな？と思ってしまう

**デフォルトの名無しさん** · 2025/05/06(火) 15:04:10.81

>>242
忠臣蔵みたいに、諦めたふりをするぐらいがちょうどいい
危険思想？
なんのことやら