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/03/23(月) 18:36:24.14

>>241
別に駄目とは言ってません。
「静的解析でメモリ管理を自動化した。」
というのは言いすぎだと言うことです。

**デフォルトの名無しさん** · 2020/03/23(月) 18:54:37.87

そりゃ循環参照とかウンコード書けばの話だろ、何か問題有るのか？

**デフォルトの名無しさん** · 2020/03/23(月) 18:56:19.36

Heap=Rcだと勘違いしてんのかな？

**デフォルトの名無しさん** · 2020/03/23(月) 19:00:04.36

荒らしにかまうやつも荒らし

暇なおじいさんが各言語に難癖つけて回ってる
Kotlinの次はRust

**デフォルトの名無しさん** · 2020/03/23(月) 19:15:41.65

おかしな奴に絡まれるからRustはダメ言語

**デフォルトの名無しさん** · 2020/03/23(月) 19:16:56.45

>>242
結局のところライフタイムは人間が書くし、それを元にいくらかのチェックと推論をするだけ。
今まで自動化できてなかった分 (の一部) を新しいやり方で自動化したってだけのことで、
何もかも自動でやってくれるような最強解析能力を持ってるなんて誰も言ってないよ。
ストローマン論法はやめろよな。

もう一度書くけど、 Rust のシステムはメモリリークの排除を目的にしていない。

**デフォルトの名無しさん** · 2020/03/23(月) 20:19:04.31

藁人形クッソ抜ける？

**デフォルトの名無しさん** · 2020/03/23(月) 21:49:49.89

リソースの開放をプログラム内で完璧にやろうとせずに
プロセスの再起動とかの水準で考えてしまえばいいこともあるかもね

**デフォルトの名無しさん** · 2020/03/23(月) 22:15:27.45

メモリ以外のリソース回収に関してはGCよりRust（あるいはC++のスマポ）がはるかに優秀なんだよな。
Rustに慣れると他言語でusingとかするのが面倒になってくるし、ついつい付け忘れて困る。

**デフォルトの名無しさん** · 2020/03/24(火) 00:09:09.52

Kotlinスレでnullポインタの方が良いと
荒らしてたのと同一人物だったのか

**デフォルトの名無しさん** · 2020/03/24(火) 02:50:53.94

体制側と違う意見は大事。
自分の頭で考えない人は、効能書きや権威やネットで書かれたことを鵜呑みにしてしまう。

**デフォルトの名無しさん** · 2020/03/24(火) 10:04:19.30

メモリ以外のリソース回収なんてむしろなくね

**デフォルトの名無しさん** · 2020/03/24(火) 10:37:53.99

いやファイルポインタ、コネクション、スレッドなどいくらでもあるだろ。

**デフォルトの名無しさん** · 2020/03/24(火) 12:20:20.31

>>250
こんな出てきたばかりの言語に慣れてる人なんているかい。

**デフォルトの名無しさん** · 2020/03/24(火) 12:43:11.53

ファイルハンドルくらいならusingでもいいけど、デバイスコンテキストみたいな微妙に寿命が長いのが困る。
Disposeとか呼び忘れても大抵GCが回収してくれてぱっと見動くけど、
時々回収してくれなくて再現性の低いバグになるとか。

**デフォルトの名無しさん** · 2020/03/24(火) 14:22:30.48

Box<T>のソースを見ていたら、Box::new が次のような1行だけのソースで、
box キーワードを調べてみたら、組み込みの Box::new の実装とだけしか
情報がない。つまり、ソースがあるようで実質的には無い：
impl<T> Box<T> {
　pub fn new(x: T) -> Box<T> {
　　box x
　}
}

同様に Vec<T> のソースを見ていたら、RawVec なるものが出ていて、
RawVecのソースもあったがそこで、core::ptr なるものが使ってあり、
そのソースはないようだ。

Cにとってかわるシステム言語と言いながら、本質的には組み込み関数ばかりで
ソースを追っていくことができない。
Cは最初から理解できて、このような闇が存在しないので、高級アセンブラであり、
システム言語であった。
Rustにはその代わりは務まらないのではないか。

**デフォルトの名無しさん** · 2020/03/24(火) 14:31:46.69

ツッコミどころ満載だけど
荒らしの相手したら負け

**デフォルトの名無しさん** · 2020/03/24(火) 14:40:33.66

正しく
怖がる

**デフォルトの名無しさん** · 2020/03/24(火) 14:43:56.87

巨大学術掲示板群 - アルファ・ラボ
ttp://x0000.net

