Rust part12

**デフォルトの名無しさん** · 2021/08/24(火) 22:55:27.78

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

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

**デフォルトの名無しさん** · 2021/09/07(火) 12:42:27.81

nullの可能性がある複数の参照を作りたい場合って
OptionとかRcを組み合わせるの？
縦によも横にもコードが長くなりそう

**デフォルトの名無しさん** · 2021/09/07(火) 13:22:01.93

Option<&T> や &Option<T>でも良いかも知れないけど状況次第
可変参照にしたいなら Rc<RefCell<Option<T>>> とかになるかも

**デフォルトの名無しさん** · 2021/09/07(火) 14:39:19.62

Rustの文化詳しくないけど、null objectは使わないの？
せっかく静的安全性にこだわっているのに、型無しのnullを使うのはこだわりが足りない気がするなぁ。

**デフォルトの名無しさん** · 2021/09/07(火) 15:00:30.72

OptionがあるのにNullObjectいらなくないです？

**デフォルトの名無しさん** · 2021/09/07(火) 15:16:47.38

>>314
見当違い。 >>312 はどこも指さない参照を便宜的に null と言ってるだけで、
実際には代数的データ型を活用して区別しようとしている。

**デフォルトの名無しさん** · 2021/09/07(火) 15:20:59.00

NullObjectは時代遅れ過ぎる

**312** · 2021/09/07(火) 15:36:48.61

>>316
正解

ただし、Rc<RefCell<Option<T>>>とか見ちゃうと
生ポインタにしたくなってくる……

**デフォルトの名無しさん** · 2021/09/07(火) 15:42:12.42

参照をRcするような場面てあんまりないような気がする

ところでRc<RefCell<Option<T>>>は、
参照じゃなくてヒープにある（かもしれない）Tの共有になりませんか

**デフォルトの名無しさん** · 2021/09/07(火) 15:58:38.34

