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/07/31(水) 00:47:02.26

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

Rust Reference Book
https://doc.rust-lang.org/reference/
Rust Standard Library
https://doc.rust-lang.org/std/
Rust rustc Book
https://doc.rust-lang.org/rustc/
Rust rustdoc Book
https://doc.rust-lang.org/rustdoc/
Rust rustup Book
https://rust-lang.github.io/rustup/
Rust Cargo Book
https://doc.rust-lang.org/cargo/
Rust unstable Book
https://doc.rust-lang.org/nightly/unstable-book/
Rust macro Book
https://danielkeep.github.io/tlborm/book/
Rust CLI (Command Line Interface) apps Book
https://rust-cli.github.io/book/
Rust Future Book
https://cfsamson.github.io/books-futures-explained/
Rust async-std Book
https://book.async.rs/
Rust tokio Book
https://tokio.rs/tokio/tutorial
Rust serde Book
https://serde.rs/

**デフォルトの名無しさん** · 2024/08/01(木) 16:24:10.41

>>1
乙

**デフォルトの名無しさん** · 2024/08/01(木) 18:56:40.59

https://prcdn.freetls.fastly.net/release_image/22017/53/22017-53-0b7b835a46293a3a03b057104ef0d96b-2440x1394.png

**デフォルトの名無しさん** · 2024/08/01(木) 23:55:38.74

「The Rust Foundation」は、人命や財産に関わるような安全性が決定的に重要になるシステムのために、
Rust言語を責任を持ってサポートするためのコンソーシアム「Safety-Critical Rust Consortium」の設立を発表しました。
設立には日本からWoven by Toyotaが参加

**デフォルトの名無しさん** · 2024/08/03(土) 23:20:11.39

今日調べたけど、RustでVecを拡張するときのサイズは前の2倍
JavaとRubyは1.5倍
Pythonはややこしくて約112.5%
Goはまず2倍だけど要素数が256を超えたら1.25倍におさえる

Rustはメモリ大目に使いがちかも

**デフォルトの名無しさん** · 2024/08/03(土) 23:47:40.31

Note that the exponential growth is important.
On each reallocation, we have to copy twice as much, but then it takes twice as long to fill up again.
These factors cancel out and we get (on average) constant-time .push().

**デフォルトの名無しさん** · 2024/08/04(日) 09:23:44.30

>>7
そのレートを利用者側で調整出来れば最強だった

**デフォルトの名無しさん** · 2024/08/04(日) 12:21:30.93

要らない
設定できてしまうと、測定もせずに小さなレートを設定してかえって遅くなるか、
神経質な人やチームなら必要もないのにいちいち測定する羽目になって生産性爆下がりするかの二択になる
本当に調整する価値のある状況ならちゃんと測定して決めるはずだし、その手間に比べたら自前で適宜リサイズするくらい全く問題にならない手間だろう

**デフォルトの名無しさん** · 2024/08/04(日) 12:26:21.94

>>7
それらGC言語は言語によってはメモリ管理上で仕方ない場合もあるのかもしれないが
C++やRustでは全く問題がないように作られているためパフォーマンスの良い2倍にしている
重要な点はキャパシティを2倍にしても実メモリ割り当ては2倍の消費をせずにその後ベクタを使用した長さ分だけに限られること

**デフォルトの名無しさん** · 2024/08/04(日) 12:30:08.75

んなわけあるかい
いつのまにか勝手に他に割り当てられたらキャパシティの意味ないでしょ

**デフォルトの名無しさん** · 2024/08/04(日) 12:37:16.12

>>12
実メモリ割り当てと仮想メモリ割り当ての違いを学ぼう
C++でもRustでもベクタのキャパ内の未使用エリアにアクセスしない
そのため未使用分の実メモリ割り当ては発生せずメモリ使用量の問題が起きない

**デフォルトの名無しさん** · 2024/08/04(日) 13:05:57.09

まーた複オジの嘘がはじまったね

**デフォルトの名無しさん** · 2024/08/04(日) 14:52:31.44

ユーザ空間の話してるときにカーネルの話混ぜないでよ

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

