Rust part28

**デフォルトの名無しさん** · 2025/03/24(月) 17:37:00.15

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

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

**デフォルトの名無しさん** · 2025/04/30(水) 01:03:45.45

どっちかが絶対いいというものではなくて使い分けるもの

**デフォルトの名無しさん** · 2025/04/30(水) 01:38:53.14

>>873
the best code is no code at all か、なるほどね

構造体更新記法を使ってもらわないと、メンバー追加したときにコンパイル通らなくなるけど
それを問題視する人としない人がいるって感じ？

個人的には、今のRustはその程度の軽い互換性破壊は日常茶飯事だから別にいいのでは？って気がするけど

**デフォルトの名無しさん** · 2025/04/30(水) 06:24:04.68

内部用は自由だが
少なくとも公開ライブラリの構造体の初期化の結論は出ている

まず各フィールド個別のpub化は以下の点で良くない
・構造体の値個別や全体の制約による無矛盾性を保証できない
・内部実装の改善による構造の変化に対応できない
・今後の機能拡張によるフィールド増加に弱い

したがってどうしてもビルダーパターンを使いたくないのならば
Foo初期化指定用の構造体FooConfigを更に用意してそれはpubを許して
Foo::init(FooConfig { FooConfig:: default(), i: 123, s: "abc" })?
またはこうする
FooConfig { FooConfig:: default(), i: 123, s: "abc" }.init()?
そしてinit()内で指定値チェックと本当の内部構造への変換をする形になる

同じことはビルダーパターンだとderive_builderを用いると提供側は簡単
使う側はおなじみの以下の形になる
FooBuilder::default().i(123).s("abc").build()?
どちらの方式も指定の構文が異なるだけで同じような形になってることがわかる

個人的にはビルダーパターンの方がよりシンプルだと思う
そしてRustでの主流となっている

**デフォルトの名無しさん** · 2025/04/30(水) 10:08:02.30

強制すれば良いのに

**デフォルトの名無しさん** · 2025/04/30(水) 11:07:06.59

ビルダー自体が便利だとは思えないんだよな
オプション引数やオーバーロードが無いのを解決するためのもので、他の言語から来ると戸惑うと思う
(型で遷移を表現するなど、パターン自体は Rust らしいし、理解自体は容易だけど)

オーバーロードは別の面倒を生むから無くて良いと思うけど、オプション引数は個人的にはあると嬉しい気がする

実はGoもオプション引数が無い言語で、代わりに functional option パターンというのを使うんだけど、これもイディオムを知らない人にとって直観的でないと言われがち
同時期に登場した言語がどちらも採用しなかったんだから、多分それなりの理由があるんだろうな

**デフォルトの名無しさん** · 2025/04/30(水) 11:52:30.40

簡単に言えば、virtualを使ってないデザインパターンは追放されない

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

ム板全体が限界過疎集落化してるのに
Rustスレだけ人が居るのはなぜ？
他に交流の場が無いのかな？

**デフォルトの名無しさん** · 2025/04/30(水) 12:11:54.22

自作自演

**デフォルトの名無しさん** · 2025/04/30(水) 12:21:33.61

規模が大きくなるにつれてbestよりconsistentの重要性が高まるものだ
将来的な変更容易性がどうのと言って必要以上に凝ろうとする奴に限って、
革新的で最高にクールなニュースタイルのビルダーが出てきたらすぐにちゃぶ台返しをする
まあ初期化時のパラメータの与え方なんて壊滅的変更されたところで大した問題じゃないから、
そういう奴に自由にオナニーさせて発散させておくにはいいのかもね

**デフォルトの名無しさん** · 2025/04/30(水) 12:21:42.88

単に書き方がちょっと面倒というのを解決したいならマクロを使えばよいということだと思う。
実際にそういう使われかたをしてるし。

**デフォルトの名無しさん** · 2025/04/30(水) 12:44:48.88

自演

**デフォルトの名無しさん** · 2025/04/30(水) 13:00:34.55

>>870
>>873
どうせ最適化で同じコードになるんだろうけど
記述的には同じことの繰り返しが多過ぎて効率が悪過ぎるイメージ
スマートじゃない
>>883
マクロは有効ではある

**デフォルトの名無しさん** · 2025/04/30(水) 14:42:30.43

>>878
Builderパターンは設定(引数渡し)とオブジェクト生成を分離するのが本質的な特徴。

