Rust part13

**デフォルトの名無しさん** · 2021/11/07(日) 10:04:59.35

公式
https://www.rust-lang.org/
https://blog.rust-lang.org/
https://github.com/rust-lang/rust

Web上の実行環境
https://play.rust-lang.org

日本語の情報
https://rust-jp.rs/

※Rustを学びたい人はまず最初に公式のThe Bookを読むこと
https://doc.rust-lang.org/book/

※Rustのasyncについて知りたければ「async-book」は必読
https://rust-lang.github.io/async-book/

※C++との比較は専用スレへ
C++ vs Rust
https://mevius.5ch.net/test/read.cgi/tech/1619219089/

※次スレは原則>>980が立てること

前スレ
Rust part12
https://mevius.5ch.net/test/read.cgi/tech/1629813327/

**デフォルトの名無しさん** · 2022/01/15(土) 17:52:02.36

>Cでポインタへのポインタをダブルポインタと言い張ったり
>Cで関数へポインタで値渡ししてるだけのことを参照渡しと言い張ったり
c++でポインタ渡しを参照渡し言うならそりゃ誤解は出てくるが、そんなに問題にならんわ。
てか extern C で参照渡しは普通にポインタ扱いになるしな。
rustで所有権のコピー言うのは明確に意味がおかしい。

**デフォルトの名無しさん** · 2022/01/15(土) 18:25:43.70

もうええやろこの話題は…こんな枝葉の問題でギャーギャー騒いでたら何も身につかんで…
Rust棒を使って気に食わないやつを殴りたいだけなんか…？

**デフォルトの名無しさん** · 2022/01/15(土) 18:25:58.18

所有権 → リソースの解放義務
コピーしたらアカン

**デフォルトの名無しさん** · 2022/01/15(土) 19:00:19.86

c++23以降で契約プログラミングのサポートが入るらしいけど、rustって言語レベルで契約プログラミングサポートしてる？

**デフォルトの名無しさん** · 2022/01/15(土) 19:35:04.98

1週間以上も議論が続いている原因はおそらく
copyとmoveの対象の非対称性にあると思う

Copy trait非実装の型は「所有権がmoveされる」
Copy trait実装の型は「値がcopyされる」そして「新たな所有権が生じる」

**デフォルトの名無しさん** · 2022/01/15(土) 20:06:03.10

そんな複雑な理屈じゃなくてただのバカが意固地になってるだけだろ。。

**デフォルトの名無しさん** · 2022/01/15(土) 21:12:26.97

>>602
議論が続いてる気になってるんだw

**デフォルトの名無しさん** · 2022/01/15(土) 21:34:33.77

>>602
moveの対象も値だぞ
the bookのownershipの解説ページに1つでもmoveの対象がownershipになってる箇所あるか？
https://doc.rust-lang.org/book/ch04-01-what-is-ownership.html

@ITの記事はそこも間違ってる

**デフォルトの名無しさん** · 2022/01/15(土) 21:37:55.34

>>600
ホントこれ
所有権が何かわかってれば複製なんて考えは絶対出てこない

**デフォルトの名無しさん** · 2022/01/15(土) 21:44:00.10

俺は中立派なので
「Copyトレイト実装型は値と所有権が複製される」
でも構わないし9割以上の人々にはこれで通じるだろう
あとはどこまでこだわるかだけだ
これ以上その表現は容認できないと続けるならばスレ荒らしと変わらない

**デフォルトの名無しさん** · 2022/01/15(土) 21:52:50.82

>>607
｢所有権の複製｣は根拠の無いオレオレ用語であり
rust公式による定義は一切示されなかった

でオシマイの話
議論ですらないし
どっち派という派閥の話でもない

**デフォルトの名無しさん** · 2022/01/15(土) 22:04:56.72

一般的に「批判や反対だけならバカでもできる」と言われるので
ここは代替案、修正案、改善案を示してはどうだろうか？

**デフォルトの名無しさん** · 2022/01/15(土) 22:09:17.84

匿名掲示板のやりとりで意見を変える人なんていないしとっとと次の話題に移るに限る

**デフォルトの名無しさん** · 2022/01/15(土) 22:17:16.04

複製おじさんが必死過ぎて草www
自分の間違いに気づいてもなお苦し紛れの言い訳テラワロスw

**デフォルトの名無しさん** · 2022/01/15(土) 22:29:40.11