仮想メモリと実メモリの話はそもそもGoやJavaやRubyでも同じだろ
「他の言語では必ず実メモリから取られるから物理メモリ以上の量のデータを確保できない、だからこれらの言語では動的配列の確保を2倍よりも小さい値ずつにしている」とでも言いたいのか？

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

2倍にしていけば累積コピー回数を平均1回台に抑えられるメリットがあって
これは1+2+4+8+...+2^(n-2)+2^(n-1)=2^n-1で累積と同じになるからで
そのためC++(gccやclang)やRustは2倍を採用している状況

別問題として
2倍にしていくのはメモリがもったいなくね？があるけど
OSの仮想メモリ管理により実際に使われるまでは実メモリが使われることはないのでだいじょうぶ

さらに自らv.reserve(size)とサイズを指定する手段も用意されていて
size以下の間はお引っ越しコピーを避けることができるので見積もれる時は推奨だよ

**デフォルトの名無しさん** · 2024/08/04(日) 17:23:30.18

reallocationなんてパフォーマンス落ちるだけだし
with_capacityで自分でコントロールした方が良いと思う

**デフォルトの名無しさん** · 2024/08/04(日) 17:51:55.81

>>17
仮想メモリは消費しないのか？
32bit OSだと何もしなければ仮想メモリ4GBくらいしか無い気がするが。

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

大きなサイズに育っていくならコピー回数が少なくなる毎回2倍が有利
仮想メモリが足りるか足りないかの限界状況で用いるならwith_capacity()やreserve()を最初から用いる

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

フラグメンテーションの問題とかもあるから教科書通りの2倍固定よりも
Goのようにサイズが大きくなるにつれGrowth Factorも小さくしていくモデルのほうが一般的には良さそうだね

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

gccでもclangでもC++のvectorは2倍にしていくから
これはRustの話ではなくて
2倍にしていくのが好ましいという長年の確立された知見が存在しているんだよ

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

一方でガベージコレクション依存言語は内部のメモリ管理方式が全く異なるから
各言語個別の事情があるかもしれないけどこのスレの話題ではないね

**デフォルトの名無しさん** · 2024/08/04(日) 19:01:06.46

>>16
それらの言語は仮想メモリを持たない環境のことも考慮しての増加率なんだろうな

**デフォルトの名無しさん** · 2024/08/04(日) 19:12:09.84

仮想メモリを持たない環境でGC言語www

**デフォルトの名無しさん** · 2024/08/04(日) 19:40:14.37

思い込みの激しい人だこと

**デフォルトの名無しさん** · 2024/08/04(日) 19:41:13.70

Vecのアロケート戦略なんて標準ライブラリの実装レベルの話でしかないし、言語の特徴や優劣のような話でもないだろ
GoやJavaが2倍でも、逆にRustがより小さい値だったとしても、GCの有無とかの話に比べればずっと些細な話でしかないし
マジでなにいってるんだこいつとしか思えない

**デフォルトの名無しさん** · 2024/08/04(日) 19:48:10.28

>>25
Javaなんかはもともと組み込みをターゲットに開発された言語だね。
GCの有無と仮想メモリには何の関係もない。

**デフォルトの名無しさん** · 2024/08/04(日) 20:16:30.17

この議論
元々メモリ無駄食いのGC依存言語は無視してよくて、
Rustと同じジャンルのC++で長年議論されてきて2倍という結論が出ている。
どうしても2倍を批判したいならまずはgccやclangのC++に対して行なうとよいかと。

**デフォルトの名無しさん** · 2024/08/04(日) 20:31:51.43

2倍に対して突っ込んでるんじゃなくて延々と的外れなことを書いてることに対して突っ込まれてるだけでは？
平均的なコピー回数が少ない点で2倍は妥当ではあるけど、それも「よく使われる方法」くらいの意味しかない
C++でもMSVCだと1.5倍だったと思うし (今のバージョンでもそうかは未確認)

警備員[Lv.18] · 2024/08/04(日) 21:44:51.68

先生！チャンクアロケーター沼への入水希望者がこんなに

**デフォルトの名無しさん** · 2024/08/04(日) 22:06:56.31

