Rust part11

**デフォルトの名無しさん** · 2021/06/17(木) 00:24:12.56

公式
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/

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

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

**デフォルトの名無しさん** · 2021/07/27(火) 23:18:47.62

文は()という単純なルールを崩してまで式文から値を得たいモチベーションがよくわからん
単に;を取って式にすればいいだけなのに

**デフォルトの名無しさん** · 2021/07/27(火) 23:20:35.98

Rust書いてて式と文を意識して区別しないといけないことなんて無いよ
CやPythonならあるけど

**デフォルトの名無しさん** · 2021/07/27(火) 23:30:43.54

関数末尾だけセミコロン外すのが気に入らないなら、C/C++でやってたようにreturn x;とすればいい
それで不都合を生むことはない

**デフォルトの名無しさん** · 2021/07/28(水) 00:01:15.04

clippy先生に注意される

**デフォルトの名無しさん** · 2021/07/28(水) 01:30:00.88

全てはclippy先生の仰せのままに

**デフォルトの名無しさん** · 2021/07/28(水) 01:47:51.35

#![allow(clippy::foo)] を書けばいいじゃん

**デフォルトの名無しさん** · 2021/07/28(水) 04:09:34.57

なるほど

＞Rustのセミコロンは意味と構文からそれぞれ説明できる。
＞意味論的には、以下の原則を覚えておけば十分である。
＞
＞・セミコロンで終端された文は強制的に () 型となる。
＞・ブロックの途中の文は () 型でなければならない。
＞・ブロックの型はブロックの最後の文の型と等しい。(文がひとつもない場合は ())

**デフォルトの名無しさん** · 2021/07/28(水) 07:29:31.85

＞・ブロックの途中の文は () 型でなければならない。

これがあるから1行目の仕様なんだろうけど、これの理由ってなんなのかな。

**デフォルトの名無しさん** · 2021/07/28(水) 08:03:12.35

文に型なんてないよ

**デフォルトの名無しさん** · 2021/07/28(水) 08:14:26.64

文って値を返さないのかと思ってたけれど、
()を返してるって事？

**デフォルトの名無しさん** · 2021/07/28(水) 08:37:40.51

ブロックの型はブロックの最後の「式」の型と等しい。(「ブロックの最後に式がない」場合は())

ここの間違いが他のすべての説明によく分からない辻褄合わせを持ち込んでいるだけだと思う

**デフォルトの名無しさん** · 2021/07/28(水) 09:58:43.22

>>437
＞・ブロックの途中の文は () 型でなければならない。

そもそもブロックの途中の文を()以外にすることってできるの？
{ foo; bar } みたいなブロックを{ foo bar }とは書けないし

**デフォルトの名無しさん** · 2021/07/28(水) 10:29:08.57

>>442
それは型の問題以前に文法の問題

型だけの問題だというなら、{ let foo = (); foo bar }と書けばコンパイルできるはずだが、
もちろんそんなことはない

**デフォルトの名無しさん** · 2021/07/28(水) 11:58:08.16

Facebook、次期ビルドシステムの開発でRust言語の採用を明らかに
https://www.publickey1.jp/blog/21/facebookrust.html

**デフォルトの名無しさん** · 2021/07/28(水) 11:59:44.89

>>443
文法の問題を解決しつつブロックの途中の文を（）以外にする方法がわからんってことよ

**デフォルトの名無しさん** · 2021/07/28(水) 12:46:01.08

>>445
何度でも言う
文に型はない

**デフォルトの名無しさん** · 2021/07/28(水) 12:58:11.75

「文を()にする/()以外にする」の正確な意味を言語化してほしい
「文が評価されて結果として()/()以外が得られる」という意味で言っているのなら、文は評価されて結果を返すものではない
評価されて結果を返すものは式と呼ばれる
文は式ではない

**デフォルトの名無しさん** · 2021/07/28(水) 13:10:10.87

>>447
俺もそのへんはよくわからんが、
式文は「文が評価されて結果として()が得られる」って認識で使ってた
これが誤りならまあすまん

