Rust part24

**デフォルトの名無しさん** · 2024/05/27(月) 06:41:26.82

公式
https://www.rust-lang.org/
https://blog.rust-lang.org/
https://github.com/rust-lang/rust

公式ドキュメント
https://www.rust-lang.org/learn

Web上の実行環境
https://play.rust-lang.org

※Rustを学びたい人はまず最初に公式のThe Bookを読むこと
https://doc.rust-lang.org/book/

※Rustを学ぶ際に犯しがちな12の過ち
https://dystroy.org/blog/how-not-to-learn-rust

※Rustのasyncについて知りたければ「async-book」は必読
https://rust-lang.github.io/async-book/

※次スレは原則>>980が立てること

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

**デフォルトの名無しさん** · 2024/06/29(土) 14:06:46.53

リファクタリングの原則のひとつとして外側から見たときに変わらないというのがある。
内と外を分ける境界線がどこなのかというのは場合によるので UI レベルで同じなら良しとすることもあるけど、普通は適当なモジュール単位でやるだろう。
「変わらない」ことの保証のひとつとして型やライフタイムアノテーションは頼りになるよ。
型システムがあてにならないほどの大改革ならどうせ全部書き直しなので足を引っ張られることもない。

**デフォルトの名無しさん** · 2024/06/29(土) 14:24:33.15

Rustはリファクタリングには全く向いていない

**デフォルトの名無しさん** · 2024/06/29(土) 14:31:05.74

いつも汚いコードを貼り付けてた複オジがリファクタリングは簡単などと言い張ったところで全く説得力がない

**デフォルトの名無しさん** · 2024/06/29(土) 14:38:55.22

数のイテレータで遊んで満足してる人に機械学習の文脈が理解できるわけないやん？

**デフォルトの名無しさん** · 2024/06/29(土) 14:41:30.81

掲示板に貼れる程度の内容なら
リファクタリングしても知れてるでしょ

**デフォルトの名無しさん** · 2024/06/29(土) 15:08:40.24

>>463
Rustはリファクタリングに向いている言語だよ
リファクタリングで最も重要なことはその前後で同じ機能動作が保証されることだけど
そこで静的型付け言語が有利なことは当たり前としてRustのアクセス競合排他原則がさらに大きく効いてるよ
データ書き換え中の読み取りによるバクがリファクタリングによって入り込むことも防いでくれているね

**デフォルトの名無しさん** · 2024/06/29(土) 15:23:13.20

デジタル小作人やめるレベルの大手術ではなく
地主との関係が変わらないことを保証したいんだな

**デフォルトの名無しさん** · 2024/06/29(土) 15:34:20.66

それまで参照を持たなかった構造体にメンバとして参照を持たせると、型にジェネリックライフタイムが付いて、その型の使用箇所全部でライフタイムを書く必要がある
さらに悪いことに、実際のところこれは必要ではなく、ライフタイムを書かなくても省略されていると見なされてコンパイルが通ることもある
しかしこれでは意図通りのライフタイムになっていないことが多く、その型の使用箇所を増やしたときに初めてそのことに気づくことになる

Rust特有のリファクタリングしづらさは、あるよ

**デフォルトの名無しさん** · 2024/06/29(土) 15:52:41.67

ライフタイム関連に限らずRustのリファクタリングは
他言語に比べて波及する範囲が大きくなりやすいんだよね
それで作業量が多いからしんどい

しんどさと難しさは必ずしもイコールではないんだけど
サクサク変更できる言語を経験してると
Rustのリファクタリング時には精神的なエネルギーが相当必要

**デフォルトの名無しさん** · 2024/06/29(土) 16:01:57.62

>>469
リファクタリングの作業の大きさに対して、必要なライフタイム注釈を付けるだけの些細なことが障害になったことはないな。
ライフタイム注釈が'aになるか'_になるか省略できるかは、その必要性と省略ルールに基づくだけなので、そこで問題が発生することはないだろう。

**デフォルトの名無しさん** · 2024/06/29(土) 16:03:28.89

>>470
Rustでは様々なことをコンパイラチェックに任せられるため、リファクタリングで最も崩れにくく、人間の負担は他より小さい。

