Rust part33 (73ﾚｽ)
Rust part33 http://mevius.5ch.net/test/read.cgi/tech/1755247770/
上
下
前
次
1-
新
通常表示
512ﾊﾞｲﾄ分割
ﾚｽ栞
ﾘﾛｰﾄﾞ規制
です｡10分ほどで解除するので､
他のﾌﾞﾗｳｻﾞ
へ避難してください｡
1: デフォルトの名無しさん [] 2025/08/15(金) 17:49:30.70 ID:N8TIzbWg 公式 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 part32 https://mevius.5ch.net/test/read.cgi/tech/1755057787/ Rust part31 https://mevius.5ch.net/test/read.cgi/tech/1751545806/ Rust part30 https://mevius.5ch.net/test/read.cgi/tech/1748392296/ ﾜｯﾁｮｲスレ プログラミング言語 Rust 4【ﾜｯﾁｮｲ】 https://mevius.5ch.net/test/read.cgi/tech/1514107621/ http://mevius.5ch.net/test/read.cgi/tech/1755247770/1
2: デフォルトの名無しさん [] 2025/08/15(金) 17:59:47.23 ID:N8TIzbWg 5ch電源断とその際のバグにより 各板の現役スレ一部がタイミングの運で失われた模様 Rustはpart31とpart32両方が現役の状況であった http://mevius.5ch.net/test/read.cgi/tech/1755247770/2
3: デフォルトの名無しさん [] 2025/08/15(金) 20:39:09.07 ID:55NQaS0p 5chのシステムっていまだにperlとかなんだっけ？ http://mevius.5ch.net/test/read.cgi/tech/1755247770/3
4: デフォルトの名無しさん [] 2025/08/15(金) 21:05:50.57 ID:JdtfTdo0 誰かRustで5chクローン作ってくれろ http://mevius.5ch.net/test/read.cgi/tech/1755247770/4
5: デフォルトの名無しさん [sage] 2025/08/15(金) 21:13:27.00 ID:GcewhsmR >>2 どういうバグ？ http://mevius.5ch.net/test/read.cgi/tech/1755247770/5
6: デフォルトの名無しさん [sage] 2025/08/15(金) 21:42:40.40 ID:5gemkVLD 昔から活発な板でdat一覧ファイル壊れたりロストするから排他制御や落ちた時の途中状態からのリカバリとかザルなのかもね http://mevius.5ch.net/test/read.cgi/tech/1755247770/6
7: デフォルトの名無しさん [sage] 2025/08/15(金) 21:48:40.45 ID:XX86qaZt Rustじゃ20年ぐらい掛かりそう http://mevius.5ch.net/test/read.cgi/tech/1755247770/7
8: デフォルトの名無しさん [sage] 2025/08/15(金) 22:05:07.21 ID:y6bONxHy 2ch初期からあるread.cgiとpostの読み書き基本掲示板機能部分だけなら1日で終わるけど 後から追加した外から見えない部分が絡み合って規模も読めないね http://mevius.5ch.net/test/read.cgi/tech/1755247770/8
9: デフォルトの名無しさん [] 2025/08/15(金) 22:49:05.86 ID:bbOcnQZV 難読よいしょw部 難読宝田真月部 難読オランザピン部 難読肉壺ワッショイ部 難読自己中部 難読承認欲求部 難読ゴキブリ部 難読助かりました部 難読宇宙人部 難読でんちゃでんちゃでんちゃちゃっちゃっちゃ〜部 難読カービィ部 難読失敗作部 難読ADHD部 難読自開部 難読多動部 難読在日部 難読糖質部 難読人非人部 難読生まれも育ちもやまゆり園部 難読何ガン飛ばしてんだよオイ！！部 難読池沼部 難読トナラー部 難読表出ろこの野郎！部 難読マウント部 難読ホンモノ部 難読害悪部 難読ガガイのガイ部 難読syamu未満部 難読底辺部 難読インチュニ部 http://mevius.5ch.net/test/read.cgi/tech/1755247770/9
10: デフォルトの名無しさん [sage] 2025/08/15(金) 23:02:17.30 ID:DXpoUqnv 山下スクリプト回りの対策で、エラーが出た時にそれが何故出てるエラーなのかすら 今の5chはもはやアンドキュメントだからな http://mevius.5ch.net/test/read.cgi/tech/1755247770/10
11: デフォルトの名無しさん [sage] 2025/08/15(金) 23:41:07.28 ID:GcewhsmR 電源落ちたからって前スレまで消えるのは常識的には考えられない動きだけど5chはそういうものなんだな http://mevius.5ch.net/test/read.cgi/tech/1755247770/11
12: デフォルトの名無しさん [] 2025/08/16(土) 00:28:31.64 ID:yx9F5+UN 難読漢字部 ガイジの集まり くたばれよ みんなもポケモンゲットじゃぞ http://mevius.5ch.net/test/read.cgi/tech/1755247770/12
13: デフォルトの名無しさん [sage] 2025/08/16(土) 00:33:34.28 ID:35qrMgqn >>11 前スレのpart30は過去ログ倉庫へ移動されていたため無事だよ part31は1000になっただけで過去スレへと隠れてなくて見えたままだったのが不運 http://mevius.5ch.net/test/read.cgi/tech/1755247770/13
14: デフォルトの名無しさん [sage] 2025/08/16(土) 11:34:10.89 ID:27T353mi チューリップの中で再現性のない部分だけ消えなさい バブルは消えた http://mevius.5ch.net/test/read.cgi/tech/1755247770/14
15: デフォルトの名無しさん [] 2025/08/16(土) 15:07:42.32 ID:uzsALVJv 難読ロリコン部 難読僕のスマホ返せぇぇぇ！！部 難読とど田とどら部 難読ちぎゅ田ちぎゅら部 難読チーズホビー部 難読お薬手帳部 難読底辺部 難読積極奇異型アスペ部 難読電子障害者手帳部 難読自開部 難読穢多非人部 難読バ漢字部 難読ウィィィィィィィィッス部 難読チギュァァァァァァァァァァァァ部 難読動物園部 難読おかしな奴しかいないんだけど部 難読助かりました部 難読舌打ち部 難読類友部 難読ガイジ(ゲェジ)部 難読スタバ陽キャきっしょ部 難読僕も！僕も気持ちいいことしたい！！部 難読自己中部 難読Fラン大学中退部 難読トナラー部 難読スペシャルオリンピックス部 難読ひまわり学級部 難読ゴミ部 難読弱者男性部 難読アホロライ部 http://mevius.5ch.net/test/read.cgi/tech/1755247770/15
16: デフォルトの名無しさん [sage] 2025/08/16(土) 17:15:18.32 ID:2ZRl/XaI Check Pointが見つけたと言ってるRust製のWindowsカーネルコンポーネントの脆弱性ってどのCVEか分かる人いない？ https://blog.checkpoint.com/research/microsoft-vulnerabilities-exposed-by-check-point-research/ https://msrc.microsoft.com/update-guide/vulnerability http://mevius.5ch.net/test/read.cgi/tech/1755247770/16
17: デフォルトの名無しさん [] 2025/08/16(土) 22:23:23.06 ID:uzsALVJv 難読DSM部 難読さす障部 難読さすガイ部 難読動物園部 難読トナラー部 難読よいしょw部 難読ホンモノ部 難読頓服部 難読でんちゃでんちゃでんちゃちゃっちゃっちゃ〜部 難読マスターベーション部 難読マウント部 難読ウィィィィィィィィッス部 難読syamu未満部 難読スマホ脳部 難読多動部 難読害悪部 難読電車(バス)代割引部 難読エッホエッホ部 難読てんかん部 難読ディズニー格安部 難読フレンド申請部 難読すいません、3種のチーズ牛丼特盛りに温玉付きでお願いします部 難読水用意しろ水。イライラするわぁ部 難読おかしな奴しかいないんだけど部 難読デスマフィン部 難読コンサータ部 難読ガイジ(ゲェジ)部 難読オランザピン部 http://mevius.5ch.net/test/read.cgi/tech/1755247770/17
18: デフォルトの名無しさん [sage] 2025/08/17(日) 20:15:25.86 ID:JE2V7bGm Windows更新プログラムﾊﾞｸﾞの温床Rust 馬鹿ｺｰﾀﾞを無理やり矯正したとこで馬鹿が治る筈もなく http://mevius.5ch.net/test/read.cgi/tech/1755247770/18
19: デフォルトの名無しさん [sage] 2025/08/17(日) 21:19:09.68 ID:TxHGfZIC バグを無くせるプログラミング言語は存在しない Rustはプログラミング言語の中では最も様々な安全性を保証してくれる それ以上でもそれ以下でもない http://mevius.5ch.net/test/read.cgi/tech/1755247770/19
20: デフォルトの名無しさん [sage] 2025/08/17(日) 21:22:39.79 ID:JE2V7bGm わかってねぇな それじゃﾎﾝﾓﾉは育たないことを http://mevius.5ch.net/test/read.cgi/tech/1755247770/20
21: デフォルトの名無しさん [sage] 2025/08/17(日) 22:50:15.00 ID:XH7kxkHq Rustは生き物ですらない 育児もディールもしない http://mevius.5ch.net/test/read.cgi/tech/1755247770/21
22: デフォルトの名無しさん [sage] 2025/08/18(月) 07:58:05.46 ID:WV63/BRN RustってIT土方専用言語になりそう http://mevius.5ch.net/test/read.cgi/tech/1755247770/22
23: デフォルトの名無しさん [sage] 2025/08/18(月) 08:11:30.19 ID:ilCqlqaZ GCC Rustはだいぶ前にメインラインにマージされたみたいだけど クロス対応ってどこまで進んでいるんだ？ LLVMバックエンドがないマイコン系ISAもRustで開発できる感じ？ http://mevius.5ch.net/test/read.cgi/tech/1755247770/23
24: デフォルトの名無しさん [sage] 2025/08/18(月) 21:19:44.54 ID:xACiQreQ Rustは衰退しました。 http://mevius.5ch.net/test/read.cgi/tech/1755247770/24
25: デフォルトの名無しさん [sage] 2025/08/18(月) 21:46:08.37 ID:dnUOS2YV その書き込みもRust製のPingoraを通って投稿されてRust製のPingoraを通って皆が読んでるよ http://mevius.5ch.net/test/read.cgi/tech/1755247770/25
26: デフォルトの名無しさん [sage] 2025/08/18(月) 22:00:15.90 ID:lyr3W+Wr 横長のGUIが衰退したら次は縦長のGUIが再発明されたりする じゃあ再発明しても変化しない仕様はなんだ 0で割り算できない仕様とか http://mevius.5ch.net/test/read.cgi/tech/1755247770/26
27: デフォルトの名無しさん [sage] 2025/08/19(火) 19:22:34.36 ID:XX3oox1B COBOLみたいに固定長レコードを基本として基本的に動的アロケーションをしない方向のモダンな言語もあっていいと思う Rustを待たずとも、あれはあれでメモリ安全の究極の形の一つ http://mevius.5ch.net/test/read.cgi/tech/1755247770/27
28: デフォルトの名無しさん [sage] 2025/08/23(土) 19:14:03.74 ID:K0SmVlfv >複数の値 (いわゆる多値) を関数が返せる言語はそれほど多くない。 >LISP 系は多値のサポートがあることが多いけどそれ以外だと Go くらいじゃないかな？ Rustの()は値0個で(a,b,c)は値3個の多値 という認識で合ってますか？ http://mevius.5ch.net/test/read.cgi/tech/1755247770/28
29: デフォルトの名無しさん [sage] 2025/08/23(土) 19:50:48.28 ID:CHT0FIec >>28 いいえ。 多値ではなくタプルです。 http://mevius.5ch.net/test/read.cgi/tech/1755247770/29
30: デフォルトの名無しさん [sage] 2025/08/23(土) 21:56:54.53 ID:cDLDYI8A 夏のオージ演 http://mevius.5ch.net/test/read.cgi/tech/1755247770/30
31: デフォルトの名無しさん [sage] 2025/08/23(土) 22:15:56.19 ID:vghJtGax 多値の取り扱いの仕方の一つがタプル そしてRust公式にも Functions can use tuples to return multiple values. と明記されている >>28の引用文についてRustは関数で多値を返すことができる言語の一つ http://mevius.5ch.net/test/read.cgi/tech/1755247770/31
32: デフォルトの名無しさん [sage] 2025/08/23(土) 22:45:01.43 ID:b43T5BM2 Rustのタプルは多値で合っているが、言語によってはタプルというオブジェクト[のポインタ]を1つ返す場合もある。 そのような言語ではタプル≠多値で、Rustではタプル=多値。 Rustで関数がタプルを返す時に、各環境で可能なら複数のレジスタを使って返し、レジスタ返しの数を超えていれば、例えば呼び出し元スタックフレームの指定領域に直接書き込んで返す。 したがってRustは多値返しをサポートする言語。 http://mevius.5ch.net/test/read.cgi/tech/1755247770/32
33: デフォルトの名無しさん [sage] 2025/08/24(日) 06:23:07.67 ID:yIg8YRK3 分野によって用語の意味にブレがあるからそういうのを厳密に考えてもあんまり意味ない。 狭義の多値は継続 (continuation) に複数の値が渡ることをいうのでたぶん >>28 はその意味で言ってて、その意味ではタプルは多値ではない。 単なる言語ユーザの目線ではタプルにまとめて受け渡すことと複数の値を受け渡すことには何も違いはないから同一視しても何も困らないよ。 形式論理とかの世界の話。 http://mevius.5ch.net/test/read.cgi/tech/1755247770/33
34: デフォルトの名無しさん [sage] 2025/08/24(日) 06:51:31.37 ID:Q1fxgDlW 重要なことはオーバーヘッドの有無 タプルをオブジェクトの一種として扱う言語はオブジェクトを用意してそのアドレス単値のみを渡すため間接アクセスのオーバーヘッドが生じる タプルを多値として扱うRustは多値として渡せるためオーバーヘッドが生じない もちろんRustではタプルをBoxに入れることでアドレス単値のみ返すことも可能でオブジェクト方式の言語は常にそれをしていることになる http://mevius.5ch.net/test/read.cgi/tech/1755247770/34
35: デフォルトの名無しさん [sage] 2025/08/24(日) 07:38:29.67 ID:yIg8YRK3 アーキテクチャによって ABI は違うかもしれないけど一般的な実装としては 関数の返却値が大きい時は呼出し側でメモリを確保してそれを隠れた引数として渡すようなメカニズムになってる。 返却値はスタックを介さない。 これは C++ でも同じ。 http://mevius.5ch.net/test/read.cgi/tech/1755247770/35
36: デフォルトの名無しさん [sage] 2025/08/24(日) 07:52:38.38 ID:lHuVCVKu >>35 ほぼ合っているが一部だけ違う 間違ってる部分は「スタックを介さない」 正解は「スタックを介す」ことで高速に引き渡す サイズの大きな値を返す場合 具体的には呼び出し元でスタックポインタを増減することでスタックフレームを拡大してその確保領域のアドレスを隠れた引数としてレジスタ渡しする 呼び出された関数側ではその確保領域に直接書き込んで値を返す ヒープ領域を確保して受け渡す方式と比べるとメモリ領域確保のコストがない点とスタック上でそのままメモリキャッシュに乗る点で有利 http://mevius.5ch.net/test/read.cgi/tech/1755247770/36
37: デフォルトの名無しさん [sage] 2025/08/24(日) 07:56:09.24 ID:lHuVCVKu ちなみにRustでx64アーキテクチャの時 16バイトまでならレジスタ渡しになり上記スタック領域は使われないため更に速い http://mevius.5ch.net/test/read.cgi/tech/1755247770/37
38: デフォルトの名無しさん [sage] 2025/08/24(日) 08:16:24.05 ID:lHuVCVKu ごめん、肝心なところ書き間違えてる ✕ 16バイトまでならレジスタ渡し ○ 16バイトまでならレジスタ返し http://mevius.5ch.net/test/read.cgi/tech/1755247770/38
39: デフォルトの名無しさん [sage] 2025/08/24(日) 10:58:20.04 ID:lOj53x5G 言語が多値返却をサポートしてるかどうかというのは文法としてサポートしてるかどうかという意味 文法的にはサポートしてないけど「〇〇使えば多値返却できる」のは当たり前 一般的なプログラミング言語で「Functions can use 〇〇 to return multiple values」の〇〇に当てはまるものがない言語は無いので意味がない 文法的にサポートしているかどうかと内部実装がどの程度最適化されるのかはまた別の話 http://mevius.5ch.net/test/read.cgi/tech/1755247770/39
40: デフォルトの名無しさん [sage] 2025/08/24(日) 11:01:04.53 ID:o5OQy7cK 多値が返せるか？の意味なんて、ユーザ的には戻り値の分割代入ができるか？ってだけだし ダラダラ言わずに返せますで終わりでよくね http://mevius.5ch.net/test/read.cgi/tech/1755247770/40
41: デフォルトの名無しさん [] 2025/08/24(日) 11:17:14.32 ID:DLpoJrbF Rustは多値を返す機能があるだけでなく その実装も本当に多値を返すため効率よく実行も速いことが特徴 http://mevius.5ch.net/test/read.cgi/tech/1755247770/41
42: デフォルトの名無しさん [sage] 2025/08/24(日) 11:34:24.43 ID:yIg8YRK3 >>40 仕様を読むときは言語の理屈や用語をわかってないとちゃんと読めない。 複数の要素をひとつにまとめたもの (タプルや構造体) をひとつ返すというのと複数の値を返せるというのは違うことなんだが、 Rust では同一視することにしたというならそれはそれで同一視しているという理屈をわかってないといけない。 http://mevius.5ch.net/test/read.cgi/tech/1755247770/42
43: デフォルトの名無しさん [] 2025/08/24(日) 11:46:57.61 ID:s620v8qa >>42 それは屁理屈 プログラマとしては多値を返せる機能があればよいわけで、 それがタプルという形で実現されていようが困ることは何一つない 逆に、タプルをサポートしていればそれだけで十分であり、 タプルでない多値をサポートするメリットが何もない http://mevius.5ch.net/test/read.cgi/tech/1755247770/43
44: デフォルトの名無しさん [sage] 2025/08/24(日) 11:50:38.02 ID:yIg8YRK3 >>43 実際に (複数の要素をタプルなどにまとめるのではなく) 多値をサポートしてる言語はあるわけだが、ディスってんの？ 言語の理屈の構成の仕方の話であって言語としてのメリットの話なんかしてない。 http://mevius.5ch.net/test/read.cgi/tech/1755247770/44
45: デフォルトの名無しさん [sage] 2025/08/24(日) 11:58:39.52 ID:sGVh/967 多値をサポートしてる言語の例としてGoが上で挙げられているけどさ Goはタプルがなくてみんな困っている タプルがある言語では多値がなくて困った話は聞かれない 機能として『タプル ⊃ 多値』 だからだよ http://mevius.5ch.net/test/read.cgi/tech/1755247770/45
46: デフォルトの名無しさん [sage] 2025/08/24(日) 12:05:10.36 ID:DXAve6fe Goでタプルがなくて辛いという話は聞いたことがないな 最適化の観点抜きで機能的に他でカバーできるから不要と言ってしまうと、 例えばオブジェクトは全部ヒープに置いてスマポの所有権移動だけにしてしまえば複雑なムーブは不要となり遥かにシンプルになる それはそれで一つの考え方だが、Rustはそういう言語ではないと思っているのだろう？ http://mevius.5ch.net/test/read.cgi/tech/1755247770/46
47: デフォルトの名無しさん [sage] 2025/08/24(日) 12:08:19.32 ID:veJK4T2Q 返却された値がスタック上でどう扱われるかというのは言語仕様でなく最適化の問題だから、そこはRustではなくLLVMの話 言語仕様としては「Rustではタプルを簡単に作れる」「タプルの中身を別々の変数に束縛できる」というだけ 多値返却の目的からすればこれで十分だし、多くの言語はこれに相当する Goは本当に多値返却という仕様で、これはタプルを返すのとは違う そもそもタプルが言語仕様になくて、関数の返り値でだけ多値を返せるという変わった仕様 だから、2つの戻り値を返す関数を1変数で受け取ることができなかったりする (Rustでいえば「戻り値を分解せず1つのタプル変数 t で受け取る -> t.0, t.1 のようにアクセスする」という書き方がGoではできない) だから言語仕様としての話をしたいのか、「関数から複数の戻り値を返す」という目的の話をしたいのかで話は変わる 後者については、最近の多くの言語ではサポートしてるし、そんなに話がズレることもない 前者の意味でなら、Rustは多値返却の構文を持つ言語とは違う http://mevius.5ch.net/test/read.cgi/tech/1755247770/47
48: デフォルトの名無しさん [sage] 2025/08/24(日) 12:16:23.06 ID:aQdKZ7zp Goの多値とRustのタプルは同じ どちらも実装は多値として返すため多値レジスタ返しが可能ならばそうするため効率が最も優れている 関数定義もほぼ同じ func foo() (type1, type2) {… fn foo() -> (type1, type2) {… http://mevius.5ch.net/test/read.cgi/tech/1755247770/48
49: デフォルトの名無しさん [sage] 2025/08/24(日) 12:16:31.50 ID:tCu5AZNy バカなやつほど抽象度の区別ができない バカなやつほどオレオレ定義で用語を使う バカなやつほど主語を書かない 本当に相手にする価値があるか考えよう 改善の見込みがないバカなら何を書いても時間の無駄でしかない http://mevius.5ch.net/test/read.cgi/tech/1755247770/49
50: デフォルトの名無しさん [sage] 2025/08/24(日) 12:26:32.12 ID:95hjiUrq 多値を抽象化して機能を強化したものがタプルだもんね だから多値でできることは全てタプルでもできるんだよ タプルを持つ言語は機能の低い多値を別途持つ必要がない http://mevius.5ch.net/test/read.cgi/tech/1755247770/50
51: デフォルトの名無しさん [sage] 2025/08/24(日) 12:50:55.19 ID:veJK4T2Q 「タプルがあれば十分」は殆どのケースでは同意するけど、Goに限ってはそうする理由があるんだよ エラーを多値で返す仕様かつ、エラー処理を明示的に書かせる思想の言語だから value, err := foo() のように err がコード上に表れるようにする必要があって、これはタプルだとまずい t := foo() と書けてしまうと「タプルの2要素目がエラー」というのが見えなくなる これは割とGo特有の事情で、Result型や例外を使う言語だとタプルでも困らない 言語仕様というのは他の部分も含めた全体的なデザインとして考えるものだから、「Rustではタプルで困らない」が正しくても、他の言語含めて全てそうだとは言えない http://mevius.5ch.net/test/read.cgi/tech/1755247770/51
52: デフォルトの名無しさん [sage] 2025/08/24(日) 12:56:30.01 ID:9a3ehhoR >>49 >バカなやつほど抽象度の区別ができない >バカなやつほどオレオレ定義で用語を使う >バカなやつほど主語を書かない 汚コーダーの特徴が濃縮されてるね 3番目は「書かない」というより「書けない」だと思う http://mevius.5ch.net/test/read.cgi/tech/1755247770/52
53: デフォルトの名無しさん [sage] 2025/08/24(日) 13:02:12.19 ID:LAWD3p/v 原始的な剥き出しの多値を扱う必要のない言語においては、タプル多値があれば多値をサポートしているという結論でいいんじゃないかな http://mevius.5ch.net/test/read.cgi/tech/1755247770/53
54: デフォルトの名無しさん [sage] 2025/08/24(日) 13:07:02.23 ID:vekMbO+E Rustはnamed tupleもanonymous structもなくunnamed tupleで位置でアクセスするか事前に定義した型で名前でアクセスするかしかないから利便性ではモダンな他言語に一段劣る http://mevius.5ch.net/test/read.cgi/tech/1755247770/54
55: デフォルトの名無しさん [sage] 2025/08/24(日) 13:18:17.18 ID:kBf9AmUd >>54 これ便利だと思う？ # まずnamedtuple関数をインポートします from collections import namedtuple # 次にNamed Tupleを定義します Point = namedtuple('Point', ['x', 'y']) # そしてインスタンスを作ります p = Point(10, 20) # 名前でアクセスできるようになります print(p.x) # Output: 10 print(p.y) # Output: 20 http://mevius.5ch.net/test/read.cgi/tech/1755247770/55
56: デフォルトの名無しさん [sage] 2025/08/24(日) 13:28:22.18 ID:fUN48E4b >>51 いや、エラーに限らずt.0とか普通に可読性最悪だからね 多値をタプルとして実装するなら、即時の分割代入を必須とするか、もしくはC#のようにpositionalなタプルと互換性のあるnamed tupleとするか、どちらかは必須 http://mevius.5ch.net/test/read.cgi/tech/1755247770/56
57: デフォルトの名無しさん [sage] 2025/08/24(日) 13:41:09.97 ID:uDNIRrgr 必要となるまでは1つのまとまりとして一括して扱えたほうが有利 必要になったところでパターンマッチングさせて個別に用いる http://mevius.5ch.net/test/read.cgi/tech/1755247770/57
58: デフォルトの名無しさん [sage] 2025/08/24(日) 13:49:22.14 ID:+tDfyqBW Rustは必要なところではパターンマッチングできるから不便なことはないよな http://mevius.5ch.net/test/read.cgi/tech/1755247770/58
59: デフォルトの名無しさん [sage] 2025/08/24(日) 13:56:11.80 ID:fUN48E4b 取得から消費までのコード上の距離が離れるほど人間の短期記憶の負担になり可読性が低下する 複おじは特に頭悪いから実感してるんじゃない？ http://mevius.5ch.net/test/read.cgi/tech/1755247770/59
60: デフォルトの名無しさん [sage] 2025/08/24(日) 14:11:41.28 ID:0UxuBUhy let (unko, chinko) = unkochinko とか突然出てきてunkochinkoの宣言が離れてたら、合ってるのか不安を感じてつい宣言までスクロールしちゃうわ 離れた場所での位置依存は普通に可読性最悪 http://mevius.5ch.net/test/read.cgi/tech/1755247770/60
61: デフォルトの名無しさん [sage] 2025/08/24(日) 14:14:05.68 ID:ieA/MpG4 >>56 ジェネリックに意味を持たない局面もあるからそこでt.0を使うのは適してる 意味がある局面なら例えばfor (index, name) in ...や|(index, name)| ...のように使われるから名前でアクセスできる http://mevius.5ch.net/test/read.cgi/tech/1755247770/61
62: デフォルトの名無しさん [] 2025/08/24(日) 14:15:37.70 ID:veJK4T2Q >>56 C#も分割代入しない書き方はできるじゃん その場合の可読性はPythonもC++もC#もそう変わらないかと (t[0], get<0>(t), t.Item1) 意味のある名前を付けたいなら、それはRustでもstructを定義すれば済む話だし C#の匿名クラスの便利さもまあ分かるけど、あれば嬉しいくらいで、個人的には必須とまでは思わない http://mevius.5ch.net/test/read.cgi/tech/1755247770/62
63: デフォルトの名無しさん [sage] 2025/08/24(日) 14:18:45.06 ID:m/1beq6h >>62 C#には匿名型とは別にnamed tupleがあって、positional tupleと互換性を持ったままフィールドに名前を付けられる http://mevius.5ch.net/test/read.cgi/tech/1755247770/63
64: デフォルトの名無しさん [sage] 2025/08/24(日) 14:23:02.15 ID:VS0PssfI >>55 named tupleの定義が面倒＆カッコ悪いな http://mevius.5ch.net/test/read.cgi/tech/1755247770/64
65: デフォルトの名無しさん [sage] 2025/08/24(日) 14:40:44.45 ID:f2gy7gmS Pythonの名前付きタプルは普通に使いにくいからな… その用途なら dataclass にしとけ、というのが共通認識だと思う http://mevius.5ch.net/test/read.cgi/tech/1755247770/65
66: デフォルトの名無しさん [sage] 2025/08/24(日) 17:03:59.99 ID:apxru5vn >>55 それは文法としてnamed tupleをサポートしてないからだよ サポートしてれば下のように書ける def foo() -> (x: int, y: int): return (x: 10, y: 20) p = foo() print(p.x, p.y) x, y = foo() print(x, y) http://mevius.5ch.net/test/read.cgi/tech/1755247770/66
67: デフォルトの名無しさん [sage] 2025/08/24(日) 17:15:02.39 ID:7zDT8kXu 事実と意見を区別しろ 前提を明確に示せ 異なる前提に依存する結論を無理に適用するな http://mevius.5ch.net/test/read.cgi/tech/1755247770/67
68: デフォルトの名無しさん [sage] 2025/08/24(日) 17:48:30.01 ID:+zGYyK0c >>66 これで済む話 let (x, y) = foo(); http://mevius.5ch.net/test/read.cgi/tech/1755247770/68
69: デフォルトの名無しさん [sage] 2025/08/24(日) 18:53:52.96 ID:xPc+Pkry >>66 筋がよくなく中途半端に感じる その型を他でも用いるならば型に名前を付けて宣言したほうがよく その場限りならば>>68 http://mevius.5ch.net/test/read.cgi/tech/1755247770/69
70: デフォルトの名無しさん [sage] 2025/08/24(日) 19:23:45.82 ID:o5OQy7cK let (manko, chinko) = foo(); // 本当のfoo()の返す中身は(chinko, manko) が許されるから、それって嫌だよねって話じゃないの？ http://mevius.5ch.net/test/read.cgi/tech/1755247770/70
71: デフォルトの名無しさん [sage] 2025/08/24(日) 19:32:58.00 ID:lcXQ4DrV >>70 そうそう AIに生成させるにしても、fooが別のパッケージだったりするとシグネチャだけで要素の意味を推測できないのは辛いわな http://mevius.5ch.net/test/read.cgi/tech/1755247770/71
72: デフォルトの名無しさん [sage] 2025/08/24(日) 19:44:34.69 ID:PRkNyipX 別なら構造体を定義しろ http://mevius.5ch.net/test/read.cgi/tech/1755247770/72
73: デフォルトの名無しさん [sage] 2025/08/24(日) 22:32:48.16 ID:O8wAGFa3 >>68 どっちかというと真逆でRustの場合は1mmでも名前でアクセスしたいと感じるものは構造体を定義しないといけない >>69 中途半端に感じるのは当然 事前に構造体を定義しておくほどではないが要素には名前でアクセスしたいというものすごく中途半端な状況にこそ求められる機能だから http://mevius.5ch.net/test/read.cgi/tech/1755247770/73
ﾒﾓ帳
(0/65535文字)
上
下
前
次
1-
新
書
関
写
板
覧
索
設
栞
歴
ｽﾚ情報
赤ﾚｽ抽出
画像ﾚｽ抽出
歴の未読ｽﾚ
AAｻﾑﾈｲﾙ
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.029s