Rust part25

**デフォルトの名無しさん** · 2024/07/31(水) 00:46:26.17

公式
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 part24
https://mevius.5ch.net/test/read.cgi/tech/1716759686/

ﾜｯﾁｮｲスレ
プログラミング言語 Rust 4【ﾜｯﾁｮｲ】
https://mevius.5ch.net/test/read.cgi/tech/1514107621/

**デフォルトの名無しさん** · 2024/08/10(土) 10:02:51.23

>>86
Windowsやマイクロソフトは何も悪くなかったのか

**デフォルトの名無しさん** · 2024/08/10(土) 11:11:45.08

>>86
Rustを使っていれば防げたな
スライスイテレータが個別のインデックスチェックコスト無しで境界チェックできるから

**デフォルトの名無しさん** · 2024/08/10(土) 12:59:11.84

Rustを使っていればってのは机上の空論なんだよな
自分でできないことを人に求めるなよと

**デフォルトの名無しさん** · 2024/08/10(土) 13:41:40.63

っぱRustだな

**デフォルトの名無しさん** · 2024/08/10(土) 13:42:02.22

今までそのプロジェクトに一度も貢献したことの無い人が「Rustで書き直さないの？」ってIssueを立てて即リジェクトされるのを見かける……
なぜかそういう人が好む言語 (彼らが本当にRustを書いているのかは不明)

**デフォルトの名無しさん** · 2024/08/10(土) 13:42:44.88

人間がチェックするよりコンパイラに機械的にチェックさせたほうがこういうミスは出ないってことだ

**デフォルトの名無しさん** · 2024/08/10(土) 13:45:07.25

>>92
今回のクラウドストライクのやらかしは本来はテストコードで見つかるはずの脆弱性なんだけどな

**デフォルトの名無しさん** · 2024/08/10(土) 13:56:12.38

Rustで防げる種類バグがあるのは事実でも、Rustに変えるとバグが減ります！と言っちゃうと嘘になる現実があるからみんな苦しんでるんですよ

**デフォルトの名無しさん** · 2024/08/10(土) 14:13:42.84

>>93
うっかりテストコードが抜けていても
Rustならコンパイラが撥ねてくれるからいいね

>>94
こういう参照バグやメモリ競合バグは確実に減るね

**デフォルトの名無しさん** · 2024/08/10(土) 15:13:38.79

それなのにRustは全然使われない理由って何なのかなあ

**デフォルトの名無しさん** · 2024/08/10(土) 15:33:50.34

クラウドストライクが件のセキュリティソフトを開発し始めた頃はまだRustが安定版になかったし仕方ない

**デフォルトの名無しさん** · 2024/08/10(土) 15:37:06.14

言語とビジネスは別の話だからだろ
顧客はソフトウェア製品にお金を出すのであって、「Rustで書かれていること」にお金を払うわけじゃない
既存プロジェクトを置き換えたところで顧客から追加のお金を貰えるわけではないし、置き換えをメインに作業してる間は機能追加などの開発は止まるわけだし
新規開発での採用は進んでると思うぞ

**デフォルトの名無しさん** · 2024/08/10(土) 16:01:23.31

以前からのは対策が遅れるの仕方ないよな
ただし新規案件でC++はアウトで言い訳できない
十分に学習とお試しする時間があったのだから

**デフォルトの名無しさん** · 2024/08/10(土) 16:03:24.43

もともとC++を使う案件自体が少ないんで

シビアなところは互換性を考慮してC++のまんまだし

**デフォルトの名無しさん** · 2024/08/10(土) 16:16:28.94

>>99
お前は何様なんだよw

警備員[Lv.1][新芽] · 2024/08/10(土) 16:19:11.72

チンパンジーのあいちゃん

**デフォルトの名無しさん** · 2024/08/10(土) 16:58:24.77

>>82
trait 使うのやめて

>>77 の関数を
fn moge<F>(a: &str, b: &str, f: F) -> i64
where F: for<'a> Fn(&'a Hoge) -> Fuga<'_> {
中身
let m = f(hoge);
中身
}
にかえて