>>597
参照渡しという用語は定義があるからCのポインタ値渡しに使うのは明らかに間違いなわけだが
ダブルポインタの方は正式に仕様で規定されているわけではないが俗語として通用しているな。
俗語だから前提無しに誰にでも通じるわけじゃないというところ注意が必要だが。

**デフォルトの名無しさん** · 2022/01/15(土) 22:30:43.34

複製おじさんは自演して複数人を装ういつもの人

いつも間違いを指摘されるが全く反省せず
嘘を書き続けて強弁しつつ自演擁護するのが趣味
C++じいさんと一緒にここに隔離されてる

**デフォルトの名無しさん** · 2022/01/15(土) 22:33:34.89

所有権も複製されるとするとrustの所有権システム破綻するの？
そういう話ではなくて用語の用法に違和感があるという議論だよね？
理解合ってる？

**デフォルトの名無しさん** · 2022/01/15(土) 22:44:35.60

>>614
その通り
俺は既に書いたように
『Copy trait実装の型は「値がcopyされる」そして「新たな所有権が生じる」』だが
これを『値と所有権が複製される』と表現する人がいても特に困らないしRustの理解で破綻することもない
現実にある所有権に照らし合わせると『所有権の複製』という用法に違和感があるだろうという話

**デフォルトの名無しさん** · 2022/01/15(土) 23:04:44.12

>>613
今日いきなり「複製おじさん」とかいう特異な単語を使う人が立て続けに現れたんですがｗ

**デフォルトの名無しさん** · 2022/01/15(土) 23:42:27.61

>>614
複製されたら破綻するよ
当たり前じゃん
所有権を何だと思ってんの？
わかってないの複製おじさんだけだよ

**デフォルトの名無しさん** · 2022/01/16(日) 10:16:15.91

>>614
＞所有権も複製されるとすると

所有権は複製されない。

**デフォルトの名無しさん** · 2022/01/16(日) 10:41:29.77

一週間バカにされ続けても自ら学ぼうとしないメンタルすごいよな

記事書いたやつも複製おじさんも所有権を変数単位のフラグみたいに認識してるんだよ
Copyなら変数の値をコピーして所有権フラグの値もコピーするイメージ(何か問題でも?w)

現実の所有権のように各所有権が個別リソースに紐づくと考えてないから「所有権を複製」しても問題ないと思っちゃう

所有権のメタファー台無し

**デフォルトの名無しさん** · 2022/01/16(日) 10:49:19.61

>>617
>所有権を何だと思ってんの？
この質問に答えられるようなら1週間前に終わってる話
自信がなくバカにされるのが怖くて答えられない
だから自演して印象操作に走ってしまう
それで余計にバカにされちゃう悪循環

**デフォルトの名無しさん** · 2022/01/16(日) 10:53:40.34

Rustスレは

仲介イテレータおじさん
所有権の複製おじさん
算数100点おじさん

の提供でお送りします

**デフォルトの名無しさん** · 2022/01/16(日) 10:57:58.12

みんなサビサビや!

**デフォルトの名無しさん** · 2022/01/16(日) 12:33:17.26

仲介おじさんと複製おじさんは同一人物でしょ

**デフォルトの名無しさん** · 2022/01/16(日) 14:09:05.15

しょーゆー拳！の複製とは・・・所有してない事では・・・？それとも共有？創造イテレーターおじさん。。。

**デフォルトの名無しさん** · 2022/01/17(月) 22:59:06.94

Rust 1.58で使えるようになったね

let var = 123.45;
assert_eq!(" 123.450", format!("{var: >10.3}"));

let vec = (5..=9).collect::<Vec<i32>>();
assert_eq!("[5, 6, 7, 8, 9]", format!("{vec:?}"));

**デフォルトの名無しさん** · 2022/01/19(水) 19:54:17.44

rust学習してるんだけど
コンパイル時検査で並列処理の安全性（可変参照が1つである事）を証明できるんだろうか？
実行時に借用チェックが行われてるという説明があったけどそれは必要なの？

**デフォルトの名無しさん** · 2022/01/19(水) 19:59:57.13

勘違いかも
この記事実行時にチェックしてるという意味じゃないかもしれない

**デフォルトの名無しさん** · 2022/01/19(水) 21:18:54.23

>>626
複数スレッドから参照される変数はコンパイル時に保証できないから実行時に保証されるよ
Mutexとか

**デフォルトの名無しさん** · 2022/01/19(水) 21:23:52.62

