Rust part8

**デフォルトの名無しさん** · 2020/01/24(金) 11:47:52.41

Mozilla発のRust言語のスレ

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

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

前スレ
Rust Part7
http://mevius.5ch.net/test/read.cgi/tech/1563114707/

**デフォルトの名無しさん** · 2020/06/06(土) 19:37:13.44

>>693
結局それってディストリビューション依存だからなぁ。
バージョンだって固定できないし、OSS拾ってきてコンパイルが通るようにするだけで試行錯誤が必要。

>>696
いや、頑張って環境構築すればなんとかなるのはその通りだけど、
別のソフトだとまた別の環境構築が必要になって辛いのです。

**デフォルトの名無しさん** · 2020/06/06(土) 21:37:30.50

Rustでプロキシーサーバー実装してみようと思ったんだけどTCPStreamとreqwest::headerの連携がうまくいかない

**696** · 2020/06/06(土) 22:21:08.03

漏れは、日本人が作った、バージョンマネージャーのanyenv で、
rbenv, nodenv を使って、ruby 2.6.6, node 12.16.2 を入れた

環境構築が、各言語でバラバラになるのは面倒なので、
anyenv・asdf などを使えば？

**デフォルトの名無しさん** · 2020/06/06(土) 23:04:13.04

hyperのサンプルに答えがありました

**デフォルトの名無しさん** · 2020/06/07(日) 00:03:49.64

こんな書き込みを見つけた：
loop {
// 1. you finally understood lifetimes
// 2. you get compiler lifetime /borrow complaints
// 3. you feel stupid for taking hours to fix <5 LoC
}

**デフォルトの名無しさん** · 2020/06/07(日) 00:19:04.85

ループ {
// 1. あなたはついに lifetime を理解した。
// 2. あなたはコンパイラに lifetimeやborrow の苦情を複数個言われる。
// 3. 5行未満のコードを直すのに何時間もとられることにあなたは馬鹿馬鹿しさを感じる。
}

**デフォルトの名無しさん** · 2020/06/07(日) 11:58:43.41

コンパイラに緊縛されて未定義動作を踏まないという快感を得るプレイ

**デフォルトの名無しさん** · 2020/06/07(日) 17:57:12.72

Rsutって、早い話が、CやC++に、NULLバグ等々が発生しないようにするための補助機能がついた言語ってこと？

**デフォルトの名無しさん** · 2020/06/07(日) 18:44:36.11

そうだね～、で、俺様はNullチェックは忘れないしダングリングポインタなんて組み込まないのでC/C++で良いや
という俺様スパハカがゴミグラムを生み出してきたのでRustは必須

**デフォルトの名無しさん** · 2020/06/07(日) 18:48:57.09

>>704
書き方がC/C++の文化とはかけ離れているように感じるが。

**デフォルトの名無しさん** · 2020/06/07(日) 19:46:37.12

>>706
いや、言語誕生の思想を考えただけです。
言語誕生の思想をきちんと抑えないと、メリットとデメリットを正答に評価出来ないから

**デフォルトの名無しさん** · 2020/06/07(日) 19:59:02.69

どっちかというと「関数型C++」な印象

**デフォルトの名無しさん** · 2020/06/07(日) 22:51:27.97

Hindley-Milner 型推論を元にしているから考え方は ML 系統からの影響は大きいと思う。

**デフォルトの名無しさん** · 2020/06/08(月) 02:06:14.90

C++の地獄をML（とアフィン型）の知見で楽にしようとした言語

Cの遺産を引き摺ったが故に煩雑だった前者の記法を捨てて後者のいいとこを貰ってきたので、記法が後者に似てるように見えはするけど、やってる事はそう大きく変わってはいない

**デフォルトの名無しさん** · 2020/06/08(月) 10:53:34.76

「C++ のメンバ関数の実態は this を暗黙に渡しているだけ」ってのを露骨にしたのも Rust の面白い部分だよね。
関数的な意味論を用いながらも構文糖としてのメソッド記法も用意することでオブジェクト指向的な表現が出来る。

