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/12(火) 19:18:36.86

>>524
その場合、今の文法でmut &i32と書くケースはどうすべきなの？
そこだけ変えちゃうと、全体的に整合性が取れなくなるのではないかと思うけど。

**デフォルトの名無しさん** · 2020/05/12(火) 21:20:08.42

>>525
今の文法でmut &i32と書くケースは無いよね？

`let x: &mut &i32`って書くべきケースのことなら
`let x: mut &&i32`になるんじゃない？

**デフォルトの名無しさん** · 2020/05/12(火) 21:34:24.99

>>526
確かに勘違いしてた。今の文法だとmut x: &i32だった。
なので今は
x: &mut i32
mut x: &i32
を
x: mut &i32
mut x: &i32
にしても別に問題はないのか。なんとなく両者の区別はしにくくなってる気はするけど。

**デフォルトの名無しさん** · 2020/05/12(火) 21:45:24.39

>>521
パース負荷はおいておいて、mut i32ってかいてあったら普通にコンパイルエラーでよくないか？
エラーの親切さはRustの特徴だし。
mut 書いてる時点で参照なのは当然なんだから書き忘れってすぐわかるじゃん
それに語彙的にmutable referenceとも一致して自然だから前から疑問だった

>>526 のパターンとかも今までの書き方だとかなり読みにくいよね

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

本当の理由は知らないけど、その区別しにくくなるってところがポイントだったんじゃないのかな

mut i32はコンパイルエラーだろうけど、今はエラーメッセージ見ても
&mutがあれば型、mutがあれば変数のmutabilityって詳細読まなくてもすぐ分かる

慣れかもしれんが俺は今の文法のほうが読みやすいと感じる
let mut x: &mut &i32
let mut x: mut &&i32

let mut x: &mut &mut i32
let mut x: mut mut &&i32

**デフォルトの名無しさん** · 2020/05/12(火) 22:08:09.55

tokio使ってる人いる？

**デフォルトの名無しさん** · 2020/05/12(火) 22:36:30.89

>>530
使いたくなくてもネットワーク使うcrateがtokioにべったり依存してて
非同期にこだわる意味ないアプリでも使わざるを得なくなるのがRustのダメなとこ

**デフォルトの名無しさん** · 2020/05/13(水) 00:29:51.86

actix-webでも中で使ってるしtokio単体でも使ってる

**デフォルトの名無しさん** · 2020/05/13(水) 01:28:10.47

非同期に拘らないならstd::net使えばよくない

**デフォルトの名無しさん** · 2020/05/13(水) 14:58:18.04

今の主流は tokio か async-std だけど io-uring 対応でまた勢力図に変化が起きたりするのだろうか

**デフォルトの名無しさん** · 2020/05/13(水) 22:46:58.63

乗り遅れた。
tokioは使ってないけどデスクトップでnon-blocking file ioが欲しい。ブロックしたら並列の意味がない。

>>531
ランタイムと付いてくるapiで肥大化するのが問題なんだよね。

**デフォルトの名無しさん** · 2020/05/14(木) 04:55:54.76

cargo clippyが通ってcargo buildが失敗するケースってある？

**デフォルトの名無しさん** · 2020/05/14(木) 09:41:17.62

望まぬ非同期は一応 tokio::runtime::current_thread::block_on_all() で回避できるか
それでもビルドが一気に遅くなる

**デフォルトの名無しさん** · 2020/05/14(木) 15:47:47.58

>>536
リンクでエラーになる場合とかはある

**デフォルトの名無しさん** · 2020/05/14(木) 18:17:46.89

なるほど

**デフォルトの名無しさん** · 2020/05/14(木) 21:36:47.59

日本のRust界隈で有用なRust関連のツイートしてる人教えて

**デフォルトの名無しさん** · 2020/05/14(木) 23:31:33.96

おれおれ

**デフォルトの名無しさん** · 2020/05/15(金) 09:40:19.45

鷺

**デフォルトの名無しさん** · 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