次世代言語23 Go Nim Rust Swift Kotlin TypeScript

**デフォルトの名無しさん** · 2021/11/28(日) 16:59:19.16

スレタイ以外の言語もok

前スレ
次世代言語22 Go Nim Rust Swift Kotlin TypeScript
https://mevius.5ch.net/test/read.cgi/tech/1629590343/

**デフォルトの名無しさん** · 2022/02/05(土) 14:54:37.48

>>133
そこはC++も同じだけど
C++よりも更にメモリ管理の記述が少なく済むのがRust
それでいてコンパイルが通った時点でメモリやデータ競合などの安全性が保証されるのがRust

**デフォルトの名無しさん** · 2022/02/05(土) 15:02:39.39

その上でRustは現代的なプログラミングパラダイムが洗練されて採り入れられているため書きやすい
つまりちょっとしたメモリ管理を意識してプログラミングするだけで他より数倍～十倍速くなることもあるのだから
例えばサーバー経費を何分の1に激減させつつレスポンスも良いという実利的なメリットにも効いてくる

**デフォルトの名無しさん** · 2022/02/05(土) 17:29:39.72

>>133
> 参照カウンタとかもはや実質的に確定的ですらないやん

原理的には確定的やん
GC有り言語でガベコレタイミングに苦しんだことあるやつなら
ハッキリとRAIIとGCの間に線が引ける

**デフォルトの名無しさん** · 2022/02/05(土) 17:48:34.36

>>136
不要となったら直ちにデストラクタが呼ばれる点で優れてるよな
GC言語ではそれが出来ないので後始末の記述を毎回書くことで一部補うかその機能がないか

**デフォルトの名無しさん** · 2022/02/05(土) 18:36:32.12

RAIIとGCは対立する概念じゃないがな。C++/CLIで共存できてる。

**デフォルトの名無しさん** · 2022/02/05(土) 20:00:06.29

RAII言語は必要があれば言語の枠外でGCライブラリなどを用いてGC利用も可能
その逆にGC言語はRAII利用が不可能

**デフォルトの名無しさん** · 2022/02/05(土) 20:40:28.08

それはRAIIの機能がない言語ではRAIIが使えないと言っているに等しい。

**デフォルトの名無しさん** · 2022/02/05(土) 21:10:31.12

循環参照もプログラマが自分でWeak<T>使ってなんとかするっていう言語だ
面構えが違う

**デフォルトの名無しさん** · 2022/02/07(月) 00:03:08.00

>>126
で、Rustって駄目ブラウザ以外に何作れんの？お前何作ってんの？内容ゼロで優秀性なんて言い出すウンコのコード見せろよ

**デフォルトの名無しさん** · 2022/02/07(月) 00:13:06.30

>>142
Deno

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

数年前ならいざ知らず未だにRustに実用プロダクトあるのという
煽りは痛い人になっちゃったな

**デフォルトの名無しさん** · 2022/02/07(月) 03:24:58.20

なんかRuby界隈みたいに知識のアップデート止まってる人たち多いね
もうRustなんてそこら中で使われまくってんのに

**デフォルトの名無しさん** · 2022/02/07(月) 09:18:42.53

Rustは低レイヤやライブラリから徐々に侵食していく感じだからなかなか気付かれにくいかもね
Cのライブラリと思ってたら実装はRustに置き換わってた、とかよくある

**デフォルトの名無しさん** · 2022/02/07(月) 12:33:27.96

「よくある」んなら具体例をどうぞ

**デフォルトの名無しさん** · 2022/02/07(月) 12:54:30.50

自分はGNOMEとFirefoxしか知らんな
既存の実装がrustに置き換わるというよりrustで書き直された代替実装が登場してる印象

**デフォルトの名無しさん** · 2022/02/07(月) 12:56:04.35

VSCodeの検索にripgrepが使われるようになったのも広義の置き換えとは言えるか？

**デフォルトの名無しさん** · 2022/02/07(月) 13:02:36.93

この手の手合はそんなものは下らない一般的じゃないと
言い続けるだけだからなあ