**デフォルトの名無しさん** · 2020/06/08(月) 13:11:59.47

RustはC++ではゼロコストで出来ていたものが、出来なくなってしまっていることが多い。

**デフォルトの名無しさん** · 2020/06/08(月) 13:14:25.82

>>712
具体的には？

**デフォルトの名無しさん** · 2020/06/08(月) 13:19:16.88

関数的な意味論ねぇ
表層的に一部それっぽいってだけでは？

**デフォルトの名無しさん** · 2020/06/08(月) 13:28:01.70

言語として純粋関数型に分類される Haskell ですら
オブジェクト指向のスタイルで構築されたライブラリは有るから……。
(そのためのフレームワークである lens はまあまあ人気。)

言語仕様での理屈がどうあれ最終的には使い方次第。

**デフォルトの名無しさん** · 2020/06/08(月) 13:36:41.82

>>713
言うと改善されるので言わない。

**デフォルトの名無しさん** · 2020/06/08(月) 13:46:18.64

memmove()すらunsafeなしではかけないし。

**デフォルトの名無しさん** · 2020/06/08(月) 13:53:57.25

RustではpChildがHeapにとられている時、次のようなループすら書けない。
CPerson *pChild=pPerson->pChild;
while(pChild != NULL) {
(pChildに対する処理);
pChild=pChild->pNext;
}

**デフォルトの名無しさん** · 2020/06/08(月) 14:30:52.23

>>718
こういう感じのこと？

#[derive(Default)]
struct Person {
pub childs: Box<[Person]>
}

fn main() {
let person : Person = Default::default();
let childs = person.childs;
for ref child in childs.iter() {
// child に対する処理
}
}

**デフォルトの名無しさん** · 2020/06/08(月) 14:39:32.30

>>719
Heap領域にある構造体の中に、さらにHeap領域にあるデータへの
参照を持つためにBox型のメンバが有る場合、後者のBoxは、unique_ptrなので
ローカル変数にmoveすることができないためコンパイルエラーになる。
なので、参照カウント方式のRcを使う必要がある。

**デフォルトの名無しさん** · 2020/06/08(月) 14:44:31.30

>>719 の場合だと personがスタック領域にあるが、もしそれがHeap領域に
あったとすると、
let childs = person.childs;
とするとエラーになるはずだ。

**デフォルトの名無しさん** · 2020/06/08(月) 14:48:41.29

>>721
ならない。

　　　　　　(完)

**デフォルトの名無しさん** · 2020/06/08(月) 14:53:38.92

チュートリアルも読まない難癖おじいちゃんの相手すんなし

**デフォルトの名無しさん** · 2020/06/08(月) 14:56:15.14

そもそも、
struct Person {
　pub child: Box<[Person]>
}
がおかしくて、正しくは、
struct Person {
　pub child: Box<Person>
　pub next: Box<Person>
}
だ。

**デフォルトの名無しさん** · 2020/06/08(月) 14:56:44.39

>>722
全く同じではないが、こっちの環境ではなったがな。

**デフォルトの名無しさん** · 2020/06/08(月) 14:58:43.87

後付けやめろよ。
C++ のどういうコードを Rust でどう書けて欲しい (そして実際にはどういうエラーになる) のかちゃんと書け。

いや、書くな。 (どうせ見当違いなので。)

**デフォルトの名無しさん** · 2020/06/08(月) 15:03:12.27

>>725
#[derive(Debug)]
struct TAaa {
　　x: Box<i32>,
　　y: i32
}
fn main() {
　　let mut vec:Vec<TAaa> = Vec::new();
　　vec.push( TAaa {
　　　　x : Box::new(333),
　　　　y : 444
　　} );
　　let　　 x　 = vec[0].x;　// error[E0507]: cannot move out of index of `std::vec::Vec<TAaa>`
　　println!("{:#?}", x);
}
↑のように vec をHeapに確保した場合、エラーになる。
ところが、stackに確保した場合はエラーにならない。
実験済み。

**デフォルトの名無しさん** · 2020/06/08(月) 15:04:31.00

