Rust part26

**デフォルトの名無しさん** · 2024/09/20(金) 22:18:38.38

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

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

**デフォルトの名無しさん** · 2024/11/09(土) 23:06:21.72

ロックして解放してロック解除しなければいい

**デフォルトの名無しさん** · 2024/11/09(土) 23:11:14.97

>>701
基本的な知識を身に着けろよ
正規表現を内部コードにコンパイルして持つ役目がRegex構造体
可変長になるのでVecで持っていて当然ヒープは必須

**デフォルトの名無しさん** · 2024/11/10(日) 00:07:10.13

>>703
それは現状の内部実装上の都合の話
本質的にヒープが必須という話ではない
文字列リテラルにヒープが必須でないのと同じとでも言えばわかるかな？

**デフォルトの名無しさん** · 2024/11/10(日) 02:33:30.98

は～～～～キレそう

**デフォルトの名無しさん** · 2024/11/10(日) 02:34:34.55

なんの意味があんねや、このスレ

**デフォルトの名無しさん** · 2024/11/10(日) 02:36:54.54

Rustプログラマにとって有益な情報はこれ以上出ないし、まともなRustプログラマは全員逃げたことが確定して久しいので
次スレあたりから「Rust vs 世界中の全言語 Part27」とか「複製おじさんと遊ぼう Part27」とかにしましょっか
他にもスレタイ案募集

**デフォルトの名無しさん** · 2024/11/10(日) 06:48:35.70

>>704
おまえバカだろ
正規表現パターンは実行時に確定してコンパイルサイズも実行時に確定し上限サイズはわからない
ヒープは必須だ

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

入力がコンパイル時に確定してるならサイズも確定するでしょ
理屈としては以下のようなものは作れると思う

struct CompTimeRegex<const N: usize> {
　data: [u8; N]
}

// 正規表現オブジェクトをコンパイル時に計算
// サイズは入力に応じて変わる
// 入力はリテラルのみ
let r = make_regex!("+\\d");

面倒だし、それでパフォーマンスが劇的に良くなるわけでも無いだろうから必要性は微妙なところ
詳しくないけど、手続きマクロの中なら計算のためにヒープを使うこともできるよね？

**デフォルトの名無しさん** · 2024/11/10(日) 11:58:38.78

BurntSushiのベンチ結果見た？

**デフォルトの名無しさん** · 2024/11/10(日) 12:03:57.56

それは入力固定で出力の型も別仕様の別の話だな
regex::Regexは実行時に正規表現が作られてもよく
それをコンパイルするためヒープが
使われている

**デフォルトの名無しさん** · 2024/11/10(日) 12:23:01.33

正規表現をコンパイルするのと比べてヌル代入を許容するのは極めて容易で
ヌルを代入すればヒープが解放される

**デフォルトの名無しさん** · 2024/11/10(日) 12:27:06.24

const文脈って、実際今なんか有効な活用されてるの？

**デフォルトの名無しさん** · 2024/11/10(日) 12:30:28.79

ちなみにzigの似た機能は有効活用されまくり

**デフォルトの名無しさん** · 2024/11/10(日) 12:38:27.50

ぐちゃぐちゃできるとかできない言ってるが自分で実装する気のある人間は一人もいねえんだろ？？？
だったら終わりだよ

**デフォルトの名無しさん** · 2024/11/10(日) 13:02:04.64

>>711
だから>>709はCompTimeRegexという従来のRegexではない型を作って話を展開してるわけ
ちゃんと読めてる？

**デフォルトの名無しさん** · 2024/11/10(日) 13:06:11.38

意図的な誤読、ストローマン論法、誰もがわかりきった説明を脈絡無く貼って議論を拡散させる
マジで不毛

**デフォルトの名無しさん** · 2024/11/10(日) 13:11:04.55

結局さ
ヒープは全部開放しなさい派閥は>>661のコードでRegex内部のArcが未解放のままプロセス終了するのは、ええんか？？ええんか？？どうなんだオラ？？って話ってことでええんよな

**デフォルトの名無しさん** · 2024/11/10(日) 13:16:48.60