>>21
Goがなぜそんなやり方をしているのか
実行しながら実メモリ使用量の変化を傍らでウォッチして見た
Goの大きなsliceでcapacityが増える時に実メモリ使用量が急激に増える
C++やRustではcapacityが増えてもそんな変動は起きない
つまりGoはこの問題のため2倍ではなく1.25倍にせざるをえないと思われる

**デフォルトの名無しさん** · 2024/08/05(月) 00:28:29.24

>>16の主張が間違っていた可能性があるな
例えば世代別GC各管理領域も拡張再編などが起きるため
C++/Rustとは状況が異なり
増やしたメモリ領域への書き込みがすぐに生じて実メモリ使用量が一気に増えてしまうのかもしれない

**デフォルトの名無しさん** · 2024/08/05(月) 02:39:57.82

C++で folly::fbvector を開発したFacebookによれば
成長係数2は最悪であることが数学的に証明されてるらしい
結論は1.5

https://github.com/facebook/folly/blob/main/folly/docs/FBVector.md

https://medium.com/smucs/fbvector-a-possible-replacement-for-std-vector-e46bb31b8a56

**デフォルトの名無しさん** · 2024/08/05(月) 05:37:35.60

>>34
読んでみたが色々とおかしい
まず1.5倍がベストな理由が書かれていない
次に2倍が悪い理由の説明と現実が合っていない

書かれている2倍が悪い理由を具体的な数字で書いてみると
例えばベクタの使用メモリサイズが育っていって1GBになっている時に
過去に使った半分の512MBの空きが抜け殻としてあり
さらにその前の分として半分の256MBの空きもありそれが過去に繰り返されていて
512MB + 256MB + 128MB + 64MB + ...
= 1GB未満のの再利用できていないメモリがあることになる
つまり再利用ができていないために合わせて約2GBのメモリを確保しているにも関わらず使っているのは半分の1GBなってしまう

という2倍が悪い理由が書かれている
しかしこれは現実と異なる
実際にベクタをゼロから地道にプッシュしていきそのサイズが1GBになった時
確保しているメモリサイズを調べると1GBである
再利用できていない昔の抜け殻が計1GB弱残るという話が現実と合っていない

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

mmap/munmapでOSにメモリを返却できるから古い抜け殻は残らない
さらにmremapで実コピーをせずに利用可能サイズを増やすことができる
それらを呼び出すコストがかかるためその頻度が1.x倍より少なくなる2倍が好ましい

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

話が難しいから何を言っているかじゃなくて誰が言ってるかでしか判断出来ねえ
そして5chをソースにfollyのreadmeを否定する意見を信じることも出来ねえ

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

話は聞かせてもらった
最適な比率は2でも1.5でもなく黄金比1.618だな
こういう問題は大体フィボナッチ数列が正解になる
僕は数学に詳しいんだ

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

>>37
わかる
もうちょいライトなユーザ向けのスレも欲しいかも

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

>>37
むしろ彼しか問題にしてないだろ
g++とclang++のvectorとrustcのVecは2倍にしていく
もし2倍が致命的なら大論争になり変更されるはずだ
現実には実用面も含めて問題となっていない

**デフォルトの名無しさん** · 2024/08/05(月) 13:06:57.87

「致命的」に後退しちゃったねｗ

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

Linux などのメモリ管理戦略ではアロケータは空いてる番地を返すだけで
アクセスするまで実メモリの割り当てをしない。 (割り当てを遅延させる。)

vector を極端に伸ばしたり縮めたりするなら話は別だが、
徐々に伸びていって最後に捨てる一般的なユースケースなら
倍率はテキトーでも理論的な効率はそんなに差はない。

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

rustやc++では再割り当てが行われると参照が無効になるから2倍にして頻度を下げるのかも

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

https://github.com/rust-lang/rust/issues/29931
これだね
2015年から議論されてるけど、結局1.5倍がいいという結論には至ってないし
実際1.5倍を試してみた結果パフォーマンスが落ちてるから単純に1.5倍にするのはダメそう
もし1.X倍でパフォーマンス上がる方法があるならそのissueに報告すれば採用されるかもよ

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