物理学化学生物学数学天文学地理地学
IT 電子工学言語学方言国語など

**デフォルトの名無しさん** · 2020/03/24(火) 14:44:12.30

Rustは概念が整理されてない。
Cは、ポインタという概念さえ理解すれば(そしてそれは、プログラミングに適性が有る人にはそんなに難しいわけではない)、それだけを頼りにあらゆるものが構築できた。
ところが、Rustはいくら学んでも終わりが無いくらい基礎の部分が難しい。
Box<T>が何をやっているかは、自然言語で説明されるばかりで肝心の
コードも擬似コードもなかなか見つからない。

**デフォルトの名無しさん** · 2020/03/24(火) 15:04:27.63

Box<T>のデストラクタである所の Drop trait の drop 関数を調べてみると、
次のようになっており、compilerの埋め込み処理というコメントになっている。
恐らく、Box<T>が削除される際にコンパイラが何らかの処理を入れているが、
ソース中には書いてない。
こんな状態で Cの後釜を名乗ってほしくない。

unsafe impl<#[may_dangle] T: ?Sized> Drop for Box<T> {
　　fn drop(&mut self) {
　　　　// FIXME: Do nothing, drop is currently performed by compiler.
　　}
}

**デフォルトの名無しさん** · 2020/03/24(火) 15:45:47.44

>>257
それは悔しいけどちょっと理解できる
コンパイラーのソースみるとcompiler builtinで見れないやつとかあるし
いや、どこにあんねんと

**デフォルトの名無しさん** · 2020/03/24(火) 16:11:12.01

Option<Box<T>> で、Some(Box::new<xxx>)
とした場合に、どういう状況の時にこのメモリが解放されるのか、
その仕組みも分かりにくい。

**デフォルトの名無しさん** · 2020/03/24(火) 16:46:57.83

>>264
誤: Some(Box::new<xxx>)
正: Some(Box<T>::new(値))

**デフォルトの名無しさん** · 2020/03/24(火) 17:02:53.60

なんぼ間違えんねん落ち着けや

**デフォルトの名無しさん** · 2020/03/24(火) 17:20:04.56

Rustでの代入記号は、i32/f32/bool/str などのprimitive型以外は原則的に copy動作
ではなく、move 動作のようなもので、所有権の移動が発生する。
例外は、Copy traitsが実装されている型の場合で、その場合も copy動作になる。

Option<XXX>は、Copy traitsが実装されているらしく、Optionが他動詞で代入記号
を使うと、copy動作になるらしい。
ただし、これは文書で明確には述べられてないのでよくわからない。
根拠は、Optionのソースは以下のようになっていて、#[derive(Copy, ...)]の部分が、
Copy traitsを自動実装する、という意味になるらしいからだ：

