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(火) 10:31:19.04

>>831
Rustを使えなくて使いたくない人はRustスレに来るなよ
ここはRustを使いたい人や学びたい人のためのスレだよ

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

普通にストローマン論法だね
相手の主張を捻じ曲げてそれに対して批判するやり方

**デフォルトの名無しさん** · 2025/04/29(火) 10:33:11.40

＞　C++使えるならRustも使え
これは間違い

**デフォルトの名無しさん** · 2025/04/29(火) 10:36:53.75

スレを荒らしてる人は自覚ないのかな
ここはRustを使いたい人のためのRustスレ
Rustアンチスレがちゃんと別にあるのだから棲み分けしよう

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

Rustは好きだけど、Rustを過剰に持ち上げるカルティストは嫌い
こういう輩のせいでRustは信者がうざいとか言われるし、まともな開発者にも迷惑がかかる
良い点も悪い点も含めて、言語の特性や現状を正しく認識しようというのがなぜできないのか

**デフォルトの名無しさん** · 2025/04/29(火) 10:54:37.77

>>836
それは100点満点を狙うやつがやること
0でも100でもないグレーなやつはそんなことをしない

**デフォルトの名無しさん** · 2025/04/29(火) 10:59:16.54

>>836
そんなどうでもいい話は専用スレを立ててやったら？
一般的に言語XのスレでX信者があーだこーだ言い続けて許されるとは思えないので

**デフォルトの名無しさん** · 2025/04/29(火) 11:00:35.07

狂信者がrustの地位や評判を落としてるのでその他の人間には迷惑

**デフォルトの名無しさん** · 2025/04/29(火) 11:03:29.06

言語にアイデンティティを求めてる人の極論はともかく、他は別にRustを叩いているようにも荒らしているようにも見えないな
議論をするときには自己のポジションとアイデンティティを自分の中で区別しておいた方がいい
このスレは優しい方で、特にRustを採用できるような分野でやってきたいならそれができないと辛い思いするよ

**デフォルトの名無しさん** · 2025/04/29(火) 11:07:36.96

>>839
そういう陰謀論的な話は専用スレを立ててやるべきかな
ここでやるのは荒らし行為

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

陰暴論でなんでもない

＞　C++使えるならRustも使える

これが間違いだと理解できないのは狂信者だろ
C++は型あり言語からやってきたらだいたいの人はコードを書ける
ただ危険なコードも容易に書ける
Rustはそれを阻止するために縛りがある　危険でない部分でもそれが必要になる

その概念を理解しないとコンパイルエラーから抜け出せないので実用的な成果物は作れない

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

>>842
Rust初心者がコンパイル通らなくて困ってるのかな
どの言語でもその言語の決まりを守らないとコンパイルエラーだよ
C++に関して言えば弱い型付け言語で未定義動作もエラーにしないからコンパイルエラーは少なくなるけど
今は強い型付けで未定義動作を許さない言語のほうが主流になってるよ

**デフォルトの名無しさん** · 2025/04/29(火) 11:35:49.34

>危険でない部分でもそれが必要になる

ギリギリ危険でないコードを不合格にするんだな
極めてなにか効率にたいする侮辱を感じます

**デフォルトの名無しさん** · 2025/04/29(火) 11:50:27.89

可変参照の排他性なんかは場合によっては効率性を犠牲にしても安全側に倒してる例だね。

**デフォルトの名無しさん** · 2025/04/29(火) 11:58:15.87

>>845
あれは参照の競合スパゲッティプログラムを避けることに繋がって良い判断かな
他にもC++のvectorの要素へ参照を持ったままpushしてヒープ移動になる典型的バグも防止できているね

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

C++ を使えている人なら Rust のチュートリアルを読めば簡単な実務を始められるくらいにはなれそうな感覚があるんだけどなぁ。
難易度の高さをしきりに主張する人がずっといるのがなんだかよくわからない。
いや、難しいと感じる人だっているというのを否定するつもりはないんだけどさ……

C++ はかなり面倒な部類だぞ。
その面倒な C++ を使いこなせるくらいの能力という前提を付けられるときに Rust がそこまで激烈にしんどいか？

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

C++からの移行についてはそれほど議論の余地はなくて、周辺環境が許せば移行すればよい、で終わり
C++の開発というのは比較的ニッチかつ保守的なので、C++を使っていて、かつ周辺環境が移行を許す状況というのがそもそも稀

**デフォルトの名無しさん** · 2025/04/29(火) 12:50:13.98

C++が分かるならRustは学びやすい、というのはその通り
だけどそもそもC/C++をやらずに仕事できてる人も今はずっと多いわけで

> C++ はかなり面倒な部類だぞ。
> その面倒な C++ を使いこなせるくらいの能力という前提を付けられるときに
の「前提」というのが既に世間一般の感覚とズレてるのでないかと思う

**デフォルトの名無しさん** · 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回目の名称変更でちょびっと安定してくるやつね