Rc<RefCell<T>>のように所有権が共有されてる値を変更する場合なんかは実行時チェックしかできない

interior mutability patternと呼ばれるやつはみんなそう

**デフォルトの名無しさん** · 2022/01/19(水) 21:24:20.06

ガブリンチョ

**デフォルトの名無しさん** · 2022/01/20(木) 10:26:42.45

実行時に動的に借用のチェックをさせたいという動機は分かるんだが
RefCellっていう名前でそれが表現できてると思えないし
一方で内部可変性を表現してるとも思えないし
そもそも内部可変性と実行時借用規則強制と二つのことが一つの名前になってるし
じゃあどうすべきだったということも思いつかないけど
なんかモヤモヤしてる

**デフォルトの名無しさん** · 2022/01/20(木) 12:30:05.06

Cell<T> は Mutable<T>
RefCell<T> は DynamicMutable<T>

Cellが何かを一度イメージできるようになると
今のネーミングでも困らないから名前が変わることはないと思う
interior mutabilityという名前も最初は分かりにくかった
こっちはまだ変わる可能性あると思う

**デフォルトの名無しさん** · 2022/01/20(木) 12:40:28.40

https://internals.rust-lang.org/t/pre-rfc-rename-refcell-to-give-it-a-descriptive-name/533
議論はあったが決定的な代替案があったわけでもないみたいね

**デフォルトの名無しさん** · 2022/01/20(木) 12:41:15.85

あー、なるほど、名前が分かりづらいのはおれが日本人のせいなのかな、とか思ってたけど、やっぱり慣れてないと分かりづらいネーミングだったか

**デフォルトの名無しさん** · 2022/01/20(木) 13:06:17.45

そもそもBoxってなんやねん！😡

**デフォルトの名無しさん** · 2022/01/20(木) 13:18:31.58

>>631
中身を書き換えられる『セル』という分かりやすい名前
Cellは内部可変がOK
RefCellは内部可変参照がOK

違いが分かりやすいように3種類を持つ構造体を用意
struct S {
a: [i32; 3],
c: Cell<[i32; 3]>,
r: RefCell<[i32; 3]>,
}
let s = S {
a: [1, 2, 3],
c: Cell::new([1, 2, 3]),
r: RefCell::new([1, 2, 3]),
};
// s.a = [4, 5, 6]; // コンパイルエラー (sがmutじゃないため)
// s.a[1] = 5; // コンパイルエラー (sがmutじゃないため)
s.c.set([4, 5, 6]); // OK 内部可変
{
let mut p = s.r.borrow_mut(); // OK 内部可変参照
p[1] = 5;
// このブロックを抜けるとborrow自動返却
}
assert_eq!([1, 2, 3], s.a);
assert_eq!([4, 5, 6], s.c.get());
assert_eq!([1, 5, 3], *s.r.borrow());

**デフォルトの名無しさん** · 2022/01/20(木) 13:20:34.04

メソッド名が動的←→静的と対称的であったりもしないし・・・

Cell: get, get_mut, set
RefCell: get_mut, borrow, borrow_mut

ただしget_mutはそれぞれ
https://doc.rust-lang.org/std/cell/struct.Cell.html#method.get_mut
> this method expects self to be mutable, which is generally not the case when using a Cell.
https://doc.rust-lang.org/std/cell/struct.RefCell.html#method.get_mut
> this method expects self to be mutable, which is generally not the case when using a RefCell.
とあり通常の用途とやらで考えると

Cell: get, set
RefCell: borrow, borrow_mut

共に"Cell"で内部可変性を表現しつつ
用途はメソッド名で十分わかるしまぁもういいのかこれで

**デフォルトの名無しさん** · 2022/01/20(木) 13:27:05.24

>>632
>>636
Cellっていう短い名前にクッキリした役割を描いたのはRust陣営は成功かもね
Rust以前に前例があるかどうかは知らんけど

>>634
名前の説得力が不足してる疑いはあるよね

>>635
それなｗ

**デフォルトの名無しさん** · 2022/01/20(木) 13:39:18.98

>>637
Cell⇔RefCell は静的⇔動的の関係ではない
Cell⇔RefCell は直接⇔参照の関係
そのため余分にRefが付く

静的⇔動的の関係にあるのは
「&」⇔「RefCell::borrow()」)
「&mut」⇔「RefCell::borrow_mut()」

**デフォルトの名無しさん** · 2022/01/20(木) 13:52:05.11

