Rust Part7

**デフォルトの名無しさん** · 2019/07/14(日) 23:31:47.54

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 Part6
http://mevius.5ch.net/test/read.cgi/tech/1532714678/

**デフォルトの名無しさん** · 2019/10/20(日) 13:14:08.41

issueってバグじゃないだろ。
機能要望とか議論とかあるじゃん。

**デフォルトの名無しさん** · 2019/10/20(日) 23:15:26.37

小さめのサイズの本で、初心者向けの本が出た！

Rustプログラミング入門、酒井和哉、2019/10/13

**デフォルトの名無しさん** · 2019/10/20(日) 23:22:23.45

>>506
バグ発生率は、バスタブ曲線だろ。
初期によくバグる

土方をやってると、バグを多く出さないと、客に提出できないw

漏れは、平均的なIQ レベルより、間違いが少ないから、
いつも、アホみたいなバグを、わざと自分で作って、バグ発生数を増やしていたw

あらかじめ勉強している人は、滅多に間違わないから、バグ発生数基準だと困るw
一方、全く勉強していない香具師は、バグが多い

**デフォルトの名無しさん** · 2019/10/21(月) 03:46:22.99

俺は世界で一番この本を待ってた！！！！！

**デフォルトの名無しさん** · 2019/10/21(月) 13:21:09.04

仕様書にバグが多いのはあれわざと仕込んでるのかなるほど

**デフォルトの名無しさん** · 2019/10/22(火) 20:56:02.71

ネストした構造体のコンストラクトパターンみたいなやつはもっとチュートリアルで
説明した方がいいんでないのとは思う。
多分めんどくさい書き方にしかならんからやらんのだろうけれど。

**デフォルトの名無しさん** · 2019/10/23(水) 15:46:33.91

?の便利さに感動している

**デフォルトの名無しさん** · 2019/10/23(水) 16:06:56.63

え、なに？
文字化けしてますよ

**デフォルトの名無しさん** · 2019/10/23(水) 17:55:49.61

三項演算子は便利だったなぁ、と他言語を思い出して感動してるってことかな

**デフォルトの名無しさん** · 2019/10/23(水) 18:12:17.77

普通にResultの話じゃなくて？

**デフォルトの名無しさん** · 2019/10/23(水) 20:07:35.94

組み込みもネットワークツールもほとんどc以上の生産性を出すことないしな。。
一番有効な領域ってデバッガーじゃねーの？とは思う。

**デフォルトの名無しさん** · 2019/10/23(水) 20:47:39.59

Bookを6章まで読んだ俺が >>224 で書いたのが

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

?の便利さに気づいた俺が書いたのが

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

**デフォルトの名無しさん** · 2019/10/23(水) 21:06:25.79

.file_name()?.to_str()?.to_string()
Ｒｕｓｔだっさ

**デフォルトの名無しさん** · 2019/10/23(水) 21:12:36.43

公式に呼びやすい名前をつけないのがよくない
question mark operatorじゃわかりにくいから
error propagating operatorかerror handling operatorで

**デフォルトの名無しさん** · 2019/10/23(水) 21:26:40.40

ダサいかどうかとかどうでもよすぎる
性能、書きやすさ、読みやすさ、安全性がすべて

**デフォルトの名無しさん** · 2019/10/23(水) 21:31:02.23

性能　境界チェックのせいでだいぶおそい
書きやすさ　地獄
読みやすさ　悪夢
安全性　噂ではあるらしい

？まみれになるぐらいだったらヌルポで落ちても変わらんやん
どうせ無理に回復とかしないほうがいい類のだろ

**デフォルトの名無しさん** · 2019/10/23(水) 22:05:27.50

ぬるぽで落ちるのは運が良かっただけで何でも起きうるし最悪ｽｰﾊﾟｰﾊｶｰの餌食になる
?はちゃんとエラーで終了してくれる

って理解でおk?

**デフォルトの名無しさん** · 2019/10/23(水) 22:31:31.88

ヌルポって、javaのあれのこと？
シンタックスだけ比較して意味あんのかな

**デフォルトの名無しさん** · 2019/10/23(水) 23:02:51.06

>>523
ちがう
ぬるぽだとまず間違いなくぬるぽエラーで落ちる

NullSafeのありがたさはnullにならないこと
場合分けを考えずに常に変数を確実なひとつの値として扱える

**デフォルトの名無しさん** · 2019/10/23(水) 23:10:47.86