デフォルトの省略とか渡す順番の自由化とかあるけど、それも設定と生成の分離から派生した特徴でしか無い。また分離した結果として複数個所からの同時アクセスに弱いけど、そういうのを理解して使えばいい。

**デフォルトの名無しさん** · 2025/04/30(水) 15:49:41.55

あちこちがガンガン破壊的変更されていくRust界で、
初期化のとこだけBuilderパターンで互換性ありますよーってあんまり意味ない気がする

**デフォルトの名無しさん** · 2025/04/30(水) 16:17:15.30

>>880
約一名必死なやつがいるから

**デフォルトの名無しさん** · 2025/04/30(水) 17:44:14.52

>>887
Rustは他の言語と比べても破壊的変更は少ない方じゃないかな
しかもRustにはEditionという概念があって必ずCargo.tomlに指定したうえでソースコードを書く
そのため破壊的変更より前の古いソースコードも影響を受けずにコンパイルできて実行できたりする

第三者が作ったライブラリ(crate)についてはCargo.tomlにバージョン番号を指定して使っていれば
そのまま当時のソースコードを使うためコンパイルできて実行できたりする
もちろん古いものセキュリティホールなどが発見されれば対応せざるをえないのは当然だけどね

いずれも全てのケース100%で今後も永遠に大丈夫というわけではないかもしれないけど
バージョンの違いなどで苦しんでるプログラミング言語などと比べたらRustは恵まれてると思うよ

**デフォルトの名無しさん** · 2025/04/30(水) 18:21:50.73

ワシらの作るサービスがヒットするわけ無いだろ。打率0割0分5厘
スーパーなプロデューサに仕えねば

**デフォルトの名無しさん** · 2025/04/30(水) 18:50:26.71

>>889
>Rustは他の言語と比べても破壊的変更は少ない方じゃないかな
フィボナッチ作ってるだけじゃわからんよなｗ

**デフォルトの名無しさん** · 2025/04/30(水) 19:04:33.02

>>889
いやいや破壊的変更を堂々と入れるためにエディションがあるのに何言ってるの
わざわざシステマティックに管理しなきゃいけないほど言語仕様の破壊的変更の多い言語ってそんなに多くないよw

**デフォルトの名無しさん** · 2025/04/30(水) 19:17:57.26

エディションの機能あるのRustだけじゃね。
Cなんかもコンパイラオプションでゴニョゴニョ出来るけど

**デフォルトの名無しさん** · 2025/04/30(水) 19:18:18.80

>>892
もちろんエディション間には破壊的変更があるよ
でもエディション指定しているから現実には影響なしで過去のソースコードがコンパイルできて動く
そういう現実を含めて言及したよ

**デフォルトの名無しさん** · 2025/04/30(水) 19:52:49.23

そんなNPTがあるから核兵器は安全だ!みたいなこと言われてもな

**デフォルトの名無しさん** · 2025/04/30(水) 19:53:45.22

ひとつのプロジェクトに異なるエディションが混在することもできるけど、そうなると ABI の互換性は切れないし、エディションという仕組みがどれくらい長期的に機能するかちょっと読めない。
旧エディションを際限なくサポートするわけにもいかんし、ある程度古くなったエディションはそのうちサポートは切られるんじゃないかな？
新エディションに書き換えるツールは提供されてるので定期的に書き換えてメンテナンスするくらいは必要じゃない？もちろんプログラマも新エディションの機能を把握するのは要る。

**デフォルトの名無しさん** · 2025/04/30(水) 19:56:05.44

それは、仕方なし

**デフォルトの名無しさん** · 2025/04/30(水) 20:02:14.30

>>896
継続中のプロジェクトはそう
一方でメンテが昔に止まったプロジェクトでもエディション指定があるおかげでそのままコンパイルして動く点がRustは大きいかなと

**デフォルトの名無しさん** · 2025/04/30(水) 20:02:41.40

Rust ABIは一度も安定化したことがないから保つべき互換性なんてものはないので安心してください

**デフォルトの名無しさん** · 2025/04/30(水) 20:03:10.33

他でも同じ
python2 python3

**デフォルトの名無しさん** · 2025/04/30(水) 20:04:46.85

塩漬けにするなら普通は処理系のバージョンも含めて塩漬けにするもんだし、
>>896の指摘するように古いエディションのサポートが切られたら否が応でもそうするしかなくなる

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

この件でrustが優れていると言うのは違うかと