>>78 の呼ぶ側を
let x = moge(2, 5, |hoge| Fuga::from(hoge));
にしたらうまくいきました
ほんとうにありがとうございました

**デフォルトの名無しさん** · 2024/08/10(土) 17:14:57.10

多分>>76の戻り値をFuga<'a>に直すのが根本的解決だけどうまくいったならもういっか

**デフォルトの名無しさん** · 2024/08/10(土) 22:48:05.26

タウリン好き
WinMacで動くクライアントアプリ書きたかってん

**デフォルトの名無しさん** · 2024/08/10(土) 23:49:33.16

>>104
私の記憶ではそこはやってみたのですが治りませんでしたね

**デフォルトの名無しさん** · 2024/08/11(日) 08:59:52.85

>>86 >>93 ほんそれ
こんなんテストしてれば見つかる話で恥ずかしいレベルの大チョンボ
マイクロソフトはもちろんクラウドストライクを訴えれば良いし
デルタ航空はマイクロソフトとクラウドストライクに5億ドル請求って言ってるけど
マイクロソフトを訴えるのは筋違いなので
デルタ航空以外の被害受けた各社はみんなでクラウドストライクを訴えれば良い

**デフォルトの名無しさん** · 2024/08/11(日) 11:53:58.67

Rustで防げるっていうのは、リストに正常にアクセスできたかチェックを強制されるって意味？

**デフォルトの名無しさん** · 2024/08/11(日) 12:32:03.37

標準環境なら範囲外アクセスはpanicして停止する
Cだとそこに有効なデータがあるものと思ってそのまま操作してしまい、その結果何が起きるか分からないということがある (言語でなくOS側のチェックにより防がれることはある)
no-std環境のRustについては自分も詳しくないので誰か書いてくれ

**デフォルトの名無しさん** · 2024/08/11(日) 12:55:28.88

>>108
Rustでは20個の領域を作った時点で
そこをその先頭アドレス=ポインタで指すのではなく
連続体(スライス)を抽象的な参照で指す
もちろんそのスライスへの参照は内部では先頭アドレスと長さになるが抽象的なスライス参照&[T]として扱う
そこからイテレータは20個の個別参照&Tを連続的に返したりインデックス指定によりget(index)でOption<&T>を得たりできる
21個目のアドレスを得たりその中身を見たりすることはsafeの範囲ではできない

警備員[Lv.4][新芽] · 2024/08/11(日) 14:07:38.05

それはどんなアセンブルコードに落ちているの？

**デフォルトの名無しさん** · 2024/08/11(日) 14:30:38.38

抽象的なレベルで安全を確保してしまえばその後にそのコードは最適化し放題
生成アセンブルコードはcargo asmでその場で確認できる

**デフォルトの名無しさん** · 2024/08/11(日) 15:19:18.37

>>111
範囲内かどうか比較する処理は入る。
ただし、静的に絶対安全と分かる状況なら最適化で消えることもある。
そうでなくても現代的 CPU だと分岐予測によって速度的ペナルティは小さいことが多い。
ゼロコストというわけではないが、 C 風のポインタがあまりにも素朴でミスしやすいことに対する解決法としては十分以上に小さいコストだと考えられている。
今では C++ にもスライス的な、範囲を表すクラスが標準に追加されていて再編成が進んでるのでやっぱりそのほうがよいという時代の潮流があるんだと思う。

**デフォルトの名無しさん** · 2024/08/11(日) 15:21:08.97

またいつもの嘘吐きが

**デフォルトの名無しさん** · 2024/08/11(日) 16:17:49.13

zigはリリースビルドだと範囲チェックをオフにしちゃうらしい
やっぱゼロコストじゃないよね

**デフォルトの名無しさん** · 2024/08/11(日) 16:42:50.50

>>111
例えばスライスをforで回してその値を書き込む関数
#[inline(never)]
fn foo(slice: &[i32]) {
　for t in slice {
　　write_volatile!(VOLATILE, *t);
　}
}

生成アセンブリコード
::foo:
　test rsi, rsi
　je .LBB11_3
　shl rsi, 2
　xor eax, eax
.LBB11_2:
　mov ecx, dword ptr [rdi + rax]
　mov dword ptr [rip + ::VOLATILE], ecx
　add rax, 4
　cmp rsi, rax
　jne .LBB11_2
.LBB11_3:
　ret