モナドだろうがなんだろうがNullはNullだ
へたに回復してしまうとほかに影響が波及して大惨事につながりやすい
むしろ最初からNullにならないことを保証してくれる方がうれしい

なのになんでOKで帰ってきた結果からfileNaeme取るのまで？つけさせられとんじゃ

**デフォルトの名無しさん** · 2019/10/24(木) 00:25:03.31

まあNULLで潔く死んでくれた方がってのは確かにあるわな。

**デフォルトの名無しさん** · 2019/10/24(木) 00:39:21.69

エラーかどうかのチェックは、NULLかどうかのチェックとは違う
ここ大事なところなので間違えちゃダメ

**デフォルトの名無しさん** · 2019/10/24(木) 01:03:58.72

潔く死んで欲しいなら明示的にunwrapなりexceptなりすればよい
バグなのか想定されたエラーなのかを区別して明示的にコーディングできるのがrustの利点では

**デフォルトの名無しさん** · 2019/10/24(木) 05:35:47.09

OptionとかResultにケチつけてるのは加齢臭キツすぎる

**デフォルトの名無しさん** · 2019/10/24(木) 06:50:04.06

下手に回復して大惨事になるのは、下手だからでしょ

file_nameに?付けてるのはディレクトリの場合無いからでしょ
なんでそんなことが疑問になるのか分からない

**デフォルトの名無しさん** · 2019/10/24(木) 09:03:26.66

Optionとか中途半端でたちわりーわ。
てかrustみたいにライフタイム意識する言語の場合、あんまり役割ない気がするけどね。

**デフォルトの名無しさん** · 2019/10/24(木) 12:28:38.87

メソッドチェーンの中で「owned -> borrowed -> owned」するのはアンチパターンだと思うんだよね
不必要な処理が入るし可読性も下がるのでいいことない

fn main() -> Result<(), std::io::Error> {
let path = std::env::current_exe()?;
let file = path.file_name().unwrap();
println!("{:?}", file);
Ok(())
}

**デフォルトの名無しさん** · 2019/10/24(木) 12:51:50.95

そもそものお題がこちら

＞187 デフォルトの名無しさん2019/08/26(月) 20:55:57.18 ID:hNXwMePN >>206>>214>>224
＞https://play.rust-lang.org/?version=stable&;mode=debug&edition=2018&gist=8c44bed658726ada0deff031799664b7
＞1. std::env::current_exe()で実行ファイルのフルパスを得る
＞2. file_name()でファイル名だけにする
＞3. to_str()で&strにする
＞4. 途中でErrやNoneが返ってきた場合はデフォルトの値"foo"を使う
＞
＞ということをやりたいのですが、エラーでビルドできません。
＞どのように書けばいいでしょうか？

**デフォルトの名無しさん** · 2019/10/24(木) 20:32:12.47

>>534
お題があったのね
referenceを受け取ってreferenceを返す関数に抽出すればto_ownedやto_stringは不要

use std::path::PathBuf;

fn main() {
let path = std::env::current_exe().ok();
let file = file_name(path.as_ref()).unwrap_or("foo");
println!("{}", file);
}

fn file_name(path: Option<&PathBuf>) -> Option<&str> {
path?.file_name()?.to_str()
}

**デフォルトの名無しさん** · 2019/10/24(木) 21:22:39.45

勉強になりました

let file = {|| Some(path.as_ref()?.file_name()?.to_str()?)}()
.unwrap_or("foo");

でも動くようですけど関数に抽出した方が良いですか?

**デフォルトの名無しさん** · 2019/10/24(木) 21:41:02.37

それ関数作って呼んでるのとほぼ同じだし名前がついてるかどうかの違いだから好きにせえ

**デフォルトの名無しさん** · 2019/10/24(木) 21:55:47.24

Someで囲ったOptionalチェーンを返すクロージャってのが
Rustのイディオムとして認知されて来ればそういうやり方も有りかもだけど
俺は関数に抽出したほうが型が見えて読みやすいので良いんじゃないかと思う

**デフォルトの名無しさん** · 2019/10/24(木) 22:25:03.94

try blockを待て

**デフォルトの名無しさん** · 2019/10/25(金) 20:57:15.75

これまではto_string()がチェーン末尾だったからSomeに入れてたけど
末尾がto_str()になってOption返すから必要なかった

let file = {|| path.as_ref()?.file_name()?.to_str()}().unwrap_or("foo");

なぜ昨日は気が付かなかったんだろう……

**デフォルトの名無しさん** · 2019/10/25(金) 21:01:12.42