**デフォルトの名無しさん** · 2022/02/07(月) 13:48:06.41

curlとかpycaもかな
この手のは最初に入るときはレガシープラットフォーム対応の問題とかで話題になるけど
一度入ってしまうと採用が広がっても特に取り上げられることはないからなぁ

**デフォルトの名無しさん** · 2022/02/07(月) 14:27:21.78

pythonのファンシーコンソール風ゲームライブラリであるpyxelの実装がrustで書かれてて、お？ってなったわ

**デフォルトの名無しさん** · 2022/02/07(月) 15:19:33.56

その言語で書き直された〜みたいなことが話題になるうちはほぼ広がってないと考えて良いわ。

**デフォルトの名無しさん** · 2022/02/07(月) 15:43:24.90

>>153
こうなったらOKというお前の合格ラインは？

**デフォルトの名無しさん** · 2022/02/07(月) 17:52:12.40

>>150
「よくある」とやらの根拠に興味あるだけだから心配すんな
絶対批判したり非難したりしないからリラックスして述べてみ

**デフォルトの名無しさん** · 2022/02/07(月) 18:19:47.49

>>155
最近じゃITニュースサイトでも
Rustで書き直しましたという記事がちょくちょく出てることに
興味もないレベルだと次世代言語スレは難しくない？

**デフォルトの名無しさん** · 2022/02/07(月) 22:00:41.23

>>153
スクリプト言語のボトルネック部分をCで書き直さしたなんてよく話題になるからCもマイナー言語ということで良いか？

**デフォルトの名無しさん** · 2022/02/07(月) 22:12:11.68

Rustは現代的なマルチパラダイムが洗練されて採り入れられているためプログラミングがしやすい
それなのにCやC++のように最高速で動いてくれて快適かつリソースや経費の節減となってくれる
さらにオマケとしてメモリ安全やデータ競合安全などの保証まで付いてくる

**デフォルトの名無しさん** · 2022/02/07(月) 22:14:03.66

まあまあ他人に期待するのではなく自分で何か書けばいいだけでしょ
今なら車輪の再発明と叩かれることもないだろう

**デフォルトの名無しさん** · 2022/02/07(月) 22:42:44.19

「よくある」はずなのダンマリｗ

**デフォルトの名無しさん** · 2022/02/08(火) 01:03:57.80

いうほどランタイム速度を必要とするようなアプリ、どいつもこいつも書いてないってのが現実。
はったりかましたバカはよくいるけど。

**デフォルトの名無しさん** · 2022/02/08(火) 01:36:44.45

だいたいのアプリはAPI呼び出しの塊だからアプリ自体が実行時間のボトルネックになることはレアかもね

**デフォルトの名無しさん** · 2022/02/08(火) 10:12:32.37

Nimを使って作られたゲームを紹介しよう。
https://goodboygalaxy.com/
ゲームボーイアドバンス向けに作られた2Dアクションゲーム。
https://store.steampowered.com/app/1444480/Turing_Complete/
論理回路を組み立てて自作CPUを作るゲーム。Godotっていうゲームエンジンが使われている。

**デフォルトの名無しさん** · 2022/02/09(水) 13:13:49.61

>>157
そんなこといちいちドやって報告しないって意味だよ。どこぞの言語と違ってな。

**デフォルトの名無しさん** · 2022/02/09(水) 13:57:31.22

>>164
へー、リリースノートとかにも載せずにしれっと更新するのが世の中では当たり前なのね

**デフォルトの名無しさん** · 2022/02/09(水) 13:58:40.10

>>164 CからRustに書き直されることはあっても逆は無いから当然だろ

**デフォルトの名無しさん** · 2022/02/09(水) 21:57:32.65

まっ、Cはこれだけ広範囲に使われているからね。基礎教養みたいなもの。
知っていて、使えて当たり前。

Rustでなにか画期的に高速化されるわけでもないし、コーディングの量が圧倒的に減るわけでもない。Pythonのように特定分野で格段の強みがあるわけでもなし。
メモリ安全性といっても、それが課題になってくるほど大きなプロジェクトに関わってるわけでもないしなぁ・・・