**デフォルトの名無しさん** · 2025/04/30(水) 20:09:05.80

C/C++だってコンパイラオプションで規格明示すればいいだけだしねえ

**デフォルトの名無しさん** · 2025/04/30(水) 20:30:24.75

3年毎のエディションの仕組みが明確にあって
ソースコードのCargo.tomlにエディションが必ず指定されてるから
コンパイルオプション指定も含めてソースコードを全く変更せずに動く
という点が他とは異なるね

あと将来は古いのは切るかもしれないけど
今のところ最新コンパイラもエディション2015,2018,2021,2024を全てサポートしていてコンパイルして動くね
その時コンパイラが警告してくれるし移行ツールもあるのでエディション移行もしやすい

**デフォルトの名無しさん** · 2025/04/30(水) 20:53:46.40

>>903
C/C++ には欠陥報告という制度があって、規格の過去の版に遡って修正されることがある。
大半は文章の曖昧さの修正や緩和の方向だから深刻な互換性問題にはあまりならないんだけど、なにせ修正の件数自体が多いから割合として少なくても互換性を損なう修正もそこそこある。
つまり昔の C++11 と今の C++11 は別物と考える必要がある。
そんでコンパイラによって規格の修正の反映具合が違ったりして混沌としてるんだわ。
実際に昔のコードを今のコンパイラでコンパイルしようとしてもエラーがゼロなんて場合はほとんどない。

**デフォルトの名無しさん** · 2025/04/30(水) 21:04:19.22

そりゃC++は時間のスケールが違うからな
C++を引き合いに出すなら、20年待たないとRustのエディションが主張通りに機能したかどうか結論は出ない

**デフォルトの名無しさん** · 2025/04/30(水) 21:20:15.53

ここ覗いてるのってメーカー勤めの技術的リスク取れないチキンな皆さんなのかね
やっていこうぜ。不満があればイシューツリーかパッチ投げよう

**デフォルトの名無しさん** · 2025/04/30(水) 21:30:45.31

>>906
現に10年前のRust 2015 edition指定のコードが動いているから大丈夫だと思うよ
最新コンパイラが2015 editionをサポートする間はそのままコンパイルできて動作するね
その話と関係なくcargo fix -editionで半自動でedition移行ができるから自分のソースコードなら手直ししてすぐ解決

**デフォルトの名無しさん** · 2025/04/30(水) 21:47:40.41

自分のソースコードしか手直しできないってなんでだろう
もっと他人のソースコードを批評したり手直ししたりすれば楽しいのに

**デフォルトの名無しさん** · 2025/04/30(水) 22:24:04.29

人のもやればいいけど技術以外の問題があるだけでしょ
コミット権限がないとか

**デフォルトの名無しさん** · 2025/04/30(水) 23:07:35.68

>>878
今回の構造体初期化のビルダーパターンと比べて
名前なしオプション引数やオーバーロードは以下の点で劣っている
・コードを書くときに間違いを起こしやすい
・コードを読む時にもわかりにくい
・同じ型が区別できない (同じ型のheightとwidthの片方だけ指定したい時)
・多数あると組み合わせ爆発が起こる

したがって利用可能な方法は名前指定オプション引数となる
例えば
f(name1=value1, name2=value2, ...)
一方でビルダーパターンでは例えば
f().name1(value1).name2(value2) ...
コードを書く側としてはどちらも大して変わらない
慣れだけの問題であり一瞬で適応できる

利用側としては上記のように大した差はないが
提供する側のコードが面倒で冗長になることがビルダーパターンの欠点であった
しかしこの問題をRustではderive_builderが解決してしまった
初期化したい構造体への簡単な修飾でそのビルダー構造体と実装を自動生成してくれる
他に改善すべき点や案などあるだろうか

**デフォルトの名無しさん** · 2025/04/30(水) 23:46:19.22

一面しか見ないバカ
相変わらずだな

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

rustは関数オーバーロードがないからビルダーパターンに頼らざるを得ない

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

Builderと大して変わらないと思うけど
内部非公開のstruct Fooに対して内部公開のstruct FooDraftを用意して

let foo: Foo = FooDraft {
i: 123,
s: "abc",
..Default::default(),
}.try_into()?;

みたいな形は考えたことある
まじめにやるならFooDraftはnon_exhaustiveを付けた方がいい

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

どちらにしてもコンストラクタがライトウェイトじゃなくなるし利便性も低下する