>>716
全く別の話であり、これまでのregex::Regexについての話への言及・反論にはなっていないことを自覚できているならそれでよろしい

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

>>718
Rustの標準ライブラリstdは
プログラム終了時に自動的にメモリが解放されるようなまともなOS環境を対象にしていて区別しているので大丈夫
OS無しの組み込み環境では#![no_std]を宣言してcoreライブラリのみサポートされる中でのプログラミングを行なう

**デフォルトの名無しさん** · 2024/11/10(日) 14:48:06.15

>>707
みんな何処に逃げた？

**デフォルトの名無しさん** · 2024/11/10(日) 15:04:06.89

>>661
スコープを外れた場合と同じようにモジュールがアンロードされる際にデストラクトされる

**デフォルトの名無しさん** · 2024/11/10(日) 16:19:33.44

>>720
OS側でプロセスを終了させる際にメモリマップを捨てる処理のことを「解放」って呼んでるから君と君以外で話がすれ違うんだと思うよ

**デフォルトの名無しさん** · 2024/11/10(日) 16:24:01.76

あと、ええんかオラ？ってのは俺の直接の質問ではない、それに答えられてもへえそうですか
元の議題は>>661、さらに遡れば>>593であって、議題内容はそれでよいか？という確認をしているだけだ

**デフォルトの名無しさん** · 2024/11/10(日) 16:26:17.63

>>721
非匿名でまともな交流ができるコミュニティかもね
rust-jpのzulipとか、あるいは英語を頑張って公式コミュニティとかに行ったか、発言しなくてもROM専してるかも

**デフォルトの名無しさん** · 2024/11/10(日) 16:30:14.58

5chで聞くよりもChatGPTの方が適切な回答をくれると思う
Rustに限らず他の言語でも

**デフォルトの名無しさん** · 2024/11/10(日) 16:34:57.50

ChatGPTもついでにCopilot Chatもゴミだよ
省略されたライフタイムの展開が自分でやったのが合ってるか自信がなくて、試しにやらせてみたらメチャクチャなことばっか言いやがった挙げ句、キレてthe Refrenceのelision rulesのところをペタペタ3回くらいコピペしたらすみません間違っていました、何度も申し訳ございません言いながらやっと正解を返してくれた
決定論的な問題を解かせるのにはまったく向いてない

**デフォルトの名無しさん** · 2024/11/10(日) 16:36:43.08

>>727
最初からキレて始めればいいのでは？

**デフォルトの名無しさん** · 2024/11/10(日) 16:39:08.93

英語が話せる人はこっちに移住しよう！！！できない人もDeepL片手にカモン！！！
https://www.rust-lang.org/community

日本語コミュはこちら！！！ってかいい加減放置されきった翻訳版の責任者のケツ叩きに行こうぜ！！！
https://rust-lang-jp.zulipchat.com/

**デフォルトの名無しさん** · 2024/11/10(日) 16:41:30.83

>>728
キレるはともかく最初からelision rules貼ればよかった説は確かにそう、残念ながら二回目の機会がないが次はそうしてみるぜ
でもよお……こんなのrust-analyzerが完璧なinlay hint実装してくれりゃやらなくて済む話でもあるんだぜ

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

およ？ ID変わった
ID:OGC8ujy2=ID:tFJCBt9mです

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

>>722
staticはdrop呼ばれない

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

C++ で static オブジェクトの初期化順 (解体順) は問題を起こしがちだし、いっそそのへんは取り扱わないというのも妥当な判断のひとつではあるわな。

**デフォルトの名無しさん** · 2024/11/10(日) 17:43:15.44

自動化をあきらめることは賛成
だが手動で解放する技術を不要な技術と見なすことには反対する

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

StringやVecみたいなヒープを使う型をstaticで管理させた場合って、valgrindみたいなメモリリーク検出ツールに引っかかったりする？
dropが呼ばれなくても終了時に一応はメモリ解放してるのか、それとも本当に何もしていないのか

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

>>733
Rustならstatic変数初期化はOnceLockやLazyLockでマルチスレッド競合を含めて安全に初期化できる
static変数でdropはプログラムの終了時も起きないがメモリ解放問題は普通のOS環境では関係ないため問題ない
どうしてもdropしたいなら例えばOptionで包んでtake()で取り出すなどで手動drop()が可能

