Rust part33 (229ﾚｽ)
上下前次1-新
52: 08/24(日)12:56 ID:9a3ehhoR(1) AAS
>>49
>バカなやつほど抽象度の区別ができない
>バカなやつほどオレオレ定義で用語を使う
>バカなやつほど主語を書かない
汚コーダーの特徴が濃縮されてるね
3番目は「書かない」というより「書けない」だと思う
53: 08/24(日)13:02 ID:LAWD3p/v(1) AAS
原始的な剥き出しの多値を扱う必要のない言語においては、タプル多値があれば多値をサポートしているという結論でいいんじゃないかな
54(1): 08/24(日)13:07 ID:vekMbO+E(1) AAS
Rustはnamed tupleもanonymous structもなくunnamed tupleで位置でアクセスするか事前に定義した型で名前でアクセスするかしかないから利便性ではモダンな他言語に一段劣る
55(3): 08/24(日)13: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): 08/24(日)13:28 ID:fUN48E4b(1/2) AAS
>>51
いや、エラーに限らずt.0とか普通に可読性最悪だからね
多値をタプルとして実装するなら、即時の分割代入を必須とするか、もしくはC#のようにpositionalなタプルと互換性のあるnamed tupleとするか、どちらかは必須
57: 08/24(日)13:41 ID:uDNIRrgr(1) AAS
必要となるまでは1つのまとまりとして一括して扱えたほうが有利
必要になったところでパターンマッチングさせて個別に用いる
58: 08/24(日)13:49 ID:+tDfyqBW(1) AAS
Rustは必要なところではパターンマッチングできるから不便なことはないよな
59(1): 08/24(日)13:56 ID:fUN48E4b(2/2) AAS
取得から消費までのコード上の距離が離れるほど人間の短期記憶の負担になり可読性が低下する
複おじは特に頭悪いから実感してるんじゃない？
60(1): 08/24(日)14:11 ID:0UxuBUhy(1) AAS
let (unko, chinko) = unkochinko
とか突然出てきてunkochinkoの宣言が離れてたら、合ってるのか不安を感じてつい宣言までスクロールしちゃうわ
離れた場所での位置依存は普通に可読性最悪
61: 08/24(日)14:14 ID:ieA/MpG4(1) AAS
>>56
ジェネリックに意味を持たない局面もあるからそこでt.0を使うのは適してる
意味がある局面なら例えばfor (index, name) in ...や|(index, name)| ...のように使われるから名前でアクセスできる
62(1): 08/24(日)14:15 ID:veJK4T2Q(3/3) AAS
>>56
C#も分割代入しない書き方はできるじゃん
その場合の可読性はPythonもC++もC#もそう変わらないかと (t[0], get<0>(t), t.Item1)
意味のある名前を付けたいなら、それはRustでもstructを定義すれば済む話だし
C#の匿名クラスの便利さもまあ分かるけど、あれば嬉しいくらいで、個人的には必須とまでは思わない
63: 08/24(日)14:18 ID:m/1beq6h(1) AAS
>>62
C#には匿名型とは別にnamed tupleがあって、positional tupleと互換性を持ったままフィールドに名前を付けられる
64: 08/24(日)14:23 ID:VS0PssfI(1) AAS
>>55
named tupleの定義が面倒＆カッコ悪いな
65: 08/24(日)14:40 ID:f2gy7gmS(1) AAS
Pythonの名前付きタプルは普通に使いにくいからな…
その用途なら dataclass にしとけ、というのが共通認識だと思う
66(2): 08/24(日)17:03 ID:apxru5vn(1) AAS
>>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)
67: 08/24(日)17:15 ID:7zDT8kXu(1) AAS
事実と意見を区別しろ
前提を明確に示せ
異なる前提に依存する結論を無理に適用するな
68(2): 08/24(日)17:48 ID:+zGYyK0c(1) AAS
>>66
これで済む話
let (x, y) = foo();
69(1): 08/24(日)18:53 ID:xPc+Pkry(1) AAS
>>66
筋がよくなく中途半端に感じる
その型を他でも用いるならば型に名前を付けて宣言したほうがよく
その場限りならば>>68
70(1): 08/24(日)19:23 ID:o5OQy7cK(2/2) AAS
let (manko, chinko) = foo(); // 本当のfoo()の返す中身は(chinko, manko)
が許されるから、それって嫌だよねって話じゃないの？
71: 08/24(日)19:32 ID:lcXQ4DrV(1) AAS
>>70
そうそう
AIに生成させるにしても、fooが別のパッケージだったりするとシグネチャだけで要素の意味を推測できないのは辛いわな
72: 08/24(日)19:44 ID:PRkNyipX(1) AAS
別なら構造体を定義しろ
73: 08/24(日)22:32 ID:O8wAGFa3(1) AAS
>>68
どっちかというと真逆でRustの場合は1mmでも名前でアクセスしたいと感じるものは構造体を定義しないといけない
>>69
中途半端に感じるのは当然
事前に構造体を定義しておくほどではないが要素には名前でアクセスしたいというものすごく中途半端な状況にこそ求められる機能だから
74: 08/25(月)06:47 ID:E2rxLwdP(1) AAS
>>59
>>60
それらは古典的プログラミングだから無関係な処理が間に挟まったり流れが乱されるため可読性が落ちる
Rustでは抽象化したプログラミングによりメソッドチェーンで繋ぐことが多い
チェーンの間はタプルのまま旅を続けたとしても一つの流れなので可読性は落ちない
チェーンの途中もしくは最後のforやfold系でパターンマッチングされてタプルが解消されればよい
75: 08/25(月)08:15 ID:foAG4KWU(1) AAS
多値戻しは_をサポートしてなければコーダーにとってはどうでもいい話じゃないんかね。
最適化機会を明示できるかどうかくらいじゃね？
76: 08/25(月)10:18 ID:hSk6qQ9G(1) AA×
77: 08/25(月)12:25 ID:lo8Kz+ZF(1) AAS
タプルの片方は途中不要で最後に必要だが、もう片方はその逆とかよくあるある。
後者のfind()はposition()に置き換えられるが、二つのfindが対称形の処理ぽいのでそのままでもいいか。
78: 08/25(月)15:50 ID:4Ejmg1ls(1) AAS
まだ多値の話してる・・・
79: 08/25(月)16:13 ID:M76UE5qm(1) AAS
このスレはあくまで複おじのファンスレッドだから
複おじの興味が続けばその話題が続くんだよ
80: 08/25(月)21:09 ID:KzDmCwhz(1) AAS
ファンじゃなくて自演スレだから
81(2): 08/27(水)18:45 ID:s/5KNF71(1) AAS
タプルといえばzipとmultizipの方針の違いでVec指定の与え方が微妙差
let (counts, chars) = str.chars().sorted().dedup_with_count().unzip::<_, _, Vec<_ Vec<_>>();
let (counts, chars) = str.chars().sorted().dedup_with_count().multiunzip::<(Vec<_ Vec<_>)>();
上下前次1-新書関写板覧索設栞歴
あと 148 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ
ぬこの手 ぬこTOP 0.028s