組み込み的にはオブジェクト志向な方がハードウェアと馴染みがいいって感じもあるかな。

**デフォルトの名無しさん** · 2022/02/09(水) 23:51:15.16

>>167
＞メモリ安全性といっても、それが課題になってくるほど大きなプロジェクトに関わってるわけでもないしなぁ・・・

俺のやってるプロジェクトは小さい自慢かよ

**デフォルトの名無しさん** · 2022/02/10(木) 02:47:32.09

>>167
オブジェクト指向の方がハードウェアとなじみが良いというのはどういうこと？
カプセル化とか継承とか、もしかしたらメッセージパッシングとかがハードウェアの抽象化に適しているということ？

**デフォルトの名無しさん** · 2022/02/10(木) 08:14:50.21

>>169
相手にしちゃだめ

**デフォルトの名無しさん** · 2022/02/10(木) 12:40:20.38

デバイスドライバーみたいなソフトウェアだと、linuxのVFSみたいなインターフェイスを意識するのが普通だから
オブジェクト指向や関数ポインタ渡しが普通。
動的に操作方法を変える必要性が大きいものはこういう仕組みは必要になる。

**デフォルトの名無しさん** · 2022/02/10(木) 12:43:32.46

そういやRustって、コールスタック重視なのになんで所有権移動をデフォルトにしたのかね？

スタックにデータがあるなら、戻ってくるのを想定して借用をデフォルトにした方が効率良い気がするけど。

**デフォルトの名無しさん** · 2022/02/10(木) 13:01:13.03

値渡し警察「参照渡しは存在しない。あるのは借用<T>の値渡しだけだ」

**デフォルトの名無しさん** · 2022/02/10(木) 19:06:35.96

>>172
そこはRustでは最適化される
例えば大きな構造体 struct Foo { 略 } があったとして
fn main() {
let foo = sub1();
}
fn sub1() -> Foo {
let foo1 = sub2();
return foo1;
}
fn sub2() -> Foo {
let foo2 = Foo { 略 }; // 上述の大きな構造体
return foo2;
}
と多段の関数の深いところから大きな構造体を返すとする
(注: 他言語の人にもわかりやすく敢えて「return」を明記してます)

Rustではこれは最適化されて
深いsub2()の変数foo2の格納場所はmain()のスタックの位置となる
特に今回の場合だと次々に渡していくだけなので
変数foo2のアドレスとfoo1のアドレスとfooのアドレスは一致する
(もちろんこのコードでヒープは一切利用されない)

つまり返り値(の格納場所)をポインタ渡ししているのと同じことになる
C言語ではそれを自分でコードとして記述しなければならないが
Rustでは概念上や記述コード上は「値返し」でシンプルにわかりやすく
実行コードでは最適化されて「返り値の格納場所を参照渡し」になる
もちろん小さな型を返す場合は実行コードも効率よく「値返し」のままである

**デフォルトの名無しさん** · 2022/02/10(木) 19:53:19.62

>174
いや、RVOの話じゃなくて、
スタックにあるオブジェクトの所有権を関数呼び出し先に移動するのを
デフォルトにした設計的な意図は何なんだろう
という話。

継続を第一級オブジェクトとしてサポートするのでもなければ
サブルーチンはいずれリターンしてくるんだから、スタックに積んだ
オブジェクトも呼び出し先に所有権を移動しないで持ち続けるのが
自然な感じがするんだよね。
それをわざわざ移動してスタックの奥で破棄する（＝スタックに残骸が残る）
ようにしたのはなんでかね、と。

**デフォルトの名無しさん** · 2022/02/10(木) 20:19:32.65

>>175
ヒープにあるオブジェクトだと deep copy にコストかかるから shallow copy (move) をデフォルトにして
コストかかる処理はソースコード上明確になるようにしたかったからだと思う

**デフォルトの名無しさん** · 2022/02/10(木) 20:31:58.46