**デフォルトの名無しさん** · 2025/05/01(木) 01:16:01.59

お前らしょうもない言い争いしてる暇あったらRustでプログラミングしようぜ
楽しいぞ😎

**デフォルトの名無しさん** · 2025/05/01(木) 01:28:23.84

f(a,b,c);
g(a,b,c);
h(a,b,c);
ももっと短くするべきで、引数をstructにすればこの問題も解決する
が、キーワード引数はこのコードを更に長くしてしまう

**デフォルトの名無しさん** · 2025/05/01(木) 01:50:56.00

>>889
なんのcrateだったか忘れたけど使おうとしたらCargo.tomlにローカルなパスが通ってて吹いたことがある
そんなんcrates.ioに上げるなよ

**デフォルトの名無しさん** · 2025/05/01(木) 01:53:34.42

>>892-893
Cの方が相当古いバージョンのライブラリやモジュールでも動くよな
セキュリティーは置いといて

**デフォルトの名無しさん** · 2025/05/01(木) 01:58:46.40

>>907
ダブスタ意見はやめとけ

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

ワイはメーカーじゃないので暇つぶし

**デフォルトの名無しさん** · 2025/05/01(木) 10:03:23.98

完全無欠ωのRustにリスクがあることを認めるのですねわかります

**デフォルトの名無しさん** · 2025/05/01(木) 10:37:30.35

何にでもリスクはある

**デフォルトの名無しさん** · 2025/05/01(木) 10:38:10.43

成功する宝くじだけ買いたいなんて文科省だけだぞ

**デフォルトの名無しさん** · 2025/05/01(木) 10:49:46.51

コロンブスがリスクを取らなければいまだにアメリカ大陸は無人の動物王国だった
アムンゼンしかり、いつの時代も最初にリスク取る人間は周りに理解されない

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

ガチでリスクを取れる人間は今はバイブコーディング&動いてるっぽいからリリースしようぜ！に夢中なはず
Rustはコントロールできないリスクは取りたくないくせに俺スゲーしたい中途半端な人間向け

**デフォルトの名無しさん** · 2025/05/01(木) 11:49:06.01

インディアンと呼ばれた先住民が動物とはこれいかに

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

>>926
リスクだけ取りたいなら登山でもしてて

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

射程距離が長い武器は接近戦から逃げているだけだな
当たると豪語するが結局当たらない

**デフォルトの名無しさん** · 2025/05/01(木) 13:11:13.65

MSが今ビルダーパターン多用してる
過去の実績から言うとMSは99%技術選定を間違えるからそれが不安要素
MSは失敗のベンチマークとでも呼べる

**デフォルトの名無しさん** · 2025/05/01(木) 14:40:42.80

version3か3回目の名称変更でちょびっと安定してくるやつね

**デフォルトの名無しさん** · 2025/05/01(木) 14:48:48.72

大手は何にでも手を出してるから失敗も多いだけ。
成功も多い。

**デフォルトの名無しさん** · 2025/05/01(木) 15:32:50.49

逆に大手が手を引けばその技術は失敗と見做される
MSがそれで抹殺してきたのは主に自社の技術だからともかく、GoogleなんかはコミュニティのOSSを殺すから悪質

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

バカに見つかることの何が問題なの？
見つけてもいつか手を引くから問題だ
じつに論理的だ

**デフォルトの名無しさん** · 2025/05/01(木) 23:47:13.30

>>913
構造体の初期化にオーバーロードは役に立たないよ

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

Rustの欠点やRustに対する不満は数多存在するが
CやC++に対するそれらとの程度問題に過ぎない
それを殊更Rustを過剰に持ち上げるから話が可笑しくなる
そのせいで期待の裏返しで粗が目立つことにもなる
RustはRustと限界も理解した上で節度を持って付き合う距離感が大事

**デフォルトの名無しさん** · 2025/05/02(金) 08:31:39.96

過剰なのは期待ではないよ
期待などを過剰に可視化するのをやめればいいだけだ

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

Rustを教訓にした次の言語に期待

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

Rustの最大の教訓は、どんな言語でも有名になればバカ(必ずしも頭が悪いわけではなく、本来その言語が想定しない用途に使おうとする奴も含む)が使うってことだろう
Rustの仕様はそれほど効率が重要でない分野でテキトーに使おうとすると無駄なコピーが増えたりしてかえって非効率になりがちな面があるから、
そのあたりのバランスをうまく取れば非常に広く使われる言語になったかも
とはいえ次はAIの時代だからもう従来の意味での新しいプログラミング言語は必要なくなった

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

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

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

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