範囲内かどうかのチェックはC/C++と同じくループ内で1箇所のみで同じ動作になる

**デフォルトの名無しさん** · 2024/08/11(日) 17:01:54.96

ベアメタル環境でもRustってCより有用なものなの？
安全性は保証しやすくなるとして、書きやすさ (あるいは面倒臭さ) がどれほどのものか
実際経験ある人いる？

**デフォルトの名無しさん** · 2024/08/11(日) 18:11:06.27

>>117
内部的には unsafe が必要だけど外に対しては安全性を保障している基礎的な語彙が標準ライブラリにはいっぱいあるじゃん。
ああいう感じの基礎的なものを環境に合わせて作るというのがスタートラインで、それが適切に出来てればベアメタル環境だからといって特別な違いはない。

unsafe を適切に下層レイヤに押し込めれていないと全体に unsafe が頻出して Rust の安全性の恩恵を受けにくいし、
安全性の恩恵を受けられないのに Rust の面倒くさい部分はあるという状況になって嬉しくない。

最初の整備をまじめにやるのがすごく大事。

警備員[Lv.7][芽] · 2024/08/11(日) 20:48:33.63

>>116
thx

**デフォルトの名無しさん** · 2024/08/11(日) 21:00:21.89

no_stdだとRustの基本的な機能は使えるけど
I/O入出力ライブラリなどが当然ないから
Hello, World!するのにこんな感じなのね
https://zenn.dev/zulinx86/articles/rust-nostd-101#final-code

**デフォルトの名無しさん** · 2024/08/12(月) 13:11:33.58

>>117
保守には良いと思う
リファクタリングには向いていない

**デフォルトの名無しさん** · 2024/08/12(月) 13:21:38.56

>>120
ベアメタルって元々そういうもんでそ

**デフォルトの名無しさん** · 2024/08/12(月) 14:00:36.88

>>121
ちゃんとトレイトベースで作っていれば
Rustはリファクタリングもしやすくミスも防げる

**デフォルトの名無しさん** · 2024/08/12(月) 14:04:58.34

>>123
「ちゃんとトレイトベースで作っていれば」
というのが難物という罠。

**デフォルトの名無しさん** · 2024/08/12(月) 14:12:42.26

トレイトを使いこなせば便利で快適なのに
難しいと思い込んで使いこなさない人が困るだけ

**デフォルトの名無しさん** · 2024/08/12(月) 14:53:33.48

複オジに餌を与えないでください！
みんなが迷惑しています！

**デフォルトの名無しさん** · 2024/08/12(月) 15:10:33.91

事前に理想的な設計が出来るなら苦労はないんだが現実はそうではないという話だわな

**デフォルトの名無しさん** · 2024/08/12(月) 15:15:42.43

新たにtraitを導入する時やリファクタリングで構成を変える時も新たなtrait境界を満たしていけばよくて使い勝手がいいね

**デフォルトの名無しさん** · 2024/08/12(月) 15:16:59.31

リファクタリングができない難しいという
人が定期的に出るけど他の言語とも比較して
コード例出してくれ

**デフォルトの名無しさん** · 2024/08/12(月) 15:32:17.85

リファクタリングしやすいしにくいの違いの定義がそもそもわからん
そういう意味でも例を頼む

**デフォルトの名無しさん** · 2024/08/12(月) 16:20:20.18

自分的には「リファクタリングしやすい」＝「書き換えミスがコンパイルエラーとして検出されやすい」なので
型強めの静的型（Rust）>型弱めの静的型（C系）>動的型
って感じ
ただ「書き換え時にコンパイルエラーに煩わされない」を重視してて動的型がリファクタリングしやすい派もいるっぽい
（個人的にはエラーにならなくてもいつのまにか動作変わってたら意味なくない？と思うけど…）

**デフォルトの名無しさん** · 2024/08/12(月) 17:02:05.11