>176
Rustもなんだかんだ言ってヒープ使用を想定している、ということかね。
それなら所有権移動をデフォルトにした理由は判る。

**デフォルトの名無しさん** · 2022/02/10(木) 20:36:51.31

https://www.reddit.com/r/rust/comments/fa9pkp/what_is_the_motivation_behind_default_move/
このスレで作者が答えているけど、すでに参照を示す&が広く使われてるのにデフォルトを借用にすると、moveを示すために「非参照演算子」みたいなものが必要になって整合性が取れないから、とのこと
あとはスタックにどう置いてどうアクセスするかはコンパイラの最適化の問題であって
言語のセマンティクスとは別、みたいな話も

**デフォルトの名無しさん** · 2022/02/10(木) 20:48:03.49

>>175
Rustではそんな無駄なことはしていないので大丈夫
まずメソッド定義は以下の3つの方法がある
(1) fn method1(self: Self, 引数)
(2) fn method1(self: &Self, 引数)
(3) fn method1(self: &mut Self, 引数)
Selfは自分の型を示す特別な型であり省略して以下のように略記も可能
(1) fn method1(self, 引数)
(2) fn method1(&self, 引数)
(3) fn method1(&mut self, 引数)
ここで>>175が最初に言っている方法は(1)のケース
参照しか利用しないメソッドなれば(2)のように定義して所有権は移動しない
参照を利用して書き換えるならば(3)のように定義して所有権は移動しない
そして所有権を移動させたいメソッドのみ(1)の定義を用いる
この3つの区別があるためRustでは無駄なことは起きない

**デフォルトの名無しさん** · 2022/02/10(木) 21:34:34.23

>>174
Rustは所有権がはっきりしてるためコンパイラが安全に最適化をガンガン出来る点が良いな
しかもプログラマーはそれを意識せずにRustのセマンティクスだけ把握して書けば後はコンパイラが勝手に最適化してくれる
これがC/C++だと自分で戻り値の場所を確保して自分でポインタを渡していき競合安全性も含めて自分でメモリ管理しなければならない
CG言語だとスタック上はあきらめてヒープで確保して返して後始末はGC任せ
Rustが有利

**デフォルトの名無しさん** · 2022/02/10(木) 21:40:15.72

>>178
どちらかに指定が必ず必要なのだから
ライフタイムを管理する必要のある参照の方に＆指定する現方法が大正解だな
参照にはsingle writer XOR multi readersのルール義務もあるしな

**デフォルトの名無しさん** · 2022/02/10(木) 21:50:15.02

ある程度は既存のメジャー言語と作法を揃えないと、タダでさえヤバい学習曲線がさらにとんでもないことになるしねえ

**デフォルトの名無しさん** · 2022/02/10(木) 22:07:58.55

可変参照と可変じゃない参照の区別が安全性保証の要になっているため
参照の方に記号を付けるのは理に適っている
いずれにしてもC/C++で安全に書く時はそれら含めて意識せざるをえない
それがRustでは様々な点でかなり楽になっているのだからC/C++より学習が大変ということはない

**デフォルトの名無しさん** · 2022/02/11(金) 12:06:27.49

>>178
なるほどねぇ。
個人的にはconst refを標準にして非参照演算子を用意するのも有りだと思うけど
（変数そのものの状態変更を呼び出し元で明記するという意味で）
そのあたりは作者の設計思想だからなぁ。

ただ、コンパイラの最適化と言語のセマンティクスを切り離すのは単純すぎる気が。
>>180みたいな話もあるんだし。

**デフォルトの名無しさん** · 2022/02/11(金) 12:49:33.03

>>184
参照を返す関数を書いてみればわかる
参照の方が特殊な存在であり記号は何でもよいが記号を付けるべき存在だとわかる
そして適切な記号としては微妙に概念が一部重なるC言語の＆を選んだのも適切

**デフォルトの名無しさん** · 2022/02/11(金) 13:38:34.47