ここにこだわるつもりは全然なくて、
ようするに>>437の「ブロックの途中の文は () 型でなければならない。」ってのがどういうこっちゃってこと
この表現だと() 型じゃなくする方法があるように読めるからさ

**デフォルトの名無しさん** · 2021/07/28(水) 13:12:38.58

この一連の議論の評価値は ()

**デフォルトの名無しさん** · 2021/07/28(水) 13:27:20.45

>>448
自分は>>441で書いた通りその部分は辻褄合わせだと思ってるよ

まあでも、自分もRust入門したころは似たようなことでこんがらがってたような気はする
ブロックが式だなんて思ってなかったからかな

**デフォルトの名無しさん** · 2021/07/28(水) 14:29:43.24

>>449
コンパイルエラーだよ

**デフォルトの名無しさん** · 2021/07/28(水) 14:52:26.31

セミコロン省略できる式文(?)の型が()ではない場合は型エラーになるね
https://play.rust-lang.org/?version=stable&;mode=debug&edition=2018&gist=85e09ac464b7f9fb07b6aa1e2d08e8c9

セミコロンをつけたり、型を()にしたりするとエラーにならない
https://play.rust-lang.org/?version=stable&;mode=debug&edition=2018&gist=4e4152ae35e8fd2821060f44ed9a2fda
https://play.rust-lang.org/?version=stable&;mode=debug&edition=2018&gist=86429babc54c38b515dfe1f9de85f127

**デフォルトの名無しさん** · 2021/07/28(水) 17:33:51.84

最も単純化してこれはコンパイル通るけど
fn main() {
　if true {
　　1
　} else {
　　0
　};
　()
}
しかし上記のifの尻のセミコロン無しだとコンパイルエラー【値が()ではない】となる
セミコロン無しでも数字1と0を()へ変えればコンパイルが通る

つまり
>>437
＞・ブロックの途中の文は () 型でなければならない。

ifをセミコロン無しで値が数字だと上記の条項を満たせないためエラー
ifをセミコロン無しで値が()だと上記の条項を満たせる

あるいは
＞・セミコロンで終端された文は強制的に () 型となる。

値が数字でもifをセミコロン終端させれば上記の条項を満たせる

**デフォルトの名無しさん** · 2021/07/28(水) 17:46:15.09

で？って感じだけど
とりあえずリファレンス見てくれば？
https://doc.rust-lang.org/reference/expressions/block-expr.html

**デフォルトの名無しさん** · 2021/07/28(水) 18:03:06.43

>>454
そのリファレンスの説明だけだと
以下はコンパイル通るけど、関数内の3つの()のうち任意の1つでも数値に変えるとコンパイルエラーとなる説明はどの部分になる？

fn main() {
　if true {
　　()
　} else {
　　()
　}
　()
}

**デフォルトの名無しさん** · 2021/07/28(水) 18:13:09.38

今問題になってるのはこっちだね
最後の方に「;省略した式文は()でないといけない」となっている
https://doc.rust-lang.org/reference/statements.html

**デフォルトの名無しさん** · 2021/07/28(水) 18:38:39.95

>>455
Note: As a control flow expression, if a block expression is the outer expression of an expression statement, the expected type is () unless it is followed immediately by a semicolon.
https://doc.rust-lang.org/reference/expressions/block-expr.html

An expression that consists of only a block expression or control flow expression, if used in a context where a statement is permitted, can omit the trailing semicolon. This can cause an ambiguity between it being parsed as a standalone statement and as a part of another expression; in this case, it is parsed as a statement. The type of ExpressionWithBlock expressions when used as statements must be the unit type.

When the trailing semicolon is omitted, the result must be type ().
https://doc.rust-lang.org/reference/statements.html#expression-statements

あとif式はifのブロックとelseのブロックで型が揃ってないとだめだよ

**デフォルトの名無しさん** · 2021/07/28(水) 20:25:06.81

>>440
「値を返さない」と「()を返す」は同義だと思う。

**デフォルトの名無しさん** · 2021/07/28(水) 20:32:49.95

>>458
値を返さないことはnever typeとして別途定義されてるから()を返すこととは違うよ

