Rust part10

**デフォルトの名無しさん** · 2021/04/02(金) 21:38:04.11

Mozilla発のRust言語のスレ

公式
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 part9
https://mevius.5ch.net/test/read.cgi/tech/1598112455/

**はちみつ餃子** ◆8X2XSCHEME · 2021/05/15(土) 15:37:59.52

>>660
言語を跨いで呼出すときはその境界で色々な処理が挟まったりもするので、
まだらに入り乱れるような形になるとそれはそれで実行性能の足を引っ張ることもある。
状況次第なので一概には言えないけど、言語を変更すると決めたなら
そこそこ大きい単位で乗り換えるのが妥当な場合は結構あると思うよ。

**デフォルトの名無しさん** · 2021/05/15(土) 17:32:17.46

>>661
それはあるね
個人用のツールだとそんなに真面目にテストも書かないから
動的型だと忘れた頃に改修したくなって詰む

**デフォルトの名無しさん** · 2021/05/15(土) 18:53:39.15

>>642
MSがdotnet対応のRust#出したらUnityワンチャンあるんやない？

**デフォルトの名無しさん** · 2021/05/15(土) 19:10:58.08

そこはRust/CLIで。

**デフォルトの名無しさん** · 2021/05/15(土) 21:52:45.98

GCのあるrustに存在意義などない

**デフォルトの名無しさん** · 2021/05/15(土) 22:13:28.16

GCとデストラクタが共存するC++/CLIはなかなか興味深い言語だった。

**デフォルトの名無しさん** · 2021/05/16(日) 11:00:47.47

RustのGCって初期はまた復活されるかもーみたいなノリじゃなかったっけ？

**デフォルトの名無しさん** · 2021/05/16(日) 11:12:01.38

RC関連についてはやるとか？

**デフォルトの名無しさん** · 2021/05/16(日) 12:07:45.66

@ pointerとか ~ pointerとかあった頃の話？

**デフォルトの名無しさん** · 2021/05/16(日) 15:06:48.66

>>665
確かにそっちか
>>666
GCがあるRustって言うよりはunsafeを外部リンクで呼び出してるようなもんだろ

**デフォルトの名無しさん** · 2021/05/17(月) 10:53:44.01

rustが覇権を取るにはPHPみたいにドキュメントの翻訳をたくさん作ること
そしてサンプルコードを盛り込むこと

**デフォルトの名無しさん** · 2021/05/18(火) 19:40:20.00

>2021 Editionは2021年10月にリリースされる。今回のエディションは「Rustの使用感を大きく改善する」ものになるという

あんまり前にこんな発表しないでほしい
やる気なくなる

**デフォルトの名無しさん** · 2021/05/18(火) 19:44:35.79

>>673
ちゃんと発表資料見れば分かるけど、大して使用感変わらんよ
クロージャー使いまくりの人が一番恩恵を受けるかな

**デフォルトの名無しさん** · 2021/05/18(火) 20:19:55.73

所有権は移動するときのほうにマークが出るべきなんじゃあ

**デフォルトの名無しさん** · 2021/05/19(水) 07:47:56.56

まぁコストかかるのはコピーだし

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

Rustの真似をしようとする言語がないのがふしぎだ

**デフォルトの名無しさん** · 2021/05/19(水) 12:30:25.52

https://en.m.wikipedia.org/wiki/Rust_(programming_language)
wikipedia見ただけだけど Crystal, Elm

**デフォルトの名無しさん** · 2021/05/19(水) 12:30:46.25

など影響を与えた言語は列挙されてた

**デフォルトの名無しさん** · 2021/05/19(水) 12:42:47.10

>>678
Elmのどこが？と思ってソースを読んだら
関数型言語なら大体持ってるEither型の名前を Result, Ok, Error にしたところがRust由来とな

うーむ持ってきたのは名前だけなのにInfluencedか

**デフォルトの名無しさん** · 2021/05/19(水) 12:59:40.27

Gleam
https://gleam.run/book/tour/index.html

OwnershipやLifetimeの考え方を採用した言語はまだ聞いたことがない

