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/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以外を考慮してるライブラリの方が少数派だろ

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

>>199
GAFMなどIT大手がtokio直接支持してるから不滅だよん

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

>>201
GAFMは飽きっぽいから、支援されてるから不滅ってことはない
あ、Rustの寿命がそれより先に来るってことかな？

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

Rustに代わりうるプログラミング言語の芽すらないよん
IT大手各社が結束して同じ新言語を支持したのはRustが最初で最後かな～

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

>>203
zig 1.0待ちだろ

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

Rustより保証してくれることが減ってしまう言語は代わりにならないよん

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

良いか悪いかよりも一貫しているかどうかが寿命を決める。
(いや、及第点程度には良いものである必要はあると思うけど。)
C がよい言語とはとても言えないけど皆が一貫して使ってたから価値あるものとして認められてたわけで。
プログラミング言語も言語だからね。

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

>>192
lifetimeって究極的には関数の引数と戻り値の間でのリソースの依存関係を示すものだから
FooのメソッドもFooを引数に取る関数も無いなら、どっちでもいいよとしかならんと思う
そして実際にメソッドや関数を定義するときになったら、別々になっていたほうが一番柔軟に指定できるから、第一選択としては分けておいたほうがいい、というのが俺の直感

>>196
「コンパイルが通ってしまい正しく動作しない、というプログラム」が作れてしまうことを問題にしているのではない
「コンパイルは通って正しく動作もするが、制約が強すぎるために使える状況が過剰に限定される関数」が作れてしまうということを問題にしている
だから前者の例を出すことに意味は無いし、あなたもよく知っている通りそれは実際できないだろう
そして「Rustのライフタイムに関するよくある誤解」5)のnext()は後者の問題を示す例になっている

>>196
trait Iteratorではそうなっていないけど、例のnext()が別のtraitのメソッドfn next<'a>(&'a self) -> Option<&'a u8>として宣言されていれば、実装側はそれに従わざるを得ない、と思ったけど
現実にそんなことが要求されることがあるか、と聞かれるとちょっと微妙かも

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

zigは本当に最強

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

>>174
>> next()を1回呼ぼうが2回呼ぼうが、

Rustではその1回目のnext()の値を保持したまま2回目を使えるかどうかの違いが大きいんだよ

最初の仕様は各々の値が使えれることが確認できればいい仕様になっているね
assert_eq!(Some(&b'1'), bytes.next());
assert_eq!(None, bytes.next());

その次の仕様は1回目の値を持ったまま2回目の値を使える仕様になっているね
let byte_1 = bytes.next();
let byte_2 = bytes.next();
if byte_1 == byte_2 {
// 何かしらの処理
}

つまり拡大された別の仕様となっているわけだよ
そのため最初の仕様ではライフタイムがselfと同じでも全く問題ないけど
次の仕様ではselfと異なるものでないといけなくなる
そこが本質があってどちらの仕様も別のものとして存在しているわけよ

わかりやすく例を挙げて説明すると
次のように&[T]ではなくVec<T>を保持するバージョンに変えてみよう

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

>>209の続き
相違点以外は元コードと同じ名前と形で書いています

struct ByteIter {
vec: Vec<u8>,
index: usize,
}

impl ByteIter {
fn next(&mut self) -> Option<&u8> {
if self.index >= self.vec.len() {
None
} else {
let byte = &self.vec[self.index];
self.index += 1;
Some(byte)
}
}
}

参照を持たなくなったので一見すると有利になっているように見えるけど
最初の仕様しか満たせなくなってる！
ところがこれはGATを用いたLending Iteratorでは当たり前の仕様なんだよ
つまり制限された間違った仕様というよりは別の仕様と捉えることもできるんじゃないかな

**デフォルトの名無しさん** · 2024/08/14(水) 19:39:11.70

>>209-210
「ByteIterはバイトのスライスを繰り返すイテレータです」
「今こうして前のプログラムを見返してみると、明らかに間違っていましたね」

とかの日本語で説明した文章をすべて無視して、コンパイルの通ったRustコードだけを正しいものとして「プログラマの意図」を見出そうとすると、そうなるんだね
どう考えるとそういう結論に至るのかはよく分かった

**デフォルトの名無しさん** · 2024/08/14(水) 19:54:05.99

>>211
最初のプログラムのどこが間違っていると主張していますか？
assertも通って機能していますよ

**デフォルトの名無しさん** · 2024/08/14(水) 20:38:24.97

日本語を読めば分かるよ
新ネタ無さそうならもう終わりにしとくね

lending iteratorって発想は無かったから、そこだけは面白かったかもね

**デフォルトの名無しさん** · 2024/08/14(水) 20:56:34.44

>>213
最初のプログラムでイテレータの仕様を満たしており正しく動作していま
すよ
コードに問題はありません

その後に行われようとしているのはイテレータの仕様とは別の
以下を通す新たな仕様を満たすための拡張です

| let byte_1 = bytes.next();
| 　　　　　 ----- first mutable borrow occurs here
| let byte_2 = bytes.next();
| 　　　　　 ^^^^^ second mutable borrow occurs here
| if byte_1 == byte_2 {
| 　 ------ first borrow later used here

両者を区別できていますか？

**デフォルトの名無しさん** · 2024/08/14(水) 23:52:37.44

最初のプログラムは関連型のItemを定義できないからIteratorの仕様を満たせないだろ
type Item = &'a u8;
だと拡張（というか修正）した方のコードになる
「正しい」の意味が噛み合ってないことに気付こう

**デフォルトの名無しさん** · 2024/08/14(水) 23:59:55.13

結局>>157の記事は破綻してるんだな
イテレータをstd::iter::Iteratorだけを指す狭い意味に取ると
その記事の最初の&u8をItemにした時点でコンパイルエラーとなるから記事は破綻
イテレータを広い意味にとってその記事の方法でもOKとすると
最初の実装でイテレータとしての機能は満たしていて
それを&'a u8にする必要はなくなり記事は破綻

**デフォルトの名無しさん** · 2024/08/15(木) 00:04:11.15

「コンパイルが通ったならばライフタイムの記述は正しい」で常に合ってるのに、
それがいかにも間違ってるかのように仕立て装うから矛盾が出てる感じ。

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

Rustは良い言語だと思うけど
清書用だね

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

他の言語よりバージョン管理（git）の技術が問われる気がする
全体の整合性が求められるから個人開発でもまじめにブランチ使わないとしんどい

**デフォルトの名無しさん** · 2024/08/15(木) 14:43:48.85

>>219
整合性が求められるのはどの言語でも同じ
どの言語でもgitを使うかどうかブランチを切るかどうかの方針や判断は同じようになされて言語とは関係ない