**デフォルトの名無しさん** · 2021/07/28(水) 21:30:00.41

never は値どころか制御も返さないから別物では？
()を返す(値は返さない)ことはできるけど、neverは返すことも不可能だと思う。

**デフォルトの名無しさん** · 2021/07/28(水) 21:34:29.80

>>455
2つのエラー要因がある
ifは式(rustでは式文と呼ぶのか)なので、then節とelse節が同じ型でないといけない
mainはTerminationトレイトを実装していないといけないので最後の()は数値にできない

**デフォルトの名無しさん** · 2021/07/28(水) 21:51:43.19

>>458
値を返さない、という言葉が今この場では曖昧に見える
本当にrustが値を返すものじゃない、と定義しているのは文法レベルで定義しているのはletや関数定義などの文
これは型チェック入る前にエラーになる

文法的に正しい、けど「値を返さない型」としか呼べないような式も存在して、それはrustだとnever type (!) と呼んでいる
loop {} とかif true { return 10} else { return 0 }とか、こいつらは式だけど決して値にならない

**デフォルトの名無しさん** · 2021/07/28(水) 23:11:13.67

>>458
違うって
何回も指摘されてるやん

**デフォルトの名無しさん** · 2021/07/28(水) 23:15:38.71

>>461
じゃあどうしてこれがコンパイルエラーとなるの？
fn main() {
　if true {
　　1
　} else {
　　0
　}
　()
}

**デフォルトの名無しさん** · 2021/07/28(水) 23:25:02.98

The syntax for a block is {, then any inner attributes, then any number of statements, then an optional expression, called the final operand, and finally a }.
The type of a block is the type of the final operand, or () if the final operand is omitted.
https://doc.rust-lang.org/reference/expressions/block-expr.html

let foo = { fn_call(); }; // final operandがないのでブロックの型は()
let bar = { fn_call() }; // final operandがあるのブロックの型はfn_call()の型

式文が()を返すわけじゃない

**デフォルトの名無しさん** · 2021/07/28(水) 23:28:39.35

>>464
fn main() {
　if true { 1 } else { 0 } // <- 式。文法的にfinal operand以外は文じゃないとダメ。if式の型が()の場合のみセミコロンを省略可。
　() // <- final operand
}

**デフォルトの名無しさん** · 2021/07/28(水) 23:34:19.58

>>466
なぜ『if式の型が()の場合のみセミコロンを省略可。』という謎ルールがあるの？？

**デフォルトの名無しさん** · 2021/07/29(木) 00:18:18.96

>>467
使い勝手がいいから

fn main() {
　if true { 1 } else { 0 }
　()
}

↑この`if true { 1 } else { 0 }`に意味ないでしょ？
意味持たせるには`let foo = if true { 1 } else { 0 };`みたいに評価結果の値を何かしら使う形にする必要がある
意味がないけどセミコロンで式文にして「値を無視します」と表明すればエラーにはしない
表明がなければ「お前意味ないことやってるぞ」とエラーにしてくれる

`if condition { println!(“1”) } else { println!(“0”) }`みたいに()に評価されるif式は
副作用を起こしたいケースなので評価結果の値を何かしら使う形じゃなくても意味がある
この使い方の時にセミコロンを必須にすると他言語習得者にとってはめちゃくちゃ使い勝手が悪い

知ってれば役に立つことはあっても普段コードを書く時に意識する必要のないルール

**デフォルトの名無しさん** · 2021/07/29(木) 00:18:47.37

>>467 他の言語での一般的な書き方も出来るようにだと思う

**デフォルトの名無しさん** · 2021/07/29(木) 00:23:32.99

>>467
if式から値が返ってきた場合、次の行まで式が継続するのか;省略なのかが曖昧になるから
()ならそれに対してなにか操作はできないから、式が継続する可能性は消えて、;省略が確定する

**デフォルトの名無しさん** · 2021/07/29(木) 00:27:10.13

>>468
>`let foo = if true { 1 } else { 0 };`

一応補足しておくと↑この場合のセミコロンは文法的にはlet statementのセミコロン

**デフォルトの名無しさん** · 2021/07/29(木) 08:55:08.12

