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/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

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

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

そして記述漏れが出る恐れが出てくる

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

Option型があると言っても
hoge(None, None, None, None, Some(1))
みたいなのはダサいよね

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

structと整合性がない

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

>>974
根本を理解していない人がビルダー初期化に文句をつけていたのか
デフォルト初期化で困るもの値だけを指定する
見落とすことはない
キーワードオプション引数方式と同じ

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

>>976
嘘を付き出すのはよろしくないかと

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

>>975
そういうケースのために記述性も効率も良いビルダー方式がある

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

>>977-978
理解力が低下してるな

デフォルト値を書き換えるのを忘れると言っている
特定の組み合わせが必要なものがあったとして、それを強制する仕組みがない
それに数個必要な引き渡しがいくつ必要なのかを覚えなくてはならない

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

>>975
それこそキーワード引数を使いたい動機で、最後のsomeにあたる引数だけ hoge(fifth=Some(10)) のようにできると楽
Rustだとそれはビルダーにすべき

>>971
言語仕様として組み込まれてるのとは利便性が全然違うじゃん
外部クレートが必要なわけだし
キーワード引数だと foo 関数の定義だけで完結するけど、ビルダーだと FooOption と FooOptionBuilder のような型の追加まで必要なわけで

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

>>980
忘れる？
キーワード指定オプション引数を付け忘れる
それに対応するメソッドを付け忘れる
どちらも同じことだ
ビルダー方式で欠点は何も存在しない

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

スクリプト言語じゃないとキーワード引数実装無理じゃね

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

>>981
derive_builderを使ったことがなく文句を言ってるのかね
この方式のほうが簡潔で冗長がなくなる
オプションキーワード引数方式だと自分でそのシグネチャを書かなければならなく冗長になる
ビルダー方式は冗長がなく有利

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

アニメーションの毎フレーム毎に呼び出すような、パフォーマンスが大事な関数でもbuilderパターン使えるの？

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

キーワード引数なら完全にゼロコストにできる
ビルダーだと、余計な初期化用の構造体が必要だし、値を指定しているパラメータについても最初にデフォルト値のコピーが走っちゃうからゼロコストにならない

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

他に膨大な議論をしてるのにキーワード引数なんてたいして重要てはない割に面倒なものは後回しだろ。
(一応は名前つき引数の提案は何年も前に出てはいる。)

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

マクロを使えばなんとか

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

>>986
Rustでビルダー方式でも最適化されてゼロコストになっている
生成コードで確認した

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

>>983
コンパイルされる言語でも使うよ (C#やKotlin)

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

>>989
何と比較してゼロコストだと言ってる？

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

昔々、X ToolkitはCでキーワード引数を実現するために
配列を使ってなかったっけ？
末尾に終端マーカーを置き忘れると落ちる

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

>>982
>>982
人間は容易に忘れるし順番ですら間違える
通常のエディタの支援が受けられる関数にした方が良い

.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()と間違える

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

>>990
おお、コンパイラ賢い

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

>>991
構造体のフィールドに値を入れていって構造体を作成しても
derive_builderを使いメソッドで値を入れていっても同じになった
メソッド呼び出しが消えた
ゼロコスト

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

構造体の初期化のために
キーワード付オプション引数の関数のシグネチャを記述するのは冗長でバカげている
Rustのderive_builder利用のビルダー方式が最も簡潔でベスト

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

SerdeやPythonのnumpy並みに「その言語の利用者ならみんな知ってる」ライブラリならともかく、ユーティリティ程度のものでも特定のライブラリにロックインするのがベストなもんかね

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

>>993
キーワード引数なら間違えないのか？

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

>>997
マクロってそういうもんだよ。

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

Rustおじさん論破した

**1001** · Over 1000

このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 39日 4時間 3分 48秒