>>735
手動dropしないならばヒープ領域を持っていても解放されない
これはBox::leak()などで意図的にメモリを解放しないようにした場合でも同様
普通のOS環境ならこれでも問題は全く起きないが
組み込み環境などで確実にメモリ解放したいならば用意するメモリアロケータで対応する
つまりプログラム終了時にメモリアロケータを呼び出して管理している全メモリを解放させればよい

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

質問の答えになってないし、組み込み環境で「プログラムが終了」したり、「管理している全メモリを解放」できるアロケータが必要などとまで言い出した

いやはや

**デフォルトの名無しさん** · 2024/11/10(日) 20:16:38.46

>>735
>>661に適当にこれだけのmain足してvalgrindかけてみた

fn main() {
let s = "2021/07/04";
let (year, month, day) = yyyymmdd(s).unwrap();
println!("{}-{}-{}", year, month, day);
}

https://pastebin.com/UN84vEFb

まあ、リーク扱いで出るよね
こういうのがあんまり多いとマジのリークと区別付きづらくて大変そうだけど、なんかアノテーションみたいなので対策できたりするのかな？

**デフォルトの名無しさん** · 2024/11/10(日) 20:28:05.31

>>738
サンクス
過去にC++で似たようなケースで顧客から「あなたの所のライブラリを使うとメモリリークが検出されるんだけど？」って指摘されたことがあって気になった
説明して伝わる相手なら良いけど、そういう面倒な人からのクレームを避けたい場合はstaticは避けたほうが良さそうだな
本質的には重要な問題でないと思うけども

**デフォルトの名無しさん** · 2024/11/10(日) 20:28:35.21

>>737
組み込み環境であろうとなかろうと各プログラムは終了する
さらにOS環境でOS内であっても各カーネルモジュールのプログラムはアンロードで終了する
一方でもし完全にモノリシックな一つのシステムなら終了後をそもそも考える必要がない

メモリアロケータについては自作したことあるなら管理してるメモリの全解放なんて楽勝だと理解できるだろ
割り当て用に確保しているバッファを返却するだけだ

**デフォルトの名無しさん** · 2024/11/10(日) 20:52:25.18

お前ら、Rustでプログラム書いた後にvalgrind ってるの？
もうそういうの終わりにしたいからRust使ってるんじゃないの？

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

相変らず単語ひとつひとつが独自用法すぎて解読が困難だね

mallocみたいなグローバルアロケータを自分で実装しようという話をしているのか？
それとも（allocator_apiがいまだにunstableなせいでボイラープレートモリモリ書かされる）typed_arenaやbumpaloのようなカスタムアロケータの話をしているのか？

前者だとしたらバッファという言葉が出てくるのがまず分からない、もしかしてヒープ領域全体のことをバッファと呼んでいて、確保/解放はsbrkのことを言っているのか？
後者だと「管理してるメモリの全解放」ですべての内容のDropしないといけなくて……って考えるとどう考えてもゲロクソむずいけど、全オブジェクトをManuallyDropに包んで返して責任放棄するのかな……

**デフォルトの名無しさん** · 2024/11/10(日) 20:56:00.86

>>741
できねーもんはできねーんだから適切な道具を使うんだよ、笑うならそこの嘘吐き宣教師を笑うんだな

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

>>742
プログラム本体終了後のメモリ解放のためにdropは必要ない
プログラム全体終了後のメモリリークが組み込みなどで困るケースが対象なのだからそれらメモリを返却するだけでよい

sbrkのあるOS環境ならsbrkでOSへ全メモリを返還できるのはその通りだが
それをしなくてもプログラム終了後にメモリリークは起きないので普通のアロケータでは行われていない
メモリリークが起きうる特殊なOSや組み込みならアロケータが借りてるメモリを全返却すればよい

**デフォルトの名無しさん** · 2024/11/10(日) 21:16:26.31

>>744
んでどっちのアロケータの話をしてるの？って

**デフォルトの名無しさん** · 2024/11/10(日) 21:22:25.58