try block
ずっと待ってるあなたのことを
意味もなくクロージャで囲む日々

**デフォルトの名無しさん** · 2019/10/25(金) 21:29:24.66

モナド早くきてくれー

**デフォルトの名無しさん** · 2019/10/25(金) 21:51:56.35

モナドられると、ややこしい人が顔出してくるんでノーセンキュー

**デフォルトの名無しさん** · 2019/10/26(土) 06:18:18.43

関数型信者がうるさくなった言語は衰退する

**デフォルトの名無しさん** · 2019/10/26(土) 09:43:29.54

関数型ことごとくすたれてない？

**デフォルトの名無しさん** · 2019/10/26(土) 10:13:18.36

モナド（高階型）来てもいいんじゃない？OptionとResultで同じようなことやってるし

**デフォルトの名無しさん** · 2019/10/26(土) 13:48:16.66

オプショナルチェーンを矛盾なく繋げるモナドが入れば覇権だと思う
正直それだけできれば小難しい理論はいらないし

**デフォルトの名無しさん** · 2019/10/26(土) 14:36:55.83

チェーンは滅んでほしい

**デフォルトの名無しさん** · 2019/10/26(土) 14:53:14.83

チェーンってひとくくりにするなよ。メソッドチェーンは糞だが。

**デフォルトの名無しさん** · 2019/10/26(土) 15:11:41.74

チェーン評価ってのも聞いたことがあるな

**デフォルトの名無しさん** · 2019/10/26(土) 16:45:06.90

>>547
矛盾ってのがよくわからないんだけど
今のオプショナルチェーンだと何が問題なの？

**デフォルトの名無しさん** · 2019/10/26(土) 19:08:07.88

この板で否定的な言い分を魔に受けないほうがいい
冗談で言ってるか、冗談みたいな馬鹿の言い分だから

**デフォルトの名無しさん** · 2019/10/26(土) 23:02:43.13

おっぱい好きだけど爆乳は好きじゃない。

**デフォルトの名無しさん** · 2019/10/26(土) 23:16:28.89

奇乳きらい

◆QZaw55cn4c · 2019/10/27(日) 15:39:15.22

貧乳こそ正義

**デフォルトの名無しさん** · 2019/10/27(日) 20:10:25.95

**デフォルトの名無しさん** · 2019/10/27(日) 21:47:29.52

雄π

**デフォルトの名無しさん** · 2019/10/28(月) 07:30:15.50

ちっぱいだいすき

**デフォルトの名無しさん** · 2019/10/28(月) 11:04:07.07

たかが乳ですら意見割れてるのに関数型の話がまとまるわけないな

**デフォルトの名無しさん** · 2019/10/29(火) 22:37:06.24

うまいことドメイン駆動設計をオブジェクト指向から切り離せないかな？
Javaでアーキテクチャを考えると、「このコードはどこに書くべきか」がずっと分からなくなる
関数のシグネチャ読めばそれがMなのかCなのか業務ロジックなのか入出力なのか、全部分かるように書けないものか

**デフォルトの名無しさん** · 2019/10/29(火) 23:45:32.33

スレチ？それどもRustで考えてるのかな
JavaでもC#でもシグニチャ読めばMなのかCなのかくらいはわかるように書けると思うが

それはいいとしてDDDの本質はOOとは関係ないよ
Functional DDDの本がScalaとF#を例にしたのがそれぞれ出てるから読んでみるといいかも
F#のほうの著者のサイトみればRustのEnumでも同じような事できるのがわかるはず
https://fsharpforfunandprofit.com/ddd/

**デフォルトの名無しさん** · 2019/10/30(水) 00:09:30.97

はえ～

**デフォルトの名無しさん** · 2019/11/01(金) 14:20:55.93

Vulkanが公式でRustをサポートしてくれればRust製のゲームとかもっと出てくるのかなぁ

**デフォルトの名無しさん** · 2019/11/01(金) 15:16:52.33

enumの配列はメモリやばい？
https://play.rust-lang.org/?version=stable&;mode=debug&edition=2018&gist=0eeab60af9f7385db00275b2d168ac2c

**デフォルトの名無しさん** · 2019/11/01(金) 15:49:15.26

>>564
enum MyEnum {
Foo,
Bar(i32),
Baz(i32, i32, i32, i32, i32),
}