ああ，書き換え中にエラーなり警告なりが出るのが煩わしいってことか
大抵の言語でそれはありそうだから，エディタの設定で最後にタイプしてから何秒後にアナライザのチェックを入れるかとかいじればいいのでは

**デフォルトの名無しさん** · 2024/08/12(月) 17:13:40.85

JetBrainsがリファクタリング機能の出来具合で比べてみると一目瞭然
静的型付け言語の中では最弱

**デフォルトの名無しさん** · 2024/08/12(月) 17:14:55.12

前スレでもリファクタリングの話出てたけど
無かったことにしてまた同じ話するの

**デフォルトの名無しさん** · 2024/08/12(月) 17:16:15.95

プログラマの中には剛腕タイプというか、脳のメモリが大きくて広い範囲の見通しを付けられる人はいる。
そういう人にとっては抽象レイヤも静的型も邪魔になる。

でもまあそういうのはほんまもんの超人なので普通の人は静的型のほうがいいと思う

**デフォルトの名無しさん** · 2024/08/12(月) 17:23:31.41

他言語との比較もネタ切れ感無理矢理感が激しくていい加減飽きてきた

**デフォルトの名無しさん** · 2024/08/12(月) 17:32:40.07

昔から静的型付け言語はリファクタリングが不便と主張する人がいるけど
イヤなら動的型付け言語を使っていなさい、で終わる話

**デフォルトの名無しさん** · 2024/08/12(月) 20:58:59.97

