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/08/24(火) 22:59:11.03

次スレは>>980が立ててくださいな

**デフォルトの名無しさん** · 2021/08/24(火) 23:25:20.99

980ですゴメンナサイお詫びに

Rust The Book (日本語版)
https://doc.rust-jp.rs/book-ja/
Rust edition guide (日本語版)
https://doc.rust-jp.rs/edition-guide/
Rust by example (日本語版)
https://doc.rust-jp.rs/rust-by-example-ja/
Rust cookbook (日本語版)
https://uma0317.github.io/rust-cookbook-ja/
Rust API guideline (日本語版)
https://sinkuu.github.io/api-guidelines/
Rust nomicon book (日本語版)
https://doc.rust-jp.rs/rust-nomicon-ja/
Rust WASM book (日本語版)
https://moshg.github.io/rustwasm-book-ja/
Rust embeded book (日本語版)
https://tomoyuki-nakabayashi.github.io/book/
Rust enbeded discovery (日本語版)
https://tomoyuki-nakabayashi.github.io/discovery/

**デフォルトの名無しさん** · 2021/08/24(火) 23:38:41.54

Rust CLI (Command Line Interface) apps Book
https://rust-cli.github.io/book/
Rust async-std Book
https://book.async.rs/
Rust The Unstable Book
https://doc.rust-lang.org/nightly/unstable-book/
Rust rustc Book
https://doc.rust-lang.org/rustc/
Rust Cargo Book
https://doc.rust-lang.org/cargo/

**デフォルトの名無しさん** · 2021/08/25(水) 02:49:11.51

>>1
乙です。

**デフォルトの名無しさん** · 2021/08/25(水) 03:59:04.43

The Rust Reference
https://doc.rust-lang.org/reference/
The Rust Standard Library
https://doc.rust-lang.org/std/

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

前スレで循環参照なんて初心者でもすぐ作れてしまうとの意見もあったけど
Rc型を使うだけの初心者には原理的に不可能
内部可変性を与えるRefCell型も併用しないと循環参照は作れない
一つの可変参照&mutか複数の不可変参照&のどちらかのみ許されるコンパイル時確認ルールを実行時確認ルールで行なうのがRefCell型
それにより明示的に可変参照を得ることで内部可変性を持てるようにしたもの
そしてRcと組み合わせてRc<RefCell<T>>を使うことで既にあるリンクを書き換え出来るようになりようやく循環参照を作れる
もちろん自分でunsafeすればやりたい放題てすがunsafeせずともメモリ安全性ルールの元に使えます
ここまで出来る人なら強参照Rcだけでなく弱参照Weakも併用できますから循環参照を避けることも出来るでしょう

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

マーフィーの法則
失敗する余地があるなら、失敗する

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

テンプレートがやたらたくさん入り乱れる言語は嫌いだわ
可読性めちゃくちゃ悪いよな

**デフォルトの名無しさん** · 2021/08/25(水) 10:40:52.46

>>7
そこまでできてやっとRust初心者という見方もあるかもしれない

**デフォルトの名無しさん** · 2021/08/25(水) 11:24:43.65

直接関係ないけど、RefCellは借用チェックが実行時段階でのチェックになって
しまうんだってな。

**デフォルトの名無しさん** · 2021/08/25(水) 11:34:25.36

>>11
長文だから>>7をスルーしたな？

**デフォルトの名無しさん** · 2021/08/25(水) 11:41:16.58

RefCellの借用チェックが実行段階にまで持ち越されるのは、循環参照とは全く別の話。
それはつまり、「ゼロコスト」ではないということ。

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

>>7
Rc<RefCell<T>>じゃなくてRefCell<Rc<T>>だね
気持ちはよく分かる

**デフォルトの名無しさん** · 2021/08/25(水) 12:30:44.27

>>14
どっちもあるけど通常はRc<RefCell<T>>だよ

**デフォルトの名無しさん** · 2021/08/25(水) 13:42:20.13

>>983
なるほどサンクス
リージョン理論に線形論理を上手く組み合わせて、cycloneとかの欠点を克服したrustってすげーなあ
とはいってもそもそも二重開放してエラーになるというのがピンとこない
free(a);
free(a);
は二重解放しているように見えて合法だろ？
一度目のfreeでaにNULLが代入されて、二度目のfreeでは引数がNULLの場合はそのままreturnって処理されるんだから、理論上は何度free使ってもエラーにならないじゃないか

**デフォルトの名無しさん** · 2021/08/25(水) 13:42:36.69

これに答えろ

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

>>16
なぜRustのスレに書いているのか不明だけど
当然NULLにならなかったよ

キャスト警告無視で
#include <stdlib.h>
main() {
　char *ptr = malloc(1024);
　printf("ptr(1): %x\n", ptr);
　free(ptr);
　printf("ptr(2): %x\n", ptr);
　free(ptr);
　printf("ptr(3): %x\n", ptr);
}

実行結果
ptr(1): ea8f72a0
ptr(2): ea8f72a0
free(): double free detected
core dump

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

>>11
静的にチェックできないような使い方を実現するためのものなんだから
実行時チェックになるのは当然では
オーバーヘッドが気になるなら UnsafeCell を使えばよい

>>16
C には参照はないので free(a) という呼び出しで a の値が書き換わることはなく malloc で獲得した領域のアドレスがそのまま残る
領域自体は free で解放済みになっているため、アクセス (free 呼び出し含む) した場合何が起きるか分からない
このような解放済みの領域へのアクセスは use-after-free と言われるもので、脆弱性の原因として有名

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

>>18
なるほど
free内で代入されるのではなく
自分で代入しないとNULLにはならないのですね。
ありがとうございました。

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

そういやNull代入派とかいうのもいたな

**デフォルトの名無しさん** · 2021/08/26(木) 07:18:01.38

uaf防ぐのってぶっちゃけ簡単ですよね？freeしたあとにNULL代入するのを鉄則化するだけですよね？

**デフォルトの名無しさん** · 2021/08/26(木) 07:18:53.92

ポインタコピーすることないの？
加減算することないの？

**デフォルトの名無しさん** · 2021/08/26(木) 07:42:26.49

int* p1 = malloc(sizeof(int));
int* p2 = p1;
free(p1);
p1 = NULL;
free(p2);

極端に書くとこうかなあ？

**デフォルトの名無しさん** · 2021/08/26(木) 08:58:05.69

>>22
1つのオブジェクトを複数のポインタで挿している場合にそういうわけにはいかない。

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

>>25
誤字訂正: 挿して ---> 指して

**デフォルトの名無しさん** · 2021/08/26(木) 14:46:24.90

