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/15(土) 23:47:36.34

参照の寿命が尽きても参照元のデストラクタは呼ばれない
だから参照元がヒープにあろうがなかろうが参照の寿命はスタックに基づいて決めてしまえば良い

**デフォルトの名無しさん** · 2024/06/16(日) 00:42:56.54

>>170
「参照元」は誤用か
参照先と言うべきだったか

**デフォルトの名無しさん** · 2024/06/16(日) 00:50:00.04

>>169
スタック上への参照とヒープ上への参照をRustでは区別しない
ライフタイムさえ満たしていればどこを指していても区別なく参照を扱う
そのため、従来行われてきた「安全にヒープ上でに領域を確保してヒープ上への参照を返す」をしなくても
ライフタイムさえ満たしていればスタック上への参照を安全に渡したり返したり自由にできるようになった
そのため、従来はヒープ上に確保していていたケースがRustではスタック上に置くことができるようになり、その点でも高速化に寄与している

**デフォルトの名無しさん** · 2024/06/16(日) 01:00:26.12

複オジのレスはいつも通り8割は嘘だな

**デフォルトの名無しさん** · 2024/06/16(日) 01:15:13.88

>>172
別にC言語だってallocaの返したポインタとmallocの返したポインタを区別しないけど

**デフォルトの名無しさん** · 2024/06/16(日) 01:25:03.80

誰が解放するか責任もなく解放忘れや多重解放を生むＣ言語は論外だろ
解放されたスタックフレームやヒープエリアを指し続けているポインタが残ったりな

**デフォルトの名無しさん** · 2024/06/16(日) 01:32:46.10

C言語と違って区別しないわけじゃないし、C言語と違って高速ってわけでもない

**デフォルトの名無しさん** · 2024/06/16(日) 01:39:48.74

C言語同様に区別しないし、C言語同様に高速なんでしょう

**デフォルトの名無しさん** · 2024/06/16(日) 01:45:22.24

そろそろ自己隔離しとけザコども

結局C++とRustってどっちが良いの？ 9traits
ttps://mevius.5ch.net/test/read.cgi/tech/1701997063/

**デフォルトの名無しさん** · 2024/06/16(日) 03:32:45.56

へえ、コピーじゃなくて移動をデフォにしちゃうのか

**デフォルトの名無しさん** · 2024/06/16(日) 04:03:11.69

>>174
mallocで得たポインタとallocaで得たポインタは明確に区別しなければならない
mallocで得たポインタのみfreeの対象としなければならない
この区別はCプログラマーの責務でありミスると破綻する

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

>>180
コンパイラが区別してくれるわけじゃないからそう書いた
今はRustコンパイラの秘密を探ってるんだし

**デフォルトの名無しさん** · 2024/06/16(日) 04:28:58.35

Rustはヒープで確保したメモリ領域も完全自動で安全にメモリ解放されるからプログラマーの負担がなくていいよね

ヒープへの参照とスタックへの参照に区別がないだけでなく
それらをたとえ混ぜて関数間で渡したり返したりたらい回しにしても安全で
もし安全でない使い方をした時はライフタイムが切れてコンパイルエラーになるから自由と安全が両立されてるね

警備員[Lv.18] · 2024/06/16(日) 04:37:34.79

解放されたスタックフレームが残って、どうやって呼び出し元に帰るつもりなんだろう。😱

**デフォルトの名無しさん** · 2024/06/16(日) 04:43:29.58

メモリはコピーじゃなくて（所有権の）移動がデフォ
所有者がスコープを抜けるとメモリは解放
所有者に別の値が代入された際もメモリは解放
代入元は所有権が移ると未初期化の扱いになる

これだけでもかなり面白いね

**デフォルトの名無しさん** · 2024/06/16(日) 04:50:45.28

>>183
C/C++/Rustすべて関数が呼び出し元に戻るときにスタックフレームは自動解放されます
もしその破棄されたスタックフレーム上を指すポインタ(参照)がどこかに残っていた場合、
C/C++ではそのポインタ使用でそこをアクセスしてしまい気づかないバグや穴となるでしょう
Rustではコンパイル時点でライフタイムエラーとなるため問題が起きないです

