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/05/16(土) 07:49:09.76

io-uringと今までの非同期処理の違いってなに？
パフォーマンスそれほど変わるもんなの

**デフォルトの名無しさん** · 2020/05/16(土) 22:12:40.61

スレチ

**デフォルトの名無しさん** · 2020/05/18(月) 04:57:51.24

返り値に &'static str ってライフタイム指定ないといけないけど、推論だけで解決できない問題があるから書かないといけないの？
Stringからderefで生成した&strでも結局はIO以外で来たStringは'staticでしょ？推論できそうだけど

**デフォルトの名無しさん** · 2020/05/18(月) 23:19:03.18

>>540
てらモス

**デフォルトの名無しさん** · 2020/05/19(火) 03:57:06.17

IO以外で来たString、つまりコンパイル時に計算しろってことやな！
let mut string = String::from("abcde");
if long_long_time_consume() != 0 { string.insert(0, 'c') }
require_static_str(&string); // require_static_str : &'static str -> ()
というコードが正しいかどうか、実際に長い長ーい計算しないと分からないけどできるならやれってことやな！絶対使わんわ！

**デフォルトの名無しさん** · 2020/05/21(木) 00:27:51.21

paizaにRustの問題ないのつら

**デフォルトの名無しさん** · 2020/05/21(木) 13:46:29.84

競技プログラミングだとアルゴリズムの理解はともかく言語機能の活用は必ずしも身につかないしなぁ……。

Rust のようなプログラミング言語はいかにして抽象化層を構築するか、
いかにしてミスを防ぐか、
そのために必要なのはどんな機能かに意識が割かれたデザインが多いので、
手早くやることが正義の競技プログラミングではマッチしない。

ステップアップには良いかもしれんが、初心者向けには各言語向けの課題が欲しいよね。

**デフォルトの名無しさん** · 2020/05/21(木) 19:20:37.36

enum MyEnum {
Foo,
Bar,
Baz,
}

のようなデータを載せないシンプルなenumで
Clone/CopyやPartialEq/Eqなどを実装しない場合ってどんな意図があったりするの？

**デフォルトの名無しさん** · 2020/05/21(木) 19:32:35.91

意図もクソも本来の普通のenumだろ
値そのものに特に意味がなくて、複数のオプションを区別するためだけに使う単なる定数

**デフォルトの名無しさん** · 2020/05/21(木) 19:52:52.75

ただのサボりだろ、省略することに意図なんて無い

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

Rc<Hoge>のHogeの参照を取りたいとき &*rc_hoge とするのと rc_hoge.as_ref() とするのとどっちがおすすめ？

**デフォルトの名無しさん** · 2020/05/22(金) 01:00:57.91

>>551
同意

**デフォルトの名無しさん** · 2020/05/22(金) 09:19:49.56

>>551
順序に意味はなくていいが、
Copy は出来て欲しーーってワイは思うやで。

**デフォルトの名無しさん** · 2020/05/22(金) 20:50:02.94

enumだけ勝手にCopyついてるとか嫌すぎて草

>>553
as_ref()

**デフォルトの名無しさん** · 2020/05/22(金) 21:08:41.77

non_exhaustive で pub な enum は勝手に Copy になると意図せぬ破壊的変更を起こしやすくなってしまう

**デフォルトの名無しさん** · 2020/05/22(金) 21:09:50.79

>>553
Hoge が AsRef 実装してるかもしれないから Rc::as_ref か &*

**デフォルトの名無しさん** · 2020/05/22(金) 21:16:35.95

最近ずっと弄ってるけどRust難しいのう・・・

**デフォルトの名無しさん** · 2020/05/23(土) 09:31:16.71

C++がそうだからとかの理由はなしで
[[[i32; 3]; 3]; 3]
がなんで
[3; [3; [3; i32]]]
じゃないの？
行列の時かなり読みにくいしさ

**デフォルトの名無しさん** · 2020/05/23(土) 12:43:47.04

なしでと言うかC++erが記法にノイズを持ち込んでるのは明らかなんだが

**デフォルトの名無しさん** · 2020/05/23(土) 15:44:24.84

>>560
それって型としては [[[i32]]] なんでしょ？
大きさの情報は後付けというか、
補足的なニュアンスを感じるので後にくるのが自然だと受け入れてる。
実際のところはどういう議論があったのか知らんけど。

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

>>561
じゃあこの型をRustに持ち込んだのはC++erのMozilla社員ってこと？