#[derive(Copy, PartialEq, PartialOrd, Eq, Ord, Debug, Hash)]
#[rustc_diagnostic_item = "option_type"]
#[stable(feature = "rust1", since = "1.0.0")]
pub enum Option<T> {
/// No value
#[stable(feature = "rust1", since = "1.0.0")]
None,
/// Some value `T`
#[stable(feature = "rust1", since = "1.0.0")]
Some(#[stable(feature = "rust1", since = "1.0.0")] T),
}

**デフォルトの名無しさん** · 2020/03/24(火) 17:21:21.85

>>267
誤：Optionが他動詞で
正：Option型同士で

**デフォルトの名無しさん** · 2020/03/24(火) 17:31:35.81

>>263
compiler builtinはコンパイラのソースの中にあるよ

コンパイラのソースでcompiler built-inは見たこと無いけど

**デフォルトの名無しさん** · 2020/03/24(火) 18:30:07.73

>>278
ないよ
https://github.com/rust-lang/rust/blob/master/src/libcore/macros/mod.rs#L1196-L1200
https://doc.rust-lang.org/src/core/macros/mod.rs.html#1146-1150

**デフォルトの名無しさん** · 2020/03/24(火) 18:46:17.48

汽車　汽車　チンポ　チンポ
シコシコ　チンポッポ
チンポを出して　シコシコ　チンポッポ

**デフォルトの名無しさん** · 2020/03/24(火) 19:01:03.96

>>278
期待してるぞ

**デフォルトの名無しさん** · 2020/03/24(火) 23:11:28.78

>>278
それコンパイラのソースじゃないよ

**デフォルトの名無しさん** · 2020/03/25(水) 01:18:57.46

Rustは、コンパイラ時エラーに悩まされる反面、実行時エラーに悩まされるのを減らす
などと言われる。
しかし、コンパイル時エラーが出ると言うことは、裏を返せば、書けないアルゴリズムが存在するということだ。
直感的ではない回りくどい書き方が必要となり記述量が多くなる。
他の言語では好きな書き方が出来て、それはどれも正解だが、Rustでは正解が非常に狭くなる。
正解が狭いことがエラーを減らすなどという人がいるが、実際には、Rustは
書けるアルゴリズムが狭い、と言うことなのである。
これは言語設計の問題である。

なお、ここで言っているアルゴリズムは、全体的なものではなく、細かいミクロ的なものである。
通常の言語では、1つの仕事を細かい変数の使い方まで含めれば数万通り以上に書けるだろう。
そして、そのどれもが正解であり、結果が正しくバグも無いのだから、内のどれかが悪い書き方という
ことは特にない。
ところが、Rustでは、その大部分の書き方が出来ないのである。
駄目だから敢えてできなくしているのではなく、Rustが設計上、書けないアルゴリズムがあるということに他ならない。
つまり、Rustは書けるアルゴリズムが、本来コンピュータが書けるアルゴリズムの内の、非常に狭いサブセットに限られてしまうということである。
これは、Rustの大きな欠陥である。

**デフォルトの名無しさん** · 2020/03/25(水) 01:25:39.41

>>274
「駄目な書き方だからエラーにしている」
と言うのは間違いで、正しくは、
「Rustコンパイラの静的解析能力では、書き方を非常に限定しないと
　正しいことを保障できなかったり、自動化できなかったりするため、
　しょうがなく狭い書き方しか出来なくしている」
と言うことに他ならない。
人間には脳内の静的解析で明らかに正しいことが分かる書き方でも、
Rustコンパイラではでは同じことができないため、敢えて
変数束縛、借用、単一参照など、コンパイラでも解析できる程度の
範囲に書き方を限定して無理やり人間のプログラミングの可能性を
狭めているに過ぎない。

**デフォルトの名無しさん** · 2020/03/25(水) 01:26:44.15

コピペじゃなかったのか…ウケるw

**デフォルトの名無しさん** · 2020/03/25(水) 07:56:19.45

みんなドキュメントコメントで日本語も一緒に書くときってどうしてる？
こんな連ねた感じでいいのかな？
/// Returns a Person object
/// Personオブジェクトを返す

**デフォルトの名無しさん** · 2020/03/25(水) 08:01:15.06

例が悪いわ。
そんな糞コメント書くな、になってしまう。

**デフォルトの名無しさん** · 2020/03/25(水) 08:57:55.31

>>278
期待を裏切りよって

**デフォルトの名無しさん** · 2020/03/25(水) 09:06:21.89

言いたいことも言えないこんな世の中じゃポイズン

**デフォルトの名無しさん** · 2020/03/25(水) 11:14:11.00

Cからprintln使ってるRustの関数呼ぶとメモリリークしよる(´・ω・`)

**デフォルトの名無しさん** · 2020/03/25(水) 12:42:04.62

>>277
それコメントの意味なくね？

**デフォルトの名無しさん** · 2020/03/25(水) 14:08:14.89

>>277
Personオブジェクトを返すって
-> Person
-> Box<dyn Person>
どっちのこと？

**デフォルトの名無しさん** · 2020/03/25(水) 16:36:38.82

今だにCopyトレイトの命名は失敗だと再確認する

**デフォルトの名無しさん** · 2020/03/26(木) 02:55:12.87

Box<T> は copy ではなく move なんだとさ。

**デフォルトの名無しさん** · 2020/03/26(木) 02:58:28.01

>>267
Option<T> は、Copy。
Box<T> は、Move。
だから、
Option<Box<T>> は、外側が Copy で、中身が Move らしい。

**デフォルトの名無しさん** · 2020/03/26(木) 03:37:08.94

中身がCopyのときだけOptionもCopyになるんじゃないの？？

**デフォルトの名無しさん** · 2020/03/26(木) 03:46:23.72

>>287
分からない。

**デフォルトの名無しさん** · 2020/03/26(木) 03:48:11.78

>>285
ソースを示しておくと、以下の公式(?)サイトに、
「because Box isn't Copy」という言葉が書かれている：
https://doc.rust-lang.org/nomicon/checked-uninit.html

**デフォルトの名無しさん** · 2020/03/26(木) 04:59:35.60

struct のメンバに local 変数を代入した場合、エラーになる？

**デフォルトの名無しさん** · 2020/03/26(木) 12:36:34.09

https://doc.rust-lang.org/std/option/enum.Option.html#impl-Copy

impl<T> Copy for Option<T> where T: Copy {}

**デフォルトの名無しさん** · 2020/03/26(木) 14:56:26.41

>>291
それは >>267 とちゃんと整合しているな。
Option<T>は、Copy と Cloneの両方が実装されていると言うことで、
ならば、原則論からすればOptionは代入演算子でMove動作「ではなく」Copy動作
だということになる。

**デフォルトの名無しさん** · 2020/03/26(木) 15:33:44.04

>>292
>ならば、原則論からすればOptionは代入演算子でMove動作「ではなく」Copy動作
は？
where T: Copyって書いてるやん
オレオレ原則論書き散らかして荒らすのやめてくれ

**デフォルトの名無しさん** · 2020/03/26(木) 17:17:35.74

c++の代替というけど、rust理解するにはc++でメモリイメージ固めた方が学習速いんじゃねーの？

**デフォルトの名無しさん** · 2020/03/26(木) 18:48:36.88

>>292
Optionは型ではない
Option<T>は型
区別してくれ

**デフォルトの名無しさん** · 2020/03/26(木) 21:50:13.71

ML系列の記法に慣れるとrustがどうしてalgol系列の記法にしたのか納得できなくなる。どんだけカンマ打たせるねん。
少し頑張れば関数の型も推論できると思うんだけど人まかせにしてるのが好きじゃない。せめて、勝手に挿入できるような記法にしとくべきだったと思う

**デフォルトの名無しさん** · 2020/03/27(金) 00:25:53.78

インスタンスでフィールドアクセスにカンマ使わない場合どんなのがいいの？

推論は関数で境界作りたかったんでしょ

**デフォルトの名無しさん** · 2020/03/27(金) 00:33:57.86

>>282
日本語のコメントはどう書くだけなのか聞きたかったから特に意図はない例だよ

>>283
完全な例だからあれだけどBoxではない
struct Person {
name: String,
}

impl Person {
pub fn new(name: &str) -> Self {
Self {
name: name.to_string()
}
}
}

**デフォルトの名無しさん** · 2020/03/27(金) 00:47:04.38

型推論の能力的には関数も全部できるけど、ドキュメント目的であえてしてないはず。

**デフォルトの名無しさん** · 2020/03/27(金) 01:16:32.86

TypeScriptは戻り値の型を省略できるけど、書かないと訳が分からなくなるので言語的には省略出来てもコーディングルールで強制してるわ
Cみたいに変数宣言含めて型を全部書くのも面倒だけど、行き過ぎた省略もメンテナンス性を損なうと思う

**デフォルトの名無しさん** · 2020/03/27(金) 03:32:10.02

>>296
どういうカンマの事？

**デフォルトの名無しさん** · 2020/03/27(金) 15:34:02.04

C/C++に疲れた人が使って幸せになれるのがRustだと思ってたけど
実態は全然違うってことか

**デフォルトの名無しさん** · 2020/03/27(金) 17:00:38.31

C++17に疲れた人なら結構幸せになれるんじゃない。
C89に疲れた人だと厳しそうだが…。

**デフォルトの名無しさん** · 2020/03/27(金) 18:51:24.66

RustのコンパイラソースをCloneしてそれをベースに名前も違うプログラミング言語作るのってライセンス的にどうなの？
rustcの構文解析の部分を変えてからそのrustcも全部その言語に変換したいんだけど

**デフォルトの名無しさん** · 2020/03/27(金) 18:57:46.96

>>304
そういう考えだから、人を馬鹿にするんだな。
ちょこっといじっただけの癖に全体を自分が造ったみたいな態度をとる。

**デフォルトの名無しさん** · 2020/03/27(金) 19:49:39.79

>>299 あえてやらないなら、せめてコンパイラが推論した結果を教えてくれよと思う
この処理のこの部分だけ一旦切り出して別の処理にしてみたい、とかやるときにすげー大変

Haskellでも型表記は省略できるけどしない方が良いねって作法がメジャーなのは知ってるけど、型推論でサポートしてくれるからrustよりストレス少ない
ちょいとクロージャを関数として外に出しとこう、とか、ここ切り分けて別パターン用意して比較してみよう、とかやるのが面倒くさい

あ、まずクロージャにして型エラーを起こして教えてもらう、とかやればできるんかな…

**デフォルトの名無しさん** · 2020/03/27(金) 19:59:43.89

>>306
型を自分で書くのが面倒なときは()とかi32とか適当な型で埋めておいて、エラーメッセージから正しい型を持ってくるというのはありだよ。
（逆に言えば正しいエラーメッセージを出せるということは、関数プロトタイプまでちゃんと型推論できているということでもある）

**デフォルトの名無しさん** · 2020/03/27(金) 21:21:00.05

関数の型を推論するのを捨ててるから
Deref coercionだったりFrom/Intoだったり中身を書くときに型を省略できるんじゃないの？

owned/shared/mutの違いに加えてlifetimeもあるから
それらも含めて推論することになると現実に使えるレベルになるのかどうか怪しい
少なくとも現時点で注力するようなポイントじゃないと思う

**デフォルトの名無しさん** · 2020/03/27(金) 22:30:46.16

>>304
ライセンス的にも道義的にもなんの問題もないんで、ぜひ面白言語作ってくれ。
Rust/Cargoの名前やロゴ使うと商標権には引っかかるのでそこだけちゃんと変えてればOK。

**デフォルトの名無しさん** · 2020/03/28(土) 02:49:23.51

>>309
コミットも常に最新を本家からチェリーピックして最新機能とか享受大丈夫？
道理的に叩かれそうじゃない？

**デフォルトの名無しさん** · 2020/03/28(土) 09:49:38.92

HACK言語の成り立ちを参考にしたら
答えが見えてくるかもしれないよ

**デフォルトの名無しさん** · 2020/03/28(土) 19:16:01.84

WebKitとBlinkみたいな感じでしょ？へーきへーき

**デフォルトの名無しさん** · 2020/03/28(土) 20:00:00.22

githubのissueのタグで頭についてるE-easyとかT-compilerみたいな大文字のアルファベットってどういう意味があるの？

**デフォルトの名無しさん** · 2020/03/28(土) 21:27:53.53

>>313
https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#issue-triage

**デフォルトの名無しさん** · 2020/03/28(土) 21:34:01.64

>>310
ライセンス的には問題ない
道義的にはライセンス踏襲してRustを元にしてるよって書いとけば問題無いと思う

**デフォルトの名無しさん** · 2020/03/29(日) 13:50:06.97

この引数に&つけるのって
iter.map(|&i| i * 2)
これと同等？
for i in iter {
let i = &i;
}

**デフォルトの名無しさん** · 2020/03/29(日) 15:02:02.33

巨大な学術掲示板群アルファ・ラボ
ttp://x0000.net

物理学化学生物学数学天文学地理地学
IT 電子工学言語学方言国語など

**デフォルトの名無しさん** · 2020/03/29(日) 15:16:29.91

>>316
逆
let &i = i;

**デフォルトの名無しさん** · 2020/03/30(月) 03:34:27.53

>>318
let i = 1;
let &i = i;
これだとコンパイル通らないよ

**デフォルトの名無しさん** · 2020/03/30(月) 03:44:28.46

記法の問題で、>>318は、C++ と勘違いしたんでは。
Rustだと
let i = 1;
let j = &i;
が正しいはず。

**デフォルトの名無しさん** · 2020/03/30(月) 03:57:10.09

iter.map(|i| i * 2)
と書いた場合、|i| i * 2 の部分は、closure や Lambda expression, lambdas
と呼ばれるものなんだろうけど、|&i| と書く形式はなかなか検索では出てこない。

**デフォルトの名無しさん** · 2020/03/30(月) 04:01:22.73

>>318が書いてるの合ってると思うけど？
https://play.rust-lang.org/?version=stable&;mode=debug&edition=2018&gist=6d886f2d3b944871c18856f0e19da71c

iterがshared referenceをイテレートするから
パターンマッチで`&`を1枚剥がした型にして使ってる
for &i in iterと同じ

**デフォルトの名無しさん** · 2020/03/30(月) 04:40:37.32

>>322
ところで、
let &x = y;
ってどういう意味ですか？

let y:i32 = 5;
let x:&i32 = y;
とは違うんでしょうか？

**デフォルトの名無しさん** · 2020/03/30(月) 04:45:30.74

誤: let x:&i32 = y;
正: let x:&i32 = &y;

**デフォルトの名無しさん** · 2020/03/30(月) 11:38:27.40

>>323
左辺に代入する時にパターンマッチ使ってDestructuringしてる
例えばyが&i32ならxはi32になる

let i = 1;
let &i = i;
これがコンパイル取らないのは
右辺がintegerで左辺がreferenceを要求しててマッチしないから

let i:i32 = 1;
let i = &i;
let &i = i;
let i:() = i;
↑こうやって試せば3行目の&iへの代入でiが&i32じゃなくi32になってるのが分かる
https://play.rust-lang.org/?version=stable&;mode=debug&edition=2018&gist=1d23370e99b388e2205c43e863885315

**デフォルトの名無しさん** · 2020/03/30(月) 14:27:14.40

>>325
let i:() = i;
はどういう意味でしょう。

**デフォルトの名無しさん** · 2020/03/30(月) 14:34:27.40

>>326
C で言う void みたいなもんだよ。
あり得ない型を指定してエラーメッセージを出させたら
メッセージに右辺の側の型も表示されるという
型確認のテクニック

**デフォルトの名無しさん** · 2020/03/30(月) 15:23:14.22

1.38からはstd::any::type_nameがstabilizeされてるので
エラーメッセージやnightly使わずに変数の型をprintして確認できるみたい
(consumeしないようにreferenceで渡すから少し分かりにくいかもだけど)

fn type_of<T>(_: &T) -> &str {
std::any::type_name::<T>()
}

fn main() {
let i = 1;
let i = &i;
let &i = i;
println!("{}", type_of(&i));
}

type_name_of_valってのも追加されてるけど
こっちはまだstabilizeされてない

**デフォルトの名無しさん** · 2020/03/30(月) 16:45:46.87

>>327
なるほど。貴重なテクニック有難うございます。

>>328
それを使えば構造体(?)や参照型などの lifetime も表示できますでしょうか？

何か lifetimeを確認する方法をご存知の型がいらっしゃればご教授頂ければ幸いです。

**デフォルトの名無しさん** · 2020/03/30(月) 18:21:13.55

>>329
聞く前に試せばわかるよね

**デフォルトの名無しさん** · 2020/03/30(月) 18:43:59.32

/1SwYHDd氏やるなぁ
こういう細かいことまで知ってる人のRust歴気になる

**デフォルトの名無しさん** · 2020/03/31(火) 00:49:28.04

さっきオナラしようとしたらウンチが少し出てしまったんだけど
ばれてないからいいよね　ごめんね

**デフォルトの名無しさん** · 2020/03/31(火) 03:36:52.65

在宅だったら放屁は自由

**デフォルトの名無しさん** · 2020/03/31(火) 13:51:38.31

う～ん。ちがうなぁ。

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

やりたいこと
Optionからの安全な値の取り出しを構文レベルで保証、およびNone時に数行の処理と戻り値を伴う正常の早期returnをしたい

if Some(v) = foo.get() {
安全に取り出せるがネストが嫌すぎる
} else {
位置が遠すぎる
}

let v = if Some(v) = foo.get() {
v　　　　　　　　安全取り出しだが冗長すぎて嫌
} else {
}

let v = match foo.get() {
Some(v) => v 　　　安全取り出しだが冗長すぎて嫌
None => { }
}

if foo.is_none() {
構文で保証されずプログラマの注意力次第で嫌すぎる
}
let v = foo.get().unwrap();

let v = foo.get().ok_or_else(||{
は？正常終了つってんだろが？エラー値で返すんじゃねえよバカか？
})?;

**デフォルトの名無しさん** · 2020/04/01(水) 08:10:52.28

let v = foo?;

**デフォルトの名無しさん** · 2020/04/01(水) 08:19:02.46

は？

**デフォルトの名無しさん** · 2020/04/01(水) 09:19:54.63

構文を調整したいならマクロじゃない？
let v = safe_get!(v, {
失敗した
return Ok (());
});
みたいな。ベタ書き以外でearly returnしたいならマクロか?演算子みたいにコンパイラサポートがいると思う。

**デフォルトの名無しさん** · 2020/04/01(水) 10:13:55.16

なんでboolって1byteあるの？

**デフォルトの名無しさん** · 2020/04/01(水) 11:20:10.79

C は bit field あるのにな

**デフォルトの名無しさん** · 2020/04/01(水) 11:25:37.12

>>335
map_or_elseでSomeの時とNoneの時に適用するクロージャを渡せる
でもどうしても1行で書きたいとかchainしたい場合じゃなければ普通にmatchかif-else使うな

fn foo(){
get().map_or_else(|| bar(), |x| baz(x))
}

fn foo(){
match get() {
None => bar(),
Some(x) => baz(x)
}
}

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

**デフォルトの名無しさん** · 2020/04/01(水) 11:30:33.60

>>341
クロージャ渡しじゃearly returnできないって話では？