**デフォルトの名無しさん** · 2024/06/29(土) 16:10:10.85

糠に釘
暖簾に腕押し
複オジにRust

**デフォルトの名無しさん** · 2024/06/29(土) 16:52:22.95

>>471
「ライフタイム注釈が'aになるか'_になるか省略できるか」は、すべての使用箇所ごとに以下を検討したうえで決まる

* 追加するライフタイムは既存のライフタイムと同じであるべきか
* 既存と同じであるべきでないなら、そのライフタイムはどこで宣言すべきか（impl? fn? トレイトや構造体?）

それで1つの型がリファクタリングできたところで、

* トレイトや構造体にジェネリックライフタイムパラメータを追加した場合、そいつにも同じ作業がいる。最初から繰り返し

ここまでのすべての作業に尋常でない集中力が必要になる
繰り返しの中でライフタイムの宣言箇所の選択が誤っていたことに後で気づいたりすると悲惨だ
「エラーのあるコードをgit commitしない方が良い」という思い込みを捨て、選択を必要とするタイミングでgitに記録するようにして、
作業効率は安定はするようになったが、それでも作業を捨てるというのは気が滅入る
「あ、この関数の引数にライフタイム追加することになるけど、後で戻り値にもライフタイム追加することになるな」なんて思っても一挙に作業してはいけない
少なくとも自分の頭では作業の段取りを崩すだけだった

そしてここまでを全集中して完了してコンパイルを通すところまで持って行けても、クレート外の使用箇所でおかしなことにならないことは保証できない
ボローチェッカーは書かれている使用法が妥当であるかどうかしか検証しないからだ

こっちは体験談として言っているんだから、机上の空論を弄するのはもうやめなさい

**デフォルトの名無しさん** · 2024/06/29(土) 16:58:20.78

Rustはライフタイムさえ正しく書けていれば本当に有用な助けを与えてくれる
しかしライフタイムを正しく書くための助けはほとんど与えてくれないので、自分で書く必要があるときには上と同じような期待をしてはいけない

**デフォルトの名無しさん** · 2024/06/29(土) 16:59:51.95

知ったかぶりして間違ったこと書く
やんわり間違いを指摘される
反省せずに開き直る！

またこの流れ
ググればすぐわかるような間違いなのになんなんだろうな

**デフォルトの名無しさん** · 2024/06/29(土) 17:06:14.07

>>474
>>475
それは大きな誤解をしているなあ
ライフタイムアノテーションを間違って書いて矛盾が起きていればコンパイルエラーとなるよ
コンパイルが通れば正しく書けているからプログラマーがそこで困ることはないよ

**デフォルトの名無しさん** · 2024/06/29(土) 17:17:23.37

>>477
いいからこれでも読んでろ
https://github.com/pretzelhammer/rust-blog/blob/master/posts/translations/jp/common-rust-lifetime-misconceptions.md

> Rustのトレイトオブジェクトへのライフタイム省略ルールはどんな状況でも正しいというわけではない
> Rustはプログラムの意味についてプログラマよりも知っているわけではない
> Rustのコンパイラが吐くエラーメッセージでおすすめされる修正はコンパイルが通るようにするが、コンパイルが通り、かつプログラムへの要求をちゃんと満たしたものするわけではない

**デフォルトの名無しさん** · 2024/06/29(土) 17:26:08.00

それは省略ルールの結果が望むものと一致するかどうかは限らないという意味だぜ
間違っていると部分的にはコンパイルが通ったとしてもプログラム全体ではコンパイルエラーとなる
そのミスをコンパイラが見逃すことはない

**デフォルトの名無しさん** · 2024/06/29(土) 18:07:09.50

言語を比較しなくても
&Tに比べてRc<T>はリファクタリングしやすいとかいう認識でいいよな

ただ進化論じゃないんだから&Tが淘汰されてRc<T>が生き残るということはない
言語を比較すれば淘汰される言語もありうる

**デフォルトの名無しさん** · 2024/06/29(土) 18:13:00.59