>>44
rustcがベンチマークのネタに適してないんじゃないの？

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

>>45
そう思うならrustc以外のアプリでベンチ取って提示してみれば？
少なくともパフォーマンス低下するアプリが一つ示されたんだからそれ以上のデータ出さないと話進まないでしょ

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

もっと歴史の長いGCCのC++もClangのC++もvectorの再割り当ての長さ2倍を採用している
そしてGCを用いてメモリ管理する言語は各々で諸事情があるようだから参考にできない

**デフォルトの名無しさん** · 2024/08/05(月) 16:04:04.60

fbvectorの話はアロケータが確保する単位に合わせて無駄を無くすということと
Vecのリサイズによって開放されたメモリ領域を再利用しやすくするということが書いてるだけ

どっちも理にかなってる

**デフォルトの名無しさん** · 2024/08/05(月) 16:26:39.60

標準として提供する機能には平均的な性能が高いよりも
最悪の場合でもそれなりの性能が出るほうを優先するみたいな考え方もあるし
設計思想にもよるわな。

**デフォルトの名無しさん** · 2024/08/05(月) 18:42:38.74

https://medium.com/smucs/fbvector-a-possible-replacement-for-std-vector-e46bb31b8a56
C++の結果だけど結構な差が出てる
この人のコードを自分の環境でも試してみたがpush_backで5倍前後違う

単純に1.5倍固定じゃなくて真似したやつで試してみたらいいのにね

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

>>50
ソース見てみたけど恣意的に10倍ずつ異なる長さで順にアロケーションを汚染していき
vectorは単発使い捨てで毎回残らないからその前の残骸の空きエリアにたまたま上手くマッチするかの勝負になっていて
現実とはかけ離れたテストになっていると思った

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

>>49
速度vsメモリ効率なんかもあるしね

**デフォルトの名無しさん** · 2024/08/05(月) 23:56:18.02

>>50
こんなに違いが出るのか

**デフォルトの名無しさん** · 2024/08/06(火) 00:27:44.41

>>44を読んでると
1.5倍にすると実用なプログラムでは遅くなるのに対し
>>50の特殊なベンチな時だけ1.5倍がとても速い理由は
他のメモリ割り当てに邪魔されずに1つのベクタだけがどんどん成長していくからで
1+1.5+1.5^2+1.5^3 ＜ 1.5^4 であるため
自分が過去に用いたところを結合してそのまま使えるため速いらしい
しかし現実のプログラムは他のヒープ利用も間に起きるためその再利用はうまく行かずメリットが起こらないと

**デフォルトの名無しさん** · 2024/08/06(火) 10:36:53.30

2.71828倍が良いとおもいますん

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

1.14514倍で

**デフォルトの名無しさん** · 2024/08/06(火) 17:53:14.98

C++が1.5倍伸長のFBVectorで自分の抜け殻を上手く再利用する件
Rustはなぜ2倍伸長でもっと速いのかを調べてみた

同じように他に邪魔されず伸長していくケースだと
RustのVecは以下のように
128Kバイトまでは同じアドレスのまま移動せずにコピー無しで2倍伸長していく
256Kバイト以上ではmremap利用でアドレスは移動するがコピー無しで2倍伸長していく
そのためRustのVecは2倍伸長でもサイズが巨大になっても速いことがわかった

addr=0x5642549e6ab0 cap=8 len=1+1
addr=0x5642549e6ab0 cap=8 len=2+1
addr=0x5642549e6ab0 cap=8 len=4+1
addr=0x5642549e6ab0 cap=16 len=8+1
addr=0x5642549e6ab0 cap=32 len=16+1
(途中略) 【アドレスはずっと変わらない】
addr=0x5642549e6ab0 cap=32K len=16K+1
addr=0x5642549e6ab0 cap=64K len=32K+1
addr=0x5642549e6ab0 cap=128K len=64K+1
【ここでアドレスが変化＆mremap利用が始まる】
addr=0x7f661c06f010 cap=256K len=128K+1
addr=0x7f661bfee010 cap=512K len=256K+1
addr=0x7f661beed010 cap=1M len=512K+1
addr=0x7f661bcec010 cap=2M len=1M+1
(以降略)