>>639
少なくとも構造体の説明としては

https://doc.rust-lang.org/std/cell/struct.Cell.html
> A mutable memory location.

https://doc.rust-lang.org/std/cell/struct.RefCell.html
> A mutable memory location with dynamically checked borrow rules

↑のように書いてあるね
だから
SCell // A mutable memory location with statically checked borrow rules
DCell // A mutable memory location with dynamically checked borrow rules
こんなんでもよかったんじゃないかなぁと思ったがこれはこれで石投げられそう

**デフォルトの名無しさん** · 2022/01/20(木) 14:13:35.66

>>640
それは違う
間違った解釈で無関係な場所に「with statically checked borrow rules」を付けてはいけない

参照借用規則『multi readers xor single writer』に対して
以下が「静的チェック⇔動的チェック」の関係にある
静的チェック: multi「 &」xor single「&mut」
動的チェック: multi「RefCell::borrow()」xor single「RefCell::borrow_mut()」

一方でCellとRefCellの関係は
内部可変性が「直接書き換えOK」⇔「参照書き換えOK」の関係
だからCellに対してRef(参照)が付くRefCellという名前になっている
そして参照となるRefCellに対してのみ上述の参照借用規則が適用される

**デフォルトの名無しさん** · 2022/01/20(木) 14:23:25.93

>>641
なるほどね

https://doc.rust-lang.org/std/cell/struct.Cell.html#method.get_mut
> If you require interior mutability by reference,
> consider using RefCell which provides run-time checked mutable borrows through its borrow_mut method.

↑ここでもまずは「参照による内部可変性が必要な場合は」と先に来てるね
「実行時に動的に借用のチェックをさせたいという」のが動機だと俺勝手に思いこんでたけど
それは一番じゃないみたい

**デフォルトの名無しさん** · 2022/01/20(木) 14:32:46.88

>>635
Cell/RefCellと違ってBoxは分かりやすくていい名前だと思うぞ
Boxing/Unboxingは他の言語でも普通に使われてるよね？
旧名のOwned<T>や代替案のHeap<T>に比べると確実にいい

**デフォルトの名無しさん** · 2022/01/20(木) 14:45:20.72

Boxing/UnboxingはC#やJavaにもあるからBoxには全く違和感なかったけど
よく考えるとソースコード上にBoxという文字列が出現するのはRustだけかも？

**デフォルトの名無しさん** · 2022/01/20(木) 14:54:02.35

Scheme でも次の規格に Box が入ることになっている。
(既に導入している処理系も結構ある。)

**デフォルトの名無しさん** · 2022/01/20(木) 15:32:21.48

通常の型TやBox<T>などがSend+Syncである一方
Cell<T>とRefCell<T>は!Send+!Syncであることと引き換えに内部可変性を得ている
つまりmutではない参照の内部にあったとしても
「Cell<T>」は「mut T」のように成れて直接書き換え可能
「RefCell<T>」は「&mut T」を得られて参照書き換え可能
ここでCellとRefCellの違いは「&」すなわち「Ref」だからこの命名自体は分かりやすいと思う

**デフォルトの名無しさん** · 2022/01/20(木) 16:52:16.46

>>644
むしろJava等にあるからこそ戸惑ったわ
既にあるBoxing/Unboxingへの理解に対して
Rustでは突如構造体としてBoxだもん

**デフォルトの名無しさん** · 2022/01/20(木) 23:14:12.74

まあBox と名前を合わせてBoxCellとか逆にBoxをRefにするかした方が統一的な名前づけだったとは思う。

**デフォルトの名無しさん** · 2022/01/21(金) 07:08:34.56

>>648
Box<T>はヒープ上にTの場所を確保してそこを指し示します
Cell<T>はヒープ上かどうかは無関係で例えば>>636の使用例では全てスタック上
したがって「Boxと名前を合わせてBoxCellとか」はおかしいです

TとCell<T>はメモリ上の格納場所も実体も同じです
つまりCellとは内部可変性という特性を与え示していると考えたほうがわかりやすいでしょう
RefCell<T>も同様ですがこちらは参照借用規則の実行時チェックのためのborrowフラグが余分に確保されます

もうひとつの「BoxをRefにするかした方が統一的な名前づけだったとは思う」もおかしいです
refは参照(reference)の略としてあちこちで使われておりヒープ上かどうかは無関係ですが
Box<T>はあくまでもTがヒープ上にあることが主眼です