>>745
普通の仮想メモリOS環境ならstaticでもBox::leakでもプログラム終了後にメモリリークは起きないから対策の必要がない
そうでない特殊なOSや組み込み環境ならばそれ用に用意するメモリアロケータをプログラム終了直前に呼び出して全メモリ返却させればメモリリークは起きない

**デフォルトの名無しさん** · 2024/11/10(日) 21:35:16.61

>>746
グローバルアロケータの話をしてんのか、カスタムアロケータの話をしてんのか、って聞いてんだよ

自分の頭の中の理屈をダンプするんじゃなく、言葉の定義をすり合わせる努力をしろ

**デフォルトの名無しさん** · 2024/11/10(日) 21:41:49.64

少なくともvalgrindとかperfmonみたいなやつは、プログラム終了時にヒープを辿って解放済みマークの無い場所を見つけたらリークって報告するんだし、一般的にはそれがリークだよ
プロセス終了時にメモリマップの割り当てが解除されるとか、どうでもええわ

**デフォルトの名無しさん** · 2024/11/10(日) 21:48:10.22

>>747
Rustでは#[global_allocator]指定でカスタムなグローバルアロケータを使える
プログラム終了後にメモリリークが起きうる組み込み環境なら対応した自作のアロケータを実装してそのように指定して用いる

**デフォルトの名無しさん** · 2024/11/10(日) 22:10:00.14

>>729
May I talk about the ownership reproduction in the formal community web page?

**デフォルトの名無しさん** · 2024/11/10(日) 22:15:02.72

> プログラム終了後にメモリリークが起きうる組み込み環境
組み込みやったことないから知らんけど、そんな環境があんの？

**デフォルトの名無しさん** · 2024/11/10(日) 22:27:44.25

https://github.com/rust-embedded/embedded-alloc

組み込みの典型的なコードってこのREADMEのサンプルコードみたいなんでいいのかね
プログラム(main)は終了しない
ヒープの「解放」処理も無い
合ってるよな？

自由に使える物理アドレス空間の一部を実行時アロケーションのために使用するってだけなら、使い終わりにやる「解放」の処理というのは何の話を言ってるんだ？って思ってたけど
そんなものはない、で合ってるのよな？

**デフォルトの名無しさん** · 2024/11/10(日) 22:31:44.37

>>750
search first

**デフォルトの名無しさん** · 2024/11/10(日) 22:33:46.00

>>751
そういう特殊な環境を出してるのは俺ではないからね
すべてを明示的に解放しなくても我々が普通に使っている仮想メモリ利用では問題ないよという話と
組み込みだとそんな仮定はできなくてメモリリークしていく可能性があるよという話の両方が出ているから
後者でも対応したメモリアロケータを用意すれば対応できるよと解決策を示した

**デフォルトの名無しさん** · 2024/11/10(日) 22:41:08.35

>>753
What do you mean? What I want to do is talking and having a discussion, not searching.

**デフォルトの名無しさん** · 2024/11/10(日) 22:48:01.15

>>754
> そういう特殊な環境を出してるのは俺ではないからね
あれ、そうだっけって思って辿ってみたら言い出してたの>>604だったわ
やっぱお前じゃねーか複おじ

プロセスにしろ組み込みのプログラムにしろ、OSだかシステムファームウェアだかの外部の管理者的存在が行儀の悪いやつのケツを拭いてくれてるだけのことを、
常識的のあるプログラマは「リークしていない」とは言わないんだよ

**デフォルトの名無しさん** · 2024/11/10(日) 23:04:28.91

プログラムの最後に行儀よくbrkやsbrkでOSへメモリを解放しているアロケーターを見たことないな
OSにとってはどうでもいいことだからそんな行儀よさは不要なのだろう
ましてやアロケーターの内部でフラグなどをオフにするだけのfree()はプログラムの最後にいらない
実行中に再利用できるようにするかどうかが本質だろうね

**デフォルトの名無しさん** · 2024/11/10(日) 23:16:52.46

えーではリークの定義に関して直接的反論はなしということで
以下はすべて誤りであったということでよろしいですね
対戦ありがとうございました