**デフォルトの名無しさん** · 2024/06/16(日) 05:46:32.57

正体不明のボイス・トォ・スカル
マイクロ波聴覚効果の機能より

神の声兵器は機器の場所が割れているので
ハッキング下と奪取後に器機を複製できた音を宣言していた

電磁波音波なのでむやみに器機に仕掛けると誰かが攻撃しているとすぐに設置したものは察知するが
その監視網をかいくぐるということは一発で危機をジャックしたことになる

そして機器の性能は年々よくなるので自分に行って見分けがつかないくらいになると器機使用者が幻覚を見ていると錯覚し始める

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

メモリはそれ自体は無論のこと、それを指すポインタもひとつしかないわけだ

**デフォルトの名無しさん** · 2024/06/16(日) 07:56:02.10

この発想は正直なかったわ
ひとつのメモリをあちこちから参照すればするほど高効率みたいな思い込みがあるからね

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

>>167
>全部stack
そういう描き方をすればそうなるってだけで
そういう描き方ならCでも出来る

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

>>169-171
CにBoxを導入すれば解決

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

>>173
ほんそれ

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

で、配列の要素だったり構造体のメンバだったりは「移動済み」にできない？

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

とにかく&をつければアドレスを借用できて、その生存規則違反はコンパイラがはじく、と

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

新参に教えといてあげると
172, 175, 180, 182あたりはすべて複製おじさん(通称複オジ)という同一人物だよ
知ったかぶりで出鱈目ばかり書いて全く反省しないという
悪い意味で有名な人ので騙されないように注意してね

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

1日10行推敲するより1日1万行書いた方が数値化に貢献しやすいからしょうがない

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

ボローチェッカーは作るのも使うのも難しそう
よくこんなこと可能だと思ったもんだ

**デフォルトの名無しさん** · 2024/06/16(日) 11:48:19.48

Rustの中ではつまらないというか泥臭い部分だね

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

>>196
ライフタイムについてまじめに知りたいなら（ある程度Rustには慣れた前提として）NLLのRFCを読むのをおすすめしたい
ttps://rust-lang.github.io/rfcs/2094-nll.html

そろそろこれよりいい資料は出ないもんかね……というかReferenceに明記してもらえんかね
なんか1.79でも地味にルールが拡張されたようだし

**デフォルトの名無しさん** · 2024/06/16(日) 12:23:11.10

ええっと、メモリの所有者が
・スコープを抜けること
・別の値が代入されること
・別の変数に所有権を移動させること
はもともと検出できる前提なのだよね
ボローチェッカーと言ってもその３つの組み合わせに毛が生えた程度なのかどうか

**デフォルトの名無しさん** · 2024/06/16(日) 12:27:02.82

>>198
全ての言語仕様を「仕様書」としてまとめる提案は出ているんだけど何年も動きがないんだよね……

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

>>174
allocaで得たポインタfreeしてそうなコメントだな

**デフォルトの名無しさん** · 2024/06/16(日) 12:32:49.98

>>199
メモリとかアドレスとか言ってる時点で正確な理解から遠いと思う。
変数はメモリではないし、参照はアドレスではない。
処理系の実装としてはそのように対応するという想定はあるだろうけど機械語レベルの事情と言語のルールはレイヤが違う。

**デフォルトの名無しさん** · 2024/06/16(日) 12:33:46.16

>>201
機械語知ってるからそんな心配はない

**デフォルトの名無しさん** · 2024/06/16(日) 12:36:26.13

>>202
そうだね。Rustは高級アセンブラってわけではまったくないね。勘違いしてた

**デフォルトの名無しさん** · 2024/06/16(日) 12:42:20.38

代入だったり関数呼び出しの引数だったりはコピーじゃなくて移動がキホンって時点で機械語ともC言語とも違う

**デフォルトの名無しさん** · 2024/06/16(日) 12:51:16.07

>>205
代入と考えるよりもパターンマッチングと考えるといいかな
＝や引数などで複雑なパターンを書いてもマッチングしてくれるよ
それがたまたま1対1の時が昔からの代入に相当してマッチングして移動

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