Rustの面倒臭さって静的型付けだけでないと思う
方針が見えてるものを堅く作る分には強いけど、作る→試す→改善するといったサイクルを回すような開発は負荷が大きい
Rustでのゲーム開発を断念したLogLog Gamesが出した文章 (https://loglog.games/blog/leaving-rust-gamedev/) なんかは、全てに同意しないにしても、Rustってそういうデメリットはあるよねって感じるだろうし

**デフォルトの名無しさん** · 2024/08/12(月) 21:02:06.81

matchで全揃い(Some(a), Some(b), Some(c)) =>などができない言語だと確かに面倒かもしれない

484 デフォルトの名無しさん 2024/08/12(月) 17:05:54
Optional型の変数はNoneの場合のハンドリングが必要だから余計に複雑度が増す
だからNoneで明示的に初期化が必要な関数ローカルの状態変数が3つもあるのなら
リファクタリングを検討したほうがいいと思ってる

**デフォルトの名無しさん** · 2024/08/12(月) 21:06:34.61

>>138
その人も「Once you get good at Rust all of these problems will go away」と書いているように
Rust流のやり方を身に着ければ消える問題ばかり

**デフォルトの名無しさん** · 2024/08/12(月) 21:13:39.00

https://github.com/rust-lang/rust/issues/91639

デフォルトでwarnにもdenyにもなってないけど最重要級のlint見つけたぞい
前スレのライフタイムリファクタの話題が出た時点で教えて欲しかったな……

**デフォルトの名無しさん** · 2024/08/12(月) 21:19:15.69

>>140
内容読んでるか？
その反応こそ批判対象の一部だぞ
Rustの根本的な部分で困難が生じていても、Rustコミュニティは「それはあなたがRustのやり方を知らないだけだ」としか言わない、というのを批判してるチャプターだ

**デフォルトの名無しさん** · 2024/08/12(月) 21:32:50.85

複オジをRustコミュニティの代表者として扱うなよ

**デフォルトの名無しさん** · 2024/08/12(月) 21:42:37.55

>>141
それよりも簡単な解決方法として
ライフタイム'1と'2の相違エラーが出た時点で
その部分の省略ライフタイムを自分で明示的に補ってやればいい
そうすると何が問題だったのかが視覚化される

**デフォルトの名無しさん** · 2024/08/12(月) 22:04:56.11

>>139
Pythonでも普通に出来るぞw
論点そこじゃないだろww

**デフォルトの名無しさん** · 2024/08/12(月) 22:12:53.72

他言語と比較して優位を示したい向きがメインになってしまうとどうも Rust の問題の存在を否定する方向に向かいがちで良くないな
そう考えるとオナニーコードでレスバやってたほうがいくらかマシだったのかもしれん

**デフォルトの名無しさん** · 2024/08/12(月) 23:01:06.12

リファクタリングの件でも他の件でもいいけど、
他の言語と比較してRustで何が難しくて困っているのかを具体的なコード例で出してくれないと、
話が進まずに個人の感想か空想に終わってしまう。

**デフォルトの名無しさん** · 2024/08/13(火) 12:11:44.59

>>131
ミスをコンパイルエラーにしてくれることがプログラム書いて色々試してる時もリファクタリングしてる時も一番重要だもんな
他の言語だと実行時のエラーや実行時のデバッグに依存せざるを得なかったことがRustでは実行前に解決することが多くて開発効率が良くて助かる

**デフォルトの名無しさん** · 2024/08/13(火) 12:58:50.63

設計を変更する際に必要な変更が多いのはありそう
例えば既存のコードをasyncに対応させようとすると、必要なデータを Arc, Mutex で包んだり、参照のせいでSendできないものをOwnedな型に置き換えたり、トレイト境界に Sync + Send を付けてまわったりといった手間が要る
「設計を変更する」と決めたのでなく、「変更するとどうなるか試したい」といった場合でもこういった作業が必要で、その点は面倒かもしれない
必要な変更をコンパイラが教えてくれるのがありがたいというのは自分も同意する

**デフォルトの名無しさん** · 2024/08/13(火) 13:12:20.55

>>149
シングルスレッドの言語以外は
メモリを共有するならそれら排他制御が必要となる点で言語に関係なく同じ
メモリを直接共有しない(例えばチャネル使用)ならRustでもそれらは必要ない
つまりRust特有の話ではない

**デフォルトの名無しさん** · 2024/08/13(火) 13:12:37.07

動的言語に比べて静的言語がリファクタリングしやすいのは当たり前
モダンな言語の中でRustは所有権とライフタイムのせいで他に比べて明らかにリファクタリングが面倒

火を見るより明らかなことなのになぜ必死に否定したがるのか意味がわからない

**デフォルトの名無しさん** · 2024/08/13(火) 13:14:54.05

>>149
asyncはリファクタリングとはまた別のRustの弱点

**デフォルトの名無しさん** · 2024/08/13(火) 13:23:07.46

>>152
Rustのasyncはスタックレスでリソース消費も少なく高速で動作して使い勝手もいいよ
何を根拠に弱点と？

**デフォルトの名無しさん** · 2024/08/13(火) 13:28:41.46

>>151
所有権とライフタイムは慣れの問題であり大した問題ではない。
それが出来ない人はGCに依存して遅くメモリ喰いの言語を使っていなさい。

**デフォルトの名無しさん** · 2024/08/13(火) 13:46:36.22

非同期による排他は別にしても参照まわりの面倒さはある
&str にするか String にするか、Rc<String> なのか Arc<Mutex<String>> なのかといったものを考える必要があるし、リファクタ/設計変更の際にこれらの置き換え作業が必要になることはある
細かな最適化はできなくても、GC有りの言語がシンプルに1つString型だけ提供しているのは楽といえば楽

なぜエラーになるのかはコンパイラが教えてくれるし、慣れれば分かるものだけど、必要な変更が他の静的言語に比べて多くて面倒というのは否めないでしょ
自分はRustは好きだし良い言語だと思ってるけど、不便が無いとは思わないし、それが分からないのは現実の開発経験が無いんじゃないかとすら思う

**デフォルトの名無しさん** · 2024/08/13(火) 13:51:51.56

Rustはわかってないとそもそも型チェックに通るコードが書けない

**デフォルトの名無しさん** · 2024/08/13(火) 14:03:17.07

もっと経験を積むと「なぜエラーになるのかはコンパイラが教えてくれる」どころか「コンパイラはこちらのミスをエラーにしてくれる」すら思い込みだったと気づく時が来る
もう一度貼っておくからよく読むように
特に「5) コンパイルされたならライフタイムの記述は正しい」と「7) コンパイラのエラーメッセージはプログラムの直し方を教えてくれる」

https://github.com/pretzelhammer/rust-blog/blob/master/posts/translations/jp/common-rust-lifetime-misconceptions.md