>>726
海外のサイトでも、RustはC/C++から単純移行ができ無い事が問題とされている。
FortranからCへは単純移行が出来たからCが普及したと書いてあった。

**デフォルトの名無しさん** · 2020/06/08(月) 15:16:36.76

>>726
後付ではない。
C++で、pChild、pNextと言えば、当然そういう構造体になる。

**デフォルトの名無しさん** · 2020/06/08(月) 15:47:14.20

>>727
型・寿命・所有権の条件が同じならヒープかスタックかというのは関係ない。
お前が結果的に違う条件で書いるだけ。

>>728
知らんがな。
同じように書けるんなら新しい言語を導入する意味ないだろ。
制約が厳しい替わりに問題点が検出されやすいのが Rust の利点なんだから、
その利点が要らんなら別に Rust を使わんでいいよ。

**デフォルトの名無しさん** · 2020/06/08(月) 16:43:05.54

>>730
>型・寿命・所有権の条件が同じならヒープかスタックかというのは関係ない。
>お前が結果的に違う条件で書いるだけ。
1.実験してみたところ、>>727でBoxをRcに変えてもエラーのままだった。
2.単純にTAaaをスタックに確保した場合、正常にコンパイルされた。
3.TAaaを以下のようにHeapに確保した場合も、正常にコンパイルされた：
fn main() {
let bbb = Box::new( TAaa {
x : Box::new(333),
y : 444
} );
println!( "bbb = {:#?}", bbb );
println!( "bbb.x = {:#?}", bbb.x );
println!( "let x = bbb.x;" );
let x = bbb.x;
println!( "x = {:#?}", x );
}
つまり、Vec<TAaa>の場合にだけエラーになる。

**デフォルトの名無しさん** · 2020/06/08(月) 16:57:23.12

>>731
ついでに言えば >>727 のエラーが出る行を

let ref x = vec[0].x;

とか

let x = vec.swap_remove(0);

とか

let x = vec[0].x.clone();

とかすることでもコンパイルは通る。

**デフォルトの名無しさん** · 2020/06/08(月) 17:21:28.18

>>732
>let x = vec.swap_remove(0);
let x = vec.swap_remove(0).x
のことかな?

**デフォルトの名無しさん** · 2020/06/08(月) 17:33:12.05

rustじゃ書けないおじさんのコードを添削する流れ、何度目だ

**デフォルトの名無しさん** · 2020/06/08(月) 18:00:02.94

std::mem::take

**デフォルトの名無しさん** · 2020/06/08(月) 18:06:13.25

>>733
おっと、せやな。
.x が無くてもコンパイルは通ってしまうからミスったわ。

**デフォルトの名無しさん** · 2020/06/08(月) 18:15:14.24

ID真っ赤、お顔も真っ赤ｗ

**デフォルトの名無しさん** · 2020/06/08(月) 18:20:45.97

>>734
ワイも初心者ではあるんよ。
The book (第二版の日本語訳の無料で読めるやつ) を読み終わって、試しに 500 行くらいのコードを書いてみたって程度。
本を読んでいる間はコードを書いてない。
手を動かすと理解しやすいという人も多いけど、
感覚でやってしまいがちで書いてある理屈をしっかり把握するのが疎かになる気がするから。

で、 The book を読めばこの程度には理解できるので理解できてないやつは単にアホという証明でもあるし、
逆に返答に詰るようなら俺がまだ入門級のことが理解できてない (どこが理解できていないか) ことがわかるので
練習の題材としてちょうどいいわという気持ちで相手してた。

**デフォルトの名無しさん** · 2020/06/08(月) 18:37:00.38

>>738
では、>>732 で
>let ref x = vec[0].x;
の borrow が合法かどうか、どうやってコンパイラが静的に解析しているか
アルゴリズムを説明してみてください。

**デフォルトの名無しさん** · 2020/06/08(月) 21:16:08.81

>>739
let ref というのは直接的には The book に出てこないと思うけど、
let もパターンマッチだということはタプルの項目で示されている。
たとえば let a = &1; と書いたら a には 1 の参照が入るし、
let &a = &1; と書いたら a は (参照を経由する) 値になる。