>>25
複数のポインタにそれぞれNULL代入したらいいだけの話ですよね？
難しい話ですか？

**デフォルトの名無しさん** · 2021/08/26(木) 14:52:56.47

>>23
加減算考慮するとなんかやばいんですか？
本当に素人なので教えてください！！

**デフォルトの名無しさん** · 2021/08/26(木) 14:53:33.93

>>24
p2=NULL;すればいいだけの話ですよね？

**デフォルトの名無しさん** · 2021/08/26(木) 14:54:04.18

Cスレでやれよ

**デフォルトの名無しさん** · 2021/08/26(木) 14:55:34.47

>>27
効率が落ちる。

**デフォルトの名無しさん** · 2021/08/26(木) 15:01:32.05

>>27
プログラミングをしたことがなく
頭の中での思考実験もできないのか
プログラマーに向いていない

**デフォルトの名無しさん** · 2021/08/26(木) 15:04:39.60

手で書くと効率は落ちないが、実行段階で自動的に NULL を入れようとすると
効率が落ちるという意味ね。時間とメモリーの両方で。
NULLが入っているか判定して error にするなどの処理も必要となったりする。

**デフォルトの名無しさん** · 2021/08/26(木) 15:06:19.25

>>27
難しいです…

**デフォルトの名無しさん** · 2021/08/26(木) 15:11:05.26

>>32
すみません。
おっしゃるとおりかも知れないです。。

**デフォルトの名無しさん** · 2021/08/26(木) 15:12:24.56

>>31
>>33
そんなに効率が落ちますか？

**デフォルトの名無しさん** · 2021/08/26(木) 15:18:41.61

>>36
凄く落ちるわけではないが。

**デフォルトの名無しさん** · 2021/08/26(木) 15:21:09.64

>>36
参照カウンタ方式は、自動的に関連するポインタを巡ってNULLを入れるよりは
効率が良いのでプログラマーの裁量で選択できるようになっている。
しかし、それでも僅かに効率が落ちるのでなるべく使わないでプログラムする
方が良いと思うプログラマーが多いということだよ。

**デフォルトの名無しさん** · 2021/08/26(木) 15:24:37.81

プログラマーならば、まず思考実験、それで解決しなければコーディング
その上で問題点を尋ねる
それをしない人はプログラマーではないから、このスレの邪魔

**デフォルトの名無しさん** · 2021/08/26(木) 15:24:45.61

>>38
そんな僅かな効率の低下でも忌避されるんですね！！
わかりました！！

**デフォルトの名無しさん** · 2021/08/26(木) 15:25:39.02

>>39
こわい。。

**デフォルトの名無しさん** · 2021/08/26(木) 15:25:45.57

手作業で書く場合は、1つのオブジェクトを削除する場合、それを参照する
全てのポインタに NULL を入れるのは効率が良い。だから、多くのC/C++
プログラマはかつてそうしてきたし、今でもそうすることも多い。
ところが自動でそれをやるには静的解析は難しいので実行段階でも
余計なメモリーを追加で消費して行うことになる。それが効率が悪い。
そして、NULLが入っているかどうか分からないのでその参照を
使う場合には、いつも最初にNULLが入ってないことを確認してから
作業をする必要があり、その判定に 2 クロックくらいかかる。
この2クロックが忌避される。

**デフォルトの名無しさん** · 2021/08/26(木) 15:26:04.39

>>7
言ってる事はかねがね同意ですが、プログラムが共同作業の為にRefCell<Rc<List>>とA氏が定義してあるものに
違う人B氏が何も考えずにRc::clone(&a)で循環を入れてしまう事は十分あり得るでしょう。
状況次第ですが循環参照を考慮してないA氏が悪いのか、Rc::clone(&a)でぶち込んだ人が悪いのかは要件次第ですが
これを簡単と言わずに（あなたは言っていませんが）難しいと表現するのは違和感がありますよ

**デフォルトの名無しさん** · 2021/08/26(木) 15:28:09.24

>>42
詳しい解説ありがとうございますm(_ _)m
メモさせていただきます。

**デフォルトの名無しさん** · 2021/08/26(木) 15:28:30.66

>>37
嘘を教えたらあかんやろ
N人の人が自分を指しているとして
まずそのN人をどうやって知る？

**デフォルトの名無しさん** · 2021/08/26(木) 15:29:12.92

>>45
自力で数えればいいんではないでしょうか？

**デフォルトの名無しさん** · 2021/08/26(木) 15:30:36.47

>>40
まあ、そういうこと。
というのは、参照カウンタも、1つのヒープノードに対して必ず1つ必要になるので、
ノード数が多いときには膨大なメモリーの無駄になるから。
それとノード数が多いときに参照カウンタを 0 クリアしたり、1足したり
する作業も馬鹿にならないと考えるプログラマが多い。

なぜかというと、そういう自動化を行わなくても、人が頭で考えて手作業で
NULLを入れても十分に安全にプログラムできるプログラマが多かったからだよ、
少なくとも昔のCプログラマには。
手作業でやってもとくに危険を感じないので、効率を落としてまで自動化する
必要が無いと思われている。
手作業でNULLを入れるのは難しくない。
ところが、コンパイラが自動で効率を落とさずにそれをやるのはめちゃくちゃ難しい。
それは人間の脳がそれだけ優秀だということだよ。

**デフォルトの名無しさん** · 2021/08/26(木) 15:31:47.17

>>45
手作業で人間が頭で考えたら、難しく感じないプログラマが多かった、という
ことだよ。
難しく感じるプログラマも居る。
数学の才能だと思う。

**デフォルトの名無しさん** · 2021/08/26(木) 15:32:40.17

コピーしたポインタを別スレッドに転送とかしてたら、いつNULL代入すべきかすら分からんしなぁ

**デフォルトの名無しさん** · 2021/08/26(木) 15:32:44.57

>>48
ああ、自動化の効率面の話か。
凄く効率が落ちるわけではないよ。
リンクで辿るだけだから。

**デフォルトの名無しさん** · 2021/08/26(木) 15:42:17.45

>>47
違うだろ
ある時点でNヶ所から指されているとして
そのNヶ所をどうやって知る？誰がどのようにNヶ所を管理する？

**デフォルトの名無しさん** · 2021/08/26(木) 15:43:01.48

>>51
僕がです。

**デフォルトの名無しさん** · 2021/08/26(木) 15:46:08.68

>>51
静的解析はコンパイラには難しいが、動的なら簡単。
人間にも、「一般性を持って」は分かる方法は無い。

**デフォルトの名無しさん** · 2021/08/26(木) 15:47:35.53