>>470
構文解析フェーズで型を意識してるの？

**デフォルトの名無しさん** · 2021/07/29(木) 22:05:11.47

>>470
こういうことかな
if true { () } else { () } - 2 【値-2】
if true { 1 } else { 0 } - 2 【エラー】
if true { 1 } else { 0 }; - 2 【値-2】
(if true { 1 } else { 0 }) - 2 【値-1】

**デフォルトの名無しさん** · 2021/07/30(金) 02:02:42.06

rust version 1.54.0 リリース

**デフォルトの名無しさん** · 2021/07/30(金) 11:59:34.52

https://twitter.com/mattn_jp/status/1420772207186255880
https://twitter.com/5chan_nel (5ch newer account)

**デフォルトの名無しさん** · 2021/07/30(金) 13:41:26.16

Cは、明確にポインタをつかって書くことで手作業で最適化できるが、
Rustのsafeモードは、見た目は参照もポインタも使わず実体コピーのような
書き方をする。例えば、
let a = Box::new(オブジェクト名:{・・・});
や、
let b = Box::new(オブジェクトを返す関数(・・・));
のように。
これはちゃんとコピーが生じないように最適化されているのだろうか？

C++は、同様の書き方をする場合は、無駄をなくすために例えば、
vector::emplace_back()
なるものがあり、最適化に任さずに明確にコピーを省略するマクロの様な
働きをするらしい。

**デフォルトの名無しさん** · 2021/07/30(金) 14:17:32.88

>>476
あと、C++の場合、
CPerson person = CPerson(・・・);
と書いた場合は、代入にならずに必ず、
CPerson person(・・・);
と書いた場合と全く同様にコンストラクタが呼び出されることが決まっている。
Rustの場合、そういうことが全くドキュメント化されてない。
C++プログラマはそのことを理解しているから高速なコードが書けるが、
Rustは書いてないのでテキトーに書くしかない。
結果、あまり速くないコードになって、しかもどこが原因かも分からなく
なりそう。

**はちみつ餃子** ◆8X2XSCHEME · 2021/07/30(金) 14:26:14.81

>>476
https://doc.rust-lang.org/beta/unstable-book/language-features/box-syntax.html

**デフォルトの名無しさん** · 2021/07/30(金) 14:26:20.43

それよりdropがいつ走るかわからない方が怖いわ

**デフォルトの名無しさん** · 2021/07/30(金) 15:17:37.81

Rustでは、CPersonのメンバ関数 new()の中で Heapにオブジェクトを作る時、
fn new(yyy) {
return Box::new( CPerson {
age: xxxx,
name: xxxx
} );
}
みたいに書くしかないらしい。しかし、C++だと、コンストラクタの中で、
GetSystemModuleName(&name, zzz);
のような書き方も出来る。
何が言いたいかと言えば、Rustだと代入形式でしか書けないので柔軟性に
欠けるということ。

**デフォルトの名無しさん** · 2021/07/30(金) 15:19:00.34

>>478
リンク先間違ってない？

**デフォルトの名無しさん** · 2021/07/30(金) 15:31:40.72

bindings_after_at stableになったのうれしい

**デフォルトの名無しさん** · 2021/07/30(金) 16:14:14.47

>>480
メモリ安全性を保つのが困難になっていくからそれを避ける方法がベストだよ

**デフォルトの名無しさん** · 2021/07/30(金) 16:42:36.73

>>483
なんともなあ。

**デフォルトの名無しさん** · 2021/07/30(金) 16:53:36.97

せっかくだしこっち使ってくれよ
https://mevius.5ch.net/test/read.cgi/tech/1619219089/

**デフォルトの名無しさん** · 2021/07/30(金) 16:58:32.68

>>476
コピーが生じないように最適化される。
つまり、スタック上の一時オブジェクトをヒープにコピーするのではなく、ヒープ上に直接オブジェクトを作成する。

**デフォルトの名無しさん** · 2021/07/30(金) 17:02:02.06

>>480
具体的にこのように書きたいけどエラーになるというRustのコードを示してください。（他の言語のコードは不要）
それによりようやく初めて、何を問題としているのか、何が問題なのか、がはっきりします。