>>469
その逆のリファクタリングを影響範囲が大き過ぎて無理って話をcargoのissueで見たことある
cargoはそれ以外でも技術的負債が溜まってるけど影響範囲が大きくなるから簡単に手を入れられないってことを中の人がよくボヤいてるね

**デフォルトの名無しさん** · 2024/06/29(土) 18:24:11.81

C/C++をメモリ安全にするプロジェクト
https://www.itmedia.co.jp/enterprise/articles/2406/28/news084.html
Rustイラネになりそう

**デフォルトの名無しさん** · 2024/06/29(土) 18:44:47.93

>>482
それは自動で見つけられる脆弱性の範囲を広げる話
その種の脆弱性をゼロにするRustへと移行する流れはそのまま変わらず

**デフォルトの名無しさん** · 2024/06/29(土) 20:21:20.41

>>480
Rc<T>の比較対象はTやBox<T>
・Tの参照は&T
・Box<T>の参照は&T
・Rc<T>の参照は&T
どれも同じになり&Tは不要とならない

違いはスコープから外れたとき
裸のTはTがスタック上ですぐ消える
Box<T>はTがヒープ上ですぐ消える
Rc<T>はTがヒープ上でカウンタが最後のときだけ消える

**デフォルトの名無しさん** · 2024/06/29(土) 20:23:11.41

>>469
これか……
https://github.com/rust-lang/cargo/issues/7342

> I think the answer here is "Alex thought it was fun to avoid RefCell and Mutex", there's no real technical motivation.

「cloneを避ける/ロックを避ける/参照カウンタのコストを避ける」みたいなゼロコスト主義も節度を持ってやれってことね
とりあえず「型のジェネリックライフタイム引数を変更するのは多大なコストがかかる」という理解は合っていると思っておくことにするか

**デフォルトの名無しさん** · 2024/06/29(土) 20:23:40.20

>>481だった

**デフォルトの名無しさん** · 2024/06/29(土) 21:57:07.55

問題は節度というより抽象化軽視
ゼロコストという損得勘定に強く依存するよりは高コスト抽象化の方がマシ
と判断できなくなる

**デフォルトの名無しさん** · 2024/06/29(土) 22:55:28.22

>>469
それは単にライフタイムに不慣れなだけじゃないかなと思った
構造体に参照を含むのはよくあることでライフタイムパラメタを付けるだけ
あとは関数で参照を含むデータを返す時にどの引数に由来するかを指定することなどしかすべきことはない
慣れてしまうと大したことはしていないよね

そこでもし間違えて指定してしまっても違反があればコンパイラが必ずエラーとするので安心して大丈夫
では何故コンパイラが自動で指定(解釈)してくれないのか？というと、複数の参照に対して別扱いするかどうかや複数の関係指定など各自に方針の余地があるため

**デフォルトの名無しさん** · 2024/06/29(土) 23:12:35.54

C/C++だとそのへんを脳内の方針で逸脱しないように人間が監視しないといけない
Rustは楽

**デフォルトの名無しさん** · 2024/06/29(土) 23:26:59.72

固定長配列をスライスに、BoxをRcに変換すると抽象度は上がる
失敗するかもしれないパターンマッチは抽象度を下げる
コンパイル時または実行時エラーかもしれないborrowも抽象度を下げる

**デフォルトの名無しさん** · 2024/06/30(日) 02:58:29.53

>>467
詭弁

>>469
++

>>474
++おまえもかが口癖になる

**デフォルトの名無しさん** · 2024/06/30(日) 03:44:32.65

>>474
ライフタイム初心者なだけだな
そんなことでは悩まなくなる

**デフォルトの名無しさん** · 2024/06/30(日) 05:54:25.07

>>309
横からすみません。
C＃を関数型っぽく書いたら、ここまではなったのでRustだったらどうなるのか聞いても良いでしょうか？

public static void Main(string[] args) { args.ToList().ForEach(f); }

static void f(string fileName)
{
Console.WriteLine(fileName);
File.ReadAllLines(fileName).Select(g).ToList().ForEach(Console.WriteLine);
}

static Func<string,int,string> g = (line,i) => $"{i + 1,2}:{line}";