>>185
もともとコールスタック（>>172）の話をしているのに、ヒープデータ前提の参照戻し関数の話をされてもねぇ。
Rustが「効率的にするという約束はしているが、コールスタックとかヒープとかは関係ない」というスタンスなら別だけど。

**デフォルトの名無しさん** · 2022/02/11(金) 13:47:41.99

>>186
ほら理解できていない
まずは実際にプログラミングしてみなさい
ヒープなんか一切用いなくてスタック上しか使わなくても参照返しは必ず起きるしライフタイムの管理が必須となる

**デフォルトの名無しさん** · 2022/02/11(金) 14:39:24.16

>>187
そこまで言うんだったら具体的なコードを例示してくれない？
「参照返しは必ず起きる」と理解できるような普遍的なコードで頼むよ。

**デフォルトの名無しさん** · 2022/02/11(金) 15:19:57.69

>>187
>ヒープなんか一切用いなくてスタック上しか使わなくても参照返しは必ず起きるしライフタイムの管理が必須となる
これは嘘だろ。実際fortranはヒープ使わないし、変数の寿命なんて問題は考えなくて済む。
そういう意味じゃめっちゃ安全。

**デフォルトの名無しさん** · 2022/02/11(金) 16:01:25.44

>>188
数値配列の処理や文字列の処理でよく起きますね
例えばイメージしやすい例だと入力文字列から前置文字列と後置文字列に挟まれた文字列を返す関数
// 【input_str】 = 【prefix_str】 + 【output_str】 + 【postfix_str】
fn get_str_between<'a>(input_str: &'a str, prefix_str: &str, postfix_str: &str) -> Option<&'a str> {
let start_index = input_str.find(prefix_str)? + prefix_str.len();
let end_index = input_str[start_index..].find(postfix_str)? + start_index;
Some(&input_str[start_index..end_index])
}
このように引数に複数の参照が来る時に参照を返す場合はライフタイムの明記をします
この例だと関数が返す参照は引数のinput_strのライフタイムと同じですよと伝えることで
この返り値がさらにどこか別の関数で使われたりあるいは構造体に格納されたりしても出自がわかり安全なわけです

ちなみに文字列処理はヒープエリアを一切使わなくても
スタック上の配列(ex. ArrayString)やstaticエリアだけでも完結できますからその突っ込みは無しでよろしくw

**デフォルトの名無しさん** · 2022/02/11(金) 17:17:31.83

ああ、データ自体を外部から参照する関数なら参照返しも普通か。>>186自体は間違いだな。

ただ、>>184（参照・実体の表記法／関数呼び出し規則）とはあんまり関係していない気が……やっぱり、Rustの設計思想が>>178だからというのが結論に思えるなぁ。
まあ、このあたりをいじくると、所有権を持つ変数が必ずひとつ存在するRustの設計思想からいじくらなきゃいかんような気がするから、Rustじゃ無理か。

**デフォルトの名無しさん** · 2022/02/11(金) 18:27:07.40

>>191
そこはRust限定の話ではなく一般的な話だと思う
参照というのはあくまでも実体があってこそ生きていられる存在
だから実体を保有する変数がどこかに必ず存在していて
その実体が参照よりも長生きしていないとダングリングポインタになってしまう

(ここからはRustの話)
したがって実体の方を本体として無記号にし
それに依存している存在にすぎない参照の方を＆記号で示している

**デフォルトの名無しさん** · 2022/02/11(金) 23:20:00.56

>>189
すべての関数呼び出しが末尾再帰であれば、呼び出しにあたって現在のスタックフレームを保存する必要はないから、中途半端な
手続き言語で分かった風に語りだす人は、どこかおかしい。コンピューターサイエンスとか齧ったことは無さそう。Rustをやってる人の
こういう語りは言語の発展の邪魔でしかないね

**デフォルトの名無しさん** · 2022/02/11(金) 23:30:45.78

>>193
どうみてもその>>189はRustをわかっていない人がむしろ(デタラメにRustを)批判してるような

**デフォルトの名無しさん** · 2022/02/12(土) 01:31:10.49