>>562
その型はスライスだから全く別。しかも&もないからそんな型ない

**デフォルトの名無しさん** · 2020/05/23(土) 22:35:14.94

let x = Box::new(String::from("foo"));
let y = *x;

これyにmoveできるの入門ドキュメントで説明されてなかったから結構驚いた

**デフォルトの名無しさん** · 2020/05/23(土) 23:03:55.77

>>563
>その型はスライスだから全く別。しかも&もないからそんな型ない
rustのドキュメントも混同しまくってるけど[T]はDSTのarrayで&[T]がDSTのarrayの借用（スライス）だぞ。

>>564
Boxのrustdocに書いてある

**デフォルトの名無しさん** · 2020/05/24(日) 01:52:15.18

>>565
[[[i32; 3]; 3]] は存在できるが [[[I32]]] は存在できない
配列の要素毎にサイズが可変となってしまう

**562** · 2020/05/24(日) 09:30:45.62

>>566
スライスにとって要素の数の情報は動的なもの (実質的に fat pointer) で
配列にとっての要素の数は型の一部ってこと？

**デフォルトの名無しさん** · 2020/05/24(日) 17:28:53.26

>>567
そういうこと
もっと言うと [T] の要素数情報は配列自体ではなく配列への参照 (fat pointer) が保持してるから
[T] が単独で存在することはできなくて、
参照経由の &[T] やスマートポインタ経由の Box<[T]>, Rc<[T]> といった形でしか存在できない

**562** · 2020/05/24(日) 17:59:17.80

>>568
そういうことか。
fat pointer を基礎に据えることを除けば
C/C++ のルールとかなり似てるのでわかりやすいな。
(けどそれ故に C/C++ 的な考え方に引きずられてしまう部分もある……。)

**デフォルトの名無しさん** · 2020/05/24(日) 20:09:44.60

言いたい事は理解できるが
存在できないって言い方は少し引っかかる

**デフォルトの名無しさん** · 2020/05/24(日) 23:17:03.73

6月号で特集が組まれてます
初心者の方は是非

**デフォルトの名無しさん** · 2020/05/24(日) 23:36:35.12

なにこれどうなってるの？traitでFizzBuzz？
https://github.com/doctorn/trait-eval

**デフォルトの名無しさん** · 2020/05/25(月) 09:27:38.21

traitのFizzbuzzに付属してるtrait群がいいね。From実装してなくて爪甘いけど

**デフォルトの名無しさん** · 2020/05/25(月) 22:39:28.81

>>566
>[[[i32; 3]; 3]] は存在できるが
unsizedだからできない。
というか存在はしてる。rustはリージョンでメモリ管理するからコンパイル時に
リージョンのサイズが分かる必要があるからDSTが第一級じゃないだけ。
スライスにすればそのスライスのサイズはusize*2だからzoneを確保できるだろ。
コンパイル時にポインタのサイズが分かれば良いだけだから

assert_eq!(::std::alloc::Layout::new::<*const [u64]>(), ::std::alloc::Layout::new::<&[u64]>());

は通る。the bookとnomiconよめ。

**デフォルトの名無しさん** · 2020/05/26(火) 01:25:10.52

>>540
https://search.yahoo.co.jp/realtime/search?p=Rust

**デフォルトの名無しさん** · 2020/05/26(火) 09:22:21.48

>>574
(要素数と要素サイズがコンパイル時で既知である必要があるarrayの形では)存在できない
と読んでくれ

**デフォルトの名無しさん** · 2020/05/26(火) 12:44:21.66

::stdの指定の仕方ってなんで使うの？stdじゃなくて
自作のmod std作った時にしか被らないぐらいしか利点なさそう。しかもそんな紛らわしい名前で作らないし

**デフォルトの名無しさん** · 2020/05/26(火) 23:26:23.63

他の crate に公開するマクロで使う

**デフォルトの名無しさん** · 2020/05/26(火) 23:27:54.23

std以外のcrateにも使えるから、モジュールとの名前かぶりで使わざるを得ないときもある
testとか

**デフォルトの名無しさん** · 2020/05/27(水) 10:28:00.44

2018の次期バージョンっていくつ？

**デフォルトの名無しさん** · 2020/05/27(水) 11:01:45.48

>>580
Prepare for a possible Rust 2021 Edition
https://github.com/rust-lang/rfcs/blob/master/text/2857-roadmap-2020.md

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