あえて機械語レベルでも考えるとするなら概念的には移動でも (最適化を別にすれば) ビットパターンはコピーしている。
所有権を失った変数にはアクセスできないように静的に制限されるから所有権が移動したように見える。
借用は (借用が存在している間は) 移動を許さない権利として捉えることができる。

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

>>200
現状だとここを見ておくのがいいかも
https://public-docs.ferrocene.dev/main/specification/index.html
ISO 26262の認定通すために書かれたものだからかなりちゃんとしている

**デフォルトの名無しさん** · 2024/06/16(日) 15:11:48.05

>>208
C/C++はISO認定だからな
一方、Rust連中はほんぽん仕様変える(変えたい)から、そんなISOレベルの仕様書書く意味がないって感じじゃないのか

**デフォルトの名無しさん** · 2024/06/16(日) 15:51:37.66

>>209
C++ だって三年ごとに更新する制度になってるし、その間の議論でも仕様の文面をどう変えるかという形式をとる。
頻繁に変えるつもりがあるならなおさら今どうなってるのかの全体像を把握できる仕組みがないと困る。

**デフォルトの名無しさん** · 2024/06/16(日) 15:52:59.06

RubyもISOになったことあるし

**デフォルトの名無しさん** · 2024/06/16(日) 15:57:39.35

15.4:16 ??? (this should describe the order of borrowing and when the borrow is returned)

わろた

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

NLLというくらいだからもともとLL

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

まあ一応（ボローチェッカーというものが）可能そう

**デフォルトの名無しさん** · 2024/06/16(日) 17:20:46.77

コンパイラはプログラム中の全ての参照型に対してライフタイムを割り当てる、と

**デフォルトの名無しさん** · 2024/06/16(日) 17:45:29.17

言語にISO標準を求めるのって相当なお爺ちゃんでしょ
もうそういう時代じゃないですよ

**デフォルトの名無しさん** · 2024/06/16(日) 17:52:05.41

>>215
所有者がどのスタックフレーム(の中のどのブロックスコープ)にいるかだけの話だよな
そこより先なら参照は生きて
そこより元なら参照も死ぬ

もちろんそんな神の絶対的な視点を実行前のコンパイル時点で静的に持つことはできない
しかし各関数内での出入り(引数がinで返り値がout)は静的にわかるから
相対的な視点で有効か無効かわかることになると

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

>>216
ISO 規格が必要なんて話はしてないだろ。
仕様書が要るって話をしてるんだぞ。

**デフォルトの名無しさん** · 2024/06/16(日) 18:05:26.18

複製おじさんと遊ぼうスレ

**デフォルトの名無しさん** · 2024/06/16(日) 18:43:24.33

>>218
>仕様書が要るって話をしてるんだぞ。
別に全然要らないぞ
逆になんで要るんだ？

**デフォルトの名無しさん** · 2024/06/16(日) 18:44:48.95

ひとつしかない所有者がスコープを抜ける、もしくは所有者に別の値が代入されると、そこから先にはメモリはもうない

**デフォルトの名無しさん** · 2024/06/16(日) 18:57:47.09

なんとなく、所有者はスタックの根元の方に、参照はスタックの枝葉の方にいそうなイメージ

**デフォルトの名無しさん** · 2024/06/16(日) 19:01:15.44

>>221
有効な参照(借用)が存在したまま移動や破棄は起きない
これは静的に判定されコンパイルエラーとなる

**デフォルトの名無しさん** · 2024/06/16(日) 19:08:46.55

>>223
つまり所有権も静的に解析できる？

**デフォルトの名無しさん** · 2024/06/16(日) 19:26:50.69

ここは結局こんな感じなのでID:dwkxcYMWは本当のことが知りたいならrust-lang-jpのZulipにでも行くといい
ttps://rust-lang-jp.zulipchat.com/

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

>>220
じゃあ言語の仕様をどうやって把握すんの？
何が出来ていれば Rust のコンパイラを実装できましたって言えるの？

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

>>224
できるというか、それが Rust のキモやで。

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

ゴールポストを固定することが正しいという考えが衰退したんだよな
正しさを疑うことが常識になったから

**デフォルトの名無しさん** · 2024/06/16(日) 22:29:00.55

>>228
ゴールを設定したいという話じゃなくて「今」どうなっているか見えないと疑うべきものすら存在できないって話なんだよ。

**デフォルトの名無しさん** · 2024/06/16(日) 22:37:41.81

>>226
>じゃあ言語の仕様をどうやって把握すんの？
言語の仕様はリファレンスで把握しろよ

>Rust のコンパイラを実装できましたって言えるの？
言える必要性が全くないやろ
どうしても言いたければ公式が用意してるコンパイラと標準ライブラリのテストを全部通したらいいんじゃね？

**デフォルトの名無しさん** · 2024/06/16(日) 23:02:11.93

>>230
端的に言うと現状のリファレンスマニュアルで Rust の仕様の全てを読み取ることは出来ない。
そのことは >>198 あたりからの話題の流れ。
リファレンスマニュアルは仕様を書くものじゃないし。

**デフォルトの名無しさん** · 2024/06/17(月) 06:58:24.07

【マイクロ波センサー】長距離でも壁があっても動きを検出！
↓2010年ごろには完成
高齢化社会を支える“見守りシステム”の開発に成功-カギを握った半導体ソリューションとは
↓2026年ごろにさらに性能工場
旭化成、ミリ波・マイクロ波帯の空洞共振器による微小金属検査システムを開発

男女関係なく陰部を撮影
一度でも盗撮されていれば正確な色合いの・・・
初期型は赤外線センサー【自動ドアのセンサなど】

子どもが言語を獲得していくのと同じようにAIモデルに学習させることに成功
AIを使って「赤外線カメラ画像のフルカラー化」に成功！

世界中で横行

**デフォルトの名無しさん** · 2024/06/17(月) 16:27:54.49

役に立たないどんぐり

**デフォルトの名無しさん** · 2024/06/17(月) 21:23:17.19

卒業式でみんなで思い出を言うやつみたいだな

卒業生　「そして役に立たないどんぐり！」
卒業生一同　「どんぐり～」

**デフォルトの名無しさん** · 2024/06/17(月) 21:51:46.63

卒業生A　「高速で動作しながら保たれる高いメモリ安全性」
卒業生一同　「安全性！」

**デフォルトの名無しさん** · 2024/06/17(月) 22:06:12.81

米ホワイトハウス「ソフトウェアはメモリ安全でなければならない」との声明を発表：「C」「C++」よりも「Rust」などの言語を推奨
https://atmarkit.itmedia.co.jp/ait/articles/2403/18/news045.html

**デフォルトの名無しさん** · 2024/06/18(火) 00:33:44.73

卒業生　「みんなで借りた所有権」
卒業生一同　「所有権！」

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

AIにC++とRustのコードを比較してもらった
https://nshinchan01.hateblo.jp/entry/2024/06/18/021159

**デフォルトの名無しさん** · 2024/06/18(火) 08:51:41.62

見えない仕様書より見えているコロンブスを殴る
殴る

**デフォルトの名無しさん** · 2024/06/18(火) 09:12:34.89

>>238
sum()自体は使わないとしてこうかな

fn foo(input: impl IntoIterator<Item = i32>) -> i32 {
　input
　　.into_iter()
　　.filter(|x| x % 2 == 0)
　　.map(|x| x * 2)
　　.fold(0, |sum, x| sum + x)
}

fn main() {
　let numbers = vec![1, 2, 3, 4, 5];
　assert_eq!(foo(numbers), 12);
}

**デフォルトの名無しさん** · 2024/06/18(火) 12:23:59.59

Rustの仕様と実装の分離ができてないと、公式の実装が唯一になるから困る分野があるんだろうね。
Cとかコンパイラいっぱいあるじゃん。

Rustぐらい複雑で成長途上の言語で仕様を文書化して実装を交換可能にするなんて事実上無理っぽいけど、10年後ぐらいには問題でてくるのかもね。

**デフォルトの名無しさん** · 2024/06/18(火) 12:31:26.48

>>241
現在のRustの仕様は実用的なプログラミングをする上で十分なレベルとなっているけど
さらに便利にするための追加仕様がTODOリストに積まれていてそれらが少しずつ解決されて追加されていってる状況ですね
まだ当面しばらくは現状体制のまま成長させていくのが望ましいと思います

**デフォルトの名無しさん** · 2024/06/18(火) 13:47:06.59

実装が仕様でもいいけど、その場合はその実装のコアの部分を明確にした方がいいかもね

**デフォルトの名無しさん** · 2024/06/18(火) 13:51:40.72

GPT-4oがAIベンチマークのARC-AGIで50％のスコアに到達、これまでの最高記録である34％を大幅に更新
2024年06月18日
※さらに最適化すれば７０%以上も可能な模様

スマホに搭載可能な小型透視チップが開発される
2024年06月18日

**デフォルトの名無しさん** · 2024/06/18(火) 16:50:36.49

>>241
Cの標準化の更新なんて10年とかだろうが。

**デフォルトの名無しさん** · 2024/06/18(火) 18:04:47.12

>>241
>Cとかコンパイラいっぱいあるじゃん。
それは各チップでそれぞれ別のCコンパイラが必要なのと
クローズドソースでプロプライエタリのコンパイラを有償で販売できる環境があるからだよ

Rustだと各チップで必要になるのはLLVM対応であってRustのコンパイラではないし
リスクをとってまでプロプライエタリなコンパイラをわざわざ作るメリットもほぼない
それにコンパイラが乱立しないというのは今のところはエコシステム的にはメリットしかない

**デフォルトの名無しさん** · 2024/06/18(火) 19:09:22.28

gccが頑張ってるくらい？

**デフォルトの名無しさん** · 2024/06/18(火) 19:12:43.09

団体がすべての主導権を握ってるならある日急にガラッと変えても誰も文句を言えない
実装が仕様です

C++や他の言語で規格がって言ってるのはコンパイラだけの問題じゃなくてコード利用してる側の都合でもある

**デフォルトの名無しさん** · 2024/06/18(火) 19:12:43.05

Rust Foundation自身がrfc3355をmergeして仕様策定やります宣言してるのに
今更そんなこと言ってもね

**デフォルトの名無しさん** · 2024/06/18(火) 19:36:21.60

そもそも、仕様を必要とするのはコンパイラだけじゃない

ttps://blog.rust-lang.org/2022/07/01/RLS-deprecation.html

少なくとも、公式がrustc依存のRLSを捨ててrust-analyzerへの乗り換えを宣言した時点から
「rustc実装が仕様」状態から脱却しなくてはならないという意識はRust Foundation内にもずっとあったと考えるべきだろう

**デフォルトの名無しさん** · 2024/06/18(火) 23:19:40.06

Rustのコンパイラを作るために理解すべき仕様と
Rustを使うために理解すべき仕様を
仕様という言葉で一括りにするから話がおかしくなる

**デフォルトの名無しさん** · 2024/06/19(水) 01:01:46.69

>>248
>C++や他の言語で規格がって言ってるのはコンパイラだけの問題じゃなくてコード利用してる側の都合でもある
コードを利用してる側の都合というのは複数の実装が存在するけど
リファレンス実装やデファクトスタンダードが存在しないから規格がないと困るからでしょ

今も規格が生きてる言語というとC, C++, COBOL, Ada, Fortran, JavaScript, C#くらい
C#を除くと各ベンダーがクローズドソースでプロプライエタリなコンパイラを作ってた時代からの言語
C#はOSS/マルチプラットフォーム化されて必要性はもうなくなってる

**デフォルトの名無しさん** · 2024/06/19(水) 01:08:50.95

Javaも、本家SunとGnuとあったな。今は知らんが

**デフォルトの名無しさん** · 2024/06/19(水) 04:09:25.16

ボイス・トォ・スカル
スポーツで試用しているとそっく露呈

選手の動きを撮影してそれを2倍.4倍...スロー再生すれば明確に使用しているを見つけられる
通常の者でも動けなくとも音と動作は見えているのでそれをシミレーション【通常の者主軸】にあてはめて動作をみればよい
それにプラスΑでそれが可能な回数を数学を用いて算出【科Ⓚ立論や物理的法則の確率論】すれば明らかにおかしいが判明

人間の筋肉量などを基本にの運動能力を設定しておくこと
さらに公共の場で日常生活のⓀ感の鋭さを調べれば本人がその能力があるかがわかる

知力の方は根気よく罠にかけるように会話をしていけば露呈する

**デフォルトの名無しさん** · 2024/06/19(水) 07:18:12.06

レーザーで「トリウム原子核」を励起することに成功、原子核時計などの革新的技術への道が開かれる
2024年04月30日

量子もつれの伝達速度の限界を解明することに成功！
2024/04/02

世界初！「量子もつれ」の画像撮影に成功
2019/07/15

量子テレポーテーションとワーム・ホールの移動速度判明
地球上に幽霊も神も観測可能なのになぜ観測不能?
量子テレポーテーション中は量子のもつれがないので双方観測不能
など考えましょう

**デフォルトの名無しさん** · 2024/06/19(水) 10:09:36.86

ここもう、ちゃんと教えてくれる上級者を追い出し終えてしまったと思う
初心者が自分以下の初心者にマウント取るだけのスレになってしまった
最後まで我慢して付き合ってくれた上級者まで汚い言葉で追い出して。
そんなんだからいつまでも下手なんだろうし、しょうがないか

**デフォルトの名無しさん** · 2024/06/19(水) 11:17:34.73

上級者がいるとマウント取られてうざいから追い出し得だろ😅

**デフォルトの名無しさん** · 2024/06/19(水) 17:53:51.50

質問です
イテレータから"名前1", "データ1", "名前2", "データ2", ...と渡ってくるのですが
これを(名前, データ)のイテレータに変換する方法、または、そのように扱える方法ありますか？

**デフォルトの名無しさん** · 2024/06/19(水) 18:29:49.29

擬態初心者

**デフォルトの名無しさん** · 2024/06/19(水) 18:44:02.73

>>248
気に入らないなら、フォークすれば良いじゃん

**デフォルトの名無しさん** · 2024/06/19(水) 18:46:24.24

パンがなければ？

**デフォルトの名無しさん** · 2024/06/19(水) 19:22:09.94

>>256
書き込み規制が頻繁過ぎて信頼できないプラットホームだからだよ。
そもそも使えないことがあるのは内容がどうこう以前に論外。

**デフォルトの名無しさん** · 2024/06/19(水) 21:18:42.18

このスレに上級者はいらねえ
真面目な質問をしたい時はissueか公式フォーラムかredditに行く
ここにはマウントを取って気持ちよくなるために来ているんだ
上級者は去れ

**デフォルトの名無しさん** · 2024/06/19(水) 21:32:54.13

>>258
1. itertoolsのtuples
2. nextを直接&指定回数呼び出すイテレータアダプターを書く
3. scan + filter_map

**デフォルトの名無しさん** · 2024/06/19(水) 23:58:52.30

>>258
奇数個が来た時のエラー処理を考えると
Result<(名前, データ), 残り>を返すイテレーターが適切

>>264
tuples()は奇数個エラーに気付けないのが惜しい

**デフォルトの名無しさん** · 2024/06/20(木) 00:27:34.04

>>265
奇数個はエラーってのはタプルの要素数2個の場合限定なので
もう少し一般化して使える方法がいいと思うよ
itertoolsはchunksとか他にも使えるやつがあるから用途に応じて使い分けてね

**デフォルトの名無しさん** · 2024/06/20(木) 00:30:45.20

chunksは使いにくくタプルにするのも面倒だな

**デフォルトの名無しさん** · 2024/06/20(木) 00:49:36.16

複おじに餌を与えないでください

**デフォルトの名無しさん** · 2024/06/20(木) 02:27:54.12

いつの間にかHaskellがC#より速くなってた…。
https://nshinchan01.hateblo.jp/entry/2024/06/20/021327

HaskellとC#だけでなく、Rust/Pythonともベンチマーク比較してますのでどうぞ( ^^) _旦~~
（コードも掲載してるので、速度だけでなくコードの比較にもなってます）

**デフォルトの名無しさん** · 2024/06/20(木) 08:11:10.55

HaskellあればRustいらねーじゃん