Go言語の作者Rob Pike氏が2015年に発表した「Go言語が成功した理由は何なのか？」で
> mapやfilterのような機能は言語の表現力を高めるものであり、書いていて楽しい言語に繋がるわけだが、
> これはそのトレードオフとなるメンテナンス性が高く扱いやすい言語という点をを犠牲にするだけでなく、
> （極めて素晴らしい方法で実装しない限り）コンピューターリソースを非常に消費するものだ。
と述べていて当時はその通りに思われてGoでは毎回for文で書くことがシンプルで良いとされてきた
しかしその後Rustのイテレータ実装ではfor文とほぼ同様に速く動かせるようになり
for文で毎回ごちゃごちゃ書くよりメンテナンス性もよく扱いやすいとわかった

**デフォルトの名無しさん** · 2022/02/12(土) 02:24:04.92

Rust創造イテレータおじさん。。。

**デフォルトの名無しさん** · 2022/02/12(土) 02:36:04.74

どうみても言語の否定じゃなく、どうでも良いようなことを延々と語りだすそいつの思考の人格・性格的否定だろうに。
こんな読解力も何もない奴ばっかか・・・

**デフォルトの名無しさん** · 2022/02/12(土) 14:28:17.06

>>195
Rust開発者は天才だから仕方ない

**デフォルトの名無しさん** · 2022/02/12(土) 16:13:21.86

所有権という概念を生み出したrustの人（名前わすれた）は天才だよ
効率性と安全性を同時に実現してる
これを関数型言語の人が生み出せなかったのは謎すぎる

**デフォルトの名無しさん** · 2022/02/12(土) 16:49:53.94

Ruby にはLazy があるから、無限配列でも、iterate できる

実行順序を変える。
書いた通りに前から実行しない

**デフォルトの名無しさん** · 2022/02/12(土) 17:46:20.26

所有権というかRAIIパターンはC++の方が先でlifetimeの方が独創性あると思う

**デフォルトの名無しさん** · 2022/02/12(土) 18:09:28.52

ライフタイムによって本体だけでなくその参照の正当性まで保証できるようになったわけだ

>>200
Rustのイテレータは受動的に遅延生成だから無限生成もできるけど
勝手に実行順序を変えるようなことはなくプログラマーが書いた通り

**デフォルトの名無しさん** · 2022/02/12(土) 18:33:27.41

>>199
あいつら本当はラムダ計算をしたいのに実現出来なくて仕方なくチューリングマシン考えてる妥協の民だからそんな発想なさそうｗ

**デフォルトの名無しさん** · 2022/02/12(土) 18:34:57.60

>>199
関数型言語は同一データの共有が極めて多く発生するため、GCなしの実装は実用的ではない
参照透過な言語ならメモリの共有さえしなければいいわけでGCなしの実装は極めて容易だけど、無限のメモリを必要とする

**デフォルトの名無しさん** · 2022/02/12(土) 19:00:19.19

関数型はGCが問題になるような途中過程の実行タイミングのシビアな用途に使われないからってのも大きな理由だと思う
性能面で言えば、ガベージの数が命令形に比べて桁違いに多いからいちいち参照カウントとかやってたらクソ非効率だろうし

**デフォルトの名無しさん** · 2022/02/12(土) 19:37:20.77

Ruby で普通の繰り返しは、a が無限要素だと、aで止まる

a.b.c
つまり、aの要素数ループ、bの要素数ループ、cの要素数ループの順番

それが、Lazy では、実行順序が変わって、
aの1つ目の要素、bの1つ目の要素、cの1つ目の要素
aの2つ目の要素、bの2つ目の要素、cの2つ目の要素
となる

つまり、aが3要素とすると、a1a2a3・b1b2b3・c1c2c3 が、
a1b1c1・a2b2c2・a3b3c3 に変わる

**デフォルトの名無しさん** · 2022/02/12(土) 21:05:09.08

>>201
確かに所有権っぽいことならC++でもそれっぽく書けはする
ライフタイムは最初なんじゃこれって思ったけど
我慢して書いてみると見事に"missing piece"を埋めてくれた

