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/29(火) 13:27:22.82

C++は学んだことないけど
スタック領域とヒープ領域の違いは理解できていたからRustを学ぶうえで特に困ったことはなかったよ
ライフタイムも関数を抜けたら消えちゃうスタック領域とその変数に管理されて依存するヒープ領域
関数の呼び出し入れ子で祖先側のスタック領域は子孫側のスタック領域より長生きというだけの話だった

**デフォルトの名無しさん** · 2025/04/29(火) 13:56:05.54

>>849
このトピックは >>842 などに対する反論なのであくまでも C++ は使えることを前提にしたときという限定的なもので、平均的なプログラマにとっての Rust の難易度については全く述べてない。
C++ を充分に使いこなせている人が多くないことは認識しているよ。

C++ を使うときは C++ が必要なときなので C++ みたいなことをもっと楽に出来るなら喜ばしいだろう。
C++ や Rust みたいなものが必要ないなら使えとは言わんよ。だって必要ないんだから。

**デフォルトの名無しさん** · 2025/04/29(火) 14:28:41.68

Rustは脳死で使えるイディオムが豊富なので楽
C++は時代によって流儀が変わりすぎる

**デフォルトの名無しさん** · 2025/04/29(火) 14:32:21.54

昔からム板は平均より遥かに上のひとしかおらんがな
平均的なプログラマーは3年目ぐらいからは勉強すらしてないし

**デフォルトの名無しさん** · 2025/04/29(火) 16:32:22.17

>>852
C++ は設計理念のひとつとしてプログラマに選択の余地を与える (間違いの可能性があっても) というものを含んでいるので意図通りの結果ではある。
分野ごとの流儀や時代の要請が言語の流儀と噛み合わなくなると単にその言語が使われなくなるだけなので長く生き残るには (汚くても) 色々とできるように詰め込むしか仕方がないんだ。

**デフォルトの名無しさん** · 2025/04/29(火) 16:32:23.99

ム板が平均よりはるかに上？

**デフォルトの名無しさん** · 2025/04/29(火) 16:48:30.04

大半の人は情報収集しないしコミュニティに属さないのは本当だ。
そういう意味では多少なりとも交流を持とうとしているのは平均以上の可能性が高い。
その一方で、ガチの上級者はガチの業務をしてるしガチなコミュニティに属しているからこんなとこにいない。

**デフォルトの名無しさん** · 2025/04/29(火) 17:51:47.71

>>854
Rustはどうしても必要不可欠ならばその汚いもの(unsafe)を関数やモジュールやクレートの中に閉じ込めて清らかな(safe)インターフェイスを公開する枠組みを持たせたね
そのように閉じ込めることでコンパイラによる自動保証の外の範囲も限定して管理できるようになり安全性と柔軟性や高速性の両立バランスをRustは手に入れた

**デフォルトの名無しさん** · 2025/04/29(火) 18:17:31.81

交流しているのは評論家だけ
クリエイターの能力値はDS並に謎に包まれている

**デフォルトの名無しさん** · 2025/04/29(火) 18:25:25.23

いちいち訳語につっかかったり普及してるかどうかのレスバしかしてない奴らの集団が平均以上なわけないじゃん

**デフォルトの名無しさん** · 2025/04/29(火) 18:37:35.61

Rustでイディオムっぽく感じるのって個人的にはビルダーくらいな気がする
オプション引数やオーバーロードが無いから慣習的にビルダーを多様する、みたいなもので
他は割と言語デザインに沿って素直に書けるという感じ

**デフォルトの名無しさん** · 2025/04/29(火) 18:45:02.43

どっかでビルダーパターンは良くないぞ、考え直せって記事を読んだ気がするが
内容を忘れてしまった
誰か教えて

**デフォルトの名無しさん** · 2025/04/29(火) 19:13:59.81

ウェブショッピンクサービス ViaWeb (後に Yahoo に買われた) の創設者であるポール・グレアムはイディオム (デザインパターン) が必要とされる言語は悪い言語だと述べてる。
頻繁に使われるパターンがあるならそのパターンは言語機能やライブラリになっているべきで、ユーザがパターンに沿って書くのはあほくさいという話。

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

>>857
汚い部分を隠して残る綺麗な部分は Rust の流儀だ。
Rust では Rust 的ではない抽象化ができないようになっている。

C++ 的な混沌よりは Rust の流儀を強制されたほうが今のところはマシなんだが、そうはいっても未来がどうなるかはわからんからなぁ……という現実が理想的ではないという話。

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

リスパーの言うことなんか聞くな

**デフォルトの名無しさん** · 2025/04/29(火) 19:40:07.38

BufWriterとかでnewにinnerを丸呑みさせて用が済んだらinto_innerで摘出するパターンもRust特有だと思う
他の言語だとinnerは参照で渡しそうだけどRustでそれやると可変参照のライフタイムでカオスになる
このパターンに慣れるまで何回かカオスを経験した

**デフォルトの名無しさん** · 2025/04/29(火) 19:41:32.29

Common Lisp は有用な選択肢だと思うけどなあ。
ガッとラフに作れるというのと機械語レベルでのチューニングもできるという良いとこ取りだ。
ただ、ユーザが少ないと使えるライブラリも少なくて、だからユーザが伸びないというスパイラルがある。
物量が正義というのが現実なんだよね……。

**デフォルトの名無しさん** · 2025/04/29(火) 19:45:09.79

builder嫌い
たかが構造体にパラメータ詰めるだけのことにいちいちオリジナリティを出すな

**デフォルトの名無しさん** · 2025/04/29(火) 19:52:58.08

>>848
RustとC++の相性は最悪

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

>>865
それ分かる
なんか名前無いのかな？

**デフォルトの名無しさん** · 2025/04/29(火) 21:09:44.91

>>861
これかな？
ビルダーの代わりにinit struct pattern というのを提案してる
https://xaeroxe.github.io/init-struct-pattern/

ボイラープレートが少なくて簡単だけど、初期化用の構造体のフィールドがpublicなのは好みが分かれる
現状はビルダーの方が主流
外部に公開するライブラリのAPIとして使うのは微妙だけど、自分たちのコードの内部で使う分にはアリかもしれない

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

>>870
それだ！
追記された結論は、マクロでビルダーを生成させましょう、なのか……

**デフォルトの名無しさん** · 2025/04/29(火) 22:02:39.41

車オブジェクトに高度を変えるメソッドがあったらおかしい
空飛ぶ車オブジェクトは一時的にメソッドの存在自体を消すシステムをもつべき

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

こっち見といたほうがいいと思う
https://kerkour.com/rust-abolish-the-builder-pattern

YakShaverInitをinitしてYakShaver返すとかいろんな意味で微妙
YakShaverBuilderをbuildしてYakShaver返す癖が抜けてない

**デフォルトの名無しさん** · 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実装していなければムーブ渡しになる
生成コードでのムーブの実装はコピーして元を捨てる(＝それ以降は使えない使われない)
元が使われないため、生成コードでは最適化によりコピーが消える場合が多い

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