参照にマッチするのではなく値にマッチさせた上で参照が欲しいときに使うのが
ref であるということは match の説明の中にある。
つまりこの場合に let ref x = vec[0].x; というのは
let x = &(vec[0].x); と書くのと理屈は同じ。

**デフォルトの名無しさん** · 2020/06/08(月) 21:34:44.64

公式で丁寧にしかも無料で公開されてる本もろくに読めないガイジたちがわらわらするスレになっちまったな
ちょっと名が知れ渡っただけでこんなことになんだから、一般的になったらとんでもないな

**デフォルトの名無しさん** · 2020/06/08(月) 22:57:09.22

rust+wasmちょっとやってみたけど、単純な処理に記述だけが無駄に複雑になりすぎる
組み込みとかシステム系で使われそうだけど、一般的とか言う広く色々な使われ方はしないだろコレ

**デフォルトの名無しさん** · 2020/06/08(月) 23:32:06.17

JSみたいに直接DOM触れて、直接実行できるなら普及するけど、現状のめんどくささならなぁ・・・

**デフォルトの名無しさん** · 2020/06/09(火) 00:44:22.52

>>740
それは分かっている。
iとjがループ内で変化したような場合、
vec[i].x
からmutableで借用した場合、
vec[j].x
からimmutableで借用できるかどうかの判定をコンパイラが一般的に行うのが難しいんだよ。
だからそのアルゴリズムを理解しているのかと聞いている。

**デフォルトの名無しさん** · 2020/06/09(火) 00:52:40.12

>>744
似た例で言えば、
dst[i]をmutableで借用した場合、src[i]をimmutableで借用しようとしたときに、
srcとdstが同じアドレスに被って無いかの判定が静的には物凄く難しいと
されているので、エラーになってしまうかも知れないというようなことを心配
しているんだよ。

**デフォルトの名無しさん** · 2020/06/09(火) 01:01:34.80

>>745
もっとちゃんと書くと、
src[0]～src[99]までに対して処理するような場合だと、src[i]をaに借用してから
f(a)、g(a)、h(a)に順番に渡して何か処理するようなことは出来ると思われるが、
ここに、dst[0]～dst[99]も加わって、dst[j]をbにmutableで借用
しようとすると、mutableで借用した場合にimmutableでは借用できないというルールを
この場合にはコンパイラが静的には判断できなくなってコンパイル・エラーになって
しまう可能性を心配している。

つまり、コンパイルの借用チェッカは、予めよくあるパターンに対して特別な
処理を実装している場合には通るが、一般的には判断できるわけ無いので通らない
のではないかと考えられるんだよ。

**デフォルトの名無しさん** · 2020/06/09(火) 08:06:27.82

このページに唐突にRustの話が出てくるのウケるな
https://developer.mozilla.org/en-US/docs/Learn/HTML/Introduction_to_HTML/Debugging_HTML

**デフォルトの名無しさん** · 2020/06/09(火) 08:13:44.15

let x = 5;
println!("{}", if 0 < x < 10 { "in" } else { "out" });
この比較方法ができない理由ってなんかある？例えば最適化に響く？とか
可読性も労力もこれ出来たほうがいいと思うんだけど

**デフォルトの名無しさん** · 2020/06/09(火) 10:15:42.01

最初の比較でBoolになってんのを整数と比較してるからじぇね？
特に可読性が上がるとも思わないし、むしろ老眼で見逃す勢が出るから&&挟んだ方が見やすいな

**デフォルトの名無しさん** · 2020/06/09(火) 10:25:43.24

その書き方ができる言語は割と少数派な気がする
pythonではできるが

**デフォルトの名無しさん** · 2020/06/09(火) 10:40:14.84

a < x > b
これを見て何がしたいのか直感的に理解できる人間は多数派ではないだろう
結局 lb < x < ub のパターンしか使わないんなら range で十分

**デフォルトの名無しさん** · 2020/06/09(火) 10:58:25.83