**デフォルトの名無しさん** · 2024/06/30(日) 09:33:23.06

どうもならんよ

**デフォルトの名無しさん** · 2024/06/30(日) 10:12:23.11

リファクタリングのすごさは、外側から見たら何も変化しないことだからね

**デフォルトの名無しさん** · 2024/06/30(日) 10:30:41.18

>>493
何回ToListすんねんw
ReadAllLines含めて3回とも必要ないやろ

**デフォルトの名無しさん** · 2024/06/30(日) 10:53:06.05

あえて >>493 で頑張ると
https://paiza.io/projects/sk40IXUgPm0k_VgI1wsHBg

fn main() {
let cwln = |s| { println!("{}", s) };
let g = |(i, line): (usize, &str)| { format!("{:>2}:{}", i + 1, line) };
let f = |file_name: String| {
cwln(file_name.clone());
std::fs::read_to_string(file_name).map(|u8b| {
u8b.lines().enumerate().map(g).for_each(cwln)
}).unwrap()
};

std::env::args().skip(1).for_each(f)
}

**デフォルトの名無しさん** · 2024/06/30(日) 10:54:12.53

do記法のたぐいはラムダで実装しても命令型で実装してもどっちでもいい
外側から見れば同じだからだ

**デフォルトの名無しさん** · 2024/06/30(日) 11:17:03.52

>>496
.net標準にはList型にしかForEachが導入されてないからやな。
C#ではチェインメソッドにしないほうがいいとされてる。
https://learn.microsoft.com/en-us/archive/blogs/ericlippert/foreach-vs-foreach

**デフォルトの名無しさん** · 2024/06/30(日) 12:31:43.09

>>499
「.ForEachしたいけど標準にないからToListする」という考え方が間違い
enumerable.ToList().ForEach()のパターンは最悪

それとそのEric Rippertの意見がMSやC#コミュニティのコンセンサスというわけではないよ
IEnumerable以外ではForEach等の副作用適用メソッドが標準で用意されてるものが多々あるしIEnumerableに拡張メソッド追加して使ってるところもごまんとある

**デフォルトの名無しさん** · 2024/06/30(日) 13:08:54.78

>>497
キツイ

**デフォルトの名無しさん** · 2024/06/30(日) 13:13:35.11

>>500
foreachとForEachくらいは好きなほうでやればいいわな
ものによっては最適化度合いが変わるからそこだけ気にしとけばいい

**デフォルトの名無しさん** · 2024/06/30(日) 13:41:54.85

unwarpほんま糞ダサい

**デフォルトの名無しさん** · 2024/06/30(日) 14:01:03.54

「すべてはオブジェクトである」が糞ダサいのだ
いい感じの構文糖はたいていオブジェクトではない

**デフォルトの名無しさん** · 2024/06/30(日) 15:34:51.28

>>497
エラー返しができていない
ファイル一括読み込みでなくバッファリングすべき
本当の関数型だとセミコロンを使うのは邪道

**デフォルトの名無しさん** · 2024/06/30(日) 16:34:51.56

>>497
ありがとうございます。
u8b受け取ってるラムダ式を関数化したらスッキリしそうですね。

>>496
Selectもindexを受け取れるんですが値を返さないとダメで、
あえてvoidなメソッドの後にreturn 0を、入れてエラーが出なくなったと思ったら、
遅延評価なのかfor/foreach/ForEachじゃないと中身を実行してくれないんですよ…orz
（結論、Selectはデータ加工専用で入出力には使えない）

**デフォルトの名無しさん** · 2024/06/30(日) 16:49:10.64

Rustで関数型のように書くなら

use std::env;
use std::fs::File;
use std::io::{self, BufRead, BufReader};

fn main() -> io::Result<()> {
　env::args()
　　.skip(1)
　　.inspect(|file_name| println!("{file_name}"))
　　.map(|file_name| {
　　　File::open(file_name).and_then(|file| {
　　　　BufReader::new(file)
　　　　　.lines()
　　　　　.enumerate()
　　　　　.map(|(i, line)| line.map(|line| println!("{}: {line}", i + 1)))
　　　　　.collect()
　　　})
　　})
　　.collect()
}