本来Rustに触るべきじゃない層にまで浸透しつつあるのはええの

**デフォルトの名無しさん** · 2025/05/02(金) 15:42:00.82

>>939
無駄なコピーが増えて非効率？
そんなのどの言語でも参照を使わずにコピーしていたら起きるだろ
さらに言語によってはコピーしてるつもりがなくても内部でコピーしてることもある
一方でRustならプリミティブな整数などを除いて、コピーは明示的にCopy実装するかclone()した時のみ起きる
そして参照を様々な形でサポートしていいるため、Rustで無駄なコピーが増えて非効率になることはない

**デフォルトの名無しさん** · 2025/05/02(金) 15:48:12.35

Cで構造体を関数に引数渡しするとコピーが走るわけだが、Rustでは同様の問題はないのですかの

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

>>943
ムーブは機械語レベルではコピーと同じだとドキュメントにも書いてある。
つまり素朴な解釈ではコピーされるし、コピーのコストはある。
その上で最適化によってコピーが避けられることもある。
Rust の性質的にエイリアス解析が万全なので C よりは有利に最適化できる。

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

確実に引数のコピーを避けるなら参照渡しだよね。Cと同じかの

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

コストよりも所有権の事情で決めるもんだよ。
参照を渡すかどうかはコストの問題ではなく所有権を渡すのが妥当かどうかの話。

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

スタックサイズに制限がある環境では、スタック使用量を見積もれないとマズいのです。
高速道路公団になっちゃうよ

**デフォルトの名無しさん** · 2025/05/02(金) 17:10:01.59

今どきキーワード引数が無いのは普通に不便なんだけど
追加しないのはどういうこだわりなの？

**デフォルトの名無しさん** · 2025/05/02(金) 17:25:37.72

>>943
Rustの構造体は明示的にCopy実装した時のみコピー値渡しできるようになる
逆にコピー値渡しの必要がなければCopy実装しないのが通常
ちなみにヒープを所有するものを含むとそもそもCopy実装できない

Copy実装していなければムーブ渡しになる
生成コードでのムーブの実装はコピーして元を捨てる(＝それ以降は使えない使われない)
元が使われないため、生成コードでは最適化によりコピーが消える場合が多い

他の関数へムーブしてしまうとそれ以降は使えないため、実際にムーブが使われるケースはいくつかのパターンとなり、それ以外はムーブではなく参照を渡す
ムーブが使われる例としては、初期化作成して渡すだけ、他の型へ変換、他の型の一部に組み込み、など

**デフォルトの名無しさん** · 2025/05/02(金) 17:48:28.97

>>949
ありがとう。慣れれば簡単そうね

**デフォルトの名無しさん** · 2025/05/02(金) 18:13:18.00

>>948
ABI を策定してみて。

**デフォルトの名無しさん** · 2025/05/02(金) 18:30:03.50

キーワード引数とABIは関係なくない？
例えば fn func(foo: i32, bar: i32) というシグニチャの関数について、
呼び出し側で func(bar: 10, foo: 20); のように記述したものが func(20, 10); に置き換えられるような仕組みだし、
コンパイル時に解決する問題な気がする

そもそもRustは (C互換のコードを除いて) 安定したABIを持ってないんじゃないっけ？

**デフォルトの名無しさん** · 2025/05/02(金) 18:34:07.60

>>943
コピーしたくなければポインタで渡すだけでいいんだぞ

**デフォルトの名無しさん** · 2025/05/02(金) 18:53:01.38

キーワード引数は関数の型との兼ね合いだろうな
fn foo(a: u32)
を
fn foo(a: u32, b: u32 = 0)
に変えたときに
F: Fn(u32)
に渡せるかみたいなややこしい話が出てくる

最初から
fn foo(a: u32, opt_args: FooOptArgs)
で頑張ってもらった方が分かりやすい

**デフォルトの名無しさん** · 2025/05/02(金) 18:57:27.48

オプション引数はそのままOption<T>型の引数で使われていて困らないね

**デフォルトの名無しさん** · 2025/05/02(金) 19:34:53.93

キーワード引数があれば、Builderパターンとか要らなくなるんだけど

**デフォルトの名無しさん** · 2025/05/02(金) 19:49:08.87