余談ですがこの関係でRefといえばstd::cell::Refという構造体があり
これはRefCell::borrow()が返す型として直接意識することはなく使われています
ちなみにRefCell::borrow_mut()が返す型はstd::cell::RefMutです

**デフォルトの名無しさん** · 2022/01/21(金) 10:40:22.86

何も分かってねーなこいつ。
なぜBoxにするか、なぜRefCellにするかってのは要するに構造体のサイズを決定できない場合を想定してるわけよ。
スタックにそういういう動的にサイズが異なる実体をおくことも最近のコンパイラではないこともないが、通常はヒープに置くわ。
文字通りしか考えないで実際の使い方なんか一切考えないやつってのが丸わかりになるって意味では
分かってなさそうなやつにこの辺りについて問いただすってのは割と良いかも。

**デフォルトの名無しさん** · 2022/01/21(金) 11:50:08.61

皆の言ってることがよくわからん
そもそもBoxとRefCellって対比させるようなものか？

**デフォルトの名無しさん** · 2022/01/21(金) 12:13:07.97

T -- Box<T>
Cell<T> -- RefCell<T>
って普通に考えれば対比させると思うけど。

**デフォルトの名無しさん** · 2022/01/21(金) 13:03:50.49

RefCell<T>はTへのrefが作れるCell (実行時にborrow checkする)
TとBox<T>はborrowに関しては同じ振る舞いでデータの場所がヒープか否かの違い
全然関係性違うと思うんだけど

**デフォルトの名無しさん** · 2022/01/21(金) 16:26:46.26

>>653と>>649は合っている
>>650は間違っている
BoxとRefCellには共通点も類似性も関係性も何もない

**デフォルトの名無しさん** · 2022/01/21(金) 16:43:50.31

「所有権の複製」がおかしいってことは納得言ってくれたん？ｗ

**デフォルトの名無しさん** · 2022/01/21(金) 23:30:48.05

表現の問題だけど別にいいんじゃね？

**デフォルトの名無しさん** · 2022/01/22(土) 00:49:37.07

ダメです
明らかにおかしい
ポインタ渡しと参照渡しを間違えてるくらいにはおかしい

**デフォルトの名無しさん** · 2022/01/22(土) 01:05:08.77

それは解釈のレイヤの問題。
JIS の情報処理用語の定義では参照呼び (参照渡しという言葉は定義がないが実質的に同じだろう) はオブジェクトの場所を渡すことと定義されていて、
ポインタという形で場所を渡すのも参照呼びの一種ということになる。
言語仕様の話をしているところで異なるレイヤが混ざるのはおかしくはあるが、
実例を示そうとしたり、逆に抽象的に説明しようとしたりすると境界が曖昧になることはある。

**デフォルトの名無しさん** · 2022/01/22(土) 19:22:08.25

じゃああなたはポインタ渡しと参照渡しを間違えてもいいよ

**デフォルトの名無しさん** · 2022/01/22(土) 19:59:43.90

>>658
ポインタ渡しと参照渡しが同じなら、nullptrを渡すのと同じことを参照渡しでどうやるか教えてくれ。

**デフォルトの名無しさん** · 2022/01/22(土) 20:05:58.29

>>657
参照渡しじゃなくてダブルポインタの方だろ。

**デフォルトの名無しさん** · 2022/01/22(土) 20:32:06.98

ポインタ渡しっていう用語も使わないでほしい
ポインタ型の時に特別なもんでもなんでもなく
他の場合と同じcall by valueなのだから

**デフォルトの名無しさん** · 2022/01/22(土) 20:53:17.10

rustにおいて参照渡しと言ったらどういう意味になるんだろうか

**デフォルトの名無しさん** · 2022/01/22(土) 22:32:38.62

>>657
そんなレベルじゃないだろw
「値の参照外し」くらいのありえねーやつだぞ

**デフォルトの名無しさん** · 2022/01/22(土) 23:03:41.04

>>663
&Tを渡すこと

**デフォルトの名無しさん** · 2022/01/22(土) 23:09:33.04

>>654
>BoxとRefCellには共通点も類似性も関係性も何もない
そうそう、何の共通点も類似性も関係性もないのに
The BookではBoxとRefCellを対比させてどういうケースにどっちを使うかわざわざ解説してるんだよなぁ
何の共通点も類似性も関係性も無いにも関わらずw