**デフォルトの名無しさん** · 2024/06/30(日) 16:59:35.48

質問です。

.map(|(i, line)| line.map(|line| println!("{}: {line}", i + 1)))
↑
line.mapは文字列へのmapで１文字１文字に番号振ってる様に見えますが、違うのでしょうか？
素直に

.map(|(i, line)| println!("{}: {line}", i + 1))

とは出来ないのでしょうか？

**デフォルトの名無しさん** · 2024/06/30(日) 17:13:06.42

>>508
そこは手続き型で書くと
let line = line?;
のところ
最初のlineはio::Result<String>型
それをmapして次のlineがString型

**デフォルトの名無しさん** · 2024/06/30(日) 17:55:47.01

こうやって関数型を勘違いしたやつが量産されてるんだな

**デフォルトの名無しさん** · 2024/06/30(日) 18:10:42.55

>>509
なるほど、最初のmapと内側のmapで型が違うのですね。
ありがとうございました。

**デフォルトの名無しさん** · 2024/06/30(日) 18:12:41.76

さすが二つ名持ちの汚コーダー
ひと味もふた味も違う

**デフォルトの名無しさん** · 2024/06/30(日) 18:28:40.79

関数型のように書きたいならば基本はfor_eachを使わない
行き詰まりのfor_eachを使うと値もエラーも返せなくなる

**デフォルトの名無しさん** · 2024/06/30(日) 18:46:14.08

>>506
イテレータがどういうものか全然理解してないのな
試行錯誤もいいが最低限の座学知識は必要やぞ

**デフォルトの名無しさん** · 2024/06/30(日) 20:38:10.26

let a: [u32; 4] = [1, 2, 3, 4];
let s: &[u32] = &a[1..3];

a[5]; と書くとコンパイルエラーが発生しますが、
s[5]; と書くとコンパイルは通り実行時にエラーが発生します。

なぜ、 s[5]; が範囲外の領域へのアクセスであることをコンパイル時に見抜けないのでしょうか？

本を見ても、理由が書いてないです。
ただ、そうなるとしか書いてありません。

**デフォルトの名無しさん** · 2024/06/30(日) 21:21:34.70

見抜けるようになっていないから
a は array である一方で s は slice
array は型として長さの情報を持つ一方 slice は持たない
slice の長さはコンパイル時にわからないしわかろうともしないしチェックもない

**デフォルトの名無しさん** · 2024/06/30(日) 21:23:59.76

>>515
静的にサイズが定数だと静的に比較できるから事前にコンパイルエラーとなる
配列は静的にサイズが定数
スライスもこのように静的にサイズを定数にしてやれば事前にコンパイルエラーとなる
const X: &[u32] = &[1, 2, 3, 4];
let x = X[5];

**デフォルトの名無しさん** · 2024/06/30(日) 21:57:28.27

🦀🦀🦀

**デフォルトの名無しさん** · 2024/06/30(日) 22:10:02.00

本といえども一方通行のメディアではなくなってるんじゃないか
読者の側がそれをどうしても知りたい気持ちを表明しなければならないのが双方向でしょ

**デフォルトの名無しさん** · 2024/06/30(日) 22:48:34.24

>>513
一体全体何を言ってるんだ？

**デフォルトの名無しさん** · 2024/06/30(日) 23:09:55.43

>>520
for_eachは値を返せない
関数は基本的に値やエラーを返す
イテレータ利用で値やエラーを返すためにはfor_eachではなくcollectやfoldなどを用いる

>>507のように表示するだけで値を返さない場合であっても
関数はエラーを返さなければならない

**デフォルトの名無しさん** · 2024/07/01(月) 00:45:59.76

>>521
>for_eachは値を返せない
for_eachはunitを返してるよ

>関数は基本的に値やエラーを返す
voidやunitやnilを返すものも関数だよ

>イテレータ利用で値やエラーを返すためにはfor_eachではなくcollectやfoldなどを用いる
try_for_each使ってね
file openやprintのような副作用をイテレータのmapで行うのは関数型の考え方からは程遠いよ