pub enum KansaiPref {
Osaka,
Hyogo,
Kyoto,
}
こういうenumを文字列から生成する時ってnewよりfrom_strで作った方がいいの？

impl KansaiPref {
fn new(s: &str) -> Self {
use Self::*;
match s {
"大阪" => Osaka,
"兵庫" => Hyogo,
"京都" => Kyoto,
_ => unimplemented!(),
}
}

newかfrom_str

impl FromStr for KansaiPref {
type Err = ...;
fn from_str(s: &str) -> Result<Self, Self::Err> {
use Self::*;
match s {
"大阪" => Osaka,
"兵庫" => Hyogo,
"京都" => Kyoto,
_ => unimplemented!(),
}
}
}

**デフォルトの名無しさん** · 2020/05/28(木) 10:15:20.06

>>582
どっちでもいいと思うけど自分ならfrom_str選ぶ
理由はenumをnewするのにResult(かOption)が返されるシグニチャよりも
input.parse::<KansaiPref>()してResultが返されるほうが意図が伝わりやすいから

**デフォルトの名無しさん** · 2020/05/28(木) 12:26:13.92

>>582
俺は初心者だから意見としてはそれほどあてにならないけど、
from_str を使った方がいいと思う。
new はただの習慣だが FromStr は制約として機能するので、
既存の枠組みの中で便利に機能する可能性がある。

**デフォルトの名無しさん** · 2020/05/28(木) 22:03:56.44

多言語展開を考えるとどれも使いたくねえな…と思ってしまう

**デフォルトの名無しさん** · 2020/05/29(金) 07:36:25.48

FromStr実装するならちゃんと Err 返してくれ

**デフォルトの名無しさん** · 2020/05/29(金) 16:33:26.54

let a : Box<[T; 1000]> = Box::new([Default::default();1000]);

みたいなのってスタックに要素を作ってからヒープにコピーするようになるから効率が悪いし、
Copy を実装してない型だと使えないみたいなんだけど、これって今はどうするのが常套手段なの？

前提条件として変数の型は Box<[T; 1000]> というのは固定ということにして、
unsafe も避けられるものなら避けたい。

**デフォルトの名無しさん** · 2020/05/29(金) 17:24:59.34

>>587
vec![Default::default();1000].into_boxed_slice();

**デフォルトの名無しさん** · 2020/05/29(金) 21:21:26.13

>>586
標準でString or &str のパース失敗時に返すErrの型とかあんの？

**デフォルトの名無しさん** · 2020/05/30(土) 00:58:42.40

vec! と同じような使い勝手の box! があってもよさそうな気がするけど、
そういうクレートがあったりする？

**デフォルトの名無しさん** · 2020/05/30(土) 01:42:01.99

#![feature(box_syntax)]
let a: Box<[T; 1000]> = box [Default::default(); 1000];

https://github.com/rust-lang/rust/issues/53827

**デフォルトの名無しさん** · 2020/05/30(土) 01:46:59.27

>>591
おおっ、これぞ私が必要としていたもの！

**デフォルトの名無しさん** · 2020/05/30(土) 07:24:57.35

待望の新言語

ZetZ、形式的検証機能を備えたCのダイアレクト
https://www.infoq.com/jp/news/2020/05/zz-formal-verified-c-dialect/

**デフォルトの名無しさん** · 2020/05/30(土) 11:52:22.59

# と #! はどういう使い分けがあるの？

**デフォルトの名無しさん** · 2020/05/30(土) 13:01:17.39

>>594
#は直後の構文要素に対するアノテーションで
#!はそれを含むスコープ全体へのアノテーション。

**デフォルトの名無しさん** · 2020/05/30(土) 15:53:27.03

>>595
Thx

**デフォルトの名無しさん** · 2020/06/01(月) 10:13:32.80

loopとスレッドスリープでやるのもいいけど、いい感じにデーモン立てて一定時間経ったら関数実行してくれるような仕組みのクレートってない？

**デフォルトの名無しさん** · 2020/06/01(月) 10:31:33.62

借用や所有の概念って、Rustがはじめてなのかと思ったら、D言語に既にあったんだね。

**デフォルトの名無しさん** · 2020/06/01(月) 10:51:02.85

>>598
あー。D言語の方がRustを参考に取り入れたらしい。

**デフォルトの名無しさん** · 2020/06/01(月) 11:12:31.20

Rustのヒープは必ず参照カウンタが入ってしまうので、C/C++言語に比べれば遅くなるね。

**デフォルトの名無しさん** · 2020/06/01(月) 11:19:51.79

>>600
Rc以外は参照カウンタ入らないよ。
解放タイミングはコンパイル時に決定するんだからカウンタいらない。

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

>>601
Box<T>も参照カウンタ入ってないの？

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

>>601
それより、参照カウンタが入っているかどうかはどこを読めば分かるの？

**デフォルトの名無しさん** · 2020/06/01(月) 11:35:58.71

C++ vs Rust
unique_ptr<T> ---> Box<T>
shared_ptr<T> ---> Rc<T>
weak_ptr<T> ---> Weak<T>
ということなの？
どこに書いてある？？

**デフォルトの名無しさん** · 2020/06/01(月) 11:37:31.71

>>603
RcやArcのドキュメントにはreference counting pointerと書いてある。
Boxとか入ってないやつにわざわざ入ってないとは書いてないけど。

**デフォルトの名無しさん** · 2020/06/01(月) 11:40:30.85

let a = 7;
let a_box: Box<i32>
a_box = Box::new(a+2);　//(3)
という例があったけど、どうして、(3)がエラーにならないの？
mut 属性にしておかなければ、let文でしか代入できないんじゃなかった？

**デフォルトの名無しさん** · 2020/06/01(月) 11:43:34.61

>>604
https://doc.rust-jp.rs/book/second-edition/ch15-00-smart-pointers.html

>>606
a_boxは2行目では値が入ってないので、3行目が最初の代入だから変更ではなくmutはいらない。

**デフォルトの名無しさん** · 2020/06/01(月) 11:44:44.94

>>605
C++とは名前が変わっているだけで、>>604という理解でいいわけだね？

**デフォルトの名無しさん** · 2020/06/01(月) 11:49:39.54

>>607
>a_boxは2行目では値が入ってないので、3行目が最初の代入だから変更ではなくmutはいらない。
なるほど、最初かどうかをコンパイラが追跡していたんだね。
知らなかった。
immutableな変数は、必ず let 文でしか代入できないとばかり思っていた。
最初に読んだ documentでは、例としてそう書いてあったから。

**デフォルトの名無しさん** · 2020/06/01(月) 11:51:23.94

>>608
厳密に同じかはわからないけど、対応としては合ってるかと。

**デフォルトの名無しさん** · 2020/06/01(月) 12:19:02.82

「変数のアドレスを他の変数に代入することを借用(borrowing)という」
という理解で有ってる？

**デフォルトの名無しさん** · 2020/06/01(月) 12:37:12.92

ID: o7IiynR8
こいつやべーだろ。なんにも知らないくせにRustのヒープは必ず参照カウンタが入るとか嘘吹かしてんじゃねえか
蓋開けれみりゃ初心者のクレクレゴミだし、どういう自信で最初言ったんだよ

**デフォルトの名無しさん** · 2020/06/01(月) 12:37:39.24

>>611
実態はアドレスだが所有権管理の対象になるのはアドレスではなく参照。

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

コンパイル時に所有権のチェックをしてるってのがよくわかってなくて変なことを言ってるのかもね。
「所有権の移動」が「実行時にアドレスと一緒に所有権が渡される」みたいな認識だとしたら
参照カウンタによって実装されるという ID:o7IiynR8 みたいな言説になるのはわからんでもない。

が、 Rust は静的解析の賢さでメモリの安全性を高めるのがウリのひとつなんだからそんなわけねーだろというくらいには
想像できて欲しいよ。

**デフォルトの名無しさん** · 2020/06/01(月) 13:24:10.03

C++の概念に言い換えて理解しようというのが
そもそも無理筋な気が

**デフォルトの名無しさん** · 2020/06/01(月) 13:41:16.41

説明書読まずにとりあえず人に聞いて教えて貰おうとするやついるよね

**デフォルトの名無しさん** · 2020/06/01(月) 14:10:26.06

所有権回りは Rust の重要な特徴だから
どんな入門書でも書いてないはずはないんだよな。

**デフォルトの名無しさん** · 2020/06/01(月) 14:47:28.60

Rustの普及を阻む課題　年次調査から明らかに
https://www.atmarkit.co.jp/ait/articles/2006/01/news044.html

Rustの利用をやめた回答者にその理由を尋ねたところ「自社がRustを使っていない」という回答が最も多かった。
他の上位の理由は「習得が大変」「必要としているライブラリがない」「移行すると作業能率が落ちる」「IDE(統合開発環境)でのサポートが不十分」などだ。

Rustを利用したことがない回答者に理由を尋ねたところ、「Rustを学んだことがないから。ただし、学びたい」「自社がRustを使っていないから」という回答が、いずれも約4分の1の割合に達し、この2つで回答の過半数を占めた。

Rustの普及拡大への最大の課題として挙げた上位3つは、「トレーニング／ドキュメントの充実」「ライブラリの充実／改善」「IDEの統合」だ。

**デフォルトの名無しさん** · 2020/06/01(月) 15:24:58.77

https://blog.rust-lang.org/2020/04/17/Rust-survey-2019.html

**デフォルトの名無しさん** · 2020/06/01(月) 15:45:21.43

ちょっと変わった傾向だな:

55% of Rust users develop on Linux
24% develop on Windows
23% develop on macOS

**デフォルトの名無しさん** · 2020/06/01(月) 15:59:56.59

間違った知識を他人に教えるのは説明書読む以前の問題

**デフォルトの名無しさん** · 2020/06/01(月) 16:00:16.74

回答者がターゲットとしているプラットフォームも以下の様に書かれているが、回答者がWebBackendを職業にしている人が多いことに対応している可能性が高い :
Linux: 36.9%、
Windows: 16.3%、
maxOS: 14.7%
WebAssembly: 14.4%
Embedded: 7.6%
iOS: 2.9%
BSD: 2.7%
Android: 2.4%

When it comes to what platforms using are targeting for their applications Linux remains the first choice with 36.9%,with Windows as second at 16.3%.
Following close behind Windows are macOS and Web Assembly at 14% each

**デフォルトの名無しさん** · 2020/06/01(月) 17:53:49.92

Some a = xxx; // 何か初期済みであると仮定
let b1 = Box::new(a);
let b2 = b1;
とした場合、b1が持っていた所有権はb2に移ってしまい、
b1はこれ以後使えなくなるという理解で有ってますか？

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

初心者なもので、正しく(?)は、
let b1 = Box<Some>::new();
let b2 = b1;
なのかも知れません。

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

>>623
とりあえずThe Bookの所有権のところを一通り読んでから質問してください
その質問の答えも試し方も全部書いてますので
https://doc.rust-lang.org/book/ch04-01-what-is-ownership.html

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

>>625
そこは一時間ほど前に読みましたが、>>623のことは分からないので質問しました。

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

>>623
お前が正しく理解してるかどうか知らんけど個別の事例として言えば Yes だ。
所有権は移動して、元の変数はもう使えない。

だけどそんなことはやってみたらわかりやすいエラーメッセージが出るじゃないの。

fn main() {
let a = 20;
let b1 = Box::new(a);
let b2 = b1;
println!("{}", b1);
}

みたいなことを書いたら

error[E0382]: use of moved value: `b1`

って出るし、どこでムーブ (所有権の移管) 済みかまでも表示してくれる。
Rust のエラーメッセージはめっちゃ親切なんだから、
「この場合はどうですか」なんて質問する間があったらやってみりゃいいんだよ。

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

Rustのエラーメッセージがすごく親切なのは分かるんだけど、小手先で直そうとするとどんどん修正範囲が広くなっていって最終的に「設計が悪い」みたいな結論になっちゃう
他言語よりコーディング時に考慮すべき点が多いというか違うというか…慣れればそういうことも無くなるのかね

**デフォルトの名無しさん** · 2020/06/01(月) 22:13:40.55

>>628
色々調べてる途中だけど、どうも、C言語で出来ていたことの何割かは
Rustでは禁止されていて出来ないと思う。
https://stackoverflow.com/questions/40875152/reference-to-element-in-vector
を見てもRustではarrayの1つの要素に対する参照は作れないようだし。
C/C++では当然、そのようなものへの参照やポインタが好きなように作れる。
これが出来ないことである種の組み合わせ爆発が起こりがちになり、
C/C++よりプログラムがしにくくなるだろう。

**デフォルトの名無しさん** · 2020/06/01(月) 22:19:12.08

>>729
例えばの話、C言語だと1つのCPerson型のデータをファイルに出力する関数を
void write(FILE *fp, CPerson const *person);
のように作りさえすれば、
CPerson persons[100];
for (int idx=0; idx<100; idx++ ) {
write(fp, &persons[idx]);
}
でCPersonの配列にも対応できてしまう。
このようなことがRustではできなくなるはず。
無理やり観が有るが、CPersonのメンバ関数としてwrite()関数を作ってしまうことで対応できるかも知れない。

**デフォルトの名無しさん** · 2020/06/01(月) 22:50:56.49

rustはまだ勉強中だけど、630がアホなこと言ってるのは俺でもわかる。

**デフォルトの名無しさん** · 2020/06/01(月) 22:53:23.54

ID:T0vrM+QLやID:bf1cRh+Bと同一人物だね

**デフォルトの名無しさん** · 2020/06/01(月) 22:54:16.92

荒らしの相手するやつも荒らし

**デフォルトの名無しさん** · 2020/06/01(月) 23:37:56.02

もうこのスレで公式すら読んでないような初心者質問するやつ無視でよくね。文章から見て同一人物っぽいし
それとそのテンプレ追加も次立てる人お願い >>999

**デフォルトの名無しさん** · 2020/06/02(火) 10:45:35.24

>>629
https://doc.rust-lang.org/1.9.0/book/structs.html
によれば、構造体メンバのアドレスを参照型変数に代入することができるらしい。

**デフォルトの名無しさん** · 2020/06/02(火) 10:57:29.35

diesel辛いっていう人多いけど、乗り換えるならどんなクレートになんだろうね

**デフォルトの名無しさん** · 2020/06/02(火) 11:19:09.02

>>627 >>634
読んでも書いてない。

**デフォルトの名無しさん** · 2020/06/02(火) 19:18:24.00

結局c++やらんとrustを理解するなんて無理なんだよ

**デフォルトの名無しさん** · 2020/06/02(火) 20:16:57.29

>>638
こないだ C++ スレで >>623 の ID は見たぞ。

**デフォルトの名無しさん** · 2020/06/03(水) 02:21:24.02

https://users.rust-lang.org/t/isnt-rust-too-difficult-to-be-widely-adopted/6173/37
↑のサイトに寄れば、Blandy & Orendorff の Programming Rust の
評判が良いらしい：
I’m also new to Rust and have found the “Programming Rust” book by Blandy & Orendorff to be very helpful.
Especially the chapters on ownership and references.
It is an expensive book though.

また、Box<T>, Rc<T>, RefCell<T>は必要ないという見方があるらしい。
最初から用意されているコンテナを使えば十分という意味のようだ :

I also didn’t need Box, Rc, RefCell, or friends.

**デフォルトの名無しさん** · 2020/06/03(水) 02:34:58.13

>>638
(C++は、C++11から大幅に改定されたので)、海外のサイトに寄れば、
C++11より前のC++からRustを学ぼうとすると大変だが、C++11以後
からだと対応関係が分かり易くて楽なのだそうだ。
unique_ptrとBox<T>が対応しているような話か。
ただ、C++の特徴であるtemplateに相当するものがまだRustにはないことが
残念だと書かれていた。

**デフォルトの名無しさん** · 2020/06/03(水) 02:45:19.00

そのサイトに寄れば、Rustで難しいのは、借用や所有の概念ではなく、
lifetimeなのだそうだ。
個人的にも、構造体のlifetimeについて説明不足を感じた。
構造体の変数のスコープと構造体のメタ部分で記述するライフタイムの
関係性がbookなどでは書かれて無いように思えた。
分からんけど。

**デフォルトの名無しさん** · 2020/06/03(水) 02:59:40.24

2018/04 の時点でも、まだ、lifetimeに関する資料が足りてないと感じている人がいたそうだ。
Can we maybe have a book or booklet exclusively covering lifetimes?
I don’t think the first level of instruction material on lifetimes which is found
in the rust book and others which talks about the syntax and the aliasing rules and elision is enough.
It leads to an incomplete model which only frustrates when you discover its incompleteness.
Rust nominoc does go further. For example it shows with detailed examples how lifetimes start with
a let binding and how they interact with other lifetimes in the same scope.
This is fundamental stuff and absolutely essential to understanding.
But there are still aspects not covered there.
For instance I realized that lifetimes can be shrunk as needed by the compiler only from this
forum (thanks @vitalyd) which invalidated my previous model.
And I’m sure there are other aspects I don’t know about.
I think we just need one place where one can learn everything about lifetimes and be done with it.