>>744-746
こういう感じの話？ (※ 構造体を介する意味がないのでこの例では省略)

fn bar(vec: &mut Vec<usize>, i: usize, j: usize) {
let ref x = vec[i];
let ref mut y = vec[j]; // エラー
println!("{:#?} {:#?}", x, y);
}

fn main() {
let mut vec: Vec<usize> = vec![1, 2, 3];
bar(&mut vec, 0, 1);
}

vec の所有権が貸し出されるので一律に出来ない。
可能性を心配する必要はないよ。
普通の借用ルールが適用されて確実に出来ない。 (unsafe を使わない限り。)

**デフォルトの名無しさん** · 2020/06/09(火) 13:10:15.38

このスレで赤連投してんのこいつとこいつか？？？
https://twitter.com/YutakaAoki3
https://twitter.com/SFITB
https://twitter.com/5chan_nel (5ch newer account)

**デフォルトの名無しさん** · 2020/06/09(火) 14:37:23.22

しかもそいつら繋がってんのな、Rust大嫌いなのに隠してここでやりとりしてんのな
とりあえず二人とも気持ち悪いからミュート、ブロックした
https://qiita.com/Yutaka_Aoki
https://qiita.com/SFITB

**デフォルトの名無しさん** · 2020/06/09(火) 14:41:22.18

ここはrust信者しか書き込んだらいかんらしい

**デフォルトの名無しさん** · 2020/06/09(火) 15:07:39.63

少なくともMozillaのステマが～とか言ってた頃よりだいぶましだと思うが。

**デフォルトの名無しさん** · 2020/06/09(火) 15:54:45.21

えぇ
どっから特定されたの

**デフォルトの名無しさん** · 2020/06/09(火) 19:23:53.82

dropが飴玉みたいって批判？がちょっと面白かった。
その発想はなかった的な。

**デフォルトの名無しさん** · 2020/06/09(火) 20:40:17.08

drop out とか drop off とかのニュアンスでしょ？
スコープから消えろという意味での drop であって、結果的に解体もするというのは実装側の都合だよな。
その型を利用する側の都合からするとただ消えろって話なので、drop という語をあてるのは Rust 的にはそこそこ妥当な選択だと思える。
やることが同じだから同じというのは抽象化を軽視する暴論だ。

**デフォルトの名無しさん** · 2020/06/09(火) 23:30:17.61

linuxカーネルでキャッシュをドロップする、みたいなのが用法としては近いのかな。

**デフォルトの名無しさん** · 2020/06/10(水) 01:57:37.96

>>756
https://twitter.com/YutakaAoki3/status/1270069950581858309
同一人物説

dropって命名はかなり絶妙だと思う。
時点でscoped outから取ってoutとかがいいと思うけど、outだけだと抽象的すぎるからdropが一番いい
https://twitter.com/5chan_nel (5ch newer account)

**デフォルトの名無しさん** · 2020/06/10(水) 02:51:12.39

そもそもdropって表現使ってる言語なんかなかったっけ？？

**デフォルトの名無しさん** · 2020/06/10(水) 08:25:50.22

ネイティブが決めた名前をJapsが文句言うのは流石に草

**デフォルトの名無しさん** · 2020/06/10(水) 09:37:48.27

実際にプログラミングするのは英語話者ばかりではないので
既に浸透した用語を使って欲しいというのはわからんでもないんだが、
似て非なるものに同じ名前を与えると調べにくかったりすることもあるしなぁ。

他の言語からの「移行」という視線でばかり見ていると良くなった部分も移行コストに見えてしまうんだなというのはわかった。

**デフォルトの名無しさん** · 2020/06/10(水) 10:10:31.54

そもそもdropについて言えば既存の言語でも
free, delete, dispose, finalizeとバラバラなので
浸透もクソもない。

**デフォルトの名無しさん** · 2020/06/10(水) 10:24:08.29

それぞれの用語の大まかな使い分けはあるけども、
じゃあ drop がそのどれかに当てはまるかといえば当てはまらないし。

**デフォルトの名無しさん** · 2020/06/10(水) 12:27:01.09