言っておくが現実世界では俺は天才だと言われているから、俺が簡単だと
思うことは、大部分のプログラマには難しいと思うかもしれないがな。

**デフォルトの名無しさん** · 2021/08/26(木) 15:48:12.84

>>52
データ構造は入出力の変化に伴いどんどん変化していく可能性がありますから人間は覚え追いきれないよね
さらに一つのmalloc毎にそれぞれそこをポイントしている利用者の数も利用者数も異なりますよね
それらのデータをどこでどうやって管理するつもりですか？

**デフォルトの名無しさん** · 2021/08/26(木) 15:54:12.28

まず前提が誤りです
変化を追えば覚えられます
思考実験できないんですか？

**デフォルトの名無しさん** · 2021/08/26(木) 16:04:38.88

>>56
利用者リストを覚えておくためにメモリが必要やね
それもmallocするか
mallocで取ってきたメモリ管理のために更にmallocが必要となってしまったぞ
利用者が増えてきたら利用者リストの領域が足りなくなる
またmallocするか
全てにNULLを入れるためだけに大がかりになってきたな
この方法は本当に大丈夫なのか？

**デフォルトの名無しさん** · 2021/08/26(木) 16:08:02.62

>>57
静的に確認すればすむ話です

**デフォルトの名無しさん** · 2021/08/26(木) 16:17:15.72

データが育っていったら100か所からリンクされるとか普通によくあるわけだが
その100か所にNULLを代入しにいくために100か所の場所をリストで持つのか
しかもmallocした各データ毎にリストを持つのか
全てにNULL代入はあきらめた方がいいんじゃね？

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

アクセスするとたちまち例外発生するぬるぽにはどんなデータが格納されているのだろうか

**デフォルトの名無しさん** · 2021/08/26(木) 16:23:55.37

int* p1 = malloc(sizeof(int));
int* p2 = malloc(sizeof(int));
int* p3;
if (なんかの条件) p3 = p1; else p3 = p2;
free(p1);
p1 = NULL;
// p2はまだまだ使う

こういうときp3はどうするのかっていう

**デフォルトの名無しさん** · 2021/08/26(木) 16:28:43.55

すべてのヒープを**ptrで管理すればできなくもない気がする
参照するたびに有効かチェックしないといけないから激しく面倒だけど

**デフォルトの名無しさん** · 2021/08/26(木) 16:29:37.04

>>61
なるほど
参考になります
回答してくださってありがとうございました。

**デフォルトの名無しさん** · 2021/08/26(木) 16:32:51.02

>>62
その**ptrの格納領域の確保がデータ事に発生
しかも伸長してしまいますね

**デフォルトの名無しさん** · 2021/08/26(木) 16:33:25.33

何の参考だよ

**デフォルトの名無しさん** · 2021/08/26(木) 16:36:08.26

https://twitter.com/cpp_akira/status/1430779310885859330
最近はC++の発表資料を公開すると「Rustでいいじゃん」というコメントがたくさんつくのか…。Rustへの言及とか一文字も書いてないのに。
普及活動だと思うけど、さすがに嫌がらせチックに見える。

↓の資料公開した時の話っぽいんだけど、Rustでいいじゃんって言われてるソースが見つからない・・・
https://speakerdeck.com/faithandbrave/opunhua-gajin-muc-plus-plus-falsexian-zhuang-tozhan-wang

言われててもおかしくないとは思うけど、実際のところどうなんすかねえ
アロケータ回りがまだ弱いから少なくともゲームは10年後もC++のが強そう
https://twitter.com/5chan_nel (5ch newer account)

**デフォルトの名無しさん** · 2021/08/26(木) 16:38:42.43

>>27
まだ利用者がいるのに全てへNULL代入しにいく時点で破綻
つまりまだ自分以外の誰かが利用中かどうかを知らないといけない
つまり利用者リストを管理する必要がある

**デフォルトの名無しさん** · 2021/08/26(木) 16:39:16.76

おまえらスレチがすぎるぞ
まとめてどっかいってくれ

**デフォルトの名無しさん** · 2021/08/26(木) 16:43:10.20

>>66
Rust はメモリ安全性を保証することが論文で示されているので
どうしてもC++でないと出来ないこと(＝まだRustが対応してないこと)であることを示さないと
「Rustでいいじゃん」となってしまうのは仕方ないかも

**デフォルトの名無しさん** · 2021/08/26(木) 17:32:35.75

Rustは言語仕様が未確定なのが懸念事項かな
実用上は大して困らないからどうでもいいんだけど
期待してたRust Foundationは何故かディレクター探し始めてるしｗ

**デフォルトの名無しさん** · 2021/08/26(木) 17:40:08.48

>>70
2018editionに2019のasync/awaitゼロコストサポートで言語としては完成でしょ？

**デフォルトの名無しさん** · 2021/08/26(木) 17:48:35.66

>>70
それを期待するならFoundationよりこっちかな
https://ferrous-systems.com/ferrocene/
2022年末にASIL-B認証が目標

**デフォルトの名無しさん** · 2021/08/26(木) 18:01:26.94

>>69
どの論文だよ

**デフォルトの名無しさん** · 2021/08/26(木) 22:38:09.77

>>71
まだOpenなRFCいくつあると思ってるんだ

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

そんなこと言い出したら他の言語も未完成
永久にね

**デフォルトの名無しさん** · 2021/08/26(木) 23:45:46.81

でもSchemeとか言語仕様も形式意味論も定まってるし

**デフォルトの名無しさん** · 2021/08/26(木) 23:50:11.85

とりあえず
https://doc.rust-lang.org/stable/reference/
のWarningを消してくれるだけでいいんだ
2018版だけでも確定できないのかな

**デフォルトの名無しさん** · 2021/08/26(木) 23:57:00.95

確定できないというよりメンテする人がいないんじゃないかな
言語仕様に詳しいけどコード書くよりドキュメント書きたいっていう奇特な人が要求されるわけで

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

ferroceneみたいに具体的な目標があって企業が投資してるなら進むだろうけど
リファレンスの更新とかあまり需要もないじゃない？

**デフォルトの名無しさん** · 2021/08/27(金) 00:16:19.30

完全な仕様書は間違いなく必要ではあるよな。

**デフォルトの名無しさん** · 2021/08/27(金) 00:25:02.14

完全な仕様書www
どんだけ素人なんw

**デフォルトの名無しさん** · 2021/08/27(金) 00:25:46.96

第三者が処理系を作れるレベルで言語仕様が固まれば普及が進むと思うんだけどね
Rust Foundationにはそういう方向性を期待してたけど想像以上に何もしなかった