**デフォルトの名無しさん** · 2024/08/13(火) 14:04:43.72

Rustの問題じゃないね
チーム適用や実要件に当てはめて見る実務マと趣味マの違い

**デフォルトの名無しさん** · 2024/08/13(火) 16:05:15.51

>>157
それは詭弁
例えばその「5) コンパイルされたならライフタイムの記述は正しい」
まずこれは参照の安全性を保証するRustとしては常に正しい

もちろん複数の参照が登場する時は色んな組み合わせのライフタイムの付け方がある
それらのうち参照の安全性を保証できる組み合わせのみをコンパイラは通す
コンパイルが通る組み合わせのうちどれが自分の意図なのかは各自の問題となる

もし自分の意図と異なっていた場合はそれが利用されるところで参照が切れてコンパイルエラーとなる
そのため間違っていたことに気づくことができる
そして修正してコンパイルが通れば記述は正しい
その記事の例でもこの流れで正しい記述にたどり着けている

**デフォルトの名無しさん** · 2024/08/13(火) 17:41:07.28

「Rustで作るプログラミング言語」
この本おすすめですか？

**デフォルトの名無しさん** · 2024/08/13(火) 17:55:28.98

>>159
利用の仕方が変わると、それに引っ張られて宣言側が正しかったかどうかが変わる、と言いたいの？

**デフォルトの名無しさん** · 2024/08/13(火) 18:03:57.04

>>161
一般的にそうなる
例えば二つの参照を引数にとる関数で二つに異なるライフタイムを持たせるかどうかは利用の前提や方針でどちらもありうる
利用する側(やそれを全て想定したtest)でコンパイルが通るならばそのコードは正しい

**デフォルトの名無しさん** · 2024/08/13(火) 18:21:49.94

「参照を扱う際は適切なライフタイム注釈を書く必要がある」は他の静的言語より面倒という指摘そのものでは？
「適切なライフタイム注釈を書けばコンパイルは通るし、それで安全性が保障される」のは分かってるけど、問題はそこではなくて

**デフォルトの名無しさん** · 2024/08/13(火) 18:23:56.90

>>162
なるほどね、「正しいコード」の定義に齟齬があるのね

「5) コンパイルされたならライフタイムの記述は正しい」の「正しい」は「プログラマの意図通りである」の意味だと思って
それを念頭にもう一回読み直してみて

**デフォルトの名無しさん** · 2024/08/13(火) 18:27:02.24

>>163
それはRustの問題じゃないよ
GC言語か否かの問題だね
GC言語は参照の有効性を気にしなくてもよい代わりに遅くてメモリを消費するペナルティ

**デフォルトの名無しさん** · 2024/08/13(火) 18:33:34.80

>>164
想定する利用ケースでコンパイルが通ればプログラマの意図通りで正しい
>>157の(5)の例もプログラマの意図通りでなかったためコンパイルエラーとなった
そしてコードを修正してコンパイルを通すことで意図通りの正しいコードになった

**デフォルトの名無しさん** · 2024/08/13(火) 18:35:53.44

「正しい」という言葉を多用する技術者にまともなやつはいない

**デフォルトの名無しさん** · 2024/08/13(火) 18:48:09.58

>>165
C/C++に比べても面倒では？
設計で防げる問題/考慮が要らない問題に対して必要以上のガードを書かされる感じ

例えばグローバルな変数 (一度だけ初期化され、以降は不変) に対して Sync が要るのも、初期化が複数スレッドから呼ばれた場合の安全性を保証しないとコンパイルが通らないからだけど、設計上それは要らないって場面はある
シングルスレッドなアプリだったり、マルチスレッドだけどスレッド生成は初期化の後であるいった場合

参照も同じで、設計上無効なデータを指すことがないといえるケースでも、コンパイラを納得させるために手動でライフタイム注釈を書く必要があるといった感じ

**デフォルトの名無しさん** · 2024/08/13(火) 18:49:04.65

>>167
>>157の「5) コンパイルされたならライフタイムの記述は正しい」が合っているかどうかの話が行われている
想定した使い方でコンパイルが通ったならば記述は正しい
何をどう想定するかでコードは変わりうる