**デフォルトの名無しさん** · 2024/08/06(火) 18:25:14.08

もちろんVecは2倍伸長をアロケータにリクエストするだけなので
実際に処理しているのはRust標準のGlobalアロケータ
この環境では出来たバイナリにglibcのmallocやreallocがリンクされてるので最終的にはそこに行き着くはず

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

Carbon Languageに期待

**デフォルトの名無しさん** · 2024/08/06(火) 20:16:16.47

Rustの標準アロケータを使わずに
>>57をjemalloc利用でアドレス変化を調べると全く異なる結果となった

8Kバイトまではアドレスが毎回変わりコピー移動
16Kバイトから1Mバイトまではアドレスが変わらずコピー無し
2Mバイト以上はアドレスが毎回変わりmremapが使われてないためコピー移動

少なくとも今回の前提での利用の範囲内ならば
Rust標準をそのまま用いるのが最適となる

**デフォルトの名無しさん** · 2024/08/06(火) 20:54:39.49

そういや一昔前、jemallocを採用してるから
Rustは良いんだよ、って主張があったよね

**デフォルトの名無しさん** · 2024/08/06(火) 21:01:13.77

jemallocは色々と問題もあるため5年半前の2019年1月のRust1.32で標準採用しなくなった
もちろんjemallocが好ましいケースもあるのでその時は各自で簡単に使えるようにもなってる

**デフォルトの名無しさん** · 2024/08/07(水) 00:45:04.42

未だに Vec::new_in() が安定化しないRustとは対照的に
Zigはヒープ使う関数すべてで毎回毎回アロケータを引数に渡させて
毎回毎回成功したか確認させるんだね

Linuxカーネル開発にはZigの方が向いてるんじゃなかろうか？

**デフォルトの名無しさん** · 2024/08/07(水) 01:13:06.44

{C++ std::vector, C++ fbvector, Rust std::Vec} × {jemalloc, glibc malloc, LLVM libc malloc, msvc malloc, musl libc malloc} × {Linux, macOS, Windows} × {x86_64, 仮想メモリの機能を持たない何らかのアーキテクチャ}

壮大な議論になってきたなあ
これ全部検証するつもり？

そういやglibc mallocは環境変数でヒープとmmapのどっちを使うかの閾値調整できるとか
msvc mallocは_DEBUGマクロが定義されていると確保したメモリに未初期化を表すバイトを書き込むとかもあった

条件はいくらでも付け加えられそうやね

**デフォルトの名無しさん** · 2024/08/07(水) 01:28:00.75

サイズの大きなベクタは
キャパシティ拡張してもコピーが発生しないmremap利用のアロケータが有利という結論だな
サーバなどで一般的に使われるLinux環境ならRust標準でその条件を満たすから大丈夫

**デフォルトの名無しさん** · 2024/08/07(水) 08:32:07.19

>>63
Zigはまぁ1.0にならないと検討の俎上にもあげられないし
Cと比べてそれほど強い保証が得られるわけでもないから
あまり導入するモチベーションもなさそう

**デフォルトの名無しさん** · 2024/08/07(水) 22:36:11.64

https://www.publickey1.jp/blog/24/rustservowebverso.html
2024年8月6日
欧州を基盤にオープンでセキュアなインターネットの実現を支援しているNLnet Foundationは、
昨年(2023年)末から、Linux Foundation傘下でRust製のクロスプラットフォーム対応Webブラウザエンジンとして開発が進められている「Servo」を用いたWebブラウザ「Verso」の開発プロジェクトの立ち上げを発表した。
また、この「Servo」をTauriの組み込みのWebViewとする方向で開発が始まっている。
Chromiumに代わるRust製

**デフォルトの名無しさん** · 2024/08/07(水) 22:38:49.83

>>67
名前がダサすぎるからダメ

**デフォルトの名無しさん** · 2024/08/08(木) 05:28:31.41

ChromiumがC++のメモリ管理ミスで度々セキュリティ脆弱性を招いてるから
対抗馬ができるのは良いこと

**デフォルトの名無しさん** · 2024/08/08(木) 06:03:12.33

