Rust part33 (566ﾚｽ)
上下前次1-新
40(1): デフォルトの名無しさん [sage] 2025/08/24(日) 11:01:04.53 ID:o5OQy7cK(1/2) AAS
多値が返せるか？の意味なんて、ユーザ的には戻り値の分割代入ができるか？ってだけだし
ダラダラ言わずに返せますで終わりでよくね
41: デフォルトの名無しさん [] 2025/08/24(日) 11:17:14.32 ID:DLpoJrbF(1) AAS
Rustは多値を返す機能があるだけでなく
その実装も本当に多値を返すため効率よく実行も速いことが特徴
42(1): デフォルトの名無しさん [sage] 2025/08/24(日) 11:34:24.43 ID:yIg8YRK3(3/4) AAS
>>40
仕様を読むときは言語の理屈や用語をわかってないとちゃんと読めない。
複数の要素をひとつにまとめたもの (タプルや構造体) をひとつ返すというのと複数の値を返せるというのは違うことなんだが、
Rust では同一視することにしたというならそれはそれで同一視しているという理屈をわかってないといけない。
43(1): デフォルトの名無しさん [] 2025/08/24(日) 11:46:57.61 ID:s620v8qa(1) AAS
>>42
それは屁理屈
プログラマとしては多値を返せる機能があればよいわけで、
それがタプルという形で実現されていようが困ることは何一つない
逆に、タプルをサポートしていればそれだけで十分であり、
タプルでない多値をサポートするメリットが何もない
44: デフォルトの名無しさん [sage] 2025/08/24(日) 11:50:38.02 ID:yIg8YRK3(4/4) AAS
>>43
実際に (複数の要素をタプルなどにまとめるのではなく) 多値をサポートしてる言語はあるわけだが、ディスってんの？
言語の理屈の構成の仕方の話であって言語としてのメリットの話なんかしてない。
45: デフォルトの名無しさん [sage] 2025/08/24(日) 11:58:39.52 ID:sGVh/967(1) AAS
多値をサポートしてる言語の例としてGoが上で挙げられているけどさ
Goはタプルがなくてみんな困っている
タプルがある言語では多値がなくて困った話は聞かれない
機能として『タプル ⊃ 多値』 だからだよ
46: デフォルトの名無しさん [sage] 2025/08/24(日) 12:05:10.36 ID:DXAve6fe(1) AAS
Goでタプルがなくて辛いという話は聞いたことがないな
最適化の観点抜きで機能的に他でカバーできるから不要と言ってしまうと、
例えばオブジェクトは全部ヒープに置いてスマポの所有権移動だけにしてしまえば複雑なムーブは不要となり遥かにシンプルになる
それはそれで一つの考え方だが、Rustはそういう言語ではないと思っているのだろう？
47: デフォルトの名無しさん [sage] 2025/08/24(日) 12:08:19.32 ID:veJK4T2Q(1/3) AAS
返却された値がスタック上でどう扱われるかというのは言語仕様でなく最適化の問題だから、そこはRustではなくLLVMの話
言語仕様としては「Rustではタプルを簡単に作れる」「タプルの中身を別々の変数に束縛できる」というだけ
多値返却の目的からすればこれで十分だし、多くの言語はこれに相当する
Goは本当に多値返却という仕様で、これはタプルを返すのとは違う
そもそもタプルが言語仕様になくて、関数の返り値でだけ多値を返せるという変わった仕様
だから、2つの戻り値を返す関数を1変数で受け取ることができなかったりする
(Rustでいえば「戻り値を分解せず1つのタプル変数 t で受け取る -> t.0, t.1 のようにアクセスする」という書き方がGoではできない)
だから言語仕様としての話をしたいのか、「関数から複数の戻り値を返す」という目的の話をしたいのかで話は変わる
後者については、最近の多くの言語ではサポートしてるし、そんなに話がズレることもない
前者の意味でなら、Rustは多値返却の構文を持つ言語とは違う
48: デフォルトの名無しさん [sage] 2025/08/24(日) 12:16:23.06 ID:aQdKZ7zp(1) AAS
Goの多値とRustのタプルは同じ
どちらも実装は多値として返すため多値レジスタ返しが可能ならばそうするため効率が最も優れている
関数定義もほぼ同じ
func foo() (type1, type2) {…
fn foo() -> (type1, type2) {…
49(1): デフォルトの名無しさん [sage] 2025/08/24(日) 12:16:31.50 ID:tCu5AZNy(1) AAS
バカなやつほど抽象度の区別ができない
バカなやつほどオレオレ定義で用語を使う
バカなやつほど主語を書かない
本当に相手にする価値があるか考えよう
改善の見込みがないバカなら何を書いても時間の無駄でしかない
50: デフォルトの名無しさん [sage] 2025/08/24(日) 12:26:32.12 ID:95hjiUrq(1) AAS
多値を抽象化して機能を強化したものがタプルだもんね
だから多値でできることは全てタプルでもできるんだよ
タプルを持つ言語は機能の低い多値を別途持つ必要がない
51(1): デフォルトの名無しさん [sage] 2025/08/24(日) 12:50:55.19 ID:veJK4T2Q(2/3) AAS
「タプルがあれば十分」は殆どのケースでは同意するけど、Goに限ってはそうする理由があるんだよ
エラーを多値で返す仕様かつ、エラー処理を明示的に書かせる思想の言語だから
value, err := foo()
のように err がコード上に表れるようにする必要があって、これはタプルだとまずい
t := foo() と書けてしまうと「タプルの2要素目がエラー」というのが見えなくなる
これは割とGo特有の事情で、Result型や例外を使う言語だとタプルでも困らない
言語仕様というのは他の部分も含めた全体的なデザインとして考えるものだから、「Rustではタプルで困らない」が正しくても、他の言語含めて全てそうだとは言えない
52: デフォルトの名無しさん [sage] 2025/08/24(日) 12:56:30.01 ID:9a3ehhoR(1) AAS
>>49
>バカなやつほど抽象度の区別ができない
>バカなやつほどオレオレ定義で用語を使う
>バカなやつほど主語を書かない
汚コーダーの特徴が濃縮されてるね
3番目は「書かない」というより「書けない」だと思う
53: デフォルトの名無しさん [sage] 2025/08/24(日) 13:02:12.19 ID:LAWD3p/v(1) AAS
原始的な剥き出しの多値を扱う必要のない言語においては、タプル多値があれば多値をサポートしているという結論でいいんじゃないかな
54(1): デフォルトの名無しさん [sage] 2025/08/24(日) 13:07:02.23 ID:vekMbO+E(1) AAS
Rustはnamed tupleもanonymous structもなくunnamed tupleで位置でアクセスするか事前に定義した型で名前でアクセスするかしかないから利便性ではモダンな他言語に一段劣る
55(3): デフォルトの名無しさん [sage] 2025/08/24(日) 13:18:17.18 ID:kBf9AmUd(1) AAS
>>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
56(2): デフォルトの名無しさん [sage] 2025/08/24(日) 13:28:22.18 ID:fUN48E4b(1/2) AAS
>>51
いや、エラーに限らずt.0とか普通に可読性最悪だからね
多値をタプルとして実装するなら、即時の分割代入を必須とするか、もしくはC#のようにpositionalなタプルと互換性のあるnamed tupleとするか、どちらかは必須
57: デフォルトの名無しさん [sage] 2025/08/24(日) 13:41:09.97 ID:uDNIRrgr(1) AAS
必要となるまでは1つのまとまりとして一括して扱えたほうが有利
必要になったところでパターンマッチングさせて個別に用いる
58: デフォルトの名無しさん [sage] 2025/08/24(日) 13:49:22.14 ID:+tDfyqBW(1) AAS
Rustは必要なところではパターンマッチングできるから不便なことはないよな
59(1): デフォルトの名無しさん [sage] 2025/08/24(日) 13:56:11.80 ID:fUN48E4b(2/2) AAS
取得から消費までのコード上の距離が離れるほど人間の短期記憶の負担になり可読性が低下する
複おじは特に頭悪いから実感してるんじゃない？
60(1): デフォルトの名無しさん [sage] 2025/08/24(日) 14:11:41.28 ID:0UxuBUhy(1) AAS
let (unko, chinko) = unkochinko
とか突然出てきてunkochinkoの宣言が離れてたら、合ってるのか不安を感じてつい宣言までスクロールしちゃうわ
離れた場所での位置依存は普通に可読性最悪
61: デフォルトの名無しさん [sage] 2025/08/24(日) 14:14:05.68 ID:ieA/MpG4(1) AAS
>>56
ジェネリックに意味を持たない局面もあるからそこでt.0を使うのは適してる
意味がある局面なら例えばfor (index, name) in ...や|(index, name)| ...のように使われるから名前でアクセスできる
62(1): デフォルトの名無しさん [] 2025/08/24(日) 14:15:37.70 ID:veJK4T2Q(3/3) AAS
>>56
C#も分割代入しない書き方はできるじゃん
その場合の可読性はPythonもC++もC#もそう変わらないかと (t[0], get<0>(t), t.Item1)
意味のある名前を付けたいなら、それはRustでもstructを定義すれば済む話だし
C#の匿名クラスの便利さもまあ分かるけど、あれば嬉しいくらいで、個人的には必須とまでは思わない
63: デフォルトの名無しさん [sage] 2025/08/24(日) 14:18:45.06 ID:m/1beq6h(1) AAS
>>62
C#には匿名型とは別にnamed tupleがあって、positional tupleと互換性を持ったままフィールドに名前を付けられる
64: デフォルトの名無しさん [sage] 2025/08/24(日) 14:23:02.15 ID:VS0PssfI(1) AAS
>>55
named tupleの定義が面倒＆カッコ悪いな
上下前次1-新書関写板覧索設栞歴
あと 502 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 1.064s*