**デフォルトの名無しさん** · 2021/05/19(水) 13:11:21.07

所有権の考え方を採用している言語としてはC++などがあります

**デフォルトの名無しさん** · 2021/05/19(水) 14:00:04.90

まあインスタンスの共有については何らかの言語サポートが入ってもおかしくないかもね

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

DにもOwnership入ったとか小耳に挟んだだけなら

**デフォルトの名無しさん** · 2021/05/20(木) 17:03:02.09

https://forest.watch.impress.co.jp/docs/news/1325564.html
凄いね

**デフォルトの名無しさん** · 2021/05/20(木) 17:06:31.55

>>685
UIがReactというのが残念

**デフォルトの名無しさん** · 2021/05/20(木) 18:20:18.69

逆に何ならいいんだよ

**デフォルトの名無しさん** · 2021/05/20(木) 18:33:43.55

GUIフレームワークをRustで作るうまみあまりなさそう

**デフォルトの名無しさん** · 2021/05/20(木) 19:39:25.12

Rustで作ってあるなら絶対大丈夫だな！

**デフォルトの名無しさん** · 2021/05/20(木) 22:57:01.82

設計がクソだとダメ
ダメなヤツはなにやってもダメ

**デフォルトの名無しさん** · 2021/05/21(金) 11:45:49.77

>>538
(1)もちろん例外を使わずとも関数呼び出し等がエラー値を返すことで全て実現できます

(2)ところがエラー値が返ってくると毎回if文やmatch等でエラー時はそこですぐreturnする等の処理を書く必要があって面倒かつコードが醜いため例外の使用が好まれました

(3)Rustでは関数の返り値型をResult<T,E>とすることに加えて「?」オペレーター(旧try!マクロ)を使うことで(2)の処理を自動化しました

つまり関数等呼び出し毎にifやmatch等で返り値エラーチェック＆returnの記述をしなくても末尾に「?」を記述するだけで済みます

これでチェーンも出来て具体的には
b = a.hage()?.hige()?.hoge()?
と書くだけでhage()でエラーが返れば早期エラーreturnしますしhige()やhoge()でエラーでも同様です
関数の返り値型がResult<T,E>であることが使用条件です
これはもちろん正常値の<T>型とエラー<E>型のenumです

これらにより関数を多段に深く呼び出していても深い所でのエラーがすぐにreturnを多段にしてエラーが戻って来ます
したがってRustでは例外を使わなくても困らないのです

**デフォルトの名無しさん** · 2021/05/21(金) 13:37:02.96

すまんrust新参者なんだが、Rust By Exampleのコードいじって勉強してて、以下のコードが疑問に感じられた。
以下のプログラムはmain関数内のif文は実行されないとは明らかなんやが、それでもsubの行でいわゆるuse-after-freeのコンパイルエラーが出る。
これはif文が実行されなくてもdropは実行されるということなんですか？
下のコードみたいにuse-after-freeになるかならないかがif文の条件満たすかどうかによって決まるようなプログラムでも
rustでは一緒くたにuse-after-freeになるとみなされるってことなんですね？
そう考えればそこまで賢くないコンパイラですね
struct Droppable {
id: &'static i8,
}

impl Drop for Droppable {
fn drop(&mut self) {
println!("> Dropping {}", self.id);
}
}

fn sub(d: &Droppable) {
if *d.id == 0 {
drop(d);
println!("> Test {}", d.id);
}
}
fn main() {
let _a = Droppable { id: &0 };
if *_a.id == 1 {
drop(_a);
}
sub(&_a);
}

**デフォルトの名無しさん** · 2021/05/21(金) 13:40:53.52

ちなみにコンパイルエラーも貼っておく

Compiling playground v0.0.1 (/playground)
error[E0382]: borrow of moved value: `_a`
--> src/main.rs:22:9
|
18 | let _a = Droppable { id: &0 };
| -- move occurs because `_a` has type `Droppable`, which does not implement the `Copy` trait
19 | if *_a.id == 1 {
20 | drop(_a);
| -- value moved here
21 | }
22 | sub(&_a);
| ^^^ value borrowed here after move //ここでuse-after-free errorが発生！