**デフォルトの名無しさん** · 2022/02/12(土) 23:41:53.37

我慢して書いてみるって発想は
ルールを守るよりも抜け道を探してそうなハッカーの発想とは対照的だね

**デフォルトの名無しさん** · 2022/02/12(土) 23:51:27.76

>>206
当たり前のことを書いてるだけじゃん
Rubyではlazy導入で遅延処理となり必要最小限だけをようやく処理できるようになったけど
例えばRustでは最初からそのlazyになっている
だからイテレータを連鎖した時に途中に毎回の無駄な一時配列が生成されることもない
それゆえRustではガベージが途中で生じずスタック領域のみ使用で連鎖でき軽くて速い

**デフォルトの名無しさん** · 2022/02/13(日) 03:57:54.17

array::mapは複製が生じるだろ、普通はarr.map(...).map(...)は使わないにしてもlazyだから無駄な一時配列が
生成されることもないとか言い過ぎだ。ちゃんとドキュメント読んでんのか？そもそも一時的な集合要素が必要に
なるのはアルゴリズム次第であり、”理解してないのに”信じてしまう事は愚かすぎる

**デフォルトの名無しさん** · 2022/02/13(日) 04:07:23.70

>>210
array::mapはイテレータじゃないよ

**デフォルトの名無しさん** · 2022/02/13(日) 04:15:35.21

だから複製生じるでしょ

**デフォルトの名無しさん** · 2022/02/13(日) 04:24:59.24

array::mapで複製は生じるけどイテレータがlazyか否かの議論には何も関係ないよね
mapはOption::mapなどと同じでイテレータとは関係なくコレクションやコンテナの中身を写像する関数であって、イテレータにも同様の意味を持つ関数が用意されているというだけ

>>209 のイテレータだから無駄なものは作られないは言い過ぎで反例はありそうに自分も思うけど、イテレータじゃないものを持ち出すのは例として適切ではない

イテレータそのもののせいではないが borrow checker のせいで余計なアロケーションが必要になる場合はある
以下の記事の最後の方のコード例なんかが一例
https://fasterthanli.me/series/making-our-own-executable-packer/part-6

**デフォルトの名無しさん** · 2022/02/13(日) 04:25:50.19

>>210
array::mapはイテレーターではありません
配列から配列への単なる変換です
| pub fn map<F, U>(self, f: F) -> [U; N] where F: FnMut(T) -> U
arrayでのこの定義を見ればイテレーターではなく返り値の型が配列だとわかるはずです
ちゃんとドキュメントを読みましょう

イテレーターを使えば以下のような例において
Rustでは無駄な一時配列が生成されることはありません
[6, 4, 7, 3, 5, 9, 2, 1, 8]
.iter()
.map(|n| n * n * n)
.filter(|n| n > &300)
.for_each(|n| println!("{n}"))

**デフォルトの名無しさん** · 2022/02/13(日) 04:39:02.47

<[T ; N] as Iterator>::map() のドキュメントを参照してlazyなことの裏取りをしようとしたら array::map() にたどり着いちゃったのかな
だとしたら rustdoc が分かりづらいのが悪い

**デフォルトの名無しさん** · 2022/02/13(日) 04:44:32.73

<[T; N] as Iterator> なんて存在しなかった
正しくは
<<[T; N] as IntoIterator>::IntoIter as Iterator>::map
または
<std::slice::Iter as Iterator>::map
だった

こんなの初学者わかんないよね

**デフォルトの名無しさん** · 2022/02/13(日) 04:50:04.12

>>213
イテレーター連鎖の途中で「無駄な一時配列が生成されない」は常に正しいです
ただし「そのイテレーターの機能として必要不可欠な無駄ではない」一時配列(Vec)を利用するイテレーターは存在します
いずれにせよ無駄な一時配列が生成されることはありません

**デフォルトの名無しさん** · 2022/02/13(日) 05:06:50.08

