Rust part29 YouTube動画>1本 ->画像>2枚

公式
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 part28
http://2chb.net/r/tech/1742805420/

ﾜｯﾁｮｲスレ
プログラミング言語 Rust 4【ﾜｯﾁｮｲ】
http://2chb.net/r/tech/1514107621/

>>前969
>このパターンが「便利だから」という理由で他の言語でも流行る

C++のstreamのsetwみたいでださいな

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

builderのコストは下記。名前付き引数とデフォルト値を使用した方法であれば全て不要で単なるnewの呼び出しとなるが、これらが全て最適化で消えるのか?
* パラメータ用の構造体(以下P)のアロケーション
* 構造体Pのデフォルト値での初期化
* 構造体Pのフィールドに対する上書き
* 構造体Pから最終的に作成する構造体への各フィールドの逐次的なコピー
* 構造体Pの破棄

全部消える。 構造体初期化の文法で書いた場合と同じ。
最適化しない場合の素朴な処理でもそんなに気にするような深刻な差もない。

>>4
compiler explorerで示して

は？

君は見たか？
複おじがぐうのねも出ずに論破された所を

過視化するな

大体のケースでビルダーパターンはアンチパターンと主張し続けて20年以上経つ

最適化されることを主張するなら証拠を示すべきなのは当然だが、
コピーの最適化を前提にするのなら例えば安易にCopy実装したりcloneしたりすんな、
みたいな意識高い言説は多くの場合無意味になっちゃうわけだけど、Rustおじはそれでいいのだろうか

この流れは流石に重箱の隅をつつきすぎじゃないの？
Rustのビルダーはオプショナルな動作を指定するパターンでしかないし、これが最適化されないと困る場面もそんなに無い
せいぜい、ヒープを使うデータについてビルダーを消費するか、中身を clone するかを検討するくらいでしょ

コピー動作が問題になるとしたら、例えば数十万とかの要素を持つ配列の for ループ内でビルダーを使う場合が考えられるけど、それならビルダーを1度だけ作ってそれを使いまわせばいいし

「Rustにも他の言語のオプション引数やキーワード引数があると嬉しいよね」という話なら同意だけど、ビルダーのパフォーマンスはそんなに重要な話でないというか

ストローマン論法

匿名の藁人形は作れない
作れるのは名指しできる個人や団体だけ
だから実名のSNSは嫌なんだよね

>>10
一理ある

RustやC++のゼロオーバーヘッドが意味するところは結局「俺達のコードがどのように処理系によって最適化されるかを俺達は知っている」ということであって、
どのような最適化がなされるかについて一定の透明性があり結果が自明であることが重要
その点で、コピーの最適化を前提にするってのはかなり微妙

「かいたとおりにうごく」が最適化では成り立たないからなぁ

昔ある言語でcontinueがないぞと散々言われて、gotoが実装されたことがあった
何もしないのと比較すればcontinueの提案は優れていたかもしれないが
それは比較対象との相性が良かっただけ

数年前に読んだ書籍にcontinueは使うべきでないと書かれていて驚いた

>>10
安易に clone すべきでないのは所有権管理の話で、実行コストの話とはレイヤが違う。

スマホとPCの作業を効率化したい--「Copilot Vision」の便利な8つの活用例
2025-05-03 07:00
https://japan.zdnet.com/article/35232549/


1 プログらまーまこれを改造してるので上記以外の状態でも使用できるようにしている

2 すでにプログラムがあるので１～コードを作成する必要が無い

ボイス・トォ・スカルの本態が一般パソコンにまで来たのでつい買い捨てができるようになった
マネーロンダリング 談合 インサイダー などがはかどるといわれる

>>3
それらは最適化ですべて消えて最終的な初期化構造体のみになった
イテレータメソッドチェーンなどの時と同じ原理
それはもっと極端で各イテレータ毎にいくつ構造体があろうと縮約したりレジスタ化されたりして各構造体は消えていく

複オジ脳やべぇな
視野が狭すぎる

>>19
cloneして意図通りに動作しなくなるならそりゃ普通にcloneの実装もしくは利用者側のバグだろ。作法の問題ではない。
そんな中身を理解しないままコピペしてるバカみたいな低次元のことは誰も問題にしていないでしょ。

>>10
区別できないバカなのか？
ムーブの時などを含めて実態がコピーになるといってもコピー元は二度と使われないのだから最適化できる

一方でclone()などはコピー元をその後も使うためにコピーしている
コピー元を二度と使わないならclone()の必要がない
そしてコピー元をその後も使うから最適化の前提さえ成立しない

それは少なくともbuilderの最適化の文脈においては明確に誤り
実際、derive_builderはcloneが最適化されることに依存している

RustやC++のムーブも同じで一次的にはコピーをして元を使わないため最適化できる場合が多い
一方でプログラマがコピーやクローンを明示的にした場合は元が生きていて全く異なる
そもそも元も後で使いたいからコピーしているわけだ
だからムーブとは異なり最適化でコピーが消えることはない
もちろん後で使いたい場合はコピーして渡すのではなく参照を渡すのが正解だ
したがってプログラマはコピーを可能な限り避けるべきである
暗黙のコピーが行われるプログラミング言語では意識せずコピーしてしまう
プログラムを見ただけですぐにコピーしてあることがわかる方が望ましい
RustではCopyトレイト実装した型のみ暗黙のコピーが起きる
前述のように数値などはその方が有利なので最初からCopy実装されている
ヒープを用いない型ならばプログラマは自由にCopy実装できるがコード上でそれが明示され読む側は気付ける
サイズが大きく参照で扱った方がよい型をCopy実装していればおかしいことがわかる
一方でヒープを用いていればCopy実装はできないがClone実装はできる
これはコード上でfoo.clone()とコピーすることを明示的に記述する必要がある
したがって参照を使えばよいのに無駄なコピーをしていればすぐにわかる

無駄をなくそうとしたらコンパイルが通らなくなった
っていう質問を処理するコストが高いよね
実行時のコストではなく

読む気が失せる分だけど読んだ
ところが間違ってるというか言い過ぎだと思う

クソデカ長文とかどこでも現れる辺りRustとRubyって似てるなーと思った次第である

この程度で長文扱いって普段どれだけ文章を読まないんだよ。

暗黙のコピーが行われるプログラミング言語は大体値のコピーを行っている
値はこの場合参照なのでコストは限りなく低い

暗黙でポインターをコピーしてそれがコストが掛かると言う人はいないだろ

>>30
読む気が失せるのは文章が下手くそだからであって長いことは関係ない
そしてボロボロと誤りと言うか独断に基づいた誤りがたくさん入っている

複おじはAIに下書きを食わせて推敲してもらうべきだと思う

むしろAIに生成させてるんじゃないかと思われる
同じことを何度も何度もダラダラ箇条書きに
眠くなるわ

見たい所だけ切り取ればいいんだよ
切り取りや編集の責任をトリクルダウンするために、書く側は編集をしないという戦術だろうけど
それはどうでもいい

AIではないよ
小論文など書くときに指摘されるけど、考えをまとめないでずらずらと続く文章は修正しろと言われる

一部の行頭だけ切りだすと以下のように前の文章とつなげて書いてるから読み手にはわかりにくい
↓これが連続して使われているので読み手への負担になっている

一方で
そもそも
だから
もちろん
したがって

人間の脳もスタック状になってるんでドンドン文が接続されていくと脳内にスタックが作られてスタックがチェーンして肥大化して理解が苦しくなる
これは当たり前

文章がダラダラと接続されているものは、まともに推敲されていないので、基本的に読むコストに比べて得られるものが少ない
雰囲気で書かれているので間にも間違いや矛盾が含まれている

読み手に対して読みやすさが考慮されていないのでふつーに読まなくても良い

ここでようやくchatGPTに聞いてみた

✅ 読みにくさの主な原因


1.接続詞やつなぎ言葉の多用による文の長文化

「一方で」「だから」「そもそも」「もちろん」「したがって」などの論理接続語が多く使われ、それぞれの文が長くなりがちです。
　
結果として、読者は一文ごとの意味の切れ目を捉えづらくなります。


2.
文構造が複雑で、主語と述語の対応が曖昧

「コピーして渡すのではなく参照を渡すのが正解だ」のように、主語が省略されていて読み手が文脈を補う必要があります。



3.抽象的な話が続き、具体例や対比が乏しい

例えば「ムーブはコピーと違う」と言いつつ、具体的にどう違うのかの明示がないため、読者が前提知識を持っていないと理解しにくいです。


4.
視点の切り替えが頻繁

ムーブとコピー、CopyとClone、参照と値渡しなど、話題が細かく切り替わっているが、その都度明確な導入がないため混乱を招きます。

もっと詳しく書け、とAIが言っている
みんなAIに騙されてる

さっき書いた部分は連続で接続されている

A 一方で　B　=　C（文意）
C　そもそも　D = E（文意）
E だから　F　= G（文意）
略
Y　したがって　Z

Zを理解するためにAから後を状態や文意を含めて全部覚えておかないといけない

読み手を疲弊させるには接続を多用したらいいとも言える

みんな読みやすい文を書いて良い大学、良い企業に入りたいとか
読みやすい文を書いて本を出版して売りたいとか
金の為に文を書いているからな
文なんて記号に過ぎない意味が伝わればいいのよ

意味が伝わればいいとか言ってるやつが書いた文章はたいてい伝わってねーから。
プロが推敲したってきちんと伝えるのは難しいのにそれ以下の質ならそれ以下にしか伝わらないよ。

国語の天才が推敲すると数学も理科も社会も意味がわかるようになるなら
学校で国語だけ教えてればいいだけだろボケ

確率扁微分方程式を国語で説明してくれ

三行でよろぴく

教
科
書読め

もちろんでNGしとけ

AIにコードを生成させるならもうRustはいらない子だよね

>>48
こういうのはビッグウェーブに乗る力であって国語力ではないね

他人に自分の主張を理解してもらいたいなら、少なくともわかりやすく書く必要がある

いつも例の人の文章を読んでると念仏を聞いてるような気分になる
誰かが眠くなると書いてたけど自分もその印象が強い

言葉を吐くマシーンの様で理解してもらおうなどと思ってないんだろうなと

理解されるためならなんでもしますという意志はたいして重要ではない気がする
なんでもするって言わせたい人にとって重要なだけだろう

文章の読みやすさを意識しないプログラマのコード品質って大丈夫なのか？

理解されないなら主張としては存在しないのと変わらない
公共の場にただのデカいゴミがあってみんな邪魔だなって思うだけ

derive_builderのドキュメント見てみた
Rustはこれらのclone呼び出しも最適化して賢いと書かれている

https://docs.rs/derive_builder/latest/derive_builder/#-performance-considerations

Performance Considerations

Luckily Rust is clever enough to optimize these clone-calls away in release builds for your every-day use cases. Thats quite a safe bet - we checked this for you. ;-) Switching to consuming signatures (=self) is unlikely to give you any performance gain, but very likely to restrict your API for non-chained use cases.

derive_builderはRustのセマンティクス的には割と非効率な実装を採用していて、
常に一度のbuildだけの使い捨てに特化したバージョンも提供するなど制約を強めることで更にセマンティクス上効率的な実装もありうる
でもそうしないのは実際最適化で変わんなくなるんだろう
コンパイラの解析に委ねる前にセマンティクス上の最適を目指すのがRustの大きなコンセプトだと個人的には思っているが、その観点ではあまり理想的とは言えないやり方だし、
Rustの言語側にも改善の余地があるかもしれない

#[builder(pattern = "owned")]だと使い捨てになるんでしょ
こっちをデフォルトにした方がいい気もするけど１回しかbuildしない場合は最適化されて同じになるらしい

さらに限定したケースでRustコードの段階で最適化できる可能性もあるかもしれない
この初期化ビルダーがプログラム全体のネックになる時が来たらチャレンジするかな

現実には誤差の範囲内なのでこのderive_builder利用で十分と思う
初期化関数を自分で用意せずとも構造体への属性修飾だけでよい利便性は他のプログラミング言語と比べてもベスト

でもビルダーパターンは潜在的にバグ発生の要因をはらんでいる

