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

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

**デフォルトの名無しさん** · 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秒