>>593「freeせずにプログラムが終了したり落ちたりしてもメモリリークは起きない」
>>604「freeを忘れてもあるいはfreeせぬまま異常終了となってもその仕組みによりメモリリークは起きない」
>>631「そしてfree()せずにプログラムが終了してもメモリリークは起きない」
>>744「sbrkのあるOS環境ならsbrkでOSへ全メモリを返還できるのはその通りだがそれをしなくてもプログラム終了後にメモリリークは起きない」
>>746「普通の仮想メモリOS環境ならstaticでもBox::leakでもプログラム終了後にメモリリークは起きない」
「そうでない特殊なOSや組み込み環境ならばそれ用に用意するメモリアロケータをプログラム終了直前に呼び出して全メモリ返却させればメモリリークは起きない」

**デフォルトの名無しさん** · 2024/11/10(日) 23:26:36.38

static mutは明らかにunsafeなわけだが
紙一重でunsafeとは言えないstatic変数のことを
警戒するかそれとも無駄な警備を極限まで捨てた合理主義の皇帝みたいに思うか
そういう対立はよくある

**デフォルトの名無しさん** · 2024/11/10(日) 23:33:02.28

プログラム終了後にメモリリークが起きるとすればOSが面倒をみてくれない環境だけだから
そういう環境では特殊な専用のメモリアロケータを用意するしかないだろうね
それならその自作のメモリアロケータをプログラム終了時に呼んで後始末させればメモリリークは防げる
Rustのstaticでヒープを持つ型を使っても最後まで使うメモリをBox::leak()で確保してもメモリリークは起こらないので安心していい

**デフォルトの名無しさん** · 2024/11/11(月) 00:17:42.59

Windows/Linux/macOSあたりなら
ファイルハンドルを閉じずにプログラム終了しても
OSが閉じてくれるから何の問題もない
的な主張？

**デフォルトの名無しさん** · 2024/11/11(月) 00:20:13.67

> プログラム終了後にメモリリークが起きるとすればOSが面倒をみてくれない環境
また実在しない環境の話し始めた

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

間違いを認めなくても勝手にすりゃいいけど、そんなんじゃ誰とも意思疎通できないままだぞ
いくら長文を書き連ねても一緒

**デフォルトの名無しさん** · 2024/11/11(月) 00:56:28.26

2種類ある

OSレベルのclose (例えばC言語でのシステムコールを呼ぶclose()) ならばOSが処理してくれるので異常終了含めてプログラム終了時にcloseしていなくても構わない
ただし各言語ライブラリのバッファリングなど他の機能を持つcloseはプログラム終了までに自分でcloseしないとその機能が完遂しない

一方でメモリ解放の場合
OSレベルのメモリ解放 (例えばbrk/sbrk) ならばOSがそのプログラムの仮想メモリ全体を無効にするのでプログラム終了時に解放していなくても構わない
メモリアロケーターライブラリのレベルのメモリ解放 (例えばfree()) もOSにとっては全く無関係な話なのでプログラム終了時に解放していなくても構わない

**デフォルトの名無しさん** · 2024/11/11(月) 01:04:17.69

組み込みは詳しくないんだが今ってOSを使わない
組み込みでRustとか使うの？
Rustのターゲットって多分何らかのOSありきだよね

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

>>765
語尾にオジを付けな

**デフォルトの名無しさん** · 2024/11/11(月) 01:10:52.04

マ板久々なので意味がわからないｗｗ

**デフォルトの名無しさん** · 2024/11/11(月) 01:11:20.28

webassemblyもなんか微妙な感じだしもったいない

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

>>767
そっか、じゃあ過去のRust本スレを4年分復習してきな
あとここはム板だボケジジイ

**デフォルトの名無しさん** · 2024/11/11(月) 01:16:21.72

すまんのうｗｗ

**デフォルトの名無しさん** · 2024/11/11(月) 01:27:50.38