>>58
あらゆるパターンが潜在的にバグ発生の要因をはらんでいるから意味のない発言
具体的にderive_builderでバグ発生の要因があるなら指摘して

IDEのサポートを受けた元で初期化関数を使うのがベスト
単純にビルダーパターンで起こる記述漏れ、順序の間違い、重複指定バグが減る

>>59
前スレで書いたけど複おじは反論不能だったみたいでスルーしてたな
複おじ論破されて草だった

>>60
手動で初期化関数を作るのは面倒かつバグの入る余地もあり劣ってる
derive_builderは利便性も良いからこれより優れているものを持ってこないと話にならないかと

>>61
「おじ」使いのキチガイの人かよ
具体的にderive_builderでバグ発生の要因があるなら指摘しなさい

>>62
そんなもんテストでわかるでしょう

テストしないところでビルダーパターンはバグを起こす可能性が高い
人間がビルダーパターンのメソッドに注視して思考してパラメーターを指定する場合は問題が比較的起こりにくい
それをコピペや思い込みで書くとヒューマンエラーが入り込む余地がある

ビルダーパターンで複数行でメソッドを記述した場合には列レベルで記述が抜けることが考えられる
行で記述しても対応ミスなどが起こる

複おじは問題点をわざと見ないふりをしている

>>63
前スレ見ろ
おじいちゃん

>>64
わざわざ手動で初期化関数を作ってテストするってか
面倒なだけでメリットが全くない
利便性も良いderive_builderより優れているものを持って来なされ

>>66
前スレで問題点を指摘されて論破されて何もできないで誤魔化してるんでしょ
みっともない

>>67
誤魔化してるのは君だ
derive_builderに問題点があるなら指摘しなされ
derive_builderよりも利便性の高い方法があるなら持ってきなされ

>>68
ストローマン論法だな

自分の主な主張はで前スレで書いたようにビルダーパターンは複雑なオブジェクト生成で使われるべきで
普通のオブジェクト生成ではコンストラクタなどの初期化関数を使うべきと言うもの

理由はビルダーパターンはヒューマンエラーが入り込む余地が非常に大きいから
初期化関数はIDEの補助があるのでビルダーパターンで起こる問題が発生しにくいか発生しない

それにしても「～しなされ」って言われたのは人生で初じゃないかな

ガチおじいちゃんじゃん　複おじいちゃん

>>69
詭弁はよろしくない
derive_builderは自分で初期化関数を書く必要がない
他の方法では初期化関数を書く必要がありヒューマンエラーが入り込む余地があるのはその通りだ
利便性も良くてその問題が生じないderive_builderが優れている

>>71
ストローマン論法だな

こちらの主張していない内容を勝手に作り出してそれで話を続けている

初期化関数はビルダーパターンのメソッドの適用ミスで容易に起こりうる　重複、順序ミス、記述漏れに対して有用
初期化関数自体は一回書くだけ

各所で必要になる単純なオブジェク生成の場面ではビルダーパターンはヒューマンエラーが入り込む恐れがある
それを初期化関数で行えばIDEの補助を得られるのでミスが減る

>>73
先ほどから主張しているderive_builderを使わなければIDEの補助が得られるからミスが減るの意味がわからない
derive_builderを使えば初期化関数の用意はお任せなので提供側のミスはない
利用側はデフォルト値以外の値指定をしたい時にそのメソッド候補がIDEなどで補助があるのでミスが起きようがない
derive_builderを使った方が提供側も利用側もよいのではないか

まだバグを起こす前の時期に、バグを起こしやすい習慣をやめない、まつもとなかいがいたとする
その時点で彼らをどのように処分したいのかね

>>74
ストローマン論法をやめなされ