**デフォルトの名無しさん** · 2021/08/27(金) 00:39:02.98

Foundationはもともと裏方に徹する組織だと言ってたし
その通りに動いているのでは
最近だとgccrsのライセンス絡みの知財チェックとかやってたかと

**デフォルトの名無しさん** · 2021/08/27(金) 00:45:32.58

言語仕様が固まるってのは新機能の追加をやめるということ？

**デフォルトの名無しさん** · 2021/08/27(金) 00:49:06.81

言語仕様とコンパイラのバージョンが一体化しているようではミッションクリティカルな領域で採用されない

**デフォルトの名無しさん** · 2021/08/27(金) 01:13:55.67

>>84
厳密に運用するなら機能を追加するときは言語仕様のバージョンも上げる
固めるのは言語仕様の１つのバージョンってだけで言語の進化をとめるわけじゃないよ

**デフォルトの名無しさん** · 2021/08/27(金) 01:28:41.09

>>84
現状では「今そのように動いている処理系」と「処理系の (不十分な) ドキュメント」がある状態で、
それのどこからどこまでが言語仕様として満たすべき要件なのか保証されている動作なのかがわからない。
追加するも何も今の時点でどうなっているのかわからん。

どこかにはあったりもするんだろうけど、開発者向けの議論の中などに分散していて「仕様書」としてまとまってないんだ。

**デフォルトの名無しさん** · 2021/08/27(金) 02:31:48.28

安全性は型システムによるところが大きいから、仕様書が無いと使えないというのは無いと思うがね

**デフォルトの名無しさん** · 2021/08/27(金) 02:39:18.77

コンパイラだってバグがない保証なんてないんだから
テストするしかないね

**デフォルトの名無しさん** · 2021/08/27(金) 02:39:45.83

ISO 26262のコンパイラ認証とか無理そう

**デフォルトの名無しさん** · 2021/08/27(金) 07:59:32.64

LLVMの中間表現に依存してる時点で、言語仕様をまともに設定するのは無理。
だから他のコンパイラが作られることもない。

**デフォルトの名無しさん** · 2021/08/27(金) 08:07:16.05

仕様書、仕様書言っている人はOSやライブラリのAPIとかシステムコールとかはどう考えているんだろうね
MSDNだって盲信できるほどの信頼性はないし、OSS系なんてソースコードが仕様書状態だろ
もっと言えば処理系だってオプティマイザの仕様などは文書化されていなく、実際に調査しないと判らない事も多いよな

**デフォルトの名無しさん** · 2021/08/27(金) 08:07:24.55

こんな状態じゃc++の置き替えなんて夢のまた夢だな。

**デフォルトの名無しさん** · 2021/08/27(金) 08:43:05.29

完全な仕様書wがないのが問題だ思うなら使わなければいいだけ
クッソ無駄なやりとりでスレ消費すんな

**デフォルトの名無しさん** · 2021/08/27(金) 08:54:32.00

少なくともC++はもっとずっと細かな仕様が書いてある。
例で説明する時でも、変な例で説明せずに数学の教科書の様な粒度の細かい例で
説明されているで、数学の教科書の様な雰囲気を持っている。
Rustの場合、ライフタイムの説明をとってみても、ちゃんとした数学的説明になってない。

**デフォルトの名無しさん** · 2021/08/27(金) 08:57:07.99

時々プログラミングは文系でも出来るという人が居るが、そういう人には、
数学的な説明とは何かがぴんと来ないかもしれないので、良い仕様書も
書けないかもしれない。Rustのbookの著者ももしかしたらそうなのかも。
本人は頑張って書いているつもりでも数学的な論法になってない。

**デフォルトの名無しさん** · 2021/08/27(金) 09:04:15.77

高校数学レベルで言えば、ベクトルの和の定義は図で例を使って説明されるが、
3つの矢印で、c = a + b が説明される。
これは最も粒度が細かい説明で、これ以上簡単に説明できない。
ところがRustのライフタイム注釈の説明は、説明に使われている例が不適切で
とても長いが本質が説明し切れてない。
本来は、「ライフタイム注釈とは何か」を数式や擬似命令などを使ってせいぜい2ページ以内で
説明できるはずだ。
ところが実際の説明は、変な例を使って長々と説明されている。
数学的な説明になっていないので応用が効かない。
数学的説明とはほとんどの場合「パターン」だ。パターンになっているから応用が効く。
パターンとして説明されてないと応用が効かない。

**デフォルトの名無しさん** · 2021/08/27(金) 09:06:37.74

コンパイラが一つしかない状況は現状メリットでしかない

C++のようなレガシー言語の轍を踏まない賢い選択

**デフォルトの名無しさん** · 2021/08/27(金) 09:11:46.45

数学的説明にしたいなら、
「仮定」を置く。
「入力」と「出力」を明確にする。
「最も粒度の小さい例を書き、パターン」にする。
集合論や論理学の「かつ」「または」「積集合」「和集合」「背反集合」「区間の積」
などの言葉を使って書く。
ところが、Rustのbookはこのようなことが全く出来てない。

**デフォルトの名無しさん** · 2021/08/27(金) 09:15:12.91

>>98
仕様書が数学的(パターン的、自動機械的)に書いてないので、厳密な
仕組みや仕様が分からず、他の人がコンパイラが作りにく。
だから、「Rustは実験してみないと分からない」。
ところが、CやC++やRuby,Java,C#,Pythonなどは実験しなくても分かる
ようになっている。それはなぜかというと、仕様が粒度が細かく説明されて
いるから、パターンになっており「パターンの一部への代入」や「当てはめ」
が出来るので頭の中だけで全てプログラミングできてしまうから。

**デフォルトの名無しさん** · 2021/08/27(金) 09:17:17.15

今日のNGIDがすぐ分かって助かった
感謝感謝

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

ちょっと難解だが高速なスクリプト言語としては使えるとは思う。
でもC++の置き換えは難しいな。
なぜならC++で出来ていたことがRustには移植できないから。

**デフォルトの名無しさん** · 2021/08/27(金) 09:47:25.61

算数がクラスで一番君がきてますね

**デフォルトの名無しさん** · 2021/08/27(金) 10:21:55.10

なんやいつぞやのパターンマッチングの規格についてゴネてた子か

**デフォルトの名無しさん** · 2021/08/27(金) 11:04:36.95

・Fortran/BASICからCへの移植は容易。単純なパターンが存在する。
　アルゴリズムの変更は不要。

・C++からJavaやC#への移植は容易。単純なパターンが存在する。
　アルゴリズムの変更は不要。