**デフォルトの名無しさん** · 2021/07/30(金) 17:29:20.46

VeqDequeに二分探索実装されてるけどそもそもソートできなくない？？？

**デフォルトの名無しさん** · 2021/07/30(金) 18:21:23.96

>>488
make_contiguousかas_mut_slicesで中身の可変スライスを受け取って
そのスライスのsortかsort_byを使えばソートできそう（試してない）

make_contiguousが本線っぽいからリファレンス読んでくれ

**デフォルトの名無しさん** · 2021/07/30(金) 18:33:31.64

make_contiguousするならそのあとのas_mut_slicesに対して二分探索でよくない？？？？

**デフォルトの名無しさん** · 2021/07/30(金) 19:00:01.19

その辺はもう「お好きにどうぞ」としか言えない

**デフォルトの名無しさん** · 2021/07/30(金) 20:35:47.56

contiguousじゃないがsortされてることが保証されてるケースで使いたいのかね

**デフォルトの名無しさん** · 2021/07/30(金) 21:37:49.30

sort順を壊さない位置に要素を挿入するのにbinary_searchを使う

**デフォルトの名無しさん** · 2021/07/30(金) 21:46:04.82

https://github.com/vojtechkral/rfcs/blob/vecdeque-binary-search/text/0000-vecdeque-binary-search.md#motivation

**デフォルトの名無しさん** · 2021/07/30(金) 23:01:01.92

>>486
オブジェクトを返す関数を Box::new()のパラメータの位置に書いてもそうなるの？

**デフォルトの名無しさん** · 2021/07/30(金) 23:11:44.30

>>477
explicitでなければな

**デフォルトの名無しさん** · 2021/07/31(土) 16:04:12.94

配列の添え字はusize以外も許容してほしいなー

**デフォルトの名無しさん** · 2021/07/31(土) 16:11:02.83

std::ops::Index を実装すればええんちゃう？

**デフォルトの名無しさん** · 2021/07/31(土) 16:31:36.36

>>498
おお、こんなのあるのか。知らなかった。

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

Tokio @tokio_rs
Announcing Axum - An ergonomic and modular web framework that takes full advantage of the Tokio, Hyper, and Tower ecosystem.
https://tokio.rs/blog/2021-07-announcing-axum

**デフォルトの名無しさん** · 2021/08/02(月) 10:51:16.95

Rocketが統一するんじゃなかったんかい

**デフォルトの名無しさん** · 2021/08/02(月) 11:07:27.91

axumはシンプルかつ洗練されており柔軟性もあって、よりRustっぽい
それでいてtokio直轄だから今後の主流になりそう

**デフォルトの名無しさん** · 2021/08/02(月) 11:09:36.24

actix-webと比較するとどう？

**デフォルトの名無しさん** · 2021/08/02(月) 11:22:47.21

asyncも結局Tokioが覇権になるんかな？

**デフォルトの名無しさん** · 2021/08/02(月) 11:40:06.27

高収入エンジニアは「ラスト」に注目、ファインディ調査：日本経済新聞
https://www.nikkei.com/article/DGXZQOUC312180R30C21A7000000/

**デフォルトの名無しさん** · 2021/08/02(月) 11:52:00.11

tokio、名前がダサすぎて無理w
async-std勢にもっと頑張ってほしい

**デフォルトの名無しさん** · 2021/08/02(月) 13:37:03.39

どうしても沢田研二を思い出すからな

**デフォルトの名無しさん** · 2021/08/02(月) 13:48:07.46

客の入りが悪くてダサいヤツ

**デフォルトの名無しさん** · 2021/08/02(月) 14:35:12.33

Tokioの名前の由来って普通に東京の可能性があるのか

＞I enjoyed visiting Tokio (Tokyo) the city and I liked the "io" suffix and how it plays w/ Mio as well. I don't know... naming is hard so I didn't spend too much time thinking about it.

https://www.reddit.com/r/rust/comments/d3ld9z/how_tokio_crate_got_its_name_like_that/

