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/27(木) 23:34:16.52

C/C++ だと抽象機械という概念を挟む形で仕様化されてる。
言語の挙動を抽象的な (架空の) 機械の動作として記述していて、それを実際の機械とどう対応させるかは知らんけど見かけ上の動作が仕様通りなら良しとする規定。
だから最適化を豪快にやっても結果が同じなら言語仕様に反しない。

で、抽象機械っていうのはある程度は現実のコンピュータを想定はしているけど細かいところは意図的にうやむやにして選択の余地を残してる。
C/C++ には言語仕様としてはスタックもヒープも存在せず書いてあるのは寿命についてのルールだけで、それをどういう形で実現するかは自由……
なんだけど現実にはスタックとヒープを使い分けるとちょうどいいような仕組みになってる。

C/C++ の言語仕様に低レイヤのメモリアクセスのことも確かに書いてあるんだ。
でもそれは抽象的な機械のことであって本物の機械のことじゃない。
でもある程度は対応しているという絶妙なバランスで成り立ってる。

Rust では言語の高レイヤの話と低レイヤの話の間を取り持つ理屈がまだ十分に整理されてないと思う。
言語の性質上、やっぱり低レイヤを全く意識しないで上手く使えるようなものでもないし、低レイヤのことを考えるのもそれなりには必要だと思う。
必要なんだけど意識的にレイヤを分けて考えられないなら混乱するのも確かなので、 (少なくとも最初は) 低レイヤのことは忘れろというのは理に適った助言だと思う。

**デフォルトの名無しさん** · 2024/06/27(木) 23:40:56.83

C/C++の方こそ誤魔化しているぜ
そのため未定義動作だらけだ

Rustはわかりやすく抽象的に明確だ
そして未定義動作もない

**デフォルトの名無しさん** · 2024/06/27(木) 23:46:01.41

未定義動作の話をしてはいないよ。
低レイヤとの間をどう取り持つかの話をしてる。

**デフォルトの名無しさん** · 2024/06/27(木) 23:53:14.85

Rustは低レイヤにも対応している
高い抽象度によるプログラミングもできる
高い抽象度のプログラミングにおいて低レイヤとの対応付けは不要であってやるべきではない

**デフォルトの名無しさん** · 2024/06/27(木) 23:56:31.92

オジーw

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

>>424
その論を許すなら Rust は OS やデバイスドライバを書くのには使えない言語であってよいという立場になるが、そうじゃないよね？

**デフォルトの名無しさん** · 2024/06/28(金) 00:16:19.92

>>426
なぜなの？
Rustが抽象的にプログラミングできるのも事実であるし
OSやデバイスドライバを記述できるのも事実だよ

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

>>427
低レイヤを書くための仕様が確立していなくて今はなんとなく書けているという状態を「できる」と称していいならそうだね。

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

>>428
うーん
Rustに何か欠けているわけではなく
実用的に問題なく機能している状況で
言い掛かりをつけてるだけにみえるけどどうよ

**デフォルトの名無しさん** · 2024/06/28(金) 00:48:52.30

>>429
実用的に問題があって、機能できていない。
Rust の仕様に明るくて低レイヤのメカニズムに明るくても Rust で OS は書けないから。
現状では Rust の実装に明るいという要素が求められていて、ある程度はそういうものかもしれないけど仕様 (というか文書化というべきかな) の明確化が十分とは言えない。

**デフォルトの名無しさん** · 2024/06/28(金) 00:57:19.20

>>430
本気で言ってるのかなあ
デバイスドライバはRust製に置き換えられたよ
OSもRustで新たに作られて機能することも判明してるけど
既存のOSは書き換えコストの問題だから別問題だね

**デフォルトの名無しさん** · 2024/06/28(金) 01:04:07.98

そういえばRedoxの開発は今どうなってるんだろ

**デフォルトの名無しさん** · 2024/06/28(金) 01:21:44.32

>>431
これからやる人に対して説明できる形になってないという話をしてる。
出来てるから出来るんだというのは何の根拠にもならんよ。
出来るようになるための道筋が確立しているかどうかの話なんだ。

**デフォルトの名無しさん** · 2024/06/28(金) 01:57:43.66

流れを切って申し訳ないんだけど
Rustってディープラーニングのプログラムを作るのに実用的な段階に来てる?
まだ一部の物好きが書いてるだけ?

**デフォルトの名無しさん** · 2024/06/28(金) 02:39:42.33

自分

Rustってディープラーニングのプログラムを作るのに実用的な段階に来てる?
まだ一部の物好きが書いてるだけ?

Copilot

Rustでディープラーニングのプログラムを作ることは可能ですが、まだ一部のエンジニアが実験的に取り組んでいる段階と言えます。具体的には、『ゼロから作るDeep Learning』の内容をRustで実装する試みや、Deep LearningのフレームワークDeZeroをRustで実装する試みなどがあります。

これらの試みは、Pythonで書かれたディープラーニングのコードをRustに翻訳し、Rustの学習やディープラーニングの理解を深めるためのものです。しかし、これらの実装はあくまで個々のエンジニアの学習目的で行われており、一般的なディープラーニングの実装にRustが広く使われているわけではありません。

Rustはパフォーマンスが高く、メモリ安全な言語であるため、ディープラーニングの実装にも適していると言えます。しかし、Pythonのように豊富なディープラーニングライブラリが存在しないため、現状ではディープラーニングの実装にはPythonが主に使われています。

Rustでのディープラーニングの実装が一般的になるかどうかは、今後のRustコミュニティの活動やディープラーニングの研究動向によるところが大きいでしょう。

**デフォルトの名無しさん** · 2024/06/28(金) 02:47:01.21

>>435
さっそくの返信ありがとうございます

> 今後のRustコミュニティの活動やディープラーニングの研究動向

がどうなってるかを聞きたかったんですがどんな感じですか?
libtorchバインディングのtorch-rsや
ほぼ純Rust製のcandleが出てきたのはわかったんですが
まだ周辺ライブラリが足りない感じです?

**デフォルトの名無しさん** · 2024/06/28(金) 03:31:36.21

少なくとも俺よりはAIの方が物知りだから自分でAIに聞いた方がいいと思う

警備員[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のように表示するだけで値を返さない場合であっても
関数はエラーを返さなければならない