>>765
OS無しにも対応している
Rustの標準ライブラリstd::はOS前提の機能も入っていてOS無しだと機能しないものもある
Rustの必須な言語機能はcore::ライブラリに部分に分離してまとめてあるので
ベアメタルな組み込みなどではstd::を使わない#![no-std]を指定してcore::を使う
core::では数値型や配列やスライスに文字列(str)およびその複合型が使えるがヒープは対象外なのでVecやStringは標準機能としては使えないといった違いがある

**デフォルトの名無しさん** · 2024/11/11(月) 01:31:24.31

>>768
Wasm自体ブラウザ内も外もどんどん利用が増えてる
もちろんRustで記述が定番化してる

**デフォルトの名無しさん** · 2024/11/11(月) 01:32:59.90

>>771
とこういった感じの書き込みをするRust信者が複おじ
このスレを読む上での必須知識だから覚えておくように

**デフォルトの名無しさん** · 2024/11/11(月) 07:39:38.28

>>732
これ本当？
そうだとするとstatic使った動的ライブラリをアンロードしたら本物のリークが起きる可能性があるが。

**デフォルトの名無しさん** · 2024/11/11(月) 09:19:55.92

>727
rustの質問するならclaude ai 3.5 sonetが圧倒的に優秀よ。

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

In the rust forum, we have to use English. How can I say “複おじ”? “Reproduction codger”?

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

>>727
ほんまにごみ
数学的な(結論出てる)質問しても平気で間違う

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

RustというかCargoの質問なんだけど
crates.ioにリリースしてるもので
一つのcrateでバージョンがいくつかあって
最新のバージョンだけ残して他全部yankedにしてるのに
閲覧回数レポート(crateトップページの下の方の折れ線グラフ)で
yankedされてるバージョンがいつまでもアクセスがあって増え続けて
最新の方がそっちの勢いほどには増えてない
どういう原因が考えられる？

**デフォルトの名無しさん** · 2024/11/11(月) 14:34:31.51

>>778
単純にyankされたバージョン使ってる（つまりCargo.lockにそのバージョンが載ってる）ユーザが多いってだけでは？
yankしたからといって既存のユーザが使用禁止になるわけではないので

**デフォルトの名無しさん** · 2024/11/11(月) 22:49:05.67

>>551
Rustはリファクタリングや機能拡張保守などに適した言語と言われている
強力な静的型付け、借用チェック、参照競合チェック、メモリ競合チェックなどによりコードが思わず壊れることを防ぐとともに
問題点を実行時エラーや実行時デバッグへと遅らせてしまうことを最も少なくしてくれる言語である
そのため全体の開発変更時間が他の言語より短く済んでいる

また、トレイトとトレイト境界による自然なジェネリック化がレイヤー分離独立と最小限の変更での機能追加を容易にしている
どうしてもトレイト設計をし直さなければならない大規模改修の場合でも、上述のように盤石に機能するコードとするまでが早い

**デフォルトの名無しさん** · 2024/11/11(月) 22:59:26.02

借用まわりで質問させてくれ

struct Foo {
　data: Option<Vec<u8>>
}

impl Foo {
　fn do_something(&mut self) -> &mut [u8] {
　　if let Some(x) = &mut self.data {
　　　return x;
　　}

　　// `self.data` is assigned to here but it was already borrowed
　　self.data = Some(vec![0u8; 10]);
　　self.data.as_mut().unwrap()
　}
}

これで self.data への代入の際に「既に借用されている」というエラーが出るんだけど、これって回避できない？
最初の借用が if let Some(x) = ... の箇所で行われていることは理解できるんだけど、
if let のスコープを抜けても借用された状態が続く (以降のコードでの借用ができない) のが腑に落ちない

**デフォルトの名無しさん** · 2024/11/11(月) 23:19:09.36

>>781
fn do_something(&mut self) -> &mut [u8] {
if self.data.is_none() {
self.data = Some(vec![0u8; 10]);
}
self.data.as_mut().unwrap()
}

**デフォルトの名無しさん** · 2024/11/11(月) 23:31:21.84

>>774
Static items do not call drop at the end of the program.
https://doc.rust-lang.org/reference/items/static-items.html

Drop types placed in statics WILL leak.
https://github.com/rust-lang/rfcs/pull/1440

**デフォルトの名無しさん** · 2024/11/11(月) 23:46:08.88

