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/

警備員[Lv.22] · 2024/06/28(金) 03:44:03.44

論文の検証を論文と異なる言語ではしないでしょぅ
NCNNやDarkNetを超えるエンジンがあるわけではなし

**デフォルトの名無しさん** · 2024/06/28(金) 05:55:26.25

>>417
関数の引数にオブジェクト（Copy型でない型）を渡す際は参照渡しが基本で、
うっかり所有物を引数として渡すと所有権ごと関数の向こうへ移動してしまって二度と戻って来ない
これは逆に、関数が何らかの実体を返り値として返す際には便利

とまあネチネチ考えてればわかってくるもんだよ

**デフォルトの名無しさん** · 2024/06/28(金) 07:54:27.71

>>422
unsafeを無視しちゃいかんよ。

**デフォルトの名無しさん** · 2024/06/28(金) 09:41:44.10

型がガチガチの言語でdeepnetの実装するのは面倒な割に生産性薄いわ

**デフォルトの名無しさん** · 2024/06/28(金) 09:45:48.57

仕組みがまだ確立してなくて試行錯誤があるなら型で制約しまくるのは面倒なだけだけどもうそういう段階じゃないのなら型で固めたほうが (使い方の間違いが検出されやすいので) 生産性高いよ。

**デフォルトの名無しさん** · 2024/06/28(金) 12:27:02.70

>>441
C++/C#/Javaとの比較はともかく、LLとの比較は目指すところが違うでしょ。
Rustは組み込みやOSまでカバーする言語。

医療用機器とか、自動車とか、命に関わるような分野でバグを入れないための言語なんだから。

金融も同じようなものだけど、そっちはOCamlの実績（みずほ）があるのでRustである必要は必ずしもは無い。

**デフォルトの名無しさん** · 2024/06/28(金) 13:07:10.53

LLとかいう死語を使ってるのは複オジだけだぞ

**デフォルトの名無しさん** · 2024/06/28(金) 13:32:56.61

>>441
ささっと数行書くスクリプトでなければ静的型付け言語が生産性高いよ

**デフォルトの名無しさん** · 2024/06/28(金) 17:07:56.21

うい。４０のおっさんよん(^_-)

まあ、プロトタイプは動的型言語で作って、本番のコードは静的型言語で作るなんて常識なんだから、若い人じゃなければ

> 型がガチガチの言語でdeepnetの実装するのは面倒な割に生産性薄いわ

何てこと書かないわな…。

**デフォルトの名無しさん** · 2024/06/28(金) 18:51:50.94

今のご時世にプロトタイプは動的言語とか言ってるのは頭の硬いジジイか、ジジイの本でしか勉強出来ない馬鹿がほとんどなんだよなあ

**デフォルトの名無しさん** · 2024/06/28(金) 19:09:29.56

出来る人ならそれで良いし、それで>>441の言うように生産性が低いと感じないなら全然かまわない。

馬鹿馬鹿言うけど、そういう馬鹿にも作らせないといけないし、それでも作れない救えない奴はリストラするしか道が無い。

**デフォルトの名無しさん** · 2024/06/28(金) 19:58:03.61

動的型でプロトは結局本番で書き直す時間など取れないから机上の空論ってのが最近の認識では
最初から静的型にするか、どうしようもなくなるまで動的型で耐えるかの2択じゃないかな
まぁたいていのスタートアップは耐えられなくなる前に潰れるからそれを見越して動的型というのはありだと思うが

**デフォルトの名無しさん** · 2024/06/28(金) 20:05:28.17

スタートアップ企業であろうと
動的型付け言語を使うのは開発効率が悪い

**デフォルトの名無しさん** · 2024/06/28(金) 20:36:15.04

んー…。
おっさん的には関数単位でテスト出来るかどうかが問題であって、プロトタイプは動的か静的かの問題じゃない気がするな。

最近は静的型言語でもインタラクティブシェル（略語忘れた)のインタプリタで関数単位でプロトタイプ作ってテストして、上手くいけばビルドって流れだし。

そういうのが無い言語は今でもプロトタイプは動的言語で作って…ないわｗ

場合によるな。
すでに作り方を知ってたらいきなり静的型言語で書くし、何か思いついたけど確信が持てない。みたいな時(試行錯誤が予想される)は動的型言語でプロトタイプ書いてるかな。
(静的型言語にインタラクティブシェルが無い時)

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

Rustのメモリモデル
https://doc.rust-lang.org/reference/memory-model.html

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

少人数で超大規模なシステムを作るのには Common Lisp が向いてるみたいな話もある (実際に使われてる) けど、それはプログラマが超人なだけじゃないのみたいな話もあってあまり一般化した話には出来んな。

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

権利あるいは義務が移動することを物理メモリで説明するのは難しいが
実行時型情報みたいにいちいちメモリを消費して情報を管理すれば
物理で説明できないこともない
そのためには動的言語の知識も役に立つ

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

実際機械学習でc++でもjavaでもほとんど使われてないってのに、やっぱ静的解析バカが多いんだなここ

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

Pythonでも”静的解析”は普通に使ってるだろw
自分が書いてる用語くらいは学んどけよww

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

ダックタイプあれば動的でも静的でもあんまり変わらん。ビルド時間の違いくらいか。

実装初期は設計の柔軟性を確保できればいい。まぁ、アダプタでなんとかするのが妥当なところかもしれんが。

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

オーナーシップとライフタイムの関係でGC言語なら簡単なリファクタリングがRustでは大手術が必要になることがよくある
大手術すぎて根本的なリファクタリングに着手できてない例もよく見かける

ここでいってるプロトタイプとは少し意味が違うがPython等でプロトタイプ作ってRust化する人がある一定程度いるのはプロトタイピング時にボローチェッカーで時間を浪費するよりも言語変えた方が効率がいいと考えられてるから

この辺はRustのメリットとデメリットを考えた使い分け

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

ダックタイピングがあれば良いが、Pythonのダックタイピングはライブラリの型が壊れているからダメ
あと、ダックタイピングの不満を消していくとTraitになるから出来ればTraitの方が良い

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

>>458
そういうRustでのリファクタリングならば大手術にならない
メモリ保有を適切な位置に移したり分解したりするなどの単純なリファクタリングで済んでいる
それにより保守性もデバッグ効率も上がるためリファクタリングコストは誤差に等しい
仮にGC言語で書いている時でも同様でその状態は各データが複雑に絡み合っている状態なのでリファクタリングしたほうが望ましい

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

ダックタイピングがあるってどういう状態のことだろう

**デフォルトの名無しさん** · 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を返したとしても成立するよ