**デフォルトの名無しさん** · 2024/07/01(月) 01:02:37.18

値を()しか返せないのでは意味がない

**デフォルトの名無しさん** · 2024/07/01(月) 01:19:54.94

お前の人生よりは意味あるよ

**デフォルトの名無しさん** · 2024/07/01(月) 04:16:03.32

unwrapをmapで代用とかセンス無さ過ぎ

**デフォルトの名無しさん** · 2024/07/01(月) 05:26:16.34

見抜いたことを全て警告するコンパイラがあったらこんな感じになるのか

**デフォルトの名無しさん** · 2024/07/01(月) 05:49:45.95

Rustは清書用(キリっ

**デフォルトの名無しさん** · 2024/07/01(月) 05:51:10.72

犯人不明ボイス・トォ・スカル被害者にしている者皆判明
AIで被害者が苦しんでいる映像を作成してそれで喜んでいる脳細胞を読み取れば使用しているかの判定
AIで自分が高みの見物ができるかどうかも判定
あとは下記を参考にして行えばよい

いじめで殺害したかも判明するので迷宮入り事件犯人を絞り込める
隠しカメラの場所も判明

忘れた記憶を再び思い出せるようにする脳細胞を発見！
2024.06.28
「あなたの一番古い記憶は？」人は覚えていても2歳以前の記憶にアクセスできなくなっている
2023.11.30
なぜ私たちは起こってもいない間違った記憶をしてしまうのか？
2023.11.27
自分でも気づいていない「記憶の間違い」を脳波で判断できると判明
2023.10.19
富山大、睡眠中の脳で行われている推論の演算を神経細胞レベルで解明
2024/06/26
サイコパスはためらわない？－－嘘つきの脳のメカニズム
2019/09/26

脳を刺激して特定の記憶を呼び戻す技術「記憶プロテーゼ」を開発
2024/02/21

「0」を”思う”ときの脳活動は「1」に近い！捕食者への恐怖がゼロの根幹だった？
2024.03.07
>>MEGを使うと、脳内でわずかに発生する磁場変化をとらえて、脳活動を記録することが可能です。
>>（※脳波計が脳の電気活動を読み取るのに対して、脳磁計は脳の磁気活動を読み取ります）

東工大、磁束集中器を用いない高感度「ダイヤモンド量子センサ」を開発
2024/06/07
>>日常的な検診や脳機能のより詳しい研究や、ブレイン・マシン・インタフェースの研究などへ大きく貢献できると期待されている。

**デフォルトの名無しさん** · 2024/07/01(月) 06:29:11.19

>>525
unwrapは使わずにmapでNone/Errを透過的に渡すのはRustの基本

**デフォルトの名無しさん** · 2024/07/01(月) 07:19:14.88

これmapメソッドでもmap関数でもない中立な勢力が勝つパターンだ

**デフォルトの名無しさん** · 2024/07/01(月) 11:47:54.40

Functorのmapなんだよね
でもFunctorは定義されてなくて統一的に扱えないんだから
Result/Optionはfmapとか違う名前にしておいたほうがよかったと思う

どっちにしろmap/fmapで副作用はアンチパターン

**デフォルトの名無しさん** · 2024/07/01(月) 11:55:40.56

fmapなんかflatMapと勘違いされるだろ

**デフォルトの名無しさん** · 2024/07/01(月) 12:47:47.85

そんな勘違いをする人にRustは無理

**デフォルトの名無しさん** · 2024/07/01(月) 12:59:53.25

>>525
こう書くとresultがErrの時に返せずここでpanicになってしまう

　let val = result.unwrap();
　f(val)

そのためpanicしてもいいとか絶対にErrとならない特殊な場合を除けば
unwrapを用いてはダメでmapを使ってこのように書くんだよ

　result.map(|val| f(val))

ここで本当に関数fを呼ぶだけならresult.map(f)と簡略化できるけど
f(val)の部分は式やブロックの可能性もあるので簡略化せずに進めるね

これは以下と同等でErr(err)の時に保持してくれている

　match result {
　　Ok(val) => Ok(f(val)),
　　Err(err) => Err(err),
　}

ちなみにf(val)もResultを返すときは
mapの代わりにand_thenがある

　result.and_then(|val| f(val))

つまり以下の二つは同等

　result.map(|val| f(val))
　result.and_then(|val| Ok(f(val)))

この場合はもちろん簡素なmapを用いるべき

**デフォルトの名無しさん** · 2024/07/01(月) 13:41:34.54

Rustを10年以上使ってるひとに質問です
Rust本体をバージョンアップしたときに
動かなくなった旧バージョン用のcratesや自分のプロジェクト(main.rsなど)は
どれくらいありましたか？
またdeprecatedやobsoletedにされた機能は
使えなくなるまでに実際何年くらい使い続けられましたか？

**デフォルトの名無しさん** · 2024/07/01(月) 14:05:59.07

Rust 1.0からまだ10年経っていない
Rustは3年毎のedition制度があって後方互換性がない変化はeditionが変わるため安心
今も最初のRust 2015 editionがサポートされてる
さらにedition移行支援ツールもある
Rustは他言語と比べてかなり恵まれてる良い環境

**デフォルトの名無しさん** · 2024/07/01(月) 14:11:38.44

>>534
>ちなみにf(val)もResultを返すときは
の条件なら
>つまり以下の二つは同等
>　result.map(|val| f(val)) // Resultを還さないf
>　result.and_then(|val| f(val)) // Resultを還すf
じゃないんですかね(Ok(f(val))は蛇足)

**デフォルトの名無しさん** · 2024/07/01(月) 14:22:14.04

Resultを返すか返さないか関係なくこれは常に成り立つね

>>534
＞以下の二つは同等
＞ result.map(|val| f(val))
＞ result.and_then(|val| Ok(f(val)))

例えばf(val)がOptionを返したとしても成立するよ

**デフォルトの名無しさん** · 2024/07/01(月) 14:22:38.11

flat_map の関数名を and_then にしたのはどこの言語の文化？

**デフォルトの名無しさん** · 2024/07/01(月) 14:43:32.98

iostreamの記号をまるでセガサターンのように見下して英単語を推した文化

**デフォルトの名無しさん** · 2024/07/01(月) 14:48:54.46

and_thenはor_elseに対してのantitheseだと思った

**デフォルトの名無しさん** · 2024/07/01(月) 14:51:31.68

result1.and(result2) がまずあって
result1.and_then(|ok1| return_result2(ok1)) が関数版だね
OptionでもResultでも同じ命名

**デフォルトの名無しさん** · 2024/07/01(月) 14:59:21.90

iostreamの << をRustに導入しなかったのはなぜ？

**デフォルトの名無しさん** · 2024/07/01(月) 15:05:11.12

std::fmtで十分だから

**デフォルトの名無しさん** · 2024/07/01(月) 15:05:34.52

うるせぇやりたきゃShl実装しろ

**デフォルトの名無しさん** · 2024/07/01(月) 15:30:41.32

>>543
単純な二項演算子でやると書式指定の範囲を制御できないんだよ。
C++ ではストリームに対する書式指定は永続的な効果を持っていて、その効果を上書きするまで続く。
普通の方法で指定したらグローバルな影響を持ってしまうのは明らかにまずい。

iostream が出来たときは可変長引数の関数を型安全に扱う方法 (variadic template) が無かったし、
書式指定文字列をコンパイル時に解釈して安全に扱う方法 (constexpr) も無かったから
その範囲内で当時の知見で比較的マシな形にしたらああなったという程度のもんで、
今の考え方からすると iostream は真似したいようなもんじゃない。

むしろ C++ のほうが新しい仕様では Rust 風のやり方に寄せて来てる。

**デフォルトの名無しさん** · 2024/07/01(月) 15:53:07.19

>>543
ダサすぎるから

**デフォルトの名無しさん** · 2024/07/01(月) 15:56:35.04

rustもprint時のstring interpolationはもう少しどうにかならんものかね

**デフォルトの名無しさん** · 2024/07/01(月) 18:51:52.61

macroなんで自分で描き替えればええんやで

**デフォルトの名無しさん** · 2024/07/01(月) 20:45:22.07

自作した後の自己肯定を10年続けるまでがプログラム技術

**デフォルトの名無しさん** · 2024/07/01(月) 23:04:21.05

昔、C++でprintf使ったら怖い人に怒られたのに
今じゃあれはクソ設計だったって評価に固まってるんだね、英語圏でも

**デフォルトの名無しさん** · 2024/07/01(月) 23:12:10.92

>>551
C/C++ の printf は iostream 以上にカス。
型のチェックがガバガバだし、ちゃんと理解してないやつのほうが多いので常に問題を引き起こしていた。
ただ、記法としてはこれで良かった。

**デフォルトの名無しさん** · 2024/07/02(火) 02:06:02.53

今の C/C++ の printf はコンパイル時に型チェックして警告してくれる

**デフォルトの名無しさん** · 2024/07/02(火) 05:00:17.05

>>553
型チェックできて型がわかっているのに
なぜ%dや%fや%sなど指定しなきゃいけないのか理解できない
型がゆるゆるだった大昔の遺物にみえる

**デフォルトの名無しさん** · 2024/07/02(火) 06:06:14.65

>>554
みえる、じゃなくて完全に遺物だろ

**デフォルトの名無しさん** · 2024/07/02(火) 06:44:02.90

表示はRustのDisplayトレイト実装方式が洗練されていて使いやすくていいね

**デフォルトの名無しさん** · 2024/07/02(火) 08:28:24.43

仕様書が聖書のようなものだから遺物だろうが仕様書に逆らうわけにはいかないじゃん

**デフォルトの名無しさん** · 2024/07/02(火) 08:41:47.20

>>544
C の関数は基本的にはちゃんと型はついてるが可変長引数は静的な型情報を捨てること実現してる。
もちろんそれを引き継いだ C++ も。
C++ は後に variadic template による安全な可変長引数を導入したが古いスタイルの可変長引数も廃止はしてない。
言語仕様を素朴に実装したら型はわからないんだよ。
printf などの一部の関数に限っては「関数の型情報によらずに」コンパイラが特別扱いでチェックしてる。
関数の型を元に検査してるんじゃなくて printf の仕様をビルトインして特別扱いしてるの。

**デフォルトの名無しさん** · 2024/07/02(火) 10:27:11.96

>>538
result.and_then(|val| Ok(f(val)?))
とか
result.and_then(|val| Ok(f(val).unwrap()))
じゃなくて
result.and_then(|val| Ok(f(val)))
で良いのはなぜ？

**デフォルトの名無しさん** · 2024/07/02(火) 10:37:23.15

Rust初めて使ったときは「println! みたいな基本的なものがマクロで？大丈夫かこの言語」みたいに思ったもんだが、
よくよく考えるとマクロにせずに、柔軟なシグニチャでなんとかしようとする他の言語のほうがよっぽど醜いもんな。

**デフォルトの名無しさん** · 2024/07/02(火) 10:55:15.33

>>559
上2つはResult<T>
最後のはResult<Result<T>>かResult<Option<T>>
ネストが一つ深くなる

**デフォルトの名無しさん** · 2024/07/02(火) 11:50:20.39

>>560
C++ のライトユーザは関数テンプレートのことを誤ってテンプレート関数と呼ぶことが頻繁にある。
関数テンプレートが関数であるという誤解が言葉になって表れてるんだと思う。
単に使うだけなら関数みたいに見えてしまうからかもしれない。

関数テンプレートは関数を生成する元になるテンプレートだから関数テンプレートなので「生成する」というところに着目したらマクロで生成するのでも理屈はあまり変わらないかもしれない。

ただ、 LISP 系言語の経験から言うと構文レベルで制御されるマクロはエディタのサポートが受けづらいし、ドキュメントを型で表現できないのはやりづらい。
マクロ展開の失敗がどういう失敗なのかをきちんとエラーメッセージにするのも難しい。
デメリットもあるけど、どうせどこかに問題があるならこのくらいで良いという潔さは感じる。