>>782
ありがと、これで回避できた
けど借用のルールはまだいまいち分かってない…

**デフォルトの名無しさん** · 2024/11/11(月) 23:52:53.38

staticはモジュールアンロードする可能性があるなら始末する時に手動dropできるように対処するしかないな
アンロードしないなら問題なし

**デフォルトの名無しさん** · 2024/11/12(火) 00:02:28.18

>>782
えーとOptionがnoneのとき値を入れたいという場合はもっと簡単に書けて

fn do_something()->&mut [u8] {
self.get_or_insert(vec![1,2,3])
}

という感じ。

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

>>781
&mut self.dataにも所有者がある
この匿名の所有者の寿命を'a
型を&'b mut T
とする
'bは'aより長いから'aがいくら短くても、借用された状態が続く

匿名をやめて名前をつければその名前でアクセスできる

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

なるほど、リークしちゃうんだ。

**デフォルトの名無しさん** · 2024/11/12(火) 00:50:59.75

get_mut OR (insert AND get_mut)を
1ステップにまとめるのは気持ち悪いな

1ステップにまとめていいなら
最初からデフォルト値を入れといてもいいのでは？

**デフォルトの名無しさん** · 2024/11/12(火) 02:10:28.31

>>787
さすが複オジ
ぶっ飛んでるな

**デフォルトの名無しさん** · 2024/11/12(火) 03:23:50.67

>>781
この辺のルールかなって思ったけど正直分からん
https://doc.rust-lang.org/reference/destructors.html

return x;をpanic!()に変えるとコンパイル通ってしまうのはどこかに明確な説明があるかね……

**デフォルトの名無しさん** · 2024/11/12(火) 03:24:11.27

>>781
drop scopeの決定時に制御フローは考慮されないってことなのかなって思ったけど正直分からなくなってきた
https://doc.rust-lang.org/reference/destructors.html

return x;をpanic!()に変えるとコンパイル通ってしまうのはどこかに明確な説明があるかね……

**デフォルトの名無しさん** · 2024/11/12(火) 07:26:38.88

>>789
複おじの発想が気持ち悪い

**デフォルトの名無しさん** · 2024/11/12(火) 10:15:49.34

>>781
省略せずに書くと
fn do_something<‘a>(&’a mut self) -> &’a mut [u8]

return xするとxのライフタイムは’a
xは&mut self.dataの一部なので&mut self.dataのライフタイムも’a
‘aのライフタイムに渡って&mut self.dataを借りておく必要があると解釈されるので
self.data = Some(vec![0u8; 10]);はエラーになる

マッチしない場合は借りないようにしてくれよと思うのはわかるが
これは今のバージョンのボローチェッカーの制約
nightlyで使える新しいボローチェッカーならエラーにならない

詳しいのは↓ここ
https://rust-lang.github.io/rfcs/2094-nll.html#problem-case-3-conditional-control-flow-across-functions

**デフォルトの名無しさん** · 2024/11/12(火) 10:22:11.79

if self.data.is_some() {
return self.data.as_mut().unwrap();
}
や
if let Some(ref mut x) = self.data {
return x;
}
でも
エラーにならない

**デフォルトの名無しさん** · 2024/11/12(火) 10:23:41.85

>>793
複おじではないよ

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

>>794
新しいボローチェッカーって-Zpolonius=nextのことでいいの？
付けても通らなかったけど、これが通せることを目標にしてるって意味？

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

仇討ちして英雄になりたいのか
とんでもねえ話だなこれ

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

>>797
-Z poloniusで通る

**デフォルトの名無しさん** · 2024/11/12(火) 14:07:23.60

>>799
おっいけたわありがとう
-Zpolonius=[legacy|next]だと思ってたらいつの間にやらon/offフラグになってたのね

**デフォルトの名無しさん** · 2024/11/12(火) 18:29:56.22

>>781
左右の型が一致しない(右だけ参照)この部分を
if let Some(x) = &mut self.data {
昔からの正規にrefを使って左右の型を一致させて
if let Some(ref mut x) = self.data {
こう書けばコンパイル通る点は興味深いな