初期化関数を使うと指定の重複、順序ミス、記述漏れが起こりにくいのは事実だろう
まず単純な初期化関数で指定の重複が起こるのか？
func( a,b,c,d....にたいしてaを重複指定させられるのか？
これすら判らないなら話すだけ無駄

「～しなされ」っていうのって少なくとも80歳以上じゃないかと

>>76
derive_builderで提供された場合も問題は起きないよね
仮にそのaを重複指定してしまい
.a(123)
.a(123)
と書いてもバグは起きない
可読性もよいからそれ自体を起こさないね

derive_builderは提供側も利用側もデメリットがなく最も良い方法にみえる
もっと良い方がある？

>>78
.a(123)
.a(321)

で始めの123が正しい場合問題になる

>>79
aを123で初期化したいなら前者しか起きようがない
aを321で初期化したいなら後者しか起きようがない
そんなナンセンスな指摘しかデメリットらしきものを見つけることが出来なかったということは
derive_builderが最も良い方法であることを認めたと理解してよろしいか

the bookによるとnewtypeパターンってのがあって
traitをimplすることが目的みたいだけど
どうにかすれば名前つき引数にも使えそうなんだよね

順序ミスについて
これは前スレでも書いたのを再掲

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

色指定でよく目にするのはRGB方式だけどコンピュータービジョンなどではBRGがよく使われる
最初にGRBとして覚えていても実際各段階になるとRGBと混同することがある

初期化関数では
func(P[0],P[1],P[2],...
等で考えなくても書き間違える可能性が低い　それにIDEの補助でパラメーターについてポップアップが出るのでそれでも間違いは減る
バグに気が付いて書き直す際に2か所の書き換えをしないで
.R(p[0]).R(p[1]).B(p[2]).build()　と言う間違いも入り込みやすい

書いてるそばから間違えている
BGRが正しい

>>80　の疑問については
>>82　で書いたようなミスで重複と記述漏れが発生する

そういうところまで考えたことないだろ？コーディングしてる？

>>82
その比較はおかしい
デフォルト値以外のみを指定して初期化する話なのだから
それは✕　func(P[0], P[1], P[2],...
これが○　func(R=P[0], G=P[1], B=P[2], ...

記述漏れについては
n個パラメーターを指定しないといけないのにn-1個しか記述していない場合
目で見てn個すべて指定したのかn-1個指定したのかなんて数が多くなると判らない

これは初期化関数では基本的に起こらない
数が多いとやはり大変だけどIDEの補助があったりコンパイル時にエラーがでる

ビルダーパターンでは実行時エラーや思った挙動にならない時点でしかミスに気が付かない

>>85
誰もそんな縛りは指定していない
普通に初期化関数使えばよい

これ以降ストローマン論法禁止

オプション値の初期化の話だもんな
必須値の初期化の話ならRustでも
fn foo(red: Type, green: Type, blue: Type)
とするだけなのでderive_builderは使わない
だから>>82の指摘は間違ってる

>>89
それはお爺さんにもわかりやすいように簡易化して書いているからだろ

ビルダーパターンは上にあげたようなヒューマンエラーを誘発する仕組みなので基本的に使わない方が良い

生成に柔軟性があり複雑な場合にはビルダーパターンを適用するのは良い
一般的なオブジェクト生成に対してはヒューマンエラーに弱くアンチパターン

>>87
プログラミングの基本的なことを理解していないのかい？
derive_builderを使うようなオプションで必要な項目だけ値を指定して初期化するケースを1つの初期化関数を単体で済ませようとすると
どんなプログラミング言語でもキーワード付きオプション引数を使うことになる
具体的にはf(1, 2, 3, option1=111, option5=222)などの指定方式になる
option5など名前を指定しないとどの項目を指定しているのか区別がつかないためだ

>>92
その指定だとしても重複は大体の言語ではエラーになる
ビルダーパターンは重複を検知しないのでヒューマンエラーが入り込む

>>91
オプション初期化のない一般的なオブジェクト生成でderive_builderを使う人はそりゃいないよ
それは普通にRustでも引数固定の初期化関数でおしまい

前スレを読んだけど最初から特定項目だけオプション初期化する話
だからderive_builderが最も優れているという結論になってる

>>94
重複すら検知できないのに？

重複を検知するには内部にフラグを持たなくてはならない
もちろんこれは実行時エラーになる

実行時エラーを検出するにはテストで網羅しなくてはならない

我々はコンパイル時にエラーが検出されるのを利点としてRustを使っている
それなのに実行時エラーに頼らざるを得ないビルダーパターンは劣っている

結局、話をまとめると
ビルダーパターンで
foo()
　.item1(value1)
　.item3(value3)
　.item7(value7)
と書くか

名前付きオプション引数で
foo(
　item1=value1,
　item3=value3,
　item7=value7,
)
と書くか

これだけの違いだよな
どちらも変わらん慣れだけの問題
どちらも見た通りなので指定ミスや重複ミスなど起きようがない

あとはそれらを提供するライブラリ側だ
いずれも普通は初期化関数を自分で書かなければならない
Rustでderive_builderを使えば構造体に属性を付けるだけで済みシンプルかつミスも起きない
少なくとも現状でderive_builderに欠点は見つかっておらず最善な方法であるといえる

>>99
結局何も見なかった利かなかったふりして自分のいいように矮小化し続けてるな
呆れるよ
80代になると何も感じなくなるのだろうか

的外れな言いがかりでスレを荒らしてる人は
derive_builderより良い方法を具体的にコードで示せ

精神論で間違いは発生しないと言うのは容易
間違えたら間違えた人間が悪いと言う

ビルダーパターンには結局ヒューマンエラーを防ぐように十分な対策がなされていないだろ
わかっていながら無視をする
c++精神だね

>>101
ファクトリーパターンなどを使えばよい
メソッドの種類を充実させるだけだ

ビルダーパターンはヒューマンエラーに弱い
毎回論理的構造を構築しなければならないがそこにバグが紛れ込む可能性がある

それよりも初期化のための関数を作るべき

derive_builderは全自動だからミス起きなくね？
derive_builderより好いのがあるならコードを出して

おじいちゃんは乱心して同じことを何度も書いて来る
普通の人間にはすでに書かれた内容で理解出来るのに知らないふりして実行時エラーやバグを許容している

これも相手の疲労を狙ってくるくだらないやり口なんだろうと思うが

>>104
そんな方法は存在しないよ
>>99が挙げてる二つの方法しかない
もしあるなら同様のコード例を示そう

他のスレでもでもおじいちゃん的書き込みを見ることがある
それに対して80代ではと書くと100%反論される

今回は反論されないところを見るとやはり80代以上なんだろうなと

>>108
＞　それよりも初期化のための関数を作るべき
これが全てだろう？
いくら何でも馬鹿すぎるだろう？判らないの？

Builderはオプションの追加実装が破壊的な変更にならないメリットがあるな
生成関数に全部渡す方式だとパラメータが増えて破壊的になる
新しい生成関数を追加すれば破壊的にはならないけど
オプション追加する度に生成関数増やすのはあほくさい

>>103
もし暇だったら↓のRegexBuilderをFactoryで実装する場合の関数の個数を見積もってくれ
https://docs.rs/regex/latest/regex/struct.RegexBuilder.html

>>110
今回のようなケースで初期化のための関数は>>99が挙げてる二つの方法しかない
もし他に存在するなら同様のコード例を示そう

なんで自分にレスしてんの？

>>111
他の言語でもRegexは普通にメソッドを使って解決してるけど…
長いならregexoption構造体作って指定したらよいだろう？他ではそうしてる物もある

Rustしか使ったことがない前提なのかな

さすがに馬鹿の相手をするのは疲れてきた…

おじいちゃんは他の言語は使えないの？しょうもない雑魚レベルの質問しかしないのはなんで？

デフォルト値に対して必要分だけオプション指定したい場合
まともな方法はどのプログラミング言語を使って>>99のどちらかの方式になる
まともではない方法としてはオプションの有無ごとの組み合わせ数の分だけ大量の関数を用意する手もあるけど論外だ

何で間違ってることを繰り返すの？

macroで重複チェック可能なbuilderは書けるとか書いてこないのは意外なんだけど

実行時チェックの話もchatGPTの方がまともで面白い回答や提案をしてくれる

>>118
設定値の重複チェックとか誰も気にしないからでは
重複設定によるバグとか生成関数に渡す引数の順番を間違えるバグと同じくらい起こりにくいし

一部の必須値の設定を忘れるケースは普通にあるでしょ

>>121
必須値は様々な対応が取れるため問題は起きない
・オプションにしない
・全体の整合チェックの一貫として必須値の有無の判断を入れる
・ビルド最終メソッドで指定する　(ex. std::fs::OpenOptions::open)

一番オーソドックスなのが抜けてるな
RegexBuilderの場合はRegexBuilder::new()にパターン文字列を渡してる

>>123
先頭の「オプションにしない」が
その最初に必須値を渡す意味
わかりにくてすまん
フォローサンクス

名前付き引数であれば必須パラメータも名前付きで渡せるため順番の間違いによるミスが発生しづらく可読性も高い
derive_builderを使う以上は必須パラメータもメソッドで渡すしかなく実行時エラーの可能性が排除できないしチェックのために余計なランタイムコストを払う必要がある
文句はderive_builder作者に言ってきた方がいいぞ

狂信者には何を言っても無駄であり論理的な考えを持ち合わせていない
こちらがいくら論拠を提示してもRustが正しいderive_builderが正しいとそんなミスは起こりえないと繰り返すのみ

正しくないのはお前の頭だろう

ビルド方式に問題はない
既出のstd::fs::OpenOptions::open()や
regex::RegexBuilder::new()など
Rustはビルド方式でも対応しており問題になっていない

>>125
名前付き引数であろうとなかろうとバリデーションは必要でそれは実行時エラーとなる
そしてResultを返すから実行時エラーで問題ない

>>82
順序ミス対策なら
.rgb(p[0], p[1], .p[2]).build()
でいいんじゃね？
Rustてこういうのできないんだっけ？

>>127
＞　少なくとも現状でderive_builderに欠点は見つかっておらず最善な方法であるといえる

じゃなかったのか？方針変えたのか？

“イリヤ神”がまたやった　動画生成AI「FramePack」が革命的なワケ
2025年05月05日 07時00分更新
https://ascii.jp/elem/000/004/267/4267160/
　4月17日に登場した動画生成AIプログラム「FramePack（フレームパック）」が世界的に衝撃を与えています。PCローカル環境で動画AIを動かすには、少なくともビデオメモリー（VRAM）が12GBあるビデオカードを搭載していないと難しいというのが常識でした。ところが、VRAM 6GBでも安定的に動作させられるため、一気に動画AIの裾野を広げそうです。開発したのは、画像生成AI分野で「ControlNet」や、使いやすいツール「Fooocus」などを開発してきたことで知られる、スタンフォード大学に在籍中のIllyasviel（イリヤスフィール、以下イリヤ）さん。既存の方法論にまったく違ったアプローチでブレイクスルーを引き起こす、“イリヤ神”のアプローチに再び注目が集まっています。
中略
　AI動画を作ってみたいけれども、スペックが足りないために諦めていたという人が次々に自前の環境で試すようになってきました。既にワンパッケージでインストールできる環境も整えられているため、スタートも簡単です。様々なファイルをダウンロードしてくるため、初期設定は2時間くらいは見ておく必要があるものの、圧倒的にハードルが下がりました。

>>127
名前付き引数のミスは大体言語でコンパイルエラーになるので的外れ
ビルダーパターンより安全性が高いだろ

>>126
Rustが間違っていると主張したいなら問題点と代替策を述べればよい
本当にそれが示せるならRustはIT大手各社も用いているため世界中にインパクトを与えられるぞ
この我々の5chのやりとりすらRust製のPingoraを経由しているほどネットインフラ各所でもRustは使われている

>>132
何言ってるんだよ
最後の一行が全てだろ

本当に暇さえあれば関係ない話題で誤魔化そうとするよな
脳がストローマン論法で浸食されているんだろ

それよりもbuilderパターンは初期化時の情報指定漏れをコンパイルエラーにできないのがRustらしくないと思う。

>>128
個別パラメータとして与える必要がないからその通り
Rustの言語仕様としてはそれで制限ない
そのライブラリの仕様ならタプルにすればよい

>>127
なるほど、実行時に他のバリデーションするからタイプセーフでなくていいと君は考えるわけね
それはそれで一理あるが、だったら君が使うべき言語は静的型付け言語ではなくRubyなどのゆるふわ言語だな
さようなら

ビルダーパターンで疑似カリー化が行えるのが利点なのにタプル化するって
わざわざ手足を縛ることになるけど

>>135
勘違いしていないか？
必要とはされないオプションが有る時にビルダーパターンが使われる

>>138
それマジで言ってるならRustでプログラミングしたことがないんだな
タプルで扱うのが正解
これがわからないならfor文すら書いたことがないのだろう

>>139
それは一部必須パラメータが依然として存在することと矛盾しない

>>140
もはや話がかみ合ってないな
疑似カリー化で個々のパラメータを指定してその他のパラメータをここに設定した生成物を作れるのが利点だという意味が判らないのかな
これは重複を許容する使用法

>>141
必須パラメータの事例はさっき出てただろ

>> std::fs::OpenOptions::open()
>> regex::RegexBuilder::new()

これで対応できている
誰もが使っていて問題となったことはない

>>142
カリー化の意味すら理解できてないのか？
Rustでカリー化ならばクロージャを使う
ちなみにビルダーパターンはビルダー構造体のまま変わらずカリー化は行わない

>>143
だからそれはderive_builderの作者に言ってくれ
それに前から言ってるが必須パラメータの数が増えればミスが増えるし可読性も落ちる

>>144
ストローマン論法
疑似カリー化と書いてるだろ？

derive_builderは正しいと繰り返していたのにすでに複おじになかったことにされている

微妙に論点をずらしたり相手の言ってないことに対して批判したり
本当にずっとストローマン論法続けてるよなあ
複おじいさん

ストローマン論法はやめなされｗ

>>137
Rustは静的型付けだから常にタイプセーフだよ
それらの例は引数の型が合ってなければ当然コンパイルエラーとなる
一方で引数の値が合っているかどうかは構造体の方針だから当然コンパイルエラーにできず実行時エラーとなる

>>145
何を言いたいのかわからない
fsやregexの話を作者に伝える？
そんなの知ってるだろ

>>146
カリー化は定義もメリットもはっきりしていて幅広く使われてきているが
その疑似カリー化とやらも定義もメリットもわからない
無意味なことをしようとしていないか？

>>150
見ればわかるだろうｗ疑似カリー化が何を意味しているのかぐらい

そういう議論のための議論を繰り返してなんになるんだよ

>>151
だから疑似カリー化の定義とメリットを明確にしてくれ
少なくともこの件のrgbバラバラにするのはメリットないどころかデメリットだぞ

>>128
>> 順序ミス対策なら
>> .rgb(p[0], p[1], .p[2]).build()
>> でいいんじゃね？

>>152
こちらのID辿ってみたらいい

>>62
>>68

複おじはderive_builderを全力で支持
初期化関数は全否定していた

ところが…

＞ .R(p[0]).G(p[1]).B(p[2]).build()

これ3つとも指定が必要ならメソッドを分けるべきではないと思う
それ以前にRustのプログラミングしたことないのかメソッド大文字は置いとくにしても
この場合ならp[0]はRust的な使用方法ではないな
(r, g, b)もしくはRGB構造体で持つかその参照で持つのが普通
p[i]はなるべく避けてイテレータ時点でポインタを動かして参照で持つか小さいなら値で持つ
構造があるならその構造で持つ
そのためp[i]の形が出てきたらRustでは少し臭うため怪しみ避けられないか考える

>>75
>まつもとなかい

うby界隈のmatzとそのとりまきか？

>>155
> これ3つとも指定が必要ならメソッドを分けるべきではないと思う
おっ
derive_builderって必須パラメータをランタイムチェックとはいえ個別setterの形で適切に扱えるというのが重要なコンセプトなんだけど、ここにきて全否定か

>>128
>.rgb(p[0], p[1], .p[2]).build()

重複を主張する人の場合
.rgb(p[0], p[1], .p[2]).b(3).g(4).r(5).g(6).b(7).build()
みたいな間違いが起こるんだと思うよ

ボクシングには蹴り技がない
それは重要なコンセプトだと考えていた時期が俺にもありました

コンパイラでうまくいかないから規約で縛ると言うことだろ？ビルダーパターンを導入する意義とどんどん崩れていく

RGB各値は指定が必須とは限らない
defaltで各値が0指定されていて同じなら書く必要がないだう
初期化関数では場合によっては記述する必要があるけどそれも必須ではない

疑似カリー化で少しずつパラメーターの違う複数のオブジェクト生成を行う場合にも便利

f(
　red=red,
　green=green,
　blue=blue,
)

f()
　.red(red)
　.green(green)
　.blue(blue)

どちらの方式でも間違えようがないと思うんだが
ミスが起きると言ってる人はどういうミスを想定してるのだろう

red=p[0];　//p[0]は実際はblue
green=p[1];
blue=p[0]; // コピペの修正漏れ

>>161
今更そんなところを理解できてなかったのか？
greenの指定を忘れたら前者はコンパイルエラー、後者は実行時エラー

>>162
これの悩ましいところは後ろのコピペ修正漏れでblueに正しいp[0]が指定されているので
原因が判断しにくいところ

>>163
前者と後者は同じ
greenの指定をしなくてもコンパイルエラーとならない
greenは指定しなかった場合にデフォルト値となるオプション引数

>>165
知らんがな
俺は必須パラメータの問題を指摘している

>>162
p[0]やp[1]など
可読性の悪いコードを書くやつは失格
p.red p.green p.blueにしろ

>>167
dataと言うバイト列の中の一部だとしたら？

>>166
おっちょこちょいだな
直前のこれを見ろ
必須ではなくオプションパラメーターだ

>>160
> RGB各値は指定が必須とは限らない
> defaltで各値が0指定されていて同じなら書く必要がない

>>168
バイト列？
各8bitなのか各16bitなのかそれ以上なのかそれでは構造がわからん
ちゃんと構造体の列にするべきだ

>>170
また真面に回答できないから適当に話をごまかして議論のための議論しようとしてる
受信データなどのバイト列から値を取り出すのは一般的だろう
必ずしも構造体の列構造とは限らない

それと数値指定無くすならコーディング規約でこう書かないとアウトですとするのか？
blue=data[ i + blue_index_offset];
red=data[ i + red_index_offset];
green=data[ i + green_index_offset];

>>171
あのさ
Rustでプログラミングしたことないの？
Rust以外でもシリアライズとデシリアライズしたことないの？
まともなプログラミングしたことある人ならRustですぐにserdeにたどりつく

まともな人が言ったのか人形が言ったのか全然わからない時代だ
人形が言ったにすぎないなら、そんな言葉は存在しないのと同じ

>>172
お前はわざと議論のための議論してるだけだろ
通常のコーティングで出てくるであろう例を誤魔化している

p[ i+0 ],p[ i+1 ],p[i +2 ]を取り出すだけのためにどれだけコーディング量を増やして
ライブラリ依存させていくのか
本当に意味不明

>>175
そんな可読性が悪くてミスしやすいプログラミングは避けるべきだ
構造化と抽象化が不得手でプログラマやエンジニアに向いてないな
serdeは構造体に#[derive(Serialize, Deserialize)]など付加するだけでデシリアライズ関数などは自動生成される

>>176
構造体にって自分で書いてるだろ
単なるバイト列からp[ i+0 ],p[ i+1 ],p[i +2 ]を取り出すだけのために構造体などを作らないといけない

p[ i+0/*0=赤*/ ],p[ i+1/*1=緑*/ ],p[i +2/*2=青*/ ]
俺ならこうするよ
コメントを見れば0が赤、１が緑、２が青と見たん瞬間わかる
日本語なので英語より間違えにくい
もし間違った数字が間違ってたらコメントと比べればすぐわかる

（言語を強化することにより）アプリのコーディング量を減らせという話はなかなか面白い
言語の数がアプリの数より多い気がする原因はこれかもしれない

>>174
議論のための議論をしてるのはお前だろ
それともガチで何も意味を読み取れないインデックスアクセスが正義と思ってるわけ？
どんなみじめな経験を積んできたんだよ
害悪プログラマすぎて仕事で関わらないことを願うわ

議論とは関係ないけど大体の画像処理ライブラリだとRGBもBGRも扱えるように channel[0], channel[1], channel[2] のようにアクセスさせると思う
内部のデータによって channel 数は1や4 (アルファチャネル付き) もあるし

仕事はお金を貰ってやることだから丁寧に書いて上司に褒められる必要があるけれど
趣味とか経営者とかなら何を書いてもじゆうなんだよな

簡潔で見にくいコードを書くか
冗長で醜いコードを書くか
２択だな

>>181
これはそう
画像に限らず構造化されたバイナリデータを扱うときに一般に言えることだけど、
単純にビット列をそのまま構造体として読み替える間違いは、低水準に踏み込める言語に入門して調子乗ってる初心者がやりがち

上司はunsafeの箇所をチェックすればいいのに
コンパイラが自動で調べてエラーがなかった箇所を、手動で調べ直して逆張りするのが胡散臭い

Serdeは暗黙のCopyしがち

>>180
８０代のおじいさんと仕事をする機会はないかな

話を整理すると

>>82
>> .G(p[0]).R(p[1]).B(p[2]).build()
>> のところを容易に
>> .R(p[0]).G(p[1]).B(p[2]).build()と間違え

と彼は言い出すから
それは名前付けせずにp[0]を用いていることが間違える本質的な問題という話だよな

さらに

>>160
> RGB各値は指定が必須とは限らない
> defaltで各値が0指定されていて同じなら書く必要がない

と彼は言ってるので
彼の好み通りにp[0]を用いるとして

名前付きオプション引数方式
foo(
　green = p[0],
　blue = p[2],
)

ビルダーメソッド方式
foo()
　.green(p[0])
　.blue(p2])

どちらの方式でも同じだな
仮にミスが起きるとしたらそれは名前を付けずにp[0]を使っていることが本質的な問題であると確定

構造体は
foo{green:green,blue:blue}
を
foo{green,blue}
と描ける訳で
ビルダーメソッド方式とやらも
foo().green().blue()
的に描ければ無駄が減るから改良してくれんかのぅ

>>189
その大量連投していた彼はRustをほぼ知らないと判明した上に他の言語の経験値も低そうなので彼自身に問題があることを理解できないと思う

その連投してスレを荒らしていた人が
「おじ」「複おじ」「おじいさん」「おじいちゃん」使いの人だったとはね
>>61 >>70

foo().(green).(blue)
でもいいな

RustはJavaよりも構造体リテラルの表記が強力だから
Builder使うよりOptions構造体１つで渡す方が楽かもしれんね
パターンとしてはBuilderよりマイナーだけど

>>190
引数なしで何を指定するのか？

>>193
メソッド名なしはエラー

どんな方式を取ろうとも大元の変数(ex. rgbやp)は指定せざるをえない
foo().green(rgb).blue(rgb)

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

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

これに尽きる
言語に機能が不足してるから何でもかんでもビルダーパターンにしなきゃいけなくてサードパーティのマクロに依存することになる
アホらし

>>196
真逆だろ
キーワード付オプション引数をズラズラ並べた長い長い関数シグニチャはデメリットしかない欠陥品
しかも機能拡張したらさらにキーワード付オプション引数が増えて関数シグニチャが変わるアホらしさ

複数IDと口調を使い分けて自分のレスに賛成するキチガイが複おじ

Rustのダサい処は認めるべき

>>197
ビルダーパターンは30年以上前から知られていたけどあまり有用ではないので使われていない
過去に誰かがざっくりデザインパターンを否定してたけど、その人の言うにはデザインパターンで有用なものは言語自体に取り込まれるはずだと

実際いくつかは新しい言語では取り込まれている

マクロで解決可能なんだろ？ それは「不足している」のか？
まあ標準ライブラリとして入っているべきみたいな論はあるかもしれんけど、マクロでの解決が悪くて言語機能として直接サポートするのが良いとする根拠は出てないな。

言語ユーザがそれぞれのやり方で解決できる自由さと言語の方針を強制する一貫性は両立しないがそれぞれに良さはあるし、 Rust は今のところ自由さをとりつつもデファクトな地位のライブラリはあるという状況だ。
手頃な妥協点と言えるだろ。

些細な内容なら初期化関数を複数作ればよい話で更に多くなればオプション指定する構造体を作ればよい
mutに拘る必要が無ければさらに多くの可能性がある

わざわざ穴の多いビルダーパターンを使う必要はない

>>200
ポールグレアムはイディオム (デザインパターン) は言語機能として持つかライブラリにまとめるべきと述べていて、考えられる様々なパターン (またはこれから登場する未知のパターン) をライブラリにまとめるには「本物のマクロ」が必要と主張してた。
そして本物のマクロを持つ実用的な言語は Common Lisp くらいしかなかったんだが、 Rust のマクロは彼の言う本物のマクロだ。

マクロで抽象化されてるならその実装がビルダーパターンでもそうでなくてもどうでもいいよ。

>>202
初期化関数を複数作るとオプション分の組み合わせ爆発となる一番アホな方式
それならビルダー方式がよい

>>204
他の言語では大体オーバーロードでオプション指定しているけどそれが馬鹿だとは思わないけどね

>>205
それはオプションが増えると組み合わせ爆発が起こる馬鹿な方式

>>206
同じ主張と文章を繰り返すやり方が複おじそっくりですね

オーバーロードの初期化関数で馬鹿らしいと思うのは型が同じで対象が違うものがある時
重複を避けるためにシグネチャの設計をしなくては成らないことは馬鹿らしいと思うよ

例えば基本的に2つだけ引数があって後はオプションがずらずら並ぶならやはりオプション内容を含む構造体渡せばいいと思う
そちらも設計が必要だけど

>>205
それ以前にオーバーロードは欠陥機能
オーバーロードを使うとred,green,blueのオプション実装すらできない

>Rust のマクロは彼の言う本物のマクロ

macro_rules! は偽物のマクロ
proc_macro2 が本物のマクロ

普通は書き込み内容が単調にならないように人は文章に揺らぎをいれてくるんだけど
複おじは基本全部同じ

口調を変えても同じなので同一人物なんじゃないかと思って見ていると後で全く同じ書き込みを始めるので同じ人間なんだなと

>>209
どちらも本物だ
衛生マクロの概念すら知らないのか？

>>208
何の問題もないと思うが、具体的には？

本物のマクロと言う主張は面白い

でライブラリ作成者ではなく一般的なユーザ側が書いてるマクロはどっちなのかと

>>212
オーバーロードの制限を知らないのかね？
red,green,blueそれぞれだけを指定したい関数をオーバーロードで書いてごらん

>>213
衛生的なマクロとは何かを勉強するといいよ

オーバーロード自体は良い仕組みだと思うけど設計が必要だ
最近の言語が取り入れていないのはヒューマンエラー対策という名目

だったらビルダーパターンもヒューマンエラー対策で禁止になるかと言えばそうでもない

>>216
オーバーロードは最悪な仕組み
欠陥が多すぎる上に
red,green,blue各オプションしてすら実現できない

徐々に文体におじいさんぽさが出てきたね

AIを屈服させるレベルの改善ができるなら改善してもいいけどね
どうせAIが勝つという前提なら何も修正しないのが合理的だ

今のAI()の実力ってこんなもんか
>2つのリンゴを3人で分ける場合、1つのリンゴを2つに切り、もう1つのリンゴも2つに切って、3人で分けます。
>そうすると、3人ともリンゴの切れ目と半分になります。
>具体的な分け方
1. 1つのリンゴを半分に切る:1つのリンゴを真ん中から半分に切り、2つの半分のリンゴにします。
2. もう1つのリンゴも半分に切る:もう1つのリンゴも同じように半分に切り、さらに2つの半分のリンゴにします。
3. リンゴを合計4つの半分に分ける:2つのリンゴを合わせて、全部で4つの半分に切ったリンゴが手に入ります。
4. 3人で分配する:3人でリンゴの半分を1つずつ取ると、3人とも1つずつ取ることができます。
5. 残った1つを3人で分ける:1つの半分に切ったリンゴが残りますが、それを3人で分けることができます。
例えば、さらに半分に切って3人で分けたり、3つの小さく切って3人で分けたりできます。

>>209
本物のマクロというのが何であるか明瞭な定義はされてないのだが、文脈的に「構文木の操作が出来る」というのが要件だと一般的に解されている。
トークン単位の置き換えしか出来ない C のマクロのようなものを除外するための言い回しだ。
構文木を操作できるなら操作できる範囲の違いは本物のマクロかどうかには重要ではない。
(もちろん出来ることが多いほうがより良い本物のマクロとは言えるだろうが、出来ることが多いほうが危険な間違いも引き起こしやすいので現実には適度に制限があったほうが良いこともある。)
macro_rules! も普通は本物のマクロと解される。

リスパーはmatchを知らない

matchを知らなくても理解できるマクロが本物のマクロ

複数ID使用おじ

別人が複おじと疑われたら自分は複おじじゃねーよと反論する
気持ち悪いから
ところが何故かしない

複おじはそういうのに反論しない仕組みになっている

>>214
ヒント:
struct Red(u8);

マクロ自体がただの似たような機能の概念の総称であってその中で本物だ、元祖だと言っても笑われるだけ
キーボードマクロは真のマクロではないとか衛生的ではないと言われてもそうですかと

>>223
複OGはどうでも良いけど
5chはもう禿しく過疎ってるのにこのスレだけやけに延びてるのは不自然だと感じる

>>225
「本物のマクロ」というのは正しさとか起源を主張しているわけではなくそういう名前の分類。
少なくとも C のマクロなどでは様々なイディオムを抽象化するには不十分だというごく当然の話をしてる。

なお、名前付き引数での呼び出しを前提とするならばhoge(red) と hoge(green)を名前付き引数の引数名だけで呼び分けるオーバーロードは技術的には実装できない理由は特にない
しかし、多くの言語では名前付き引数の使用はオプションだしこの場合はhoge_red(val)のように機械的に名前変えりゃいいだけだから、実装コストに見合わないという判断をされているのだろう

>>224
こうですか？わかりません

impl From<Red> for Color {...}
impl From<Green> for Color {...}
impl From<Blue> for Color {...}
impl From<(Red, Green)> for Color {...}
impl From<(Red, Blue)> for Color {...}
impl From<(Green, Blue)> for Color {...}
impl From<(Red, Green, Blue)> for Color {...}

let red = Color::from(Red(255));
let yellow = Color::from((Red(255), Green(255)));
let white = Color::from((Red(255), Green(255), Blue(255));

メリットが不確実なだけでしょ
メリットもコストも確定していてなおかつ見合わないという話ではない

このスレでずっと自演してる人って糖質とかなんだろうなあ

traitで騒いでた自演と同じ人だろう

オーバーロードはそもそもCのAPIにありがちな、後で〇〇2だの〇〇exだのが増えて格好悪くなる問題を解消するためのもの
後で引数名だけ異なるオーバーロードが増えたら名前付き引数を使っていない既存の呼び出しがエラーになるのは、互換性維持という本来の目的からすれば論外

話題のderive_builderを使ってみた
構造体に属性を付けるだけで初期化関数を書かなくて済むのは便利だね
ドキュメント見ると今回は使ってないけど色々と機能が充実してるみたい
話題のred/green/blueはこれでいいのかな

use derive_builder::Builder;

#[derive(Default, Builder, Debug)]
struct Color {
#[builder(default = "0")]
red: u8,
#[builder(default = "0")]
green: u8,
#[builder(default = "0")]
blue: u8,
}

fn main() {
let pink = ColorBuilder::default().red(255).blue(200).build().unwrap();
println!("{pink:?}"); // Color { red: 255, green: 0, blue: 200 }
}

>>235
よくない
散々言われている通り、必須属性の設定を忘れると実行時エラーになるという致命的な問題がある

>>236
例えばファイル名を打ち間違えちゃったけど
まずリリースモードの前にデバッグモードの時点で実行時エラーで気付いて
直してしまえばそれ以降は大丈夫と同じじゃないのかな
特に問題ないような

補足するとファイル名は必須項目だけど
コンパイル時にチェックできるのは型だけだから現実的にチェックできることはほとんどないよね

お前らめちゃくちゃ暇人だな
レス多すぎ

>>201
>マクロで解決可能なんだろ？
ビルダーパターンの手書きコード量を多少なりとも削減したいという問題は解決してるかもね
それが本当に解決したい問題だと思ってるのならそれでいいんじゃない

ビルダー方式でも他の方式でもなんでもいいけど
初期化のための関数を自分で書くよりも>>235のように構造体への属性マクロ指定だけにするのがいいと思う
面倒がなくコードがすっきりとしてプログラミングミスも起きないから

>>238
それはそうなのだけど、だからといってコンパイル時のチェックを安易に諦めたら、極論Cでいいだろって話になっちゃう
Rustの存在意義が問われる危険な思想

現時点のderive_builderはFooBuilder::new()に必須項目を渡すパターンには対応してないっぽいな
全部default()でも構わないケースだと使えるけどRegexBuilder::new(pattern)みたいなケースもあるから万能ではない

良い例があるな
http://2chb.net/r/tech/1643696741/33
貴方が配慮を欠いている
そのx^nつまりxのn乗を求めるにしても
例えば2^100を求めたいならば128bitがないと溢れるのでu128::pow(2, 100)となるが
2^5を求めたいだけで結果も8bitで十分ならばu8::pow(2, 5)となる
このようにメモリサイズも異なってくるので別々の関数が必要
もちろんu128::pow(x, n)があればu8::(x, n)をカバーできるが明らかに無駄である
そこで符号なし整数だけでも
u8::pow(x, n)
u16::pow(x, n)
u32::pow(x, n)
u64::pow(x, n)
u128::pow(x, n)
と5つの関数が必要となる
一方でxの型が確定しているのであればpowで再び型指定は不要なので
x.pow(n)と表記することも可能
以上は整数の場合だがxとpowの結果が小数の場合は2種類の関数が必要となる
f32::powi(x, n) 【nが整数の場合】
f32::powf(x, n) 【nも小数の場合】
もちろんnが小数のpowfだけあればpowiもカバーできるが明らかに無駄なので2種類必要となる
さらに32bit小数だけでなく64bit小数も扱う必要があるため以下も必要
f64::powi(x, n) 【nが整数の場合】
f64::powf(x, n) 【nも小数の場合】
これらもxの型が確定していれば以下のように略して書くことも可能
x.powi(n) 【nが整数の場合】
x.powf(n) 【nも小数の場合】
ちなみに「x^n」を表記するのに不自然な「pow(x, n)」よりも「x.pow(n)」の方がたまたま自然に見えるが誤差だろう
どちらでも好きな表記法を選べばよいだけにすぎない

>>244
例えば
このように
もちろん
そこで
一方で
以上は
もちろん
さらに
これらも
ちなみに


そのx　から始まって論理的？接続で参照を握ったままで最後まで離さないな
読みにくいのは当然

id変わってしまった

上の強烈な接続もビルダーパターンの一種かな？と思ってしまう

>>242
忠臣蔵みたいに、諦めたふりをするぐらいがちょうどいい
危険思想？
なんのことやら

>>245
複おじ語録よくぞまとめてくれたな
ほめてつかわす

後から〇〇2や〇〇exが増える問題ってRustだとどう対処するのが一般的なんだろう
まあRustの場合ABIを維持する必要のあるケースは比較的限られてるけど、引数増やしたら既存のソースは壊れるよね
最初から構造体にしておけというのは意味のない意見なので無しで

普通に関数が増える

>>250
ダイナミックリンクで提供する場合はバイナリ互換性が必要な場面も多いのは Rust でも変わらないよ。
言語の文化としてはスタティックリンクを使いがちではあるけど。
ダイナミックリンクは OS の機能なので言語の側からどうにか出来る余地も少ないし、 OS の文化に乗っかるしかない。

○○exがある言語でJVMを実装し、○○exに依存してないと主張する

Ubuntu 25.10から、sudoがsudo-rsに置き換わるそうだ

まあ Rust が良いかどうかはともかくたまには刷新したほうがええやろ。

いや、sudoのようなパフォーマンスが重要でないコマンドなら
RustではなくGoで書くべきだった

どんなものでも機能も速さも同じだとしても
C/C++製よりRust製を選ぶわ
C/C++のせいでのセキュリティホールが後からいくらでも見つかってる現状

>>256
余分なランタイムが必要なGoはありえない

>>250
外部ライブラリならメジャーバージョン増やして普通に破壊する
旧バージョンのAPIをcompatモジュールとかに入れとけば親切

標準ライブラリはエディションで切り替える形になりそう
std::preludeのサブモジュール名は最初v1だったけど今はrust_20XXに方針転換してる
グローバルな名前の追加も一種の破壊だし

下記は全て2025年５月７日の記事

OpenAI、ChatGPTの6つのモデルの違いと適切なプロンプトを解説
https://news.mynavi.jp/techplus/article/20250507-3275757/

Microsoftの新規のソースコードの約3割をAIが生成、Nadella氏が明かす
https://news.mynavi.jp/techplus/article/20250507-3271749/

スコットランドの住民を悩ます謎の怪音「ヘブリディアン・ハム」の正体はいまだ不明
https://karapaia.com/archives/507130.html

モダンなライブラリはdeprecateしやすいのか
古いCと最新のRustだけが残されて中途半端な時代は無かったことになりそうだ

いや、利用者が少ないうちに直しとけ心理で、どんな技術も通る道だよ
sudo-rsがいい例だがこういう長期間にわたって重要な役割を果たす、かつあまり変更が必要とされない用途が増えてくると、だんだんと進化は遅くなるものだ

>>257

(´・ω・)マジ？

>>254
この国際的なプロジェクトでセキュリティ的に重要なものから順にRust化されていく一環だよ

Memory Safety for the Internet's most critical infrastructure
https://www.memorysafety.org/

>>244-245
このように.drop();
もちろん.drop();
そこで.drop();
一方で.drop();
以上は.drop();
もちろん.drop();
さらに.drop();
これらも.drop();
ちなみに.drop();

ubuntuはsudoだけでなく、cp, ls, find, diff なんかもRust化する予定なんだな
ntpdもRust化が進められてる

>>265
error[E0040]: explicit use of destructor method
help: consider using `drop` function

参考：https://doc.rust-lang.org/error_codes/E0040.html

>>266
Ubuntuに限らず誰もが全てをC/C++製から安全なRust製へ変えたいと思っているが一気には無理なので重要なものや新たなものからRust採用という感じ

全てを変えたい、とかいうビジョンは無意味
意味のないビジョンだよ

安全でないC/C++を早く全廃したい世界の流れ

Linuxコマンド開発専用言語Rust

メンテナ高齢化問題の対策としては良い取り組みなんじゃないかな
作業するのもインターンの学生が中心だろうし

多くのシステムやインフラがRust化してるね
この5chが使ってるCloudflareもRust製へと移行した
https://github.com/cloudflare/pingora

コマンドツールがRustになってもAPIがRust用じゃない限り
CのAPIのラッパーでしかないけどそういう造りでもRust化したってカウントして良いのかは疑問

>>274
コマンドツールが誰に対するAPI？？
プログラムを書いたことないのかな？

こういうのってFedoraやらArchやらGentooあたりが人柱やってから普及していくものだと思ってたが…
Canonicalのくせに思い切ったことするなあ

Ubuntuはカジュアル路線でしょ
初期状態だとrootも使えなかったと思う
他よりもsudoの負荷が大きい

5chは真の漢が使う言語perlで書かれている

5chはperlだけでなくサーバも貧弱なのでキャッシュしてくれるCDNに頼らないと成り立たない
5chが利用しているCDNは>>273のCloudflareでRust製だよ

>>279
誰が見てもただの印象操作
子供でも分かる

5chどうこうよりも
インターネットを支えるCDN世界トップシェアのCloudflareがRust化したインパクトが大きいよな

そういう幼稚な書き込みはやめとけよｗ

もう見抜けない、最先端のAIディープフェイク動画は心臓の鼓動まで再現、判別が困難に
2025-05-08
https://karapaia.com/archives/507859.html

クラウド界トップのAWSもRust製に

AWSのプラットフォームはほぼJavaでしょ
ハードウェア寄りのローレベルな部分だけシステムプログラミング言語を使っていて、更にその中の一部でRustを使っているものもある、という程度

https://japan.zdnet.com/article/35183866/
2022-02-22 14:31
Amazon Web Services（AWS）は、同社のエンジニアたちがプログラミング言語「Rust」を使っている大きな理由として、エネルギー効率の高さを挙げる。
Rustはメモリー安全性を高め、セキュリティ関連の不具合を減らす役に立つだけでなく、PythonやJavaよりもはるかに「エネルギー効率に優れている」という。
Amazonは、2025年までにデータセンターの100％を再生エネルギーでまかなうという目標を掲げ、データセンターの環境負荷の軽減に取り組んでいる。
Rustの採用はその一翼を担うという。

Rustで構築されたAWSサービスの例としては、コンテナーアプリ用のサーバーレスプラットフォーム「Lamba」を支える「Firecracker」、「Amazon Simple Storage Service（S3）」「Amazon Elastic Compute Cloud（EC2）」、コンテンツ配信ネットワーク「Amazon CloudFront」、LinuxベースのコンテナーOS「Bottlerocket」がある。

大半は既存のソフトウェアの組み合わせなんで、仮に自社内で書いているプログラムの全てを Rust で書いても割合としては数割ってところだろう。
ただ、これから割合が増えることはあっても減りはしないとは思う。

Rustがこのままオワコンになったら撤廃もあり得るだろ

AWSもRust製か
Rust製のクラウドとJava製のクラウドが競争したらJava側が100%負けるだろうしな

クラウドってなに？
ハイパーバイザがrustで作り直されたの？

>>286
これは誤訳
原文だと、それらのサービスにRustを使っていると書かれているだけ
RedditなんかでAWS社員のコメントとか探してみりゃわかるが、AWSは基本Java

エネルギー効率に劣るJavaなんかで構築していたら笑うわ
>>286でもそう書いてるよな

Rustって人気なのね
AIにC#から移植できる？って聞いてみたらいやだって言われちゃったからRustが広まるの、なんか困る

JVM前提な特殊環境を除き
Rustの登場でJavaを使う意味は全くなくなった

何の前提も縛りも無い環境こそが特殊

コンテナ化は Java の有力なメリットだったけど Docker の隆盛で様変わりしちゃったね。

>>293
いやだと言うAI、なんかいいな

>>291
サービス提供には安全性が一番重要なのでC++ではなくJavaを採用していた
Javaより安全で性能の良いRustが出現したため切り替えた
そしてAWSが発起人となってRust Foundationを設立した

Rustで戦う領域ではない気もするけど、エンタープライズ向けはまだ弱いと思う
ここはまだJavaや.NETの資産が大きい

「ファイルが見つかりません」みたいにユーザーの言語でエラーメッセージが出たり、文字列のソート (例えば「あアいイ」のように、ひらがなカタカナを考慮した自然な順になる) だったり、そういうのが外部ライブラリ無しで揃ってるのが Java や .NET なわけで

規模としては相対的に小さくなってるけど、こういうのが必要な領域は普通にあるし、Javaが消えることは無いと思う

>>299
外部ライブラリ無しで揃ってるという発想が頭おかしい
そんな間違った奇妙な視点を持ってしまうとRustには正規表現も乱数も何もかも存在しないことになるぞ
考えを改めなさい

ここでグチャグチャ言ってる間に徐々に置き換わって行きそうだな

firefoxが全部Rustに置き換わるのに100年ぐらい掛かりそうだけどな

止まってるFirefoxより
ChromeとIEが着々とRust化を進めてるから先だろな

IE?

>>300
何でこいつ偉そうなんだ？

>>299
人月業界は考えるだけ無駄として、SaaSだと新規開発は圧倒的にフルスタックTypeScriptが多いね
Rustは海外では革新的なDB作るぜみたいなエンタープライズの基盤系スタートアップでの採用例は見かけるが、国内ではその手のスタートアップは皆無に近いから絶望的な状況

品質に関する考え方は良い要素を揃えれば良くなるという単純なものじゃないよ。
結局のところ、どんな問題が出てくるかは事前にわからない。
出てきた問題に対処し続けるという歴史によって品質が作られるんだ。
確かに C や C++ に比べて Rust は全面的に良いけれども、活発な巨大プロジェクトではもう問題に対処しつくしていて Rust に置き換えるメリットは相対的に小さい。
部分的に Rust に置き換えることはあっても問題が起こってない箇所まで含めて全面書き換えを目指すのは割に合わない。

>>306
サーバーサイドでTypeScriptを使っているようでは負けるわ

>>308
「負ける」というのは何において？
Rustで実装すると、そのサービスは使いやすくなったり、機能豊富になったり、プロトタイプを高速に作ったり、ユーザーの要望をより速く実現できたりするの？

勝ち負けが決まるのって、サービスの内容、ユーザー体験、リリース速度などが重要で、それを実現できるなら言語自体はさほど重要でない
TypeScriptはエコシステムが充実してるから、それに乗っかるのは一つの選択
(バックエンドTSはつらい点もあるから、他の技術を持ってるところなら他のものの方が良いと個人的には思うけど、そういう選択肢が世の中にあって割と普通に受け入れられてるのは現実として理解してる)

>>307
未だにC/C++が原因のセキュリティ脆弱性報告が常に何件も出続けている現実を見なきゃ

>>309
それらの点ではどの言語でもほとんど同じだね
遅くてメモリも喰うJS/TSをフロントエンド以外で使うのは適材適所ではないから不利だけど

仮に外部ライブラリを使ってもRustはエンプラには向かないでしょ
この分野はオラクルやMicrosoftのような企業が時間かけて作ったきたからできたもので、現状Rustはこの分野向けのライブラリが充実してるわけでもないし、Rustコミュニティが力を入れるとも思えない (したとしても優先度は低い)

それに、安定性や将来の入手性が最も必要な分野で、多くの部分をOSSに頼るというのは業界として受け入れないと思う
(昨今OSS絡みの事件は多い)

低レイヤやWebバックエンドなど、Rustが強みになる分野があるのはその通り

>>310
それでも何十年もc++が捨てられずに使われているのはなぜかと考えたことはないのか？

ひらがなカタカナ交じりの自然なソートなんて
今更Rustで描いても半日もかからんやろ

c++はrustに勝てる点が全くなく既存資産だけが頼みの綱で終わりでしょう
巨大な既存資産だけは消えるまでに時間がかかることでしょう

超超超熟練度が必要なCOBOLになる

C、C++、COBOL　まとめてC*

>>314
漢字も当然含むし、ロシア語や中国語などを含む世界の多数の言語にも対応する必要もあるぞ？
時刻や日時の表記も国によって違う
Javaや.NETはランタイムが大きいと言われるけど、その中にはこういうのも含まれる
手間も大きいし、この分野を再実装するのも面倒でしょ
(自分が知らないだけで、既にそういう取り組みがあるのかもしれないけど)

.NETでソートサーバを作ってそれにソートさせて結果をrustで使う

日本だとエンプラよりは自動車の方が早いかもね
ボルボにはもう入ってるし10年以内にトヨタ車に入るくらいならあり得るかも

システム周りでは標準で使われて、それ以外は他の言語の下請けになるのかと思ったが実際は違うと言うことか？

システム周りにもかかわらず外部に依存が必要であれば使われない
ライブラリが充実しないと完全な下請けにはなれず、c++のDLLのように一部高速化部位での限定利用になる

証券取引みたいに、最高のパフォーマンスと最高の信頼性が求められるガチな領域もエンタープライズにあるのは事実で、
内部的にRustを使っているところがあってもおかしくはないが、そういうのって性質上外に情報が出てこないから盛り上がんないんだよね
自動運転もそうだけど、限界の性能を出そうとすると結局は頭の良い人間を上に据えたスペースシャトル型の厳格なウォーターフォールになるんで、夢がなくてつまらないという面も

COBOL なんか古代の遺物みたいに言われつつもかなり広くつかわれてるもんな……

最高のパフォーマンスを出すにはC/C++/Rustしかない
安全性を満たすRustは唯一の存在
これから少なくとも数十年間は天下を取るのだろう

>>303
EDGEか

AI が台頭してから電力使用量が劇的に伸びてるからな。
自動車の運転を人間のプロ水準で自動化するなら動力と同じくらいの電力が計算に必要という見積りもある。
AI がまだまだ伸びる分野なら効率は重要だ。
これはコストがどうのとかいうレベルではなくコストをかけても無いものは無い (足りない) という深刻な話で、プラットフォームを担う業者がいっせいに Rust に注目しているのも無理からぬことなのかもしれぬ。

そんな見積もり知らんけど50wでLv5運転できる人間が最高だな

やったことないけど組み込みの世界ではどうなの
Rust使われてる？

トヨタはこの前、Rustで求人広告出してたじゃん

組み込みはRustが多いですね
新規案件は殆どがRust
単品ではmrubyが多いですね

トヨタ系は基本的に愛知勤務だからな
Rustでもなんでも使って求人票を飾らないと厳しいんだろう

Rust使えるなら都落ちして田舎で開発するのも悪くないかも
今はたいていタイプスクリプトばっかだから変化が欲しい

TSはフロント側とサーバー側を包括するフレームワークがあるのが強いんだよね
APIを定義してフロント側とバック側を区切る開発なら、バック側はコンパイルされるものが良いというのは同意なんだけど
TSを使うメリットがないと主張してる人は、こういう技術を知らないか、机上論を述べたいだけで実際の開発はしないから生産性など関係ないという人でしょ

>>332
その程度なら誰でも知ってるよ
SSR/SSGからhydrationしてCSRするコードも自作したことある

今のWeb開発では、独立したバックエンドAPIはオプションだからね
Next.jsでサーバーサイドロジックが存在するのがデフォなので、よほどCPU intensiveな処理でない限りは、
Rustで別途独立したバックエンドを作ることはかえって遅延とコストを増大させる
フロントエンドまでRustエンジニアが自分で面倒見るってんなら好きにすりゃいいけど、
Rustエンジニアがフロントエンドやりたいかねえ

フロントとバックエンドで常に齟齬が無ければいいんだけどと言う話になるとTSが出てくる

>>334
それはJS/TSだけでやろうとするからそういう制限になってしまう
RustとWasmも組み合わせてどこまでやるかで色んなパターンがある

>>332
RPC は昔からある取り組みじゃないか。
半世紀もかけて TS でしか実用にならない状況だと本気で思ってるのか？

Wasmはサイズがね…
ごく最近のニュースだと、Prismaが実装をRustからTypeScriptに置き換えたのが話題になってたな
デプロイ時のサイズが問題になる分野だから妥当ではあるけど

フロントだとビルド時間の長さが課題になりそう
UIの位置やサイズを微調整したい場合でも、確認のために毎回重ためのビルドが必要になると面倒じゃない？

>>338
UI 記述言語で書いて形になってから Wasm (にコンパイル可能なプログラミング言語) に変換するような仕組みもある。

>>337
RPCじゃなくてUIの描画込みの話だぞ
同じフレームワーク内でクライアントサイドのレンダリングとサーバーサイドのレンダリングを繋げたりできる
>>333 が書いてるようなもの

>>339
色んなパターンのうちそのUI記述言語を採用してのSSG/CSRのレンダリングコード共通化が有力の一つだよね
サーバーサイドからJavaScriptを完全排除してパフォーマンスを上げる方向性が正しいので

web開発の現場に言ってRustとwasmの組合せを使いなさいと言っても鼻で笑われるだけ

精神障害児で周りを振り回す無能です。
この業界で俺は死ぬかも。
悲しみ

自慢したりとか怒ると自分の首を絞める。
死ぬ。
俺はプログラミング向いてないが、この業界に行くぞ。
どうも死んだほうが良い人間です。

rustも分からんし三年間学んでプログラム書けない無能です。
質問ある？

もちろんrustも分からん。

rust is must

そもそもこの世の中教えてくれない人が悪いと奥底で思っている無能。
人との縁を切って一人で後悔しがち。
ゴミ人間だよ！

俺はガイジだ…
ガイガイガイジのガガイのガイ。
ガイジのボッチのやる気のある無能。
ゴミカス死んだほうが良い。

がががーがががががががががががが～が～が～障害児

我はガイジガガガイジ天地入れざる障害児

不勉強で天地入れざると言う言葉を知らなかったが
明治とかの言葉なのかな？

学があるね

>>352
ありがとう！
言葉を表面上の意味しか捉えられないガイジだけど、他人に迷惑かけるのは良くないよね…
スレ荒らしてすみませんでした…

どうせ俺以外誰も見ていないから好きなだけ荒らせばいいと思うよ

おちつきました。すみませんでした…

>>352
抜刀隊の歌詞にあるから知ってた。
ミリタリー趣味の人ならまあまあ知ってるんじゃないかな。
私は音楽側の趣味で知ったんだけど。

夏休みはまだ早いぞ

業界には何らかの形でメンタルを病んでる人間が50万人以上いると思う

このスレは特殊だから騙されないように

自分は悪質でなければ荒らしを許容するスレにいた

そこでは荒らしとも楽しく話してそのうち荒らしが真面目なコテになったりしていた
みんなもうどこかに行ってしまったのが残念だけどそれも運命だなと

病院行けよ
俺は今日行ったぞ

unsafeなライブラリのラッパーでsafeに設計するのってどうやるの

F-22 ada
F-35 C++

>>362
結局のところ、外側から見て safe な振る舞いになるようにするというだけ。
場合によっては不可能なこともあるけど具体的な状況がわからないとなんとも言えない。

>>362
未定義動作の可能性を排除するために必要な条件を全部チェックする
panicとデッドロックはOKらしい（停止すれば許される）

No matter what, Safe Rust can't cause Undefined Behavior.
https://doc.rust-lang.org/nomicon/safe-unsafe-meaning.html

>>342
そういう低レベルな現場は無視してもいいんだよ
現在もJSのフレームワークは乱立しながら変化進化し続けているように多様性がある
今回の件と関係なくwasmを既に併用しているところも多いからその点もだいじょうぶ

誰がその多様性とかについていくのか？
お前が低レベルな現場と呼ぶ環境だろう？

フロントにRustを使ってる「高レベル」なプロダクトって何があるの？
バックエンドなら分かるけど
その基準なら世の中のビジネス的に成功してるサービスの殆どが低レベルでしょ

>>364-365
関数の内側にunsafe書くだけ？
それだと見た目はsafeだけど内部はunsafeだから実質的にunsafeではないか？

子供が使うバリアの高度版

内部で使う関数がunsafeである理由を理解して未定義動作の可能性を排除できてないなら
外側の関数にもunsafeをつける約束

unsafeは「危険」というよりも「コンパイラが安全性をチェックできない」ブロックだと思う
内部的に unsafe を使ってても、ラップした型や関数を外から使う分には安全とみなせるなら問題ない

理想的には
・内部的にunsafeを使っているけど、外から見れば安全 -> unsafe を外して良い
・内部的に unsafe を使っており、かつその関数は利用者が適切にコードを書かないと危険 -> その関数も unsafe とマークするべき

標準ライブラリやきちんとしたライブラリは基本的にこの法則に従ってる
問題はユーザーのコードで、書こうと思えば「問題はあるけど unsafe とマークされてない関数」は作れてしまう
そこは自己責任の問題

けど、セグフォみたいなバグが実際に起きた場合に、直接の原因となるコードは unsafe ブロックの中に絞れる (ことが多い) から、それでもかなりマシだと思う
C++だとコード全体が unsafe ブロックの中にあるようなものなので…

>>365
Undefinedの有無もなにも標準化されてないからなぁ

バリア！バリアしたから大丈夫！

未完成らしいけど目安
https://doc.rust-lang.org/reference/behavior-considered-undefined.html

unsafe ＝ Rustコンパイラが安全性を保証してくれない ＝ プログラマが自分の責任で安全性を保証しなければならない ＝ C/C++と同じ状態

逆に言えば、safeつまりunsafeではない、とは、Rustコンパイラが安全性を保証できる状況にしないといけない
未定義動作がないことが根幹にある
だから未定義動作とは何か、どういう時に起きるのか、どうすれば無くせるのか、が最重要
それを完全に理解するまでは、関数内部でunsafeを使って外をsafeな関数、にする判断をしてはいけない

unsafe functionは使いどころが微妙だね
unsafe指定の理由が不明だし基準も開発者次第でまちまち
C#みたいにunsafeにはコンテキストとしての役割しか持たせない方が一貫性がある
呼び出し元に注意させたいんならunsafe_hogeみたいなネーミングルールで十分だった

バリアより感染症対策で流行ったゾーニングのイメージだな
感染リスクのあるunsafeゾーンと安全なsafeゾーンがあって
unsafeからsafeに持ち込むときは消毒（検査）が必須みたいな感じ

運用が雑になって事故るのも同じ

>>376
> それを完全に理解するまでは、関数内部でunsafeを使って外をsafeな関数、にする判断をしてはいけない
それをやると、一つの関数を unsafe にした時点でそれが呼び出し元に波及して、プログラム全体に unsafe が広がらない？
深刻なバグがコード内のどこで起こってるかを特定したい場面だと、 unsafeは本当に unsafe な操作をしてる箇所に限定されてた方が探しやすいと思う

>>377
呼び出し元に注意を持たせるものではない
unsafeブロック(関数)内はRustコンパイラが安全性を保証しない
それ以外の部分はRustコンパイラが安全性を保証してくれる
C/C++はプログラム全体がunsafeブロック内にある状況と同じと説明できる

>>379
そうだよ
理解するまではunsafeを使ったらunsafeな関数しか作れない
safeな関数にしてよいかどうかの判断が一番大事なところ
勝手に判断してsafeにしたらプログラム全体に問題が波及しかねない
まずは理解してからunsafeに手を出しましょうということ

「unsafe利用箇所をunsafeブロックで囲えば終わり」は、よくある勘違い
まず一次的には「それを含む関数もunsafe fnにしなければならない」が正解
その上で「内部でunsafeを使ったことで生じる問題が、その関数単独でまたはモジュール全体で閉じ込めることができているかを判断できてから、ようやくunsafe fnをfnにできる」が正解

unsafeな理由をブロック外部で処理すりゃsafeに出来るじゃん
たとえばなraw pointer参照が危険だとして渡す前にスタックまたはヒープ内の正しいアドレスであることを確認して引数を渡すとかの、外部でのチェック(unsafeに至る条件の排除)すれば無毒化できるわけで

そんなんC言語だって変わらんやん。Cで汎用的な関数書いたらほぼほぼポインターだらけになるし、ポインターのチェックせずに使うなんてことは危険すぎてありえんのと一緒やん

C言語にrustコンパイラーのunsafeの枠組みだけ組み込んでsafeじゃなきゃエラーにしますにしたら、コードの5割ぐらいはunsafeになってそうやけどな。標準ライブラリーからしていくらでも危険なアクセスできるし

>>382
Rustでプログラミングしたことない人には理解できないのは仕方ないが的外れ
そのCで手動でチェックをして使うようなことは
Rustではunsafeを使わずとも普通に書くことができて自動的にチェックしてくれて安全かつ楽

むしろRustでunsafeを使う頻出パターンの一つは真逆
その自動チェックを無くすためにunsafeが使われる
例えばあるアルゴリズムで既に自動チェックされて既に安全なものがアルゴリズムの都合で二重に自動チェックされてしまいコンパイルでの最適化でも消えないとする
その2回目の自動チェックを無くすためにunsafeを使う
もしそのアルゴリズムが1つの関数で完了するならばその関数外に影響はないため
関数内部でunsafeを使っていても関数自体は外向けにsafeにすることができる
そのアルゴリズムで2回目の自動チェック省略が常に正しく安全なことはプログラマが安全性を保証することになる
これがunsafeを用いて極限まで速くしつつ安全な関数を生み出すRustの典型的なパターン

https://doc.rust-lang.org/book/ch20-01-unsafe-rust.html
これが全て
unsafe function に関しては、長文複おじが主張するほどunsafeを含む関数に対して積極的に指定すべきものではなく、
むしろ極力safeとしてラップすることを推奨するトーンで書かれているように感じる
「unsafe functionは呼び出し元に注意させるためのマーク」という解釈は適切であり、常識的に考えて中でunsafe使ってようと呼び方によって未定義動作が生じるような関数はそもそも作るべきではない

unsafe指定の理由が不明って斬新な視点だと思うけどね
他の言語でunsafe使ってるから意味は理解出来る

>>384
逆だぞ
未定義動作が発生しうるパーツがunsafe関数
そのパーツを上手く使ったり組み合わせたりして未定義動作を発生させなくしたものがsafe関数

変わった人が集まって3行で済んでいた話を広げていく

>>368
無いから自演してまでしてRustを盛り上げようしてる

ここスレが立って1週間で300レスかよ
さすが究極のプログラミング言語だけあるな
関心持つ人多すぎ

>>369
その理屈だとRustで描かれたコードはすべてunsafeだ

>>389
何なんだよこの気持ち悪い複オジのレスはw

>>383
borrow mut な部分を unsafe {} で囲むとコンパイル通せるんだっけ？

>>392
unsafeであろうとRustの参照ルールは変わらない
ナマポ受給は可能

unsafeで囲むとその中で危険な必殺技が使える
強力だけどその間はリミッター解除され保護されていない状況にも近い諸刃の剣
それを呼び出す部位もunsafe扱いしたらmainまでunsafeになり危険極まりないｗ

やってることはC言語でコメントにunsafeって書くのと変わらねえじゃん

違いが判らないなら理解力が不足しているだろう
unsafeだと通常は許されないことが可能になる

>>395
全く異なる
Rustではunsafe部分のみ人間が安全性を保証する義務がある
それ以外はRustの言語仕様により自動的に安全性が保証される
一般プログラマはunsafeを使う必要がない

>>396
俺が言ってる意味がわからない方が理解力が不足してるかもよｗ

>>398
unsafeじゃない部分を無視してそれを言うのは意味がないこと
typescriptで書かれたコードがjsに変換されてそれに型が残っていないと言うのと似たような主張

他の言語でもunsafe以外では保護されている部分もunsafeで制約が解除されている

>>369
unsafeな関数には関数を呼び出す側が守るべきsafetyルールがそれぞれ定義されている
ラッパー関数がそのルールを関数内のみで不変的に守ることが保証できるのならsafe
できないなら上位で保証してもらう必要があるからunsafe

いずれにしてもunsafe関数を呼び出す側が守るべきsafetyルールは
アプリケーションのどこかの段階ではすべて守られることを保証しないといけない

>>396
その理屈だと二重の borrow mut も unsafe{} で許可してもらえるととってもありがたいんだが

>>402
unsafeの使用は安全性を守るためだけに使われるのだ
安全を脅かすためにunsafeを用いてはならないのだ

>>396
unsafeブロック内でも外でもRustのルールは基本的に同じ
何でも出来るようになるわけではない

unsafeブロック内でのみ出来ること
・unsafeな関数やメソッドの呼び出し
・unsafeなトレイトの実装
・生ポインタの逆参照
・共有体フィールドの読み取り
・可変静的変数の読み書き
このたった5つのみが許可される

文意を取れない病気なのだろうか？

まあ病気だろうね

unsafeってそんなに不味いんですね...

特殊な環境を抜きにすると普通の開発でunsafeが使われることはほとんどない
むしろコンセンサス無くunsafeを使う人がいたら問題児認定されても仕方ない
ボトルネックがあってunsafeを使うことで安全かつ劇的に改善されるなどの共通認識が出来たら注意深くみんなの監視の下で使われる

特殊な環境って...具体的にどういうのがあるんですかね...

安全に使うための条件が分からないunsafeは不味い
標準ライブラリのunsafe関数は大体Safetyで明示してる

>>378
メモリに対するバリアはunsafeを必要とせずにsafe Rustで使える
モデルはC++と同じでstd::sync::atomic::AcquireとReleaseでバリアを構成する

OS提供のヘッダーファイルと連携しないといけないからね
rustだってOSのAPIとして使われるようになったら今の形のままでは済まされないはず

その頃にはもう人間がAPIを管理することはないだろうから我々が気にする必要はない

atomicを使える局面なら最速を狙えるが
素人は無難にMutexにしとけ

処理が性能上クリティカルじゃないことが分かってる上で手を抜くのはいいけど、必要に応じてロックフリーを実装できないレベルならさすがに言語の選択から考え直すべき
場合によっちゃゲロ遅スクリプト言語でロックフリーに書かれたコードより遅くなるぞ

誰もメモリバリアの話なんかしてないだろストローオジ

>>415
その通り

>>415
ロックフリーにできるならatomicを使う方が当然よい
しかし素人がABA問題からRISCのアクセス順序崩壊まで様々な問題を理解しつつ
compare_exchange系などを正しく使いながら各々のRelaxed/Release/Acquired/SeqCstを最善に選べると思えない
複数のatomicが複雑に絡むとロックフリーはプロでも間違える歴史を繰り返してきた分野だ
さらに言えばatomicよりMutexが有利になるケースの存在も理解して適切に選ぶ必要がある
プロでも単純明快な状況でない場合はまずMutexで実装して後から見極めた上でatomicにするかどうか決める
これらの知識を身に付けるまで素人は無難にMutexにしとけ

unsafeについて

https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=18df19416bd6d705356724788636ab13
これをResultのmapとかand_thenとかを使ってスッキリ書く方法ってないでしょうか？

>>420
let z = x.or(y).or(Err("ko"));

？

>>421
x=Some(false), y=Some(true)のときz=Some(false)になるからダメじゃね？

すまんOptionとResult勘違いしてた

>>422
たし🦀

let z = x.and_then(|b1| y.map(|b2| b1 || b2).or(Ok(b1))).or_else(|_| y.or(Err("ko")));

直したらこんなんなったんだが
matchが一番わかりやすい気がする

x.map(|x| y.map_or(x, |y| x || y)).or(y).or(Err("ko"))とかになるからmatch以上にスッキリ書く方法はないんじゃないかな

一応x,yが増えた時のためにイテレータ使うパターン
let z = [x, y].into_iter().filter_map(Result::ok).reduce(|b1, b2| b1 || b2).ok_or("ko");

２つならmatchでいい気がする

幻聴で半分人間半分AIと話していたので
1 私に成りすまして話しているようにいさせている
2 成りすましの声でも身体攻撃の部分は私本人も同じ状態に陥っている
3 犯人が使用していたとしても清廉潔白の人物のように見せれる

【2025年最新】自然な声の音声読み上げソフト5選！AI技術で ...
https://ondoku3.com/ja/post/natural-voice-software/
※インストール不要で無料で５０００文字まで複数声質の音声合成エンジンで読み上げ可能

ローカルで各種AIモデルを実行できる無料ソフト「llama.cpp」がマルチモーダル入力をサポートし画像の説明などが可能に
2025年05月12日 20時00分
https://gigazine.net/news/20250512-llama-cpp--multimodal-vision-support/
>>llama.cppの詳細情報は以下のリンク先で公開されており、ソースコードやインストール手順などを確認できます。
※画像を認識させてテキスト入力が可能

ローカルでAIを動かして「コード生成」「ウェブ上の情報収集」「ファイル検索」などの操作を実行できるAIエージェント「AgenticSeek」、無料で使えてプライバシーも守れるのが強み
2025年05月05日 16時02分
https://gigazine.net/news/20250505-agenticseek-local-ai-agent
>>AgenticSeekのインストール手順は以下のページにまとまっています。
※複数サイトからレポート作成可能

>>422-423
このようにRustは面倒

>>429
その点ではRustが最も優れています

優れてるなら間違わないように設計汁

>>431
Rustは強い静的型付け言語なので間違えることはありません

>>429
わかるわ
ResultやOptionはわりと継ぎはぎだらけでasyncでの使い勝手もあってコアな開発者でもコンビネータよりもmatch推奨する人が増えてる

>>433
継ぎはぎはない
根本の理解を間違えているからそんな変な発想になる

基本はmatchで書くのが当然
例えば
match foo {
　Some(x) => Some(f(x)),
　None => None,
}
こう書いた時に意味するところはSome時にfによる写像
だからこれをfoo.map(f)と略記できるというのが根本
短く記述でき可読性も上がる

asyncでの使い勝手というのも同様
このfの形とクロージャでのキャプチャなどの制限を満たせば使えて満たさなければ使えないだけの話
matchを推奨しているのではなくmatchが基本
そのうえで可読性がよくなるメソッドが適用できるならそれを使う
メソッドチェーンもそれで短く可読性が上がるなら使う
>>420はmatchのままが可読性がいい
それだけの話

だからRustは清書用(キリっ)って言われるんだろうね

>>435
そんな話は聞いたことない
今回の話との関連すら不明

>>434
またバカおじの意味のない長文
アンチRust活動は他所でやれ

>>433
確かに最初の頃に比べると
イテレーター&コンビネーターの使用頻度がやや下がって
代わりにループ&マッチの使用頻度が上がったな

冗長でダサく感じるけど汎用性が高まる場合が多い

早期脱出はループで書くほうがわかりやすいものやループでしか実現できないことも多い
特にラベル指定など

実際どうなるかなんてその時次第だから

今回は結果をまとめて出してるんだろうけど
それぞれの実行結果で制御が加われば別に結果をまとめる必要はない場合もでて来るので綺麗に書ける必要はゼロ

>>420
ちょっと主旨から外れるけど、matchは
match (x, y) {
(Ok(b1), Ok(b2)) => Ok(b1 || b2),
(Ok(_), _ ) => x,
_ => y,
};
まで整理できますね。
2回評価するのが嫌なら二段matchがいいかと。

綺麗だねｗ

実際にはOk/Err得られた時点で既に実行済みだからその後の工夫は効果薄くて
>>427のような早期脱出になるかな
next()呼び出しで実行されるとして

関数の実行結果x,yがあります
それぞれのx,yが成功していればそれを出力してください
ただしｘ,y共に成功であれば結果を論理和して出力してください
x,y共にエラーである場合はエラーを出力してください

結果が揃っていたら悩むところないよな
現実には結果が一部しか出ていない段階で欲しい結果が得られたから以降は打ち切り、または、エラーが出たから打ち切り

二段matchも書いてみた。
let z = match x {
Err(_) => y,
Ok(false) => match y {
Err(_) => x,
_=>y,
},
_ => x,
};
普通はこんな書き方しないだろうけど。

まあしかし
元の

let z = match (x, y) {
(Ok(b1), Ok(b2)) => Ok(b1 || b2),
(Ok(b1), Err(_)) => Ok(b1),
(Err(_), Ok(b2)) => Ok(b2),
(Err(_), Err(_)) => Err("ko"),
};

これが一番可読性高くて網羅性も一目でわかっていいと思うわ

結局のところは意図が表れていて読み取りやすいことが重要で、スマートに書けてても見た他人がなんのこっちゃとなるようではあかんからな。

>>446
蛇足だけど、こっちの方がいいか。
let z = match x {
Err(_) => y,
Ok(true) => x,
_ => match y {
Err(_) => x,
_=>y,
},

};

他の言語でもあるんだけど元々シンプルに書けていたものを
その言語特有の機能で書き換えたい勢がいる

パズルとしては別に構わないけどそれでどれだけ時間を費やすのか考えてなさそう

>>441
さすが汚コーダーと呼ばれるだけはあるな

汚コーダーと言いたい気持ちもわかる
俺たちの時代は変数名は一文字で可能ならワンライナーで処理が終わるように工夫しまくってた。2行だったのが1行79文字に収まったぞ！的な
この美的感覚を共有できる仲間がいてくれて幸せである

両方Okの場合だけx.or(y)と違う動作をさせたいと考えるならそう書けばいいと思う
match (x, y) {
(Ok(b1), Ok(b2)) => Ok(b1 || b2),
_ => x.or(y),
}

入力が増える場合は上の処理を関数にしたものをループ内で呼ぶ
forループとか使っとけばショートサーキットも簡単

あと本当にErrを捨ててもいいんであればResult<bool, &str>じゃなくて
Option<bool>を受け取って返す形にしておいたほうが扱いも楽だしスッキリする

>>426のはOption<bool>化して最終的にNoneならErr(“ko”)にfallbackさせてるから
読みやすいかどうかは別にして考え方としてはわりと好み

結局>>427でええやん

AIチャットボットに「偽の記憶」を植え付けることで仮想通貨を盗む攻撃が報告される
2025年05月14日 12時00分
https://gigazine.net/news/20250514-web3-ai-agents-with-fake-memories/
>>プリンストン大学の研究チーム

過去に流通した誤情報に接触した人の半分が「正しい情報」と思っていて25％が何らかの手段で拡散している
2025年05月14日 11時25分
https://gigazine.net/news/20250514-fake-news/
>>総務省

「Firefox」の開発リポジトリが「GitHub」に移行
https://forest.watch.impress.co.jp/docs/serial/yajiuma/2013958.html
https://github.com/mozilla-firefox/firefox
JavaScript 28.5%
C++ 28.1%
HTML 22.0%
C 10.5%
Python 2.9%
Kotlin 2.5%
Other 5.5%

5次方程式に新公式を発見：ルートを超える新理論
2025.05.14 17:05:56 WEDNESDAY
https://nazology.kusuguru.co.jp/archives/177496
>>オーストラリアのニューサウスウェールズ大学（UNSW）で行われた研究
プログらまーも覚えるとよい

125年越しに解決したかもしれない「ヒルベルトの第6問題」とは？
2025年05月10日 15時00分
https://gigazine.net/news/20250510-hilberts-6th-problem-solved/

Mercurialが積極的にRust化を進めていたのは少なからずFirefoxの影響があったと思うが
酷い梯子外しで草

Mercurial は開発履歴管理で Git はパッチの連鎖管理という理念の違いがある。
それって結局は同じことじゃないのか……と思うんだけどやっぱり違うんだよな。
概念的に整理されていて理解しやすいのは Mercurual だけど、実務的に必要なのは Git。
ツールがどんな言語で書かれているとかはあまり関係なく、大規模開発だと Git のほうがやり易いというとても簡単な話。

Rust用のJITコンパイラ・インタプリタ的なものはありませんか？
PythonやJavaScriptのようにコンパイル時間を待たずにデバッグしたいんです。

RustもGo言語のように、消えてゆく運命ですか？

>>461
371 デフォルトの名無しさん sage 2025/05/14(水) 20:25:52.45 ID:u4PNt/Ez
TypeScriptを(C++等のように機械語に)コンパイルする方法が知りたいです(´・ω・)

>>462
C++標準委員会がRustを参考にしたコーダー用Safe C++（C++呼び出し専用の限定版）を作ればC++に回帰する可能性があるけど、そんな動きは無いから当面安泰じゃない？

コンパイラから全ソースコードが見えていて好きなだけ時間を使ってチェックさせるのか
商用を含め様々な出所のコンパイル済みバイナリでもリンク(静的、動的)して動かすのか
役割と責務が違う

>>457
FirefoxはメインがC+のまま変わっていない
Rust化した部分はレポジトリが別

>>460
それはよくある勘違いで、Gitのコミットはパッチではなくスナップショット
常に完全なスナップショットを持っているためにコミット間の差分の導出は極めて容易であり、
あたかもGitが差分ベースであるかのような使い勝手のコマンド体系を実現することに成功している
その結果>>460のような誤解も多い

>>467
それは実装上の話で、ここではパラダイムの話をしてる。

>>468
それ信頼できる出典ある？
仮にGitのコミットが(実装はさておきメンタルモデル上は)パッチだとしたら、rebaseやcherry-pickで新しいコミットが作られるのは変だと思わないのかな

Claude 3.7 with extended thinking 様によると

Gitはスナップショットベースのシステムで、各コミットはファイルシステム全体の完全なスナップショットを保存します（最適化されていますが）。一方、Mercurialは変更セット（changeset）という概念で差分ベースの履歴を管理します。

この根本的な違いがGitの操作モデルに影響しています。rebaseやcherry-pickが新しいコミットを作成するのは、Gitがスナップショットモデルを採用しているからこそ自然です。既存のスナップショットを新しい文脈に適用すると、新しい状態のスナップショットが必要になります。

パラダイムと実装は密接に関連しており、Gitの設計思想はLinus Torvaldsが述べているように内部データモデルから生まれています。このモデルがGitの分散性、ブランチ操作の柔軟性、大規模プロジェクトでの優位性につながっています。​​​​​​​​​​​​​​​​

>>447-448
記述量多いけど観る分には判り易い

>>465
>コンパイラから全ソースコードが見えていて好きなだけ時間を使って

Cargo の build 遅いしディスクの容量も喰いまくる(消せるけど)
そこまでやるなら他人(自分のであっても別cratesのとき)のstruct/traitを組み合わせて追加しても良い仕様にして欲しいな

>>472
Orphan Ruleが破れるのは致命的
第三者に勝手に実装されてしまう
これは必須ルール

Rust の型システムの原型になった Haskell では Orphan Rule のような制限はないから技術的には制限しない選択も可能ではあるはずだけど
通常は避けるべきと考えられているし、警告も出るし、コンパイル時間にもかなり悪影響だし、良いことは少ない。

必須というほどではないかもしれないけど、あまりにも割に合わないとは言える。

Googleが開発した進化的AI「AlphaEvolve」は未知のアルゴリズムや未解決数学問題の新解法を発見可能、すでにGoogle内部ではAI開発やチップ設計の効率化に活用されている
2025年05月15日 11時06分
https://gigazine.net/news/20250515-google-ai-algorithm-alphaevolve/

>>474
例えば第三者のクレートを利用した時
そこで標準ライブラリの型に対して標準では実装されていない標準ライブラリのトレイトの実装があっても通ってしまう
これは誤動作につながるからOrphan Ruleは必須かと
標準ライブラリ以外の型に対しても同様で第三者に実装権限を与えるのは禁じる必要がある

>>476
それは攻撃やミスに対する脆弱性を封じるという意味で制約が必須と言ってる？
こっちは (技術的な) 実現可能性という意味で必須な制約ではない (があえて制約を無くすことのデメリットが大きい) と言ってるので主旨が異なる。

>>477
Orphan Ruleなしでも脆弱性を封じることができるならば技術的な実現可能性があると言えるかもしれない
そうでないならばOrphan Ruleは必須

グローバルに適用させようとしたらそりゃ問題が起きるわ
拡張をスコープにいれる場合はモジュール内にuseステートメント書けばいいだけ

C#で言う拡張メソッドをやりたいのに、Orphan Ruleが邪魔をする
次のeditionでは廃止してほしいね

脆弱性とか全然関係ないよな

>>479
それは違うよ
それは自分で拡張用トレイトを作って、自作以外を含めた任意の型に対して実装して使う時に、自分で範囲を限定する時の話だね。
そうではなく、普通に必要のためuseしている標準やクレートのトレイトが、勝手に第三者によって実装されてしまうことを防ぐのがOrphanルール

>>480
Rustでは、自由に拡張メソッド用のトレイトを自作して、既存の型に実装して自由にメソッド拡張できます。
Orphanルールは邪魔しません。

>>481
もしOrphanルールがないと、トレイトの作成者でも型の作成者でもない第三者によって、勝手に型にトレイトが実装されてしまうため、その実装によっては脆弱性が生じる可能性があります。

>>484
トレイトの実装は可視性の指定をバイパスできないし、そもそも可視性はセキュリティのための機構ではない
その気になりゃ本来不可視なメンバにアクセスすることなんて普通に可能だし、
もしクレートの作者に悪意があって、利用者が不用意にバージョン上げる阿呆なら、サプライチェーン攻撃によってマルウェアを仕込むことなど造作もない

>>485
そんな悪意のある話はしていません。
第三者が公の型に公のトレイトを実装できてしまうと、その第三者にとっては意図通りの必要なことが実現できたとしても、他者にとっては必ずしもそうではないためその差異が穴になりうるという話です。

>>480
既存の構造体に新しいメソッドを生やしたいだけならextension traitで可
既存traitに新しいメソッドを生やしたいならextension trait + blanket implで実質同じことが可
拡張メソッド1つじゃなくtraitと実装の最低2つを定義しないといけないがそんなに気になるほどではない

Swiftの拡張メソッドのように既存インターフェースに後から適合させるのはRustでは無理

>>486
だからそれはグローバルに適用した場合の話でしょ
そりゃ問題起きる