**デフォルトの名無しさん** · 2021/08/02(月) 18:57:04.81

axumのimpl IntoResponseとかはaxcixより命名規則とかディレクトリ構造とかよかったけどappの組み立て方が微妙だなー
n-texとかがかなりいいよね

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

tokioは問題のある挙動が発覚しそうで嫌

**デフォルトの名無しさん** · 2021/08/02(月) 23:22:29.33

async-stdなら発覚しない？

**デフォルトの名無しさん** · 2021/08/03(火) 05:46:07.98

ランタイムはasync-std, tokio, actixの3系統という認識であっていますか？
今回は組み込みとか除外で、ウェブ使う前提での根幹の非同期ランタイムに限る話として。
それぞれの系統のデメリットは何ですか？

**デフォルトの名無しさん** · 2021/08/03(火) 10:52:22.44

actixは内部でtokio使ってるから実質tokio

**デフォルトの名無しさん** · 2021/08/04(水) 05:06:56.84

ここ反tokio派が多いようなので
見習ってasync-std派になろうと思います
デメリットなどあれば教えてください

**デフォルトの名無しさん** · 2021/08/04(水) 13:06:46.39

ワタシはtokio派

**デフォルトの名無しさん** · 2021/08/04(水) 13:23:10.51

どうせ遊びコードだろうしどれでもいっしょだろ

**デフォルトの名無しさん** · 2021/08/04(水) 14:08:55.46

遊びコードなら非同期なんか要らないだろ
同期処理のフレームワークにしとけ

**デフォルトの名無しさん** · 2021/08/04(水) 14:41:35.72

tokioは巨大な一枚岩になっていて方針がおかしくね？

**デフォルトの名無しさん** · 2021/08/04(水) 18:03:25.14

smolってどうなの

**デフォルトの名無しさん** · 2021/08/05(木) 00:05:10.42

>>520
smolはasync-ioやasync-fsやasync-netやasync-executorなどの親分だね
それらsmolのサブクレートであるasync-*シリーズはsmol以外のところでも使われてる

**デフォルトの名無しさん** · 2021/08/05(木) 06:32:52.89

RustではじめるWebAssembly入門～JavaScriptを超える高速なWebアプリ開発を実践しよう
https://codezine.jp/article/detail/14567

**デフォルトの名無しさん** · 2021/08/05(木) 22:19:57.77

昔はtokioも同じように多数のtokio-xxxから成り立っていた
しかしどんどん合併していき巨大な一枚岩tokioになってしまった

**デフォルトの名無しさん** · 2021/08/05(木) 23:44:46.85

最終的に各機能は連携するので整合性を維持したまま保守し続けることを考えたら
全体でひとつのパッケージにしてしまうのが楽というのはわかる。

**デフォルトの名無しさん** · 2021/08/06(金) 00:29:20.56

featureで機能on/offするtokio方式の方が使う側も楽では

**デフォルトの名無しさん** · 2021/08/06(金) 05:47:54.70

>>520
smolもasync-stdもStjepan Glavinaが立ち上げた
だからasync-ioなど両者共にベースとしている

**デフォルトの名無しさん** · 2021/08/07(土) 08:24:17.06

オライリーの本で勉強始めたんだが、説明なしにいきなりSomeとか出てきてもやもやしながら読み進んでいる。
索引にも見つからないし。この本のどこかにSomeの説明があるなら誰かページ数教えて。

**デフォルトの名無しさん** · 2021/08/07(土) 08:54:25.11

Somewhere
言いたかっただけだから叩かないで蹴らないで

**デフォルトの名無しさん** · 2021/08/07(土) 09:03:20.19

わいの持ってるオライリーの『プログラミング Rust』だと27ページ（§2.6.1）でOptionの説明してる

**デフォルトの名無しさん** · 2021/08/07(土) 09:03:35.46

索引に「Option<&T>」はない?

**デフォルトの名無しさん** · 2021/08/07(土) 09:10:40.92

同じ本です。そこで使っているSome(T)の説明がなかったので。
文脈からするとT型の値を持っている何かなんだろうけど、正体がわからないのがもやもやして。