まともに動くまで20年ぐらい掛かるんだろ

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

Firefox先生の明日はどっちだ

**デフォルトの名無しさん** · 2024/08/09(金) 06:14:59.59

Tauri2.0 Android/iOSでマルチwebviewしたかった
この流れだとVersoになるまで出来なさそう

**デフォルトの名無しさん** · 2024/08/09(金) 10:26:33.54

タウリン実際どうなん？
実用になる？

**デフォルトの名無しさん** · 2024/08/09(金) 10:41:11.99

>>73
有用だけど場合による。

**デフォルトの名無しさん** · 2024/08/09(金) 17:08:58.86

implementation of `From` is not general enough
= note: `From<&'0 Hoge>` would have to be implemented for the type `Fuga<'_>`,
for any lifetime `'0`...
= note: ...but `From<&'1 Hoge>` is actually implemented for the type `Fuga<'1>`,
for some specific lifetime `'1`

これはどうやって解決するのが普通？

**デフォルトの名無しさん** · 2024/08/09(金) 17:13:42.47

こういう実装は書いてあります
impl<'a> From<&'a Hoge> for Fuga<'a> {
fn from(src: &'a Hoge) -> Fuga<'_> {
Fuga::from(なんかの変換(src))
}
}

**デフォルトの名無しさん** · 2024/08/09(金) 17:18:10.35

fn moge<T>(a: &str, b: &str) -> i64 where T: for<'a> From<&'a Hoge> {
中身
let m = T::from(hoge);
中身
}

みたいな関数を呼んだ(コンパイル時)ときに >>75 のエラーで止まります

**デフォルトの名無しさん** · 2024/08/09(金) 17:22:16.81

呼ぶ方は
let x = moge::<Fuga>(2, 5);
みたいに呼びたいのです

**デフォルトの名無しさん** · 2024/08/09(金) 17:22:41.31

fn mame(a: &str, b: &str) -> i64 {
中身
let m = Fuga::from(hoge);
中身
}
としたときは正常にコンパイルも動作もできました

**デフォルトの名無しさん** · 2024/08/09(金) 18:10:20.58

>>77
全体が見えないのでなんとも言えないが
>>75のエラーを解決するなら
例えば
fn moge<T>(a: &str, b: &str) -> i64 where T: for<'a> From<&'a Hoge>
↓
fn moge<'a, T: 'a>(a: &str, b: &str) -> i64 where T: From<&'a Hoge>

**デフォルトの名無しさん** · 2024/08/09(金) 19:57:46.44

`src` does not live long enough
--- argument requires that `src` is borrowed for `'a`
borrowed value does not live long enough
`src` dropped here while still borrowed

**デフォルトの名無しさん** · 2024/08/09(金) 21:05:31.98

playgroundに再現する最小限のコードを貼れよ

**デフォルトの名無しさん** · 2024/08/09(金) 21:17:17.11

タウリンで作られたなんか実用的なアプリある？

**デフォルトの名無しさん** · 2024/08/09(金) 23:57:36.49

>>83
https://github.com/tauri-apps/awesome-tauri

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

>>84
なんか中国人が多いな

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

先月の航空業界や病院に政府機関など850万台のWindows端末が影響を受けた世界的な大規模システム障害について、
CrowdStrikeが根本原因分析のレポートを発表しました。

「コンテンツインタープリターは20個の値しか想定していませんでした。
したがって、21番目の値にコンテンツインタープリターがアクセスしようとすると、入力データ配列の末尾を超えて領域外のメモリが読み取られ、
その結果システムがクラッシュしました」と報告しています。

記事
https://gigazine.net/news/20240809-crowdstrike-root-cause-analysis/

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

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

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

next()で戻り値のlifetimeを不必要に小さくしているのが、単独で見て「普通に考えるとおかしい」と言えるように
>>182の構造体の例も、「普通は」struct Foo<'a, 'b>(&'a str, &'b str);のように分けるべきだろう
例外は実際に.0も.1も同じStringの部分列であることを想定しているような、同じlifetimeを持つ参照から作ることが想定されている場合か、他にもあるかもしれんが