qiitaの記事数は、Rustに対し、Goが8倍、Kotlinが1.5倍、C++が50倍、Javaが16倍。
唯一、Haskelに対しては、Rustは、100倍以上の記事数がある。

**デフォルトの名無しさん** · 2020/06/10(水) 18:15:57.47

>>767
それがどしたんや

**デフォルトの名無しさん** · 2020/06/10(水) 18:22:57.35

Haskelは触ったことのある人数で言えばRustよりずっと多いだろうけど、マサカリが怖くて記事書きづらいんだろう

**デフォルトの名無しさん** · 2020/06/10(水) 23:07:45.91

まず FireFox 表記をやめろ

**デフォルトの名無しさん** · 2020/06/11(木) 05:09:15.88

宣言型マクロでRustの処理書けない理由ってある？
今のパターンマッチ風構文で作ったから処理文入れるところがない的な？

**デフォルトの名無しさん** · 2020/06/11(木) 14:25:13.16

「Rust」はなぜ人気があるのか、Stack Overflowがユーザーのコメントを紹介
https://www.atmarkit.co.jp/ait/articles/2006/11/news051.html

**デフォルトの名無しさん** · 2020/06/11(木) 15:19:33.86

ガチ関数型と違って難しいポイントはただ複雑なだけなので、頭悪くても慣れさえすればマウンティングしやすいのが人気の理由だと思ってる

**デフォルトの名無しさん** · 2020/06/11(木) 17:27:55.76

「一番愛する言語」と聞かれたら、C++もC#もJSもPythonも全面的に好きで
使ってるわけではないから、消去法でRustを選ぶしかない。
そもそも愛すべき言語なんて一般人にはあるわけ無いし。
Rustだったら「愛すべき」と公表しても馬鹿にされないで済むみたいな。
他のどの言語を選んでも、白い目で見られそうだから。

**587** · 2020/06/11(木) 17:33:10.59

ドキュメントを眺めてたら >>587 は Nightly ではこんな感じで書けるかなって思った。

https://play.rust-lang.org/?version=nightly&;mode=debug&edition=2018&gist=75b0cca2f785445e707b113c1bce3b55

**デフォルトの名無しさん** · 2020/06/11(木) 17:43:19.49

>>774
SOのサーベイのことをいってるなら、あれは別に「愛する言語は何ですか？」というアンケートではないので「愛する」と日本語で考えてもあまり意味ないぞ。

いまRustを使っていて今後も使い続けたいですか？という質問の集計結果をmost loved languageと表現してるだけ。
だから仕事で（嫌々でも）使わざるを得ない言語は低く出るし、Rustみたいに趣味で選んでる言語は高く出るのだろう。

**デフォルトの名無しさん** · 2020/06/11(木) 22:59:22.90

>>776
Rustを愛すると答えた人でも、使っている人は5%程度しかいないと書いてあったから、
「いまRustを使っていて今後も使い続けたいですか？という質問の集計結果」
とは違うはずだ。
使って無い人も「好き」と言えた訳だから。

**デフォルトの名無しさん** · 2020/06/11(木) 23:08:36.19

>>777
ちょっと正確な質問は忘れたけど、
問1 最近よく使う言語はなんですか？
問2 その言語を今後も使い続けたいですか？
みたいな質問で、1でRustと答えた人の86%が2でyesと答えたって話。
（で、その86%ってのが全言語で1位だった）

なので5%の人しか使ってないというのとは別に矛盾しないし、
Rustを使ってない人の意見はそもそも反映されない。

**デフォルトの名無しさん** · 2020/06/11(木) 23:14:58.90

このあたり元のアンケートに答えた人や
SOのレポートを隅々まで読んだ人なら分かるんだけど
ニュースサイトの伝言ゲームで「最も人気のある言語」とかになってしまうと
ものすごく語弊があるんだよな。

**デフォルトの名無しさん** · 2020/06/11(木) 23:41:02.95