**デフォルトの名無しさん** · 2024/08/13(火) 18:59:01.23

>>168
スレッド内でしか用いないならばthread_localにより!Syncでも使えるよ
「設計上それは要らない」「設計上無効なデータを指すことがない」という思い込みは絶対にダメ
例えば無効なデータを指さないが&'staticの意味ならばそれを使えばよいのだよ

**デフォルトの名無しさん** · 2024/08/13(火) 19:01:54.22

>>166
想定するケースが最初から全部書けるならそれでいいが、残念ながらそんな現実は無いよ
ソフトウェアテストの7原則のひとつ: 全数テストは不可能

それに、意図はコード化できるものばかりではない、unsafe関数のdoc-commentに書くべきsafety sectionだってそうだろう
コード化できなければ「プログラマの意図」ではないというのならそれも一理あるだろうが、多分誰も同意しないと思うぞ

**デフォルトの名無しさん** · 2024/08/13(火) 19:10:37.01

>>171
そんな大きな話はなされていない
一般的な話はRustの範囲を超えている
今回はRustのライフタイムの記述が正しいかどうかの話
想定した使い方でコンパイルが通ればそのコードは正しい＆安全となる
想定範囲を変えたり広げたりしてコンパイルエラーとなったならばそれに対応すればよい

**デフォルトの名無しさん** · 2024/08/13(火) 19:44:50.08

そもそもの話は「他の言語に比べてリファクタや設計変更がしづらい」という話では？
誰も「ライフタイムが提供する安全性が間違ってる」なんてレスはしてないよ
安全性の保証は強力だけど、そのぶん生産性を低下させ得るデメリットもあるよねって話をしてるだけで

**デフォルトの名無しさん** · 2024/08/13(火) 19:53:38.42

>>172
あなたが「コンパイルが通ればそのコードは正しい」というとき、それは利用側と定義側を含むコード全体の正しさのことを言っているんだよね

でも例のブログ記事は、利用側のfn main()の本体に何が書かれていようと、定義側のfn next()はそれ単独で「正しい」か（≒プログラマの意図通りか）を考えられる前提で書かれているんですよ
つまりmain()でnext()を1回呼ぼうが2回呼ぼうが、next()は変えていないんだから想定する意図は変わらない
最初からnext()は間違っていたことが、main()を変えたことで明らかになった、と

そう思ってもう一回読んでみてね？

**デフォルトの名無しさん** · 2024/08/13(火) 19:55:05.46

Dioxusのチームもこのような記事を書いている
https://dioxus.notion.site/Dioxus-Labs-High-level-Rust-5fe1f1c9c8334815ad488410d948f05e

GitHub Acceleratorに選ばれるくらい有望なプロジェクトだし、間違いなくレベルの高い開発者が揃ってるチームけど、彼らですらRustの課題を指摘してるわけで

**デフォルトの名無しさん** · 2024/08/13(火) 19:56:59.13

>>173
ライフタイムをコンパイラがチェックしてくれることで生産性は低下ではなく上昇でしょ
全てのコードを人間がチェックし続けたりチェックし忘れて実行時デバッグとなることが生産性の低下ですね
さらにその参照バグにきづかないままだとセキュリティホールを招いてしまいますよ

**デフォルトの名無しさん** · 2024/08/13(火) 19:57:14.06

>>157
めっちゃ判りますωωω

**デフォルトの名無しさん** · 2024/08/13(火) 20:05:14.94

>>174
最初のコードもコンパイラが通ってアサートも通って意図通りに動いている
次のコードはイテレータが返した値を保持したままイテレータを作動させられる仕様への変更 (今回の例は可能だが必ずしも仕様変更できるかどうかは別)
それぞれコンパイルが通れば意図通りに正しく動作している

**デフォルトの名無しさん** · 2024/08/13(火) 20:07:43.05

>>174
ほんそれ

**デフォルトの名無しさん** · 2024/08/13(火) 21:30:24.68