>>944
copyが発生しうるmoveのときは暗黙でcopy出来るかどうかderive(Clone, Copy)
暗黙にcopy出来ないけどcopyの必要なmoveが起こるときはコンパイル時にエラー

**デフォルトの名無しさん** · 2025/05/02(金) 19:49:28.92

>>954
何もややこしくない
それは単純に「不可」とするのが一般的で、必要なら適当に部分適用すりゃいいだけ

**デフォルトの名無しさん** · 2025/05/02(金) 19:51:56.60

カリー化を覚えよう

**デフォルトの名無しさん** · 2025/05/02(金) 19:54:40.88

>>956
ホントに？
具体的にどのような生成コードになるの？
それらの引数はどのように関数に引き渡されるの？

**デフォルトの名無しさん** · 2025/05/02(金) 19:55:06.57

>>955
doudt

**デフォルトの名無しさん** · 2025/05/02(金) 20:07:31.93

オプション引数は結局Option型などで渡すか、あるいは、省略時の値として長い引数の個数を渡すしかない
それを避けるには可変個引数にして引数の個数を持たせて処理していくが効率もよくない

**デフォルトの名無しさん** · 2025/05/02(金) 20:10:27.21

他の言語を知っているといろいろと勉強になるから使った方が良い

**デフォルトの名無しさん** · 2025/05/02(金) 20:14:10.43

>>960
それは952も示している通りコンパイル時に呼び出し元に展開するだけ
互換性の問題はあるが実用上問題になることは稀だ
Kotlinのようにランタイムのペナルティを許容して被呼び出し側で条件分岐する流派もあるが、Rustはそっちは選ばないだろう

**デフォルトの名無しさん** · 2025/05/02(金) 20:14:30.16

>>957
繰り返すがここで言うコピーは機械語レベルでのコピーの話、ビットパターンのコピーの話をしてる。
(実行コストについての文脈なので。)
ムーブのコンパイル結果はコピーのコンパイル結果と同一であることの説明であって言語仕様の話をしてないので言語仕様の説明は不要。

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

構造体の初期化をビルダー方式にするとメリットが多い
・長い引数がなく読みやすい
・必要な指定のみメソッドでチェーンで指定すればよく書きやすい
・Rustでは多くの場合inline化されて構造体の各フィールド指定と同じコードになり効率がよい

デメリットは初めて見る人は慣れていないこと
慣れたらデメリットは消える

**デフォルトの名無しさん** · 2025/05/02(金) 20:19:38.05

カーニハンの時代のC言語は仕様上構造体は引数に値渡しできず戻せなかった
実際はある程度をすぎると可能だったらしいが

**デフォルトの名無しさん** · 2025/05/02(金) 20:26:25.98

>>967
K&R 第一版の時点でも将来的に出来るようになると明瞭に書かれていて、単に構想に実装が追い付いてなかっただけ。

**デフォルトの名無しさん** · 2025/05/02(金) 20:32:31.01

呼び出し側も定義する側にとっても冗長なのは普通にデメリットじゃない？
ビルダーは「Rustの制約を考慮すると現状これが最も妥当」くらいのものでしょ
このパターンが「便利だから」という理由で他の言語でも流行る、なんてことは想像しづらい

**デフォルトの名無しさん** · 2025/05/02(金) 20:36:36.68

ビルダパターンはオブジェクトなどの生成が複雑な場合に使われるべき
引数がやや多いと言うだけで使うのは論外
単純なものは他の仕組みファクトリーパターンでも十分では
本当に引数が多い場合もビルダーパターンは適さない

あくまでも生成が複雑なものに限定すべきである
今は過剰にビルダーパターンが使われているけど将来的には減っていくと思われる

**デフォルトの名無しさん** · 2025/05/02(金) 20:43:33.27

>>969
ビルダーで何が冗長なの？
Rustでは提供する側はderive_builderによりコードの冗長はなく非常に簡潔
利用する側はキーワード名指定オプション引き数の代わりにキーワード名メソッドを並べるだけ
全く同じで冗長なし

>>970
単純なものは例えばOption型引数などを使えばよいね

**デフォルトの名無しさん** · 2025/05/02(金) 20:48:35.63

筋肉ビルダーとして鍛えよう。AIには出来ない仕事だ

**デフォルトの名無しさん** · 2025/05/02(金) 20:49:38.85

シグネチャの範疇で済むものをキーワード名メソッドとして外に出して記述している
記述法にもよるが一覧性が低下する