>>778
あれ？　
それだと、全体の母集団の中でRustを使っている人が5%ということになってしまい、
「Rustが好きです」、と答えた人でも 95%が使ってないということとは違ってくるよ。

**デフォルトの名無しさん** · 2020/06/11(木) 23:47:20.09

>>780
使ってる人が5%というのは合ってて、
その5%のうちの86%が今後も使いたいってこと。
だからRustを好きな人が多いんじゃなくて、好きな人の割合が高いというだけ。
実際に好きな人の絶対数でいけば、ユーザーの多いPythonとかが圧勝だと思う。

**デフォルトの名無しさん** · 2020/06/11(木) 23:51:33.67

>>781
あなたはもしかして数学苦手ですか？

**デフォルトの名無しさん** · 2020/06/12(金) 02:00:09.52

>>775
Default::default() が panic したときに drop で未初期化領域アクセスして UB になりそう

**587** · 2020/06/12(金) 15:38:31.69

>>783
unwind の段階でってことですか？

**デフォルトの名無しさん** · 2020/06/12(金) 20:41:45.45

>>784
そう
何らかの工夫を入れないといけない気がする

**デフォルトの名無しさん** · 2020/06/12(金) 22:06:49.25

要素がMaybeUninitなので未初期化領域にアクセスすることはないだろうけど、逆に初期化済みの領域が解放されずに残るような？

**587** · 2020/06/12(金) 22:21:06.94

>>786
panic したときのことなので UB でさえなければメモリが解放されないのは問題にならないと思いますが。

**デフォルトの名無しさん** · 2020/06/12(金) 22:37:53.36

copylessっつうcrateがあるからそれ使うか参考にするといいかもよ

**デフォルトの名無しさん** · 2020/06/13(土) 09:06:43.07

>>783
Default::default() が panic起こす実装してるからUB以前にそこを直すべきだと思うけど違う？

**デフォルトの名無しさん** · 2020/06/14(日) 08:51:59.74

playgroundで手続きマクロ書きたいんだけど
#![crate_type="proc-macro"]
で出来なくてCargo.tomlも触れないから変更出来ないんだけどどうやっても触れない？？

**デフォルトの名無しさん** · 2020/06/16(火) 19:24:13.66

弱参照を多用する人っていないの？unsafeが基本？

**デフォルトの名無しさん** · 2020/06/18(木) 05:25:57.31

Rust楽しい言語だな
https://github.com/rust-random/rand/blob/2c2fbd6463bb3dba492d0387f05f953bdc297d2f/rand_chacha/src/chacha.rs#L32

**デフォルトの名無しさん** · 2020/06/21(日) 01:44:24.45

こういうコードを書いててどこを直せばいいかわかんないので教えてーー

https://play.rust-lang.org/?version=stable&;mode=debug&edition=2018&gist=4ce583191e5b07279b8ec65ef5198456

AddAssign の型引数のところに与えてるライフタイムがおかしいとは思うんだけど、
どう直せばいいかわかんない。
この書き方だと += の左辺以上の寿命を右辺が持ってるという意味になるの？

**デフォルトの名無しさん** · 2020/06/21(日) 20:32:40.47

あんまり詳しくないけど、ライフタイムのその書き方でエラーなるってバグじゃない？（推論力の問題？）
個人的に気になるから詳しい人教えて欲しいな

一応これで治るけど
impl<T: AddAssign<T> + From<usize> + Clone> Iterator for Fibonacci<T> {
type Item = T;
fn next(&mut self) -> Option<T> {
swap(&mut self.f0, &mut self.f1);
self.f1 += self.f0.clone();
Some(self.f0.clone())
}
}

**793** · 2020/06/21(日) 21:05:29.71

デフォルトで usize を基礎に据えているんですが、 BigUint なども効率的に扱いたいので
clone はなるべく少なくしたいという意図で参照で受け取る AddAssign を前提にしたいんですよね……。

**デフォルトの名無しさん** · 2020/06/21(日) 22:00:26.97

>>793
これでどう？

impl<T> Iterator for Fibonacci<T>
where
T: From<usize> + Clone,
T: for<'a> AddAssign<&'a T>