>>319
実体は必ずヒープ上
実体の構造は(強,弱,(借,(Some,T))
そしてそのヒープ上にある実体を指してるポインタはどこにあっても複数あってもよい

**デフォルトの名無しさん** · 2021/09/07(火) 18:22:59.95

>>319
ヒープ上にある RefCell<Option<T>> を共有することになるね
参照 (&T) ではないというのはそう

**デフォルトの名無しさん** · 2021/09/07(火) 19:09:15.95

>>316 >>318
サンクス。JavaのOptionalみたいなものね。

>>317
nullobjectと比較したときのメリットは？
条件分岐を強制させることができることくらいかしらん？

**デフォルトの名無しさん** · 2021/09/07(火) 20:06:06.42

>>322
impl<T> SomeTrait for Option<T> where T: SomeTrait { ... }
ってやれば条件分岐すら自分で書かなくていいよ

**デフォルトの名無しさん** · 2021/09/07(火) 21:28:45.74

>>323
それはTraitのメソッドで分岐相当のコードを書くか
chainさせるだけで分岐処理を遅延するかのどちらかなので
分岐すら自分で書かなくていいというのはちょっと違う気がする

**デフォルトの名無しさん** · 2021/09/07(火) 22:29:28.46

本来はOption/Result/(Either)はRust言語的な仕組みでは無く、ライブラリの作法に過ぎないが、ランタイムが
無いはずなのに、Resultなどで宣言しているところで原則として捕捉しないpanicがあるのは納得できない人は
結構いると思う。言語の構文でmatchや?など、まさにそれのサポート構文があるのに、unwrapしたらpanicで
この話は嫌がる人が結構いるけど、OptionもResultもPanicも取っ払った最小の標準ライブラリが欲しい

**デフォルトの名無しさん** · 2021/09/07(火) 22:45:10.91

>>325
何が言いたいのか分からん

**デフォルトの名無しさん** · 2021/09/07(火) 23:03:38.48

>>325
そこは使い分け。
エラーな時にそのままエラー吐かせても構わない場合は、main()をResult型にしてしまうし、
きちんとエラー処理する必要あるものな場合は、少なくともmain()やそれより下でmatchでResultを必ず受け止める。

**デフォルトの名無しさん** · 2021/09/07(火) 23:11:59.18

>>322
比較すべきものではない
ヌルオブジェクトはインターフェースで型を隠蔽する手法
一方Optionは型をラップすることでエラーを明示する手法
似てるようで根本が違う

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

あと後者の場合、unwrap()も基本的には使わない。
例外的に使うのはフィルタし終えて必ずSome(T)となっているものを剥がす時だけ。
つまりpanicはさせないので、その>>325の懸念事項は発生しない。

**デフォルトの名無しさん** · 2021/09/08(水) 07:19:42.43

素人です、質問させてください
Rustでスマホアプリやwebアプリは作れますか？
作れるとしたら
java/kotlinやswiftやjavascriptより作りやすいですか？
アプリ制作でこれらの言語よりRustは優れてますか？

**デフォルトの名無しさん** · 2021/09/08(水) 07:34:28.50

Rust＋JavaScriptでウェブアプリとそのためのサーバーサイドは作れる
ウェブブラウザ上ではJavaScriptが必須なのでRustだけにはできない
ただしウェブブラウザ上ではJavaScriptに加えてWebAssembly(Wasm)も動いてこれはRustで書いたプログラムが動く
なのでJavaScript部分を最小限にしてRustで書いたWasmがメインというケースもないわけではない
サーバーサイドはRustだけで全て構築できる

**デフォルトの名無しさん** · 2021/09/08(水) 07:48:35.45

ありがとうございました
スマホアプリを作るならKotlinやswiftってことなんですね
大変に参考になりました。ありがとうございました。

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

オマケみたいなもんやな

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

>>332
そんなことはない
スマホアプリならKotlinとSwiftの2種類を無駄に覚えずともJavaScriptだけで両OS向けスマホアプリ作成が可能
もちろんスマホでもウェブアプリが動きアプリの種類によってはウェブアプリで十分なためスマホアプリを作らないケースも出ている

一方でRustで書いてAndroid上でツワモノもいるがそれはおいとくとして
Rustをこの件で使うケースはウェブブラウザで動くWasmのプログラミングする時かサーバーサイド側
あとはGoogleがAndroid OS開発にRustを使い始めた

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

めっちゃWasm使ってるわ、使い心地としてはgoのが良いのだが
てか絶対JS書きたくない勢以外は勧められないけどな
エントリーポイントで4～5行JS書かざるを得ないが、そこはコピペだから俺は1行も書いてない

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

>>335
javascriptからwasmにディスパッチする際のオーバーヘッドってどう？

**デフォルトの名無しさん** · 2021/09/08(水) 19:45:38.33

getopt()みたいなのでRust標準はどのクレイト？

**デフォルトの名無しさん** · 2021/09/08(水) 20:27:20.45

clapだけど、それを使ったさらに便利なstructoptのほうがおすすめかも

**デフォルトの名無しさん** · 2021/09/08(水) 21:24:09.27

clapはv3でstructoptの機能を取り込むから、今ならclapの3.0.0-beta4を使うのでもいいかも

**デフォルトの名無しさん** · 2021/09/08(水) 21:44:07.80

>>339
その後、structoptはどうなるの？

**デフォルトの名無しさん** · 2021/09/08(水) 23:46:53.75

>>339
なるほど
v2のビルダー方式に加えて
v3でマクロ多用で見やすく書きやすくすっきりしたという感じ？

**デフォルトの名無しさん** · 2021/09/09(木) 00:04:52.59

マクロは見やすさだけじゃなくてコンパイル時に諸々チェックされるのが嬉しい

**デフォルトの名無しさん** · 2021/09/09(木) 20:16:33.24

数値の並びがある時に
その中の一番大きなものがある場所(index)が欲しいのですが
Rustではどう書くとよいでしょうか？

**デフォルトの名無しさん** · 2021/09/09(木) 20:38:00.34

>>343
たとえばこう
https://play.rust-lang.org/?version=stable&;mode=debug&edition=2018&gist=c7a0d0459c540d7b373b124d7faf239a

**デフォルトの名無しさん** · 2021/09/09(木) 21:09:46.20

>>344
copied()っているっけ？

**デフォルトの名無しさん** · 2021/09/09(木) 21:32:28.08

ありがとうございます
無しでもいけました

別の質問です
Vecにスライス(の各値のコピー)をappendしたいのですが
append()メソッドはVecしか引数に取れず困っています
どうすればいいでしょうか？

**デフォルトの名無しさん** · 2021/09/09(木) 21:36:39.36

ちったあググれよ
教えて君は嫌われるよ

**デフォルトの名無しさん** · 2021/09/09(木) 21:55:23.66

>>346
https://doc.rust-lang.org/std/vec/struct.Vec.html

**デフォルトの名無しさん** · 2021/09/09(木) 22:34:44.73

>>346
append()はその名前から想像しにくい実はムーブで引数側のVecは空になるｗ
じゃあappendはどうすればいいかというと
1つだけappendするpush()の複数版のpush_all()が元々あって
それは名前変更で今はextend_from_slice()になった
がその中身はより一般化したExtendトレイトのextend()を呼んでるだけになったので
結論としてはv.extend(&a)が正解

**デフォルトの名無しさん** · 2021/09/09(木) 23:25:03.49

Rust 1.55.0 リリース

**デフォルトの名無しさん** · 2021/09/10(金) 01:12:44.66

faqのような気がするんだが、以下のようなコードって
どうすればコンパイル通る？

#[derive (Copy)]
struct St{
s: String
}

fn main(){
let ar = [St{s: String::from("str")}; 10];
}

**デフォルトの名無しさん** · 2021/09/10(金) 01:34:46.88

参照を配列に格納するか
let st = St{s: String::from("str")};
let array = [&st; 10];

Stringじゃなく&strにするか
#[derive (Debug, Clone, Copy)]
struct St{
s: &'static str
}

かな？

**デフォルトの名無しさん** · 2021/09/10(金) 01:38:58.21

>>352
なるほど
勉強になりました
ありがとん

**デフォルトの名無しさん** · 2021/09/10(金) 01:44:26.77

>>351
Stringはヒープ上なのでstructの中でCopyは無理

>>352
そのStringも使わずにこれでいけますね
#[derive(Clone,Copy,Debug)]
struct St {
s: &'static str,
}
fn main() {
let ar = [St {s: &"str"}; 10];
println!("{:?}", ar);
}

**デフォルトの名無しさん** · 2021/09/10(金) 05:44:54.18

もはやご希望のものかどうかはわからんが

#[derive(Clone)]
struct St{
s: String
}

fn main(){
let ar = vec![St {s: String::from("str")}; 10];
}

CopyをCloneして配列をvecにしただけ

**デフォルトの名無しさん** · 2021/09/10(金) 06:59:27.65

>>355
vec!は単なるマクロでVec作ってるだけなので
それだと動的にヒープにString作って
そのVecを動的にヒープに作ってる
一方で>>354はヒープを全く使わないという差ですね

**デフォルトの名無しさん** · 2021/09/10(金) 07:55:51.69

>>354
>そのStringも使わずにこれでいけますね
それ>>352に書いてるのと同じじゃんw

**デフォルトの名無しさん** · 2021/09/10(金) 13:58:45.81

>>351
その後の用途によって7通りのやり方がある

let st = St {s: &"str"}; の場合は
let ar = [st; 10];
let ar = [&st; 10];
let ar = vec![st; 10];
let ar = vec![&st; 10]; の4通りが使い分け可能で
1番目はまとめて let ar = [St {s: &"str"}; 10];
3番目はまとめて let ar = vec![St {s: &"str"}; 10]; と省略可能
2番めと4番目が省略できない理由は参照なのに実体が変数にバインドされていないため

let st = St {s: String::from("str")}; の場合は
let ar = [st; 10]; の1番目だけは出来なくて
let ar = [&st; 10];
let ar = vec![st; 10];
let ar = vec![&st; 10]; の3通りが可能
3番目はまとめて let ar3 = vec![St {s: String::from("str")}; 10]; と省略可能
1番目が出来ない理由はヒープ上に作られるStringを暗黙的にコピーできないため

**デフォルトの名無しさん** · 2021/09/10(金) 15:18:43.49

無駄な長文乙

**デフォルトの名無しさん** · 2021/09/11(土) 02:12:58.97

数百行程度で、Rustらしいコードの例ってありませんか？

**デフォルトの名無しさん** · 2021/09/11(土) 02:31:10.17

>>360
何に使うん？
紹介プレゼンとか？

**デフォルトの名無しさん** · 2021/09/11(土) 02:47:02.21

>>361
学習のために自分で読むだけです

**デフォルトの名無しさん** · 2021/09/11(土) 02:58:05.44

現状はどのレベル？
とりあえず入門書は読み終わったって感じ？

**デフォルトの名無しさん** · 2021/09/11(土) 03:10:01.40

>>362
例えば>>3と>>4にあるRust各book十数個のうちどれくらい読んでみましたか？

**デフォルトの名無しさん** · 2021/09/11(土) 04:59:53.97

ただのコード例ってのとは違うけどこれ読み進めるとかどうだろう
https://rust-unofficial.github.io/too-many-lists/index.html

Linked Listを色々頑張るやつ

**デフォルトの名無しさん** · 2021/09/11(土) 05:21:08.84

>>365
それはあまりにも偏った特殊ケースであることと
初心者向けではないということと
その件だとむしろ標準ライブラリとして提供されているリンクリストや双方向キューを覚えた方が実用的かなーhttps://doc.rust-lang.org/std/collections/

**デフォルトの名無しさん** · 2021/09/11(土) 17:59:37.96

>>349
なるほど

**デフォルトの名無しさん** · 2021/09/11(土) 21:06:20.65

Rustは可読性をもう少し良くできなかったのかな
後発なのにJavaより読みにくいってのは問題だろ

**デフォルトの名無しさん** · 2021/09/11(土) 21:16:46.98

>>368
どのあたりが？

**デフォルトの名無しさん** · 2021/09/11(土) 22:08:56.74

>>368
どうすれば良くなると思う？

**デフォルトの名無しさん** · 2021/09/11(土) 22:10:09.25

>>370
専用フォントを開発

**デフォルトの名無しさん** · 2021/09/11(土) 23:22:27.41

Javaより読みにくいとはさすがに思わんけど、
ジェネリクスが<>囲いなところとか、
そもそも中かっこ＋セミコロンってのもどうなんだ、とか
Haskell並にとは言わんがもうちょっとかっこ少なくかけないのか、とか
思うところはいろいろとある

**デフォルトの名無しさん** · 2021/09/11(土) 23:44:46.13

>>372
ジェネリクスが<>囲いなところ、ってメジャーなプログラミング言語のほとんどがそうだよね？

**デフォルトの名無しさん** · 2021/09/11(土) 23:48:51.34

>>373
その通りだけどあんまり筋がよくないことでもちらほらごく一部の界隈で話題になってるような

**デフォルトの名無しさん** · 2021/09/12(日) 00:05:19.01

変にRubyの影響受けてる部分は変えて欲しいなあ

**デフォルトの名無しさん** · 2021/09/12(日) 00:20:02.96

>>374
コンパイラ実装の問題なら承知した上で敢えて <> 採用してる
曖昧性の問題は turbofish で解決するなどコンパイラ実装を複雑にしない範囲で慣例的な記法に近づけている

>>375
Rubyの影響ってクロージャの記法のことかな？

**デフォルトの名無しさん** · 2021/09/12(日) 00:39:47.78

それはSmalltalkじゃないの？

**デフォルトの名無しさん** · 2021/09/12(日) 00:49:53.96

https://doc.rust-lang.org/reference/influences.html
ここによるとクロージャの記法はRuby由来

**デフォルトの名無しさん** · 2021/09/12(日) 01:31:54.94

クロージャの記法は各言語で様々だから大して気にならないけど
こう書きたいのに書けないのが悲しい

fn make_counter_closure(init: i32) -> impl FnMut() -> i32 {
　let mut counter = init;
　move || counter--
}

この件はRustやRubyだけでなくPythonやScalaやSwiftなどでも同じで
Swiftでは昔は出来たのに後から削除されたようだから最近はそういう傾向なの？

**デフォルトの名無しさん** · 2021/09/12(日) 01:35:25.37

>>378
RubyのクロージャがSmalltalk由来だからどうなんだろ

**デフォルトの名無しさん** · 2021/09/12(日) 07:25:17.64

>>379
++と―はバグの温床だからそういう傾向
Swiftから削除されたのもRustでrejectされてるのも同じ理由

**デフォルトの名無しさん** · 2021/09/12(日) 08:11:23.50

だッさw

**デフォルトの名無しさん** · 2021/09/12(日) 10:53:10.17

>>380
起源をたどればそうかもしれないけどRustが直接的に影響を受けたのはRuby

**デフォルトの名無しさん** · 2021/09/12(日) 12:43:40.70

ベストなジェネリクスの書き方ってなんだよ
Scalaみたいなのがいいの？

**デフォルトの名無しさん** · 2021/09/12(日) 14:11:08.78

Scalaみたいに[]にするのもアリだけど配列がちょっとアレになるからさすがに避けたい気がする
D言語みたいに、例えば定義時には
struct(T) Foo { foo: T }
impl(T) Foo {
fn(T) new(foo: T) { Self { foo } }
}
みたいな感じにして、使用時には
let bar = Foo!i64::new(42);
って感じにするとか・・・？
実際に書いてみるとこれはこれで微妙な気もするが

**デフォルトの名無しさん** · 2021/09/12(日) 14:19:29.99

>>379
そこは
{ let result = counter; counter -= 1; result }
または
{ counter -= 1; counter + 1 }
になるの？

**デフォルトの名無しさん** · 2021/09/12(日) 15:54:09.04

move || { counter-=1; counter }では？？？

**デフォルトの名無しさん** · 2021/09/12(日) 15:59:39.60

>>387
それは後置デクリメントになっていない

**デフォルトの名無しさん** · 2021/09/12(日) 16:29:00.55

後置であるということをそもそも認識できていなかった、やっべえ

**デフォルトの名無しさん** · 2021/09/12(日) 16:37:25.63

まさにバグの温床となりうることが示されたな

**デフォルトの名無しさん** · 2021/09/12(日) 16:48:32.00

>>385
初期Rustは [] だったけどまさに配列と被るからと言う理由で <> にした
C++と親和性のある構文を目指しているので <> 以外は採用されにくいと思う

**デフォルトの名無しさん** · 2021/09/12(日) 22:21:50.69

>>387
見ろ！Rustがゴミのようだ！

**デフォルトの名無しさん** · 2021/09/13(月) 00:58:36.15

型変数を明示しなきゃならないのは汎用プログラミング言語の欠点だよな

**デフォルトの名無しさん** · 2021/09/13(月) 01:54:16.68

何言ってんだこのバカ

**デフォルトの名無しさん** · 2021/09/13(月) 11:03:41.66

let mut counter = init + 1;
move || { counter -= 1; counter }

これが普通だと思うのは俺だけか？

**デフォルトの名無しさん** · 2021/09/13(月) 16:07:27.15

>>395
Rubyだと普通にそういう書き方するから特に違和感はないな

**デフォルトの名無しさん** · 2021/09/14(火) 21:41:07.14

配列がusizeだけなのを何とかして欲しい
i32 as usizeとかいちいち面倒

**デフォルトの名無しさん** · 2021/09/14(火) 21:52:21.64

>>397
普通に開発していればむしろusizeという別の型になってるおかげでミスなどに気付けて助かったことある人多いと思う
i32と別になっていることは非常に重要

**デフォルトの名無しさん** · 2021/09/14(火) 23:13:54.76

usizeだとうっかりマイナスにしちゃって死ぬことがある
デバッグビルドならぱにくって気づくけど、
テストすり抜けちゃうとやばい

**デフォルトの名無しさん** · 2021/09/14(火) 23:25:50.44

i32は流石にどうかと思うけど
グリッドの4-隣接とか8-隣接をforで回すときに中心からの差分で表現したくて、
isizeとusizeでガチャガチャ変換したときはちょっとウザいなーとは思った

**デフォルトの名無しさん** · 2021/09/14(火) 23:35:48.81

impl From<u16> for usize はあるのに u32 はないのが面倒
usize のサイズがプラットフォーム依存なのは分かるけど毎回 trt_from().unwap() したくない

**デフォルトの名無しさん** · 2021/09/15(水) 06:35:42.54

Rustの難しさってある程度マスターしたあとは納得の難しさなんですか？

面倒だなー。でも（メモリ安全のためには）しょうがないか～、みたいな

**デフォルトの名無しさん** · 2021/09/15(水) 07:06:01.76

バカ矯正用補助輪付言語の難しさ

**デフォルトの名無しさん** · 2021/09/15(水) 07:55:49.68

補助輪なし言語でバグなしプログラム作れたらどこに行っても採用されると思うよ

**デフォルトの名無しさん** · 2021/09/15(水) 08:36:21.78

>>401
asでいけないっけ

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

>>405
asでも良いけどreleaseだとオーバーフローチェックしてくれないから心許ない
constの文脈だとunwrap使えないからas使わざるを得ないけど

**デフォルトの名無しさん** · 2021/09/15(水) 09:15:01.47

オーバーフローの懸念がある文脈ならtry_fromはしょうがないのでは
usizeがu32以上のプラットフォームだけ想定するならasでいいように思えちゃうんだけど

**デフォルトの名無しさん** · 2021/09/15(水) 09:44:19.90

asを使うとu32から別の型に変更したときに修正漏れのリスクがあるのが気になってしまう
まあfrom相当のユーティリティ関数自分で用意すれば良いか

**デフォルトの名無しさん** · 2021/09/15(水) 15:12:38.68

>>398
じゃあunsafe時には許可して欲しい

**デフォルトの名無しさん** · 2021/09/15(水) 15:24:13.77

暗黙の型変換が増えるのはやだよ

**デフォルトの名無しさん** · 2021/09/15(水) 20:24:30.93

緩く簡単に書きたい人向けの言語じゃないよね全体的に