・C++からRustへの移植は困難。単純なパターンは存在せず。
　アルゴリズムを根本的に変える必要がある場合がある。

**デフォルトの名無しさん** · 2021/08/27(金) 11:10:56.79

Rustアンチスレでやればいいのに

**デフォルトの名無しさん** · 2021/08/27(金) 16:15:37.78

嫌なら使うなでおわり
現状嫌でも使うしかないくらいまでのシェア獲得してないし

**デフォルトの名無しさん** · 2021/08/27(金) 16:28:39.42

個人としては使いたいけど組織として導入するには仕様の確実さというのは必要なんだわ。

**デフォルトの名無しさん** · 2021/08/27(金) 16:36:16.05

C++ドロップアウターがOOPを学び直すには良いんでないの

**デフォルトの名無しさん** · 2021/08/27(金) 16:44:56.69

大手IT企業たちの方針

プログラミング言語「Rust」のための「Rust Foundation」設立 -- AWS(Amazon)、Microsoft、Google、Mozilla、Huaweiが創設
https://japan.zdnet.com/article/35166267/

Facebookが「Rust Foundation」に参加
https://japan.zdnet.com/article/35170192/

**デフォルトの名無しさん** · 2021/08/27(金) 16:56:21.47

>>108
仕様の確実さってどういうの言ってる？
Rustでの具体例を1～2個あげてみて？

**デフォルトの名無しさん** · 2021/08/27(金) 17:09:08.75

>>111
lifetime関連

**デフォルトの名無しさん** · 2021/08/27(金) 17:14:05.77

>>112
関連じゃわかんねーわ
Lifetime Elisionとかは分かりやすく仕様定義されてるっしょ

**デフォルトの名無しさん** · 2021/08/27(金) 17:44:50.51

で、それはどこにあるっていうんだ。
これについての仕様はこっちに有ってあれについての仕様はあっちに有って
詳細はブログのここにあって……でもこれは議論のための暫定的なまとめで……
みたいなのじゃ組織の中で話を通せんのよ。

「Rust の仕様はこれです」「これを満たした処理系は (少なくとも今のところは) Rust と呼べます」
というのが仕様書であって、そういうのが欲しいわけよ。

**デフォルトの名無しさん** · 2021/08/27(金) 17:53:04.46

その論法は流石に違和感が強い

GAFA級の組織（のどこか）では採択されるのにその組織では通らないというなら、その組織か説得者が外れ値なだけでは？

**デフォルトの名無しさん** · 2021/08/27(金) 17:58:34.36

老害さん今日も公式読まずに愚痴たれる

**デフォルトの名無しさん** · 2021/08/27(金) 18:02:52.05

>>115
そのレベルの大企業というのは策定側で関与しうるし
投機的な技術的投資にも貪欲だから
「大企業は動きが遅い」「稟議が厳密」という感覚ではない。

グーグルが大規模なサービスを開始からそれほど間を置かずに畳んだことなんて何度もあるだろう。
ぽんっとやって駄目だったらポイッと捨てられるんだよ。

**デフォルトの名無しさん** · 2021/08/27(金) 18:09:32.26

そういう考え方ならISO標準でもできてから検討すればいいよ
時期尚早で時間の無駄

**デフォルトの名無しさん** · 2021/08/27(金) 18:10:07.62

実際のところC++みたいに委員会とかが仕様がっちり決める言語ってどんくらいあるの？

そもそもC++だって仕様は決まってもコンパイラが微妙に準拠しきれてない気がするんだが
gccとclangは実用上困らんレベルだとは思うが

**デフォルトの名無しさん** · 2021/08/27(金) 18:16:18.84

ISO標準のある言語で一番新しいのがRubyくらいか
もっと新しいのあったっけ？
やはりリリースから10年以上はかかる感じかね

**デフォルトの名無しさん** · 2021/08/27(金) 18:18:18.61

今の時点ではアーリーアダプタが使う言語なんだという立場でやってるならそれでもいいんだけど、
個別には割と (どこかには) まとまってるっぽいからもったいねーなという感覚がある。

**デフォルトの名無しさん** · 2021/08/27(金) 18:27:08.06

お前が標準化委員会になるんだよ！

**デフォルトの名無しさん** · 2021/08/27(金) 18:31:21.32

GAFAMだけでなく
日本でもNTTやTOYOTAなどもRustを採用しているわけで
まともな企業ならば支障なくRust採用を決定していってるでしょう

**デフォルトの名無しさん** · 2021/08/27(金) 18:52:17.41

特定の組織の土着信仰を一般論のように入れてもね

**デフォルトの名無しさん** · 2021/08/27(金) 18:54:13.62

権威でものを判断したり
権威を借りて発言したり

頭ワリーわ
正気になれ

**デフォルトの名無しさん** · 2021/08/27(金) 19:30:34.42

>>125
「権威に訴える論証」という人間の性質なんだよ。

けっこう効果あるから詐欺師とかマスゴミが良く使う。

**デフォルトの名無しさん** · 2021/08/27(金) 19:32:40.90

あの松下もわが社の製品を採用しているんですよ～
情弱「ほほう、じゃうちも採用率するわ！」

**デフォルトの名無しさん** · 2021/08/27(金) 19:33:38.34

メモリ開放の意味が解らない馬鹿に合わせるための言語なんだよな
馬鹿に合わせるとロクなことがない気がするんだけど

**デフォルトの名無しさん** · 2021/08/27(金) 19:36:05.44

わかってても間違えるのが人間なんだよ。
ヒューマンエラーを防止するのに「注意する」とかで対策を済ませちゃうわけ？

**デフォルトの名無しさん** · 2021/08/27(金) 19:43:24.40

＞グーグルによればAndroidに存在した深刻なセキュリティー脆弱性の70％近くがメモリー安全に関するバグに起因するという。
＞同様にマイクロソフトも、同社製品に存在したセキュリティー脆弱性の70％がメモリー安全に関するバグに起因すると述べている。
＞C/C++を使う限りセキュリティー脆弱性を根絶するのは不可能と考えて、Rustを採用するに至ったというわけだ。

https://xtech.nikkei.com/atcl/nxt/column/18/00692/042700054/

**デフォルトの名無しさん** · 2021/08/27(金) 19:45:18.24

あの会社もあそこもRust採用しているんだから絶対ヨシ！
https://i.imgur.com/aLxQE0R.jpg
https://i.imgur.com/NXcjrJA.jpg

**デフォルトの名無しさん** · 2021/08/27(金) 19:48:14.38