error: aborting due to previous error

For more information about this error, try `rustc --explain E0382`.
error: could not compile `playground`

To learn more, run the command again with --verbose.

**デフォルトの名無しさん** · 2021/05/21(金) 13:44:28.52

Compiling playground v0.0.1 (/playground)
error[E0382]: borrow of moved value: `_a`
--> src/main.rs:22:9
|
| let _a = Droppable { id: &0 };
| -- move occurs because `_a` has type `Droppable`, which does not implement the `Copy` trait
| if *_a.id == 1 {
| drop(_a);
| -- value moved here
| }
| sub(&_a);
| ^^^ value borrowed here after move //ここでuse-after-free errorが発生！

error: aborting due to previous error

For more information about this error, try `rustc --explain E0382`.
error: could not compile `playground`

To learn more, run the command again with --verbose.

見やすくした

**デフォルトの名無しさん** · 2021/05/21(金) 14:49:33.29

意味のないコードだよ

**デフォルトの名無しさん** · 2021/05/21(金) 14:53:16.15

コンパイラは別に値まで見ないからな
clippyが意味のない分岐だよと指摘してくれるのかどうかは知らんが

**デフォルトの名無しさん** · 2021/05/21(金) 14:55:24.20

>>692
基本的に条件分岐はpredがコンパイル時に評価できる場合でも true/false 両方あり得るものとして扱われるよ
その後の最適化フェーズであり得ないルートは除去されるだろうけど最適化の結果でコンパイルエラー差異が出ないようにする考え方なんだと思われる
無限ループ専用の構文であるloopが導入された背景もたぶんこのあたりにある

**デフォルトの名無しさん** · 2021/05/21(金) 15:52:58.09

>>697
trueのときもdrop、falseのときもdropされるとみなされるということは、
if文によってheap領域で確保しているメモリを解放するかしないか場合分けできないってことじゃん
それって不便では？

**デフォルトの名無しさん** · 2021/05/21(金) 16:14:23.61

>>698 これ元のコード見てみ
これifの条件がtrueだろうがfalseだろうがsub(&_a);は実行されるやん
ifの条件がfalseのときには問題なく実行できるけど､もしifの条件がtrueになって_aがdropされてしまった後にsub(&_a);が実行されてしまうと開放された値を使うことになる
だからRustコンパイラはエラーを吐くんだよ

**デフォルトの名無しさん** · 2021/05/21(金) 16:15:51.92

いや、普通に場合分けはできるが…

どちらかというとifの条件を変えるたびにコンパイルが通ったり通らなかったりするほうが不便では？
そこにifがあるってことは（将来的にとか何らかの条件で）実行される可能性があるからあるんでしょ
もし絶対に実行されないことが確定してるなら書く意味ないし

**デフォルトの名無しさん** · 2021/05/21(金) 16:19:22.28

場合分けしたいならこんな感じで

if *_a.id == 1 {
drop(_a);
} else {
sub(&_a);
}

**デフォルトの名無しさん** · 2021/05/21(金) 17:42:19.92

>>700
言ってる意味がさっぱりわからん
>>692のプログラムにあるとおり
現実問題、将来的に決して実行されるわけがないif文というものは存在するし
if文があるというのは実行される可能性のあるの十分条件でもなければ必要条件でもなわけでもないんやが。
ワイが言いたいのは仮にrustの型システムを無視して>>692のコードをそのままコンパイルしたとしても
if文は実行されないわけだから安全なはずなものまでを省いているというところが不思議だってことや
つまりuse-after-freeバグが現実には起きないコードまでもif文の他の条件でUAFバグが起きるがために
ひとまとめにUAFが起きるとみなすrustコンパイラの姿勢がif文である条件のときだけfreeするコードを書くのを認めないようにみえるという
ワイの感想に繋がってるわけでして

**デフォルトの名無しさん** · 2021/05/21(金) 17:53:39.45