あと例の「Rustのライフタイムについてのよくある誤解」にもある通り、こういう具体的なメンバを想定したlifeitme in pathには'inputとか'bufとか説明的な名前を付けるべきである
そうすれば「あれ、よく考えたらこの.0と.1って同じlifetimeで本当にいいのか」ってことを、利用側でコンパイルエラーになるのを待たず考慮できるとは思わんのかね
'aみたいなテキトウな名前のlifetimeが許されるのは汎用的なコンテナくらいだろう、Iter<'a, T>とかRef<'a, T>とかCow<'a, T>とか

そういう嗅覚というか、経験知みたいな情報は誰も持ち合わせちゃいないのかね

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

複オジに何を言ったところで時間の無駄
そろそろ気付いてね

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

同じところで生まれるものしか取り扱わない場合にFoo<'a, 'b, 'c, 'd, 'e>とする必要はない
そこをFoo<'a>でコンパイルが通る使い方をしているならばFoo<'a>で正しい
どちらかが間違っているという変な考えを捨てよう

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

>>188
反論を通じて考えを整理しているという面もあるので
マサカリ歓迎

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

>>175
読んだ
大雑把な要約

Rustは非常に素晴らしく成功しているがまだ改善できる点がある
一方で既存の言語には問題があり
他の新言語は社会的賛同が低い
そのため唯一の解決方法はRustをさらに改善に導くことである
そこで具体的な改善案を示す

**デフォルトの名無しさん** · 2024/08/14(水) 00:30:36.57

>>187
> >>182の構造体の例も、「普通は」struct Foo<'a, 'b>(&'a str, &'b str);のように分けるべきだろう
> 例外は実際に.0も.1も同じStringの部分列であることを想定しているような、同じlifetimeを持つ参照から作ることが想定されている場合か、他にもあるかもしれんが
これについていえば、必要なのは「構造体は自身よりも寿命の短いデータへの参照を持たない」ことなので、基本的には Foo<'a> だけで済むと思う

fn func() {
　let a: String = "foo".to_owned();
　{
　　let b: String = "bar".to_owned();
　　{
　　　let c = Foo{&a, &b};
　　}
　}
}

これはaとbは違う寿命を持つけど、Fooとしては「c が生きているうちに a と b の寿命が尽きない」ことが保証されてれば良いだけなので、aとbの寿命の区別までは必要まではない
だからメンバーは Foo<'a> の寿命である &'a だけで済むという感じ
自分の認識違いだったらすまん

**デフォルトの名無しさん** · 2024/08/14(水) 00:42:39.43

働け

**デフォルトの名無しさん** · 2024/08/14(水) 01:41:38.41

>>153
ライブラリが乱立してる点

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

>>194
まずasync/awaitはRustの標準機能
そして使われるFutureやPollやWakerなど各種はRustのcore標準ライブラリにありno_stdでも使える
asyncランタイムは用途ごとに適したものを自由に作ったり選んだり使える
標準的に使われるものはtokioがダウンロード10倍差で圧勝しており乱立と悩まなくていい

**デフォルトの名無しさん** · 2024/08/14(水) 06:30:03.80

>>164
ライフタイム注釈が間違っているのにコンパイルが通ってしまい正しく動作しない、というプログラム例を一つでも示せばよいのではないか？
そんな例は存在しないと思う
コンパイルが通ったらそのプログラムでライフタイム注釈は間違っていなくて正しく動作するよ

**デフォルトの名無しさん** · 2024/08/14(水) 09:24:59.76

挙げた手降ろせない子どもすごい増えたよな
折り合いつける知能もない

**デフォルトの名無しさん** · 2024/08/14(水) 09:32:09.98

>>183
>trait実装の場合にはtraitの宣言に合わせるために実際より小さいlifetimeを指定しないといけない場合があるしれないが

kwsk
そっちの方が知りたい

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

Tokioが圧勝しているせいでtokio でしか使えないライブラリが出てきていて、tokioが終わったらRustのasyncもオワる状況

**デフォルトの名無しさん** · 2024/08/14(水) 10:09:25.77

tokio以外を考慮してるライブラリの方が少数派だろ