C++で苦しんできた連中は
Rustのやろうとしたことは分かるし
例え失敗に終わっても責める気にはならん
どうころんでもしょせん死屍累々
Rustは人類の明日への尊い礎になるだけ

**デフォルトの名無しさん** · 2021/08/27(金) 19:57:25.52

>>125
そいつが権威主義的思考なのは確かなんだが
新興言語は大手の技術力ある会社がスポンサーにいて
継続的な投資が行われることが確実視されてるかどうかはすごく重要なこと

**デフォルトの名無しさん** · 2021/08/27(金) 21:00:14.71

>>123
二つともわけの分からん企業だな。
自動車と電話会社。

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

人々の関心の高さは感じるけどな。twitterとか見てると。

**デフォルトの名無しさん** · 2021/08/27(金) 21:07:48.98

でもtwitterでは、Pythonも活況だし、KotlinもRustと似たり寄ったりの数、検索される。
なぜかQtやRailsは検索されにくい。Djangoは沢山検索される。
cplusplusは僅かに検索される。C++やC#は直接的にはそもそもtwitterでは検索できない。
Rustの話題性がPythonやKotlinやDjangoと比べて取り立てて多いということではないようだ。

**デフォルトの名無しさん** · 2021/08/27(金) 21:44:01.80

The Bookは読まないくせにどうでもいいTwitter検索ばっかりしやがって

あーあのTwitterで独り言つぶやき続けてるひとだっけ？
忘れてた

**デフォルトの名無しさん** · 2021/08/27(金) 21:51:00.96

とにかく仕様が必要ならC++使えばよいのでは。主要メンバーがC++標準理解しているようなすごい人ばかりなんだろう

**デフォルトの名無しさん** · 2021/08/27(金) 21:58:56.53

>>138
自分達が「完全な仕様」と思えるものが存在することが重要視なんであって理解している必要はないんでしょ
ある種の宗教上の理由だよ

**デフォルトの名無しさん** · 2021/08/27(金) 22:04:01.75

実際は、Rails : Laravel = 8:2。
Django は、0

どこの学校・サロンもほぼ、Ruby on Rails

**デフォルトの名無しさん** · 2021/08/27(金) 23:00:14.26

確実にinline展開する方法ってある？
手動で書く？
マクロだとどうにかなる？

**デフォルトの名無しさん** · 2021/08/27(金) 23:01:33.75

>>134
自動車の制御はわからんでもない
即応性と安全性の両立を図らなければならないのだから

**デフォルトの名無しさん** · 2021/08/27(金) 23:13:16.52

#[inline(always)]でも100%ではないんだっけ？

**デフォルトの名無しさん** · 2021/08/27(金) 23:22:31.27

>>138
把握してないから必要なときにそれを調べればいいというようなまとまったものが必要なんだよ。

**デフォルトの名無しさん** · 2021/08/27(金) 23:40:58.77

Rust以外で高信頼性指向だとAdaとかMISRA Cとか？

**デフォルトの名無しさん** · 2021/08/27(金) 23:45:38.03

>>143
実装はわからんけど、スペック的にはalwaysも飽くまでヒントらしい

**デフォルトの名無しさん** · 2021/08/27(金) 23:52:40.05

>>145
MISRA Cは言語じゃなくてコーディング規約みたいなもん
組み込み以外では厳しくて準拠してられないと思う

**デフォルトの名無しさん** · 2021/08/28(土) 00:02:42.33

ファッション感覚のバカしかアピールしてない言語だわ。
c++理解してない奴がライフタイムをまともに理解できるとも思わん。
それもわからんバカがcをバインディングなんかしたら事故しか起きんわ。
安全性もクソもない。

**デフォルトの名無しさん** · 2021/08/28(土) 00:03:44.74

組み込み向けRustって1冊本が出たみたいだけど
実際のとこ、見込みありそうなの？
ただのホビー？

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

>>148
C++ はわかっててもミスるんだってば。

**デフォルトの名無しさん** · 2021/08/28(土) 01:13:09.37

C/C++知らないと～と言う人には型理論知ってる？って聞きたくなる
コンパイルが通れば大体ちゃんと動くようになってるって感覚はhaskellとかOCaml寄りだと思う

**デフォルトの名無しさん** · 2021/08/28(土) 01:30:02.36

Haskell の型システムは好きなんだけど
さすがに副作用 (Haskell 的にはアクションだが……) の扱いがしんどすぎるし
元から C++ には慣れてるので C++ (というか C) 風な文法や意味論と
組み合わせた言語があったらいいなぁと思ってたので
Rust の台頭にはばんじゃーい ∩( ・ω・)∩

**デフォルトの名無しさん** · 2021/08/28(土) 01:31:18.92

おまえらスルー力低すぎやろw

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

>>151
お前こそ型理論知らんだろ。。
型理論てのは結局どれだけ簡易な計算でエラーチェックするかってだけの話なんだよ。
正しく示すだけならただ単に全実行するのが一番良い。

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

ガファムがファッションでプログラミングしてるとは知らなかった

**デフォルトの名無しさん** · 2021/08/28(土) 08:46:20.33

twitterでRustは話題性があるように見えるが、ためしにLISPやSchemeや
Clojure(言語)を検索してみてもRustと似たり寄ったりの書き込みがあった。
Haskelが次代を担う言語だ、的な書き込みすらある。

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

今のgoogleじゃまともなc++プログラマもだいぶ減ってるわな。。
kumagiとかイキってるだけでまともに理解してねーじゃん。

**デフォルトの名無しさん** · 2021/08/28(土) 10:14:03.36

>>156
Haskellの型システムをRustは受け継ぎつつCG無しでメモリ安全性を達成しているので
Rustが実用的なプログラミング言語として現実に機能していますね

**デフォルトの名無しさん** · 2021/08/28(土) 11:32:23.88

CG無し

**デフォルトの名無しさん** · 2021/08/28(土) 11:39:53.86

特撮オンリーでいくわけですねわかります

**デフォルトの名無しさん** · 2021/08/28(土) 11:48:49.70

>>145
MISRAに従ってコーディングするの辛いぞ。

**デフォルトの名無しさん** · 2021/08/28(土) 12:14:36.47

>>160
特撮にはCG有るぞ

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

次のようなloop文のプログラム(可動)を
while文やfor文に書き換えてわかりやすくしたいのですが
上手く値をbreakできないので助けてください

fn main() {
　let a = [3, 5, 1, 6, 9, 4];
　print_first_even_else_zero(&a);
}
fn print_first_even_else_zero(a: &[i32]) {
　let mut i = a.iter();
　let even = loop {
　　if let Some(&n) = i.next() {
　　　if n % 2 == 0 {
　　　　break n;
　　　}
　　} else {
　　　break 0; // not found
　　}
　};
　println!("{}", even);
}