**デフォルトの名無しさん** · 2022/01/22(土) 23:45:04.56

>>666
マジでその二つは関連も類似も何もない
大きく分類してもBoxはスマートポインタの一種だが
RefCellはスマートポインタではなく内部可変性という性質の指定のみ

**デフォルトの名無しさん** · 2022/01/23(日) 00:16:51.00

>>666
https://doc.rust-lang.org/book/ch15-05-interior-mutability.html
https://doc.rust-jp.rs/book-ja/ch15-05-interior-mutability.html
ここのこと？

**デフォルトの名無しさん** · 2022/01/23(日) 01:50:05.66

clippy様がvoldemort typeを説明せよと仰せなのだが
もしかして、名前を言ってはいけないあの人のことをご存じない？

>>668
そこはinterior mutabilityの前提としてborrowing rulesを
おさらいするためにBoxを出してるだけだから違うだろ。
多義的なオレオレ用語が多くて質は悪いけど
the bookに意味もなくBoxとRefCellを登場させてる章なんてなかったと思う。

**デフォルトの名無しさん** · 2022/01/23(日) 09:58:49.85

なんでわざわざ自演するのかね？

**デフォルトの名無しさん** · 2022/01/23(日) 10:23:00.27

それが仲介おじの悪癖なんよ

**デフォルトの名無しさん** · 2022/01/23(日) 14:04:42.46

病気だな
病名は知らんけど

**デフォルトの名無しさん** · 2022/01/23(日) 15:19:04.05

rust勉強しはじめたばかり、C,C++はだいぶ昔少し経験がある程度

Cとかじゃ、constなpointerは、変数自体がconstと、指ししめす対象自体がconstである場合があり
const T * const p;
みたいな宣言があったが

Rustはデフォルトでイミュータブルなのはわかるけど、mutを付けると、変数自体も指し示す対象もmutableになってしまう？

let mut v = vec![1, 2, 3];
v.push(2);
v = vec![4,5,6];

どっちか一方を禁止する方法とかあるのですか？

**デフォルトの名無しさん** · 2022/01/23(日) 17:38:28.44

C上がりのヤツって意味のないところにconst付けがち
関数の引数にconst DWORD vとか

**デフォルトの名無しさん** · 2022/01/23(日) 19:54:52.69

>>673
どういうことをしたいのかによるけど
let x = Vec![...];
let mut y = &x;
みたいにすればyは再代入可能だけどxやvecの中身は変更不可になる

**デフォルトの名無しさん** · 2022/01/23(日) 20:02:24.55

末尾oとかWとかで荒らしてるやつ回線なんだ？亡霊か？

**デフォルトの名無しさん** · 2022/01/23(日) 20:58:37.79

えっ、一人二役まだ続けるのか

**デフォルトの名無しさん** · 2022/01/23(日) 22:45:59.41

お前Lはないだろ

**デフォルトの名無しさん** · 2022/01/23(日) 23:46:00.51

ちなみにRustでのconstとはコンパイル時点で定数(どんな複雑な型でもよい)であること
プログラミング言語によってはconstなのに実行時に決まる値(がその後変化しないこと、つまり単なるimmutable)を意味しているので意味の差に注意

**デフォルトの名無しさん** · 2022/01/23(日) 23:59:31.12

>>674
Rustでは関数の引数にconstはないな
ジェネリクスとしてのパラメータにはconstがありこちらは便利

**デフォルトの名無しさん** · 2022/01/24(月) 00:27:06.65

>>675
ありがとうございます。
やりたいことは、だいたい同じですけど、少し違って
v.push(2)か再代入のv= vec![4,5,6];のどちらかを禁じたいでしたけど
あなたの投稿みて考えて

let v = &mut vec![1, 2, 3];
v.push(2);
//v = vec![4, 5, 6]; エラーになる

で一応できました。
でも再代入可能で、中身変更不可にｖをする方法は思い浮かびませんでした。
675のようにして、vからｙに代入したらyはそうなりますが。

**デフォルトの名無しさん** · 2022/01/26(水) 20:11:49.47

すまんが、Replit使って学習してるんだけどさ
たまたま海外勢の動画見たら、同じReplitのはずなのに波線の指摘とかコード補完とか効いててびっくりしたわ
https://www.youtube.com/watch?v=MsocPEZBd-M
うちではこんなのならないんだけど・・・・やり方わかる人いたら教えてくれんかな？

**デフォルトの名無しさん** · 2022/01/26(水) 22:40:12.84