use of moved valueやborrow of moved valueを
use-after-freeとして理解してるのがそもそも間違ってる

The Bookを読んでLifetimeとOwnershipを復習してくれ

**デフォルトの名無しさん** · 2021/05/21(金) 18:00:55.07

>>692のコードをcに書き直してみたらこうなる
} Droppable;
void drop(Droppable* d) {
printf("> Dropping %d", d->id);
free(d);
}

void sub(Droppable* d) {
if (d->id == 0) {
//free(d);
printf("> Test %d", d->id);
}
}
int main() {
Droppable* _a;
_a = malloc(sizeof(Droppable));
_a->id = 0;

if (_a->id == 1) {
drop(_a);
}
sub(_a);
}

**デフォルトの名無しさん** · 2021/05/21(金) 18:01:46.42

これはrustでは弾かれるはずの「if文のある条件のときだけヒープのある部分をfree」というコードのはずだが
安全なCのプログラムや　コンパイルは通るしランタイムエラーも起こさない。
メモリ安全なプログラムの中では、cで書けるプログラムのほうがrustで書けるプログラムより広いんだね
rustはメモリ安全なcのプログラムと同等な処理を書けない部分もあって不便じゃないかっていうのが結局のところワイの疑問になるんや
じゃあrustでは「if文のある条件のときだけヒープのある部分をfree」のコードをどう書くんや？
メモリ安全性を損なってるわけでもない処理ではないはずなんやがrustのコンパイラははじくぞ？

**デフォルトの名無しさん** · 2021/05/21(金) 18:03:27.13

#include <stdio.h>
#include <stdlib.h>
typedef struct {
int id;
} Droppable;
void drop(Droppable* d) {
printf("> Dropping %d", d->id);
free(d);
}

void sub(Droppable* d) {
if (d->id == 0) {
//free(d);
printf("> Test %d", d->id);
}
}
int main() {
Droppable* _a;
_a = malloc(sizeof(Droppable));
_a->id = 0;

if (_a->id == 1) {
drop(_a);
}
sub(_a);
}

ほい完全版

**デフォルトの名無しさん** · 2021/05/21(金) 18:06:23.36

>>705
unsafe使え、というかもうちょっと具体的な例じゃないと困る
今まで出された例だと「最初から絶対通らないの分かってるならif文消せばいい」としか思えないので

**デフォルトの名無しさん** · 2021/05/21(金) 18:12:17.78

別にわざわざCで書いてもらわなくても安全なのは分かるよ
今のRustコンパイラで通らないのはボローチェッカーが最適化前にあるからなんで
部分的にでも先に最適化すれば通るようにはできるだろう
ただそれをしたい動機が分からない
本当にifが実行される可能性が一切ないなら単に消せばいい、といしか言いようがないので

**デフォルトの名無しさん** · 2021/05/21(金) 18:14:06.78

>>703
それただの論点そらしだよね
UAFってrustの独特なメモリ管理手法と相反する用語ではないし
use of moved valueやborrow of moved valueもUAFを阻止するためのものだよね
じゃあrustでは「if文のある条件のときだけヒープのある部分をfree」のコードをどう書くんや？

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

>>709
DroppableのメンバにBox<i8>持たせろ
仮に"drop"された後でもsubが正常に動くことが期待されているなら、そこで使うべきなのはdropではない

**デフォルトの名無しさん** · 2021/05/21(金) 18:22:54.40

というか >>701 で書いたif/elseの例はちゃんと「if文のある条件のときだけヒープのある部分をfree」になっているのに何か不満なのか

**デフォルトの名無しさん** · 2021/05/21(金) 18:24:13.35

>>709
UAFを阻止するためだけにあるものじゃないから
やり方は>>701で教えてくれてるやろ

とりあえずThe Book読んでね

**デフォルトの名無しさん** · 2021/05/21(金) 18:31:38.95

>>709
これでどうですか？
https://play.rust-lang.org/?version=stable&;mode=debug&edition=2018&gist=9b05ca192ab0fd529b6de05dcc64a8c9

**デフォルトの名無しさん** · 2021/05/21(金) 18:38:40.69