>>178
アサートも利用側のmain()にあるものなんだから、next()の呼び出し回数の話と同じで
ここからnext()についてのプログラマの想定を読み取ってたら、この記事が理解できないのは当然なんだってば
最初から理解する気が無くてそういう意地悪言ってるんじゃないよね？

修正後のプログラムの後に
> 今こうして前のプログラムを見返してみると、明らかに間違っていましたね。
って書いてあるんだから、これは仕様を変更したじゃなくて、最初から間違っていたのを修正したという体なんですよ

**デフォルトの名無しさん** · 2024/08/13(火) 21:51:35.56

>>180
一番最初に書いたようにその人の詭弁
後者の利用方法に対応する仕様にしたいならば最初からその後者用のアサートを入れたらよい
そうすれば一発でコンパイルエラーになって修正して終わり
ライフタイムに関してはコンパイルが通ればその利用方法については必ず正しい
コンパイルが通ったのに間違っていることはない

**デフォルトの名無しさん** · 2024/08/13(火) 22:37:13.69

もう少しわかりやすい別の例を出すと

struct Foo(&str, &str);
このライフタイム注釈が無いのは当然エラーになるのは置いとくとして

struct Foo<'a>(&'a str, &'a str);
このように宣言しても多くの用途で困ることはなく
むしろこれで都合がよいこともある
つまりこの宣言方法はバグではない
そしてこれでコンパイルが通る範囲の利用方法をしていれば正しく動作する

しかし用途によっては上記では困りエラーとなる利用方法もある
そこで
struct Foo<'a, 'b>(&'a str, &'b str);
このように宣言することで新たな利用方法に対応が可能となる
こちらに変えてもそれでコンパイルが通る範囲の利用方法をしていれば正しく動作する

どちらのケースでもコンパイラが通せば各々の利用範囲でライフタイムの記述は正しい
コンパイラが通したのに間違っているなんてことは起きない

**デフォルトの名無しさん** · 2024/08/13(火) 22:44:00.39

>>181
じゃあ別の切り口から
next()を単独で見てみようか
結局、問題の根本は戻り値のbyte(=&self.remainder[0])としてあり得る最大のlifetimeは'remainderなのに、それより小さい'mut_selfを指定してしまっていることだよね
trait実装の場合にはtraitの宣言に合わせるために実際より小さいlifetimeを指定しないといけない場合があるしれないが、この例は単なるミスで'mut_selfでなくてはいけない理由は特に無いということだった

このnext()の定義を単独で見て、おかしなところは本当に何も無いのか？
next()が正しくないということを示すために、main()の内容を考慮する必要が本当にあるのか？

別にコンパイルエラーになることをいちいち確認しなくても、「なんかおかしいなこれ」って早く気付いて修正できるならそのほうがいいでしょ、って個人的には思うけどね

**デフォルトの名無しさん** · 2024/08/13(火) 22:54:24.44

こちらの主張は最初から一貫して
>>157の記事「『5) コンパイルが通ればライフタイムの記述は正しい』は間違っている」
という主張とその説明例は詭弁だということ

以下は常に正しい
『5) コンパイルが通ればライフタイムの記述は正しい』

自分の意図通りの使い方をした利用範囲でコンパイラが通ったのならば
その利用範囲で記述は正しい
利用するつもりのない利用方法に必ずしも対応する必要がないことは>>182で説明した

**デフォルトの名無しさん** · 2024/08/13(火) 23:11:58.95

>>184
ここまでのあなたの主張は正確に言えば「*十分に実際のユースケースを反映した利用側コードとともに* コンパイルが通ればライフタイムの記述は正しい」じゃないか
強い前提を置けば正しいと言える確度も高まって当然だろう
勝手に前提を変えて違う結論を導くのは、それこそ詭弁ではないか

**デフォルトの名無しさん** · 2024/08/13(火) 23:29:33.49

利用方法とその範囲は各実際のケースで各々異なるのだよ
あらゆるケースを想定して対応することは必要ないだけでなく事実上無理なこともあるだろう
必要となるケースのみ対応すればよい
そして必要となるケースはプログラムとして書かれているかテストコードに書く
どのようなケースでもコンパイルが通ればその記述コードは正しい
コンパイルが通ったのに誤動作することは起きない