今のRustはEnumの一番大きいvariantに合わせてメモリを確保する
Baz(i32, i32, i32, i32, i32)が、4バイト x 5 = 20バイト
どのvariantかを示すTagバイトで+1バイトとパディングで+3バイト=24バイト
配列の要素数が3なら24 x 3 = 72バイト

**デフォルトの名無しさん** · 2019/11/01(金) 19:25:13.98

現職エントリ（）のドワンゴや
タイ全裸Wantedlyの推してる言語って時点で使う気起きなくなるよね

**デフォルトの名無しさん** · 2019/11/01(金) 19:29:17.10

タイ全裸って？

**デフォルトの名無しさん** · 2019/11/01(金) 21:28:00.41

>>567
タイ全裸Wantedlyでググろう
Wantedlyがタイで全裸になったわけではないが
企業としては全く信用できん

**デフォルトの名無しさん** · 2019/11/01(金) 21:55:41.28

どんなに「こんなに素晴らしい機能がある言語！」とか言われても
「でもあの個人情報お漏らし泥箱や現職エントリ（）ドワンゴとかDMCA乱用のWantedlyとかが推してる時点で……」ってなるのが
正しい社会人としてのあり方

**デフォルトの名無しさん** · 2019/11/01(金) 22:09:13.26

>>565
つまりどんなenum作るでもたくさん値を持たせないほうが余計なメモリ使わずベストってことか

**デフォルトの名無しさん** · 2019/11/01(金) 22:57:41.39

アンチドワンゴがみんなC言語使ってると思うと抜ける

**デフォルトの名無しさん** · 2019/11/01(金) 22:57:51.68

↑思うとワロタ

**デフォルトの名無しさん** · 2019/11/02(土) 02:27:34.58

まあ正直、いまだにえんじにゃーのファッションって部分がでかいわな。

**デフォルトの名無しさん** · 2019/11/02(土) 07:38:49.45

他人がなに使ってのかチラチラ伺いながら自分の使うもの決めるのか
小物すぎるだろ

**デフォルトの名無しさん** · 2019/11/02(土) 13:57:08.64

>>574
つっても現職エントリ様やタイ全裸と一緒にされたくはねえしなあ

**デフォルトの名無しさん** · 2019/11/02(土) 14:20:09.97

同じ言語使ってるだけで同一視すんのはお前だけだよ

**デフォルトの名無しさん** · 2019/11/02(土) 14:32:51.71

それらの企業はRustなんか採用する前からボロボロだっただろ。

**デフォルトの名無しさん** · 2019/11/02(土) 15:40:16.76

んでもって一発逆転をねらって水物のに飛びつくっていうアンチパターンね。

**デフォルトの名無しさん** · 2019/11/02(土) 20:44:05.92

あそこは一人が有名なだけだと思うがな

**デフォルトの名無しさん** · 2019/11/02(土) 22:56:34.85

https://github.com/woboq/qmetaobject-rs
このcrateの中で"rust!"というマクロが使われてるんですがクレート内や依存するクレートの中を探してみても定義してる箇所が見つかりません
どこで定義してるのかわかる方いませんか？

**デフォルトの名無しさん** · 2019/11/02(土) 23:31:33.69

>>580
Rustのマクロとして定義されてるものではないみたいね
↓ここら辺に説明がある
https://docs.rs/cpp/0.5.4/src/cpp/lib.rs.html#209-241

**デフォルトの名無しさん** · 2019/11/02(土) 23:48:47.52

>>581
なるほど、マクロの中で独自の擬似的なマクロを定義してるって事でしたか
そんな使い方があるなんて思いもしなかった

ありがとうございました！

**デフォルトの名無しさん** · 2019/11/03(日) 01:36:39.62

マクロの中で独自マクロ定義とか、、、
そんなことされたら俺の脳はメタメタにされてしまう。

**デフォルトの名無しさん** · 2019/11/03(日) 02:21:28.16

C++テンプレートの悪夢を再現しようとしてる人たち

**デフォルトの名無しさん** · 2019/11/03(日) 14:24:34.21

C++を理解したプログラマーはRustを使う必要がなく、C++が理解できないプログラマ―にはRustも同様に理解できない。
https://developers.srad.jp/story/15/02/20/2132207/

**デフォルトの名無しさん** · 2019/11/03(日) 17:45:13.54

>>585
古い記事のリンクなんてはるな、うざい

**デフォルトの名無しさん** · 2019/11/03(日) 20:33:09.59

traitでコピーかムーブかの判断をするようにしたのはrustの最大の失敗だな。

**デフォルトの名無しさん** · 2019/11/03(日) 22:07:42.86