Repl.itは、リンターやデバッガーからサードパーティのパッケージ、ホスティング、デプロイまで、

すべてを備えた、ブラウザー内の完全な共同クラウド開発環境です

**デフォルトの名無しさん** · 2022/01/27(木) 14:52:35.89

プログラミングRustの第2版の訳書出たんだな

**デフォルトの名無しさん** · 2022/01/27(木) 17:03:59.04

**デフォルトの名無しさん** · 2022/01/30(日) 18:39:19.14

Rustはゼロ除算はコンパイルエラーになるの？

**デフォルトの名無しさん** · 2022/01/30(日) 18:46:47.93

const文脈ならコンパイルエラーになったはず

**デフォルトの名無しさん** · 2022/01/30(日) 19:13:28.33

コンパイル時に判明しないゼロ除算やオーバーフロー除算 ex. -128_i8 / -1_i8 はpanicとなるので
それが困る場合はchecked_div()を使えばOption型が返りNoneとなる

**デフォルトの名無しさん** · 2022/01/30(日) 20:48:51.55

>>688
ほんとだ、定数式じゃなくてもエラーになるんだね
https://play.rust-lang.org/?version=stable&;mode=debug&edition=2021&gist=78efbd7a2e6ac42c15da2cfb0d11485f

即値じゃなくてもエラーにしてくれてある程度賢そう
https://play.rust-lang.org/?version=stable&;mode=debug&edition=2021&gist=381372577a28207f3a37bc007ac6e29c

**デフォルトの名無しさん** · 2022/01/30(日) 21:12:48.50

const fn divide(x:i32, y:i32) ->i32 {
x / y
}

let x = divide(1, 0); //panic
const y: i32 = divide(1, 0); //compile error

**デフォルトの名無しさん** · 2022/01/31(月) 00:45:03.08

>>690
定数式の文脈でゼロ除算起きるとコンパイルエラーになるのはある意味当然だと思うんだけど
そうじゃないところでエラーになるのが意外だった
デバッグビルドでもMIRの最適化とかで定数畳み込みみたいなことやってるのかな

**デフォルトの名無しさん** · 2022/01/31(月) 07:35:21.99

>>691
Rustではconst fnな関数を使ってconstな定数を作ることができる
つまりコンパイラがその定数を算出するためコンパイル時点で判明する

**デフォルトの名無しさん** · 2022/01/31(月) 10:25:13.89

とあるデータフォーマットを扱うライブラリを作っています。
一定形式のレコードが連続で書き込まれて最後には終端レコードが書き込まれるという単純な形式です。
Rust 上でもレコードを追加するのと終端処理のふたつのメソッドがあるだけです。
要は ↓ のように使えるライブラリだということです。

let mut file = File::create("file.hoge").unwrap();
Hoge::new(&mut file).add_entry("string1")?.add_entry("string2")?.finish();

このとき
・終端処理は必ずしたい
・終端処理はエラーの可能性もあり、それは捕捉したい (ので drop でさせられない)
という制約を静的に表現できるでしょうか？

現状では終端処理のメソッドが実行されたときにフラグを立てておいて
drop 内でそのフラグを検査するという形にしています。
可能ならコンパイル時に発見できるようにしたいです。

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

エラーを捕捉したいことをデストラクタに任せない
つまりそのような終端処理はdropされる前に終える
例えばBufWriter利用時も終える時は明示的にflushを呼ぶ
そしてflushはResultを返しエラーが判明する

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

finishの呼び忘れを静的に捕捉したいということだからflushの例では不十分かな
add_entryの戻り値型の暗黙のdropを防げばいいけど、そういった機能はまだない（RFCにはあるけど進んではない）

https://users.rust-lang.org/t/prevent-drop-at-compile-time/20508
このスレッドではdropの実装に存在しないC FFI呼び出しを書いておいて、リンクエラーとして捕捉する方法が提案されているね

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

>>694
それを制約として表現できるか (終端処理をしていないときにエラーになるように制約を書けるか) という質問をしてる。
つまり出来ないってこと？

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

>>695
それは残念。

言語の機能として用意されてないまわりくどい方法を使うと
エラーメッセージがよくわからん (本来の問題とは違う内容が出てくる) ことになりがちだし、
使うときに unsafe や forget をいちいち書いてもらわなきゃならないのは
ライブラリとして提供するときにはちょっと汚すぎるなぁ。