>>711
そうやん
rustって不思議やね

**デフォルトの名無しさん** · 2021/05/21(金) 18:44:49.25

解決しました。
なにはともあれありがとうございました。>>701の方に救われました。
ここまで関わってくださった皆様まことに協力ありがとうございました。感謝いたします。

**デフォルトの名無しさん** · 2021/05/21(金) 19:24:50.36

「理論的に安全な任意のコードは通るべき」ってイメージだったのかな
実際にはそんなことはなくて、上の例のようなコードを通すためには色々なトレードオフがあるから
単に「理論的に安全」ってだけで無条件に実装されることはない
もっと具体的なユースケースがあって、みんなが「これは通らないと不便だよね」ってなったものが実装される
数年前に実装されたnon lexical lifetimesなんかはまさにその例だね

**デフォルトの名無しさん** · 2021/05/21(金) 19:31:11.66

はぎゃーん

**デフォルトの名無しさん** · 2021/05/21(金) 21:43:48.32

クロージャの disjoint capture が破壊的変更になるのは分かるんだけど最初からこうなってなかったのはなぜ？

**デフォルトの名無しさん** · 2021/05/21(金) 22:34:26.09

iter()とinto_iter()の使い分けが分からない

iter()じゃないといけない場合があるのは分かるんだが

**デフォルトの名無しさん** · 2021/05/21(金) 22:49:37.59

into_iterは所有権を奪いItemを得ることができる
iterは&Itemを得る
他のintoで始まるものは所有権を奪うことになってる

**デフォルトの名無しさん** · 2021/05/21(金) 23:22:44.96

>>711 Rustコンパイラが問題視してるのは開放された値を使ってしまう可能性があることで､それが修正された >>701 のコードは問題ないから通る

**デフォルトの名無しさん** · 2021/05/22(土) 00:04:28.82

>>719
Rustでの変数の受け渡し方は
by (shared) reference、by mutable reference、by valueの3つなので
それに対応していろいろなものが3種類1セットになってる

イテレータならiter(), iter_mut(), into_iter()
クロージャならFn, FnMut, FnOnce
コンバージョンならAsRef, AsMut, From/Into

**デフォルトの名無しさん** · 2021/05/22(土) 00:34:10.91

as_foo(), to_foo(), into_foo() の違いも覚えておくとよいかもね

**デフォルトの名無しさん** · 2021/05/22(土) 00:45:11.88

覚えておくとはいいのはそうだけど、そのセットは少し観点違うよね
https://rust-lang.github.io/api-guidelines/naming.html#ad-hoc-conversions-follow-as_-to_-into_-conventions-c-conv

**デフォルトの名無しさん** · 2021/05/22(土) 16:34:10.81

Rustややこしいわぁ

**デフォルトの名無しさん** · 2021/05/22(土) 20:26:18.21

Rust慣れたあと他の言語行くと
良い作法が身についてて歓迎される、とかありますか？

**デフォルトの名無しさん** · 2021/05/22(土) 20:30:50.12

>>726
言語が異なれば同じことをするにも良い作法とされる方法は異なるだろうし、そんなに役に立たないかもよ。
むしろRustでは～と言い出すとかえってうるさがられる可能性も。

**デフォルトの名無しさん** · 2021/05/22(土) 20:34:58.75

rustでは変数のshadowing当たり前のように使うけど他の言語では嫌がられそう

**デフォルトの名無しさん** · 2021/05/22(土) 21:08:16.57

let value = value;
とか他言語で書いたらアホだと思われるし

**デフォルトの名無しさん** · 2021/05/22(土) 21:10:13.17

Rustはメイン関数かその次の関数のローカル変数にリソースを保持する形にしがちじゃない？
他の言語だとあんまりやらない

**デフォルトの名無しさん** · 2021/05/23(日) 03:12:09.36

>>730
他の言語でも同じだよ
それとも禁断のグローバル変数を使う駄目パターンをRustでもしたいということ？

**デフォルトの名無しさん** · 2021/05/23(日) 06:28:03.88

pythonみたいな動的型付け言語ではよう見るけどさ
Rustではこんなん要らなくしてほしいわ

**デフォルトの名無しさん** · 2021/05/23(日) 13:14:57.61

ライブラリによってはデータを持ち運ぶということが不可能だったりするからグローバル変数必須だったりするんだよな
(具体例: serenity)

**デフォルトの名無しさん** · 2021/05/23(日) 13:33:01.51

いや別に必須ではないだろ。

**デフォルトの名無しさん** · 2021/05/23(日) 13:39:52.69

log!() みたいなプログラムの各所から呼び出されるマクロや関数の実装の為には rust でも普通にグローバル変数使われているのでは

static 変数にするためには Sync が要求されたり mut にするために Mutex 使う必要があるから他の言語ほど気楽に使えないというだけで
グローバル変数そのものが禁断扱いされることはないかと

グローバル変数の濫用は他の言語同様嫌われるけどね

**デフォルトの名無しさん** · 2021/05/23(日) 13:43:31.31

一般的にどんな言語においても何らかの外部のライブラリを取り込む時には
何か一つのクラスとかオブジェクトとか構造体とかに閉じ込めてしまって
それ一つだけ持ち運ぶからグローバル変数を使うことは無いでしょう

**デフォルトの名無しさん** · 2021/05/23(日) 16:18:03.34

>>735
static変数とglobal変数はスコープが違うだろ
global変数が悪とされるのは、そのスコープの広さだからね

いつどこで誰が変更するのか、また参照するのか、スコープが広ければ広いほど把握が困難になる
把握が困難になればなるほど、それだけバグを生む温床になる

**デフォルトの名無しさん** · 2021/05/23(日) 18:34:32.71

io周りは極論すればどう管理してもグローバルだからな。
プロジェクト毎に規約設ける以外にまともに管理する方法なんてない。

**デフォルトの名無しさん** · 2021/05/23(日) 20:09:32.32

>>735
そういやロガーの設定ってどこに保存されてるの？
debug!() 呼ぶたびにMutexロックしてるのかな？

**デフォルトの名無しさん** · 2021/05/24(月) 12:11:21.84

>>736
クラスの中に入れても、グローバル変数であることは避けられないし
どんな言語においてもグローバル変数は必要。

**デフォルトの名無しさん** · 2021/05/24(月) 12:28:02.03

「:?」ってなんなんですか？
https://tourofrust.com/08_ja.html

**デフォルトの名無しさん** · 2021/05/24(月) 12:49:55.25

>>741
デバッグ用のフォーマットで出力するという意味
詳しくは以下参照
https://doc.rust-lang.org/std/fmt/

**デフォルトの名無しさん** · 2021/05/24(月) 13:24:07.35

>>740
そんなことはないだろう。
確かにグローバルでも大して変わらんてものはあるけど、
loggerを引数で渡していくっていうような実装方法もある。

**デフォルトの名無しさん** · 2021/05/24(月) 13:33:20.21

>>739
logクレートのstatic mut変数だね
ロックするのは初期化とレベル設定時だけ
出力時にロックするかどうかは実装次第

**デフォルトの名無しさん** · 2021/05/24(月) 15:43:10.46

>>740
そのクラスの存在そのものがグローバル変数(相当)だという話？
それともそのクラスもしくはそのインスタンスをグローバル変数に入れて使うということ？
後者の意味ならば必要な範囲で引数として持ち歩けばグローバル変数を普通は使わないですよね。

**はちみつ餃子** ◆8X2XSCHEME · 2021/05/24(月) 16:59:24.57

大事なのは抽象化がきちんとしているかどうか。
各部品が妥当な意味に分離されているかどうか。

グローバル変数がよくないのは色んなパーツから横断的に使われる可能性があって
部品が不必要に密結合していることの表れだからであって、
そのグローバル変数のアクセス範囲が妥当な範囲に制御されているなら問題じゃないよ。

過剰な密結合を解消せずにグローバル変数を引数に置き換えてたら
影響範囲が見えにくくなってもっと悪くなることだってありうる。

まあどういう場合なら妥当なのかってのは色々と意見はあると思うけど。

**デフォルトの名無しさん** · 2021/05/24(月) 17:17:23.03

$_POSTはセーフ

**デフォルトの名無しさん** · 2021/05/24(月) 17:21:32.94

>>746
まずは長くて区別しやすい名前に変えるのがスタートかね。

**デフォルトの名無しさん** · 2021/05/24(月) 17:31:54.98

>>742
ありがとう！なんか独特なのね

**デフォルトの名無しさん** · 2021/05/24(月) 23:12:37.25

関数型言語やったことないけど、Rustいけるかな
JavaとC++はそこそこ経験あり

**デフォルトの名無しさん** · 2021/05/24(月) 23:17:37.88

Java 8とかC++ 14以降くらいなら結構似たような機能も入ってるし
そこまで大変じゃない気がする

**デフォルトの名無しさん** · 2021/05/24(月) 23:36:00.17

c++はともかく、cくらいはやっぱ理解してた方が早道な気はする。

**デフォルトの名無しさん** · 2021/05/25(火) 01:36:21.07

以下のような関数を作ったんですがmatchが多くてどうしようか考えていました

fn foo(x: Option<u32>, y: Option<&str>) { //実際はOptionが5個とか
let x = match x {
Some(x) => x,
None => return,
};
let y = match y {
Some(y) => y,
None => return,
};
println!("{} {}", x, y);
}

考えついたのが、次のようにする方法なのですが、
fn foo(x: Option<u32>, y: Option<&str>) -> Option<()> {
let x = x?;
let y = y?;
println!("{} {}", x, y);
Some(())
}

記載の省略のためだけに返値の型をOption<()>にして最後にSome(())つけるのがすごく気持ち悪いんですが、
返値なしのままどうにかする方法はないでしょうか

**デフォルトの名無しさん** · 2021/05/25(火) 02:11:48.11

if_chain使って
if_chain!{
if let Some(x) = x;
...
then { println!("{}", x); } }

**デフォルトの名無しさん** · 2021/05/25(火) 02:16:51.35

>>753
fooの型変えられないなら、戻り値Optionはクロージャないしローカル関数に留めるといいと思う
https://play.rust-lang.org/?version=stable&;mode=debug&edition=2018&gist=aa2bc019e7329f1b6bece2597b59ee8a

**デフォルトの名無しさん** · 2021/05/25(火) 03:00:10.05

Ok(())はよく使うがSome(())はないな

普通にif-letでパターンマッチするのでよくない？
if let (Some(x), Some(y)) = (x, y) {
println!("{} {}", x, y);
}

**デフォルトの名無しさん** · 2021/05/25(火) 05:18:39.47

loggerを引数で渡すためには
ロギングを行うクラスFooがどこかしら（コンストラクタか個々のメソッドで）loggerを受け取る引数を持たねばならない
これ、ロギングみたいな裏方の仕事がFooのインターフェース仕様に影響しているということで、
抽象度が下がってるやんけ；；；

引き換えに得られるメリットは、Fooのインスタンスごとにloggerを切り替えられるというおおよそ現実的にありがたみが無い機能だけ

**デフォルトの名無しさん** · 2021/05/25(火) 06:08:48.35

>>756
それをmachでやるのがよくない？

**デフォルトの名無しさん** · 2021/05/25(火) 06:23:40.79

つか機能の分離と記述の分離はトレードオフがある
1+1=2の形式的証明がどんだけの糞みたいな分量のに成り得るかを見たらﾜｶﾙ
どっかの抽象度をつきつめれば別のところにしわ寄せが逝く
それで良いｼﾞｬﾏｲｶ人間の言語だもの、

**デフォルトの名無しさん** · 2021/05/25(火) 09:01:56.56

皆様ありがとうございます
どうもSomeをある程度書くのは避けられない感じですね

**デフォルトの名無しさん** · 2021/05/25(火) 10:09:28.07

まさかstatic変数使ってるなんて、logクレートには失望したわ