直すならいまのうち

大丈夫だろ

**デフォルトの名無しさん** · 2019/11/03(日) 23:21:37.95

どうだったらよかったのか

**デフォルトの名無しさん** · 2019/11/04(月) 02:00:10.34

>>586
5年前から何一つRustは進歩してないってことだよ
一方Nimは1.0迎えてどんどん進歩している
RustからNimへの流出もどんどん進んでる

**デフォルトの名無しさん** · 2019/11/04(月) 02:02:58.89

http://wolfbash.hateblo.jp/entry/2017/07/30/193412
そーいや結局この記事へのまともな反論は以前のスレでも出てこなかったよな

**デフォルトの名無しさん** · 2019/11/04(月) 02:16:17.42

ネタフリはいいけどもうちょっと生産的なのにしてよ

**デフォルトの名無しさん** · 2019/11/04(月) 02:22:13.55

>>589
少なくとも = をオーバーロードもしくはオーバーライドするようなやり方は
すべきでなかった。

**デフォルトの名無しさん** · 2019/11/04(月) 07:58:19.81

生産的というが、Rustが言語として生産的なことは過去にあったか？
それよりはNimへの乗り換えという前向きな選択肢を出すことの方が生産的だと思うが

**デフォルトの名無しさん** · 2019/11/04(月) 09:12:04.34

AWSも支援--プログラミング言語「Rust」人気が拡大
https://japan.zdnet.com/article/35144661/

**デフォルトの名無しさん** · 2019/11/04(月) 09:16:30.74

>>593
そうでないならどうする？
pros/consは何？

**デフォルトの名無しさん** · 2019/11/04(月) 10:29:24.02

個人的にはC/Zig/C2・C++/D/Rust・Go/Nimという棲み分けだと思っているので別にという感じだ

まぁそもそも論としてNimの話したいなら次世代言語スレかNimスレでやれよという気持ち
せっかく専用スレあるのにメインユーザーにすら使われないとか可哀想すぎるでしょう？

**デフォルトの名無しさん** · 2019/11/04(月) 11:26:47.69

NimはPythonでパフォーマンスに困ってる人にはいい言語じゃないかと思う。Pythonスレで宣伝してくればいいのに。
Rust使ってる人が移行したくなる要素はあまりない気がするけどな。

**デフォルトの名無しさん** · 2019/11/04(月) 12:05:28.47

>>596
んな簡単に示せたらおれが言語作ってるわ。
とりあえず言えることとしてはこの辺の明示性に関しては明らかに c に劣るってことくらい。

**デフォルトの名無しさん** · 2019/11/04(月) 12:16:27.30

「すべきでなかった～」とか断言したわりにしょぼい回答でがっかりだよ

**デフォルトの名無しさん** · 2019/11/04(月) 12:41:59.38

Rustの良さはCと同レベルの速さをキープしつつ
Cよりは安全にかけるところが良いのだから
言語についてごちゃごちゃ言うのは筋違い
多少面倒でも安全に倒した方が良いって人が使うもの

**デフォルトの名無しさん** · 2019/11/04(月) 12:43:51.83

インデックス１始まりの地獄はＶＢＡでさんざん味わった
一貫してるとまた違うのか？

**デフォルトの名無しさん** · 2019/11/04(月) 14:56:29.79

RustはCより身持ちが堅いけどお作法と親戚づきあいが滅茶苦茶面倒な嫁って感じ
NimとPythonは巨乳姉妹で姉は大学生、妹はフリーター
Perlはヤンデレ妹

**デフォルトの名無しさん** · 2019/11/04(月) 17:01:43.91

まあ確かにC++のauto_ptrと同じミスをしてるとは言えるよねCopyトレイトに関しては
こっちはCopyトレイトになれるものが相当限られてるのと
コンパイラがC++よりわかりやすいエラーを吐くことでギリギリ妥協の範囲を攻めてる感じ？
まあ全体的にはauto_ptrよりはマシだと思うよ
許容できるかは人次第だけど

**デフォルトの名無しさん** · 2019/11/04(月) 18:52:40.96

>>601
いや全く逆のことを指摘してるんだが。
もっと面倒でもコピーと参照については明示性のある記述方法にするべきだったのでは
ということを言っている。

**デフォルトの名無しさん** · 2019/11/05(火) 01:02:39.53

>>605
横レスだけど >>601 はRustとNimについての文脈であってCopyトレイトについての文脈じゃないと思うよ