例えばwhile文なら　let even = while let Some(&n) = i.next() { となりそうで
さらに可能ならfor文で　let even = for &n in a { となるかと思うのですが

**デフォルトの名無しさん** · 2021/08/28(土) 12:44:34.41

let even = a.iter().find(|n| *n % 2 == 0).unwrap_or(&0);

**デフォルトの名無しさん** · 2021/08/28(土) 13:03:12.27

>>164
当然それはわかりますが、for式やwhile式ではどうなるのか、という質問です

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

前スレより

625 デフォルトの名無しさん 2021/08/16(月) 09:44:36.63 ID:MZWGbmHz
loop式はbreakで指定した値を返せるのに
なぜwhile式やfor式は値を返せないの？
Option型にしてbreakで値を指定した時だけSome(値)としてそれ以外はNoneとすれば便利なのに

630 デフォルトの名無しさん sage 2021/08/16(月) 14:32:54.40 ID:ebJKRLr3
手間かけて機能拡張するほどのメリットがないってことだろうね
https://github.com/rust-lang/rfcs/issues/1767#issuecomment-292678002

**デフォルトの名無しさん** · 2021/08/28(土) 13:08:21.57

そうでしたかすみません
forとwhileは値を返さないのでご想像のようにはなりません

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

>>166
なるほど
そこでの議論を読むと一番の肝が、
「for式が()を返さないと、最後がfor式で終わる関数の返り値で互換性が無くなる」
というところにあるようですが
「break;」が()を返すことにすれば特に問題ないように見えます
実際にloop式で値なしのbreakだと()を返しています

つまり
・「for/while/loop式が返す型」は「break式の型」とする
・「値指定のない『break;』の型」は()とする
・「break式がない場合の型」も()とする
ここまでは現状と同じになりますね

問題はfor/while式はbreakせずともループを抜けるので、値を返すには、
・「『break 値;』があるfor/while式」は「else節を取ってbreak式と同じ型を返す」
という単純ルールだけで済むように見えます
何か見落としがあるでしょうか？

**デフォルトの名無しさん** · 2021/08/28(土) 14:41:22.43

8日前にちょうどその内容で開かれたRFCあるじゃん
イテレータで思考停止してたわ
https://github.com/rust-lang/rfcs/pull/3163

**デフォルトの名無しさん** · 2021/08/28(土) 15:14:25.46

>>169
なるほどありがとうございます

ところで現状のRustで>>163の例のloop式をfor式で行おうとすると
即時関数を使ってbreakをreturnに置き換えることで
let even = (|| {
　for &n in a {
　　if n % 2 == 0 {
　　　return n;
　　}
　}
　0
})();
と実現できることを思いつきましたが
この方法は表記コストはともかく実行コストもかかってしまいますか？

ちなみにこの「最初の偶数を見つけるコード」はあくまでも例として単純化したものを出しているだけで
実際には様々な例でこのパターン(＝forやwhileで値を返せると便利)が出てくるので簡略な例題として話をしています

**デフォルトの名無しさん** · 2021/08/28(土) 15:30:38.48

>>168
イテレータのコードのほうが遥かにわかりやすい上に簡潔なので
新しく文法を拡張する価値がないと開発陣は考えてる点を見落としてる。る？
特にPythonの失敗例を鑑みれば機能追加される可能性は限りなくゼロ

**デフォルトの名無しさん** · 2021/08/28(土) 15:43:20.61

>>171
現実にはfindより複雑なことでも使うだろうし
async関数呼び出して判断もあるだろうし
イテレータでは無理なことも多いのでは？

**デフォルトの名無しさん** · 2021/08/28(土) 16:01:24.35

Rustに限った話じゃないけど新しめの言語だとイテレータで記述可能な
ループは、出来るだけイテレータで記述するのが主流じゃね
forだのwhileはループ条件の誤りから簡単にバグが生まれるし
使わないで済むならそれに越したことはない
CやCの派生系言語がメインの人には理解しがたいかもしれないが

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

C++ だとテンプレートの組み合わせで回すのも一般的だけど
Go だと凝ったことするよりなんでも愚直にループを回したほうがいいというのは
基本的なスタンスになってるよね。

**デフォルトの名無しさん** · 2021/08/28(土) 16:18:39.14

>>172
説得力のある実例を出せば今みたいにRFCが即closeされることはないんじゃない？

状況によってはイテレータを拡張したほうがいいという判断も有り得るし
今のforやwhileループみたいにmutで定義した変数を更新するのでも十分かもしれない

**デフォルトの名無しさん** · 2021/08/28(土) 17:39:28.92

>>173
なるほど
出来るだけイテレータで記述する質問です
コマンドライン引数の数字の和をイテレータでpanicさせずに求める場合
これよりもっと短く出来ないでしょうか？
fn main() -> Result<(), std::num::ParseIntError> {
　println!("Sum: {}", std::env::args().skip(1).map(|s| s.parse::<i32>()).collect::<Result<Vec<i32>,_>>()?.iter().sum::<i32>());
　Ok(())
}
以下のように正しく実行できているのですがコードが長いのが気になっています
$ cargo run 10 20 30 40 50
Sum: 150
$ cargo run 10 20 XX 40 50
Error: ParseIntError { kind: InvalidDigit }

**デフォルトの名無しさん** · 2021/08/28(土) 17:58:47.12

そんなに長い？

**デフォルトの名無しさん** · 2021/08/28(土) 18:59:50.15

twitterで「Rust過激派がルール違反と判断された」
「CやC++のこと書いてた人にRustの話吹っかけて迷惑かけてた怖い人たち」
という話を見たが、誰の事？
どういうことなんだ？

**デフォルトの名無しさん** · 2021/08/28(土) 19:21:11.03

>>178
c++テンプレートテクニックの著者のことか？

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

>>61
int* p1 = malloc(sizeof(int));
int* p2 = malloc(sizeof(int));
int* p3;
if (なんかの条件) p3 = p1; else p3 = p2;
free(p1);
p1 = NULL;
if (なんかの条件) p3 = NULL;
// p2はまだまだ使う
こうすればいいだけの話だろ？ガイジか？
このコードの後 p2またはp3どちらかをfreeしても二重開放にならんよ
このぐらいも考えられないのかガイジは(笑)

**デフォルトの名無しさん** · 2021/08/28(土) 19:28:28.84

いちいち差別的な用語を使わないとレスもできないのか
プログラマとしては一流なのかもしれないが、人間としては最低だな

**デフォルトの名無しさん** · 2021/08/28(土) 20:41:09.02

>>177
このcollectしてから再びiterするところを何とか出来ないものかなと
println!("Sum: {}", std::env::args().skip(1).map(|s| s.parse::<i32>()).collect::<Result<Vec<i32>,_>>()?.iter().sum::<i32>());
イテレータだけを使う限界？

同じことをfor文を使うと短くなってわかりやすくなります
let mut total = 0;
for s in std::env::args().skip(1) {
　total += s.parse::<i32>()?;
}
println!("Sum: {}", total);

**デフォルトの名無しさん** · 2021/08/28(土) 21:00:48.99

std::env::args().skip(1).map(|s| s.parse::<i32>()).sum::<Result<i32, _>>()?

**デフォルトの名無しさん** · 2021/08/28(土) 21:02:35.90

ParseIntError返しても処理しないんだから
unwrap_or(0)みたいなので十分じゃないの？

fn main() {
let args = std::env::args().skip(1);
let sum: i32 = args.map(|s| s.parse().unwrap_or(0)).sum();
println!("Sum: {}", sum);
}

入力、計算、出力で分けてる

**デフォルトの名無しさん** · 2021/08/28(土) 21:14:51.79

>>184
非整数は飛ばす仕様になってる
エラーはエラーだと示すべきかな
あとエラー処理コードがないのは質問の本質じゃないからかと

**デフォルトの名無しさん** · 2021/08/28(土) 21:23:19.42

println!("{}", std::env::args().skip().try_fold(|sum, s| Ok(sum + s.parse::<i32>()?))?);

try_fold使うと?演算子の入る場所が変わらずに済むっぽいな

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

>>183
なるほど!
sum()もcollect()のように様々な形の集積方法が指定できるのですね
i32整数一覧が入力に来るのにsum::<i32>()とi32型指定をしないと怒られた理由がようやくわかりました
sumとcollect以外にもそういう仕様のメソッドはありますか？

**デフォルトの名無しさん** · 2021/08/28(土) 21:34:12.61

いちいち固有のiterator使うとか可読性悪くなるだけって場合も多い

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

>>186
素晴らしい!
少し修正して以下で上手く行きました
std::env::args().skip(1).try_fold(0, |sum, s| Ok(sum + s.parse::<i32>()?))?
fold()は知っていたのですがtry_fold()でOptionやResultの形でfold()できるとは便利ですね

ここまでまとめると
sum計算はResult型を返せるsum()があるので>>183でも行けて
このtry_fold()ならばsum計算以外にも汎用的に使えますね

**デフォルトの名無しさん** · 2021/08/28(土) 22:01:27.46

>>185
エラーだと示したいなら結果をハンドリングすればいいんじゃないの？

type Result<T> = std::result::Result<T, std::num::ParseIntError>;

fn main() {
let args = std::env::args().skip(1);
let sum: Result<i32> = args.map(|s| s.parse::<i32>()).sum();
match sum {
Ok(sum) => println!("Sum: {}", sum),
Err(e) => println!("Error: {}", e),
};
}

引数ゼロ個とかエラーは1種類じゃまかなえない
ハンドリングしたいならエラー設計がもう少し必要になるだろうね

**デフォルトの名無しさん** · 2021/08/28(土) 22:12:53.29

>>190
もちろんそんなことは皆わかっていて、最後のResultのErr処理は枝葉末節だから略して議論してるのだと思う
あとmain()でResult返してErrなら勝手にエラー表示してくれるみたいで便利
で、>>185で指摘したことは、>>184のunwrap_or(0)使用はエラーが消えるからマズいよね、ということでした

**デフォルトの名無しさん** · 2021/08/28(土) 22:34:29.66

>>191
何をそんなにカリカリしてるんだ？
main()でResult返したいなら別にそれでもいいんじゃない？

fn main() -> Result<()> {
let args = std::env::args().skip(1);
let sum: Result<i32> = args.map(|s| s.parse::<i32>()).sum();
println!("{}", sum?);
Ok(())
}

**デフォルトの名無しさん** · 2021/08/28(土) 22:53:59.26

>>192
皆がわかりきったことしか書いていなくて何をしたいのかわからないけど
Resultはエラー型も示さないとそのコードでは動かないよ

**デフォルトの名無しさん** · 2021/08/28(土) 23:36:35.98

今回はargs部分も枝葉末節なので外してまとめ直すと
『数値と思われる文字列の配列が与えられた時に非数値があればエラーを返すとして』
let a = ["1", "3", "5", "7", "9"];
和の場合はmap()でResultのままsum()に渡してResultを返せる
let sum = a.iter().map(|s| s.parse::<i32>()).sum::<Result<i32, _>>()?;
和だけでなく積などもtry_fold()を使えばResultを返せる
let sum = a.iter().try_fold(0, |sum, s| Ok(sum + s.parse::<i32>()?))?;
let mul = a.iter().try_fold(1, |mul, s| Ok(mul * s.parse::<i32>()?))?;
今回はparse()で文字列→数値のResultだけど一般的にResultを返す関数なら応用可能
皆さんありがとうございました

**デフォルトの名無しさん** · 2021/08/29(日) 09:06:24.35

>>179
指摘している人も、加害者もエピステーメー氏とは全く関係ない人だと思う。

**デフォルトの名無しさん** · 2021/08/29(日) 12:05:26.47

>>195
えぴすめーてーじゃないほうの共著者のほうでしょ

**デフォルトの名無しさん** · 2021/08/29(日) 13:31:13.01

ローマ字で takaha... の人のことか。
Ukic...の人も何か言ってるんだけどどういう相関関係なのか。。

**デフォルトの名無しさん** · 2021/08/29(日) 17:50:42.33

対立煽りに乗らないように

**デフォルトの名無しさん** · 2021/08/29(日) 20:28:38.19

>>174
Goは確かにその方針だけど、イテレータというか高階関数を受ける型が総称では無いから.collectや.mapなんて
型ごとに定義しないと使えないから。Go2になってくれば違ってくると思う
一方でPythonだとfunctools.reduceなんかより、リスト内包表記が使われるのは局所性で速度が速いからだけど
ループで書かずにかなり長い表現をこれで書かれると保守しずらい。
Rustでもイテレータを何回も取り出してcollectしたり、foldしたりをドットで繋げられるのはあまり読み易いとは
言えないと思う。普通にiter()を何度も呼ぶのなら、let it = a.iter();して欲しい

**デフォルトの名無しさん** · 2021/08/29(日) 21:26:36.38

そのitは一度しか使えないのでわ