>>213
そのリンク先の記事を読ませていただきましたが
借用ルール(single writer xor multiple readers)違反が原因でその回避のため途中collect()しているだけでした
具体的には&self.objectsで借用中なのに&mut selfと定義されているself.get_object()を呼び出しています
したがって今回の問題とは無関係ですね

**デフォルトの名無しさん** · 2022/02/13(日) 05:14:01.48

>>217
｢無駄な一時配列｣の意味するところがあまり腑に落ちてなかったのだけど、
例えばイテレーターアダプターを呼び出す場合に、全要素列挙して配列で返す方式ではなく、
必要に応じてイテレーターアダプターのIterator::nextが呼ばれて、
さらにその中から元となったIteratorのnext()が呼び出されて...
と、lazyに必要な分だけ呼び出される仕組みになっているということが言いたかったわけね

>>218
はい、イテレータというかborrowの制約なのでlazinessとは関係ない話ですね

**デフォルトの名無しさん** · 2022/02/13(日) 05:43:50.33

>>219
Rustの配列(array)はスタック上に置けるようコンパイル時サイズ固定なのはご存知ですよね
したがってイテレーターがもし一時配列を吐くもしくは使おうとすると必然的にサイズ可変のVec利用となりヒープを使うことになってしまいます
ところがRustの標準ライブラリのイテレーターは core::iter::Iterator すなわちcore::はヒープが無い環境でも動作可能を意味します
つまり『Rustの標準ライブラリのイテレーターは一時配列(Vec)を絶対に使わない』ように設計されているのです
一方で外部のライブラリにおいてはデータが全て完全に揃わないと動作できない機能を持つイテレーターの場合に「必要不可欠な無駄ではない一時配列(Vec)」を用いるケースがあります

**デフォルトの名無しさん** · 2022/02/13(日) 15:42:54.09

で、複製されますよね？

**デフォルトの名無しさん** · 2022/02/13(日) 15:59:57.41

上で出ていたこれなら配列は複製されない
Rustはそんな無駄なことはしない

>>214
> [6, 4, 7, 3, 5, 9, 2, 1, 8]
> .iter()
> .map(|n| n * n * n)
> .filter(|n| n > &300)
> .for_each(|n| println!("{n}"))

**デフォルトの名無しさん** · 2022/02/13(日) 16:43:01.35

そのように書くのはあなたであって"Rustだから"というのは明らかな間違いです。無駄な事をしているのはあなたであってRustではありません

**デフォルトの名無しさん** · 2022/02/14(月) 23:03:20.89

Rustのイテレータは他と機能も同じ以上なのにプログラミング言語最速
さらにヒープを使わずOSもないベアメタル環境でも動作可

**デフォルトの名無しさん** · 2022/02/15(火) 17:26:38.96

実装言語を「Go」から「Rust」に変更、ゲーマー向けチャットアプリ「Discord」
https://atmarkit.itmedia.co.jp/ait/articles/2002/10/news038.html

**デフォルトの名無しさん** · 2022/02/15(火) 18:02:19.14

>>225
次世代言語スレで2年も前のリンク持ってこられても、、、

**デフォルトの名無しさん** · 2022/02/15(火) 18:08:55.40

2020年の記事なんですけど
2020年が2年前な訳が無いんですけど

**デフォルトの名無しさん** · 2022/02/15(火) 18:42:09.32

えっ

**デフォルトの名無しさん** · 2022/02/15(火) 19:15:57.25

2022年だぜ？

**デフォルトの名無しさん** · 2022/02/15(火) 19:37:22.66

時の流れが加速している

**デフォルトの名無しさん** · 2022/02/15(火) 19:44:03.28

Rustは言語仕様が汚くライブラリもいまいちなので
同じような概念できれいな文法の言語が欲しい

**デフォルトの名無しさん** · 2022/02/15(火) 20:04:30.75

>>231
言語仕様が汚くない言語
ライブラリがいまいちじゃない言語

それぞれ例えば何？

**デフォルトの名無しさん** · 2022/02/15(火) 20:39:28.00

>>232
言語仕様が汚くない → C言語
ライブラリがいまいちじゃない .net