Rust part33 (241レス)
1-

66
(2): デフォルトの名無しさん [sage] 2025/08/24(日) 17:03:59.99 ID:apxru5vn(1) AAS
>>55
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
それは文法として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: デフォルトの名無しさん [sage] 2025/08/24(日) 17:15:02.39 ID:7zDT8kXu(1) AAS
事実と意見を区別しろ
前提を明確に示せ
異なる前提に依存する結論を無理に適用するな
68
(2): デフォルトの名無しさん [sage] 2025/08/24(日) 17:48:30.01 ID:+zGYyK0c(1) AAS
>>66
これで済む話
let (x, y) = foo();
69
(1): デフォルトの名無しさん [sage] 2025/08/24(日) 18:53:52.96 ID:xPc+Pkry(1) AAS
>>66
筋がよくなく中途半端に感じる
その型を他でも用いるならば型に名前を付けて宣言したほうがよく
その場限りならば>>68
70
(1): デフォルトの名無しさん [sage] 2025/08/24(日) 19:23:45.82 ID:o5OQy7cK(2/2) AAS
let (manko, chinko) = foo(); // 本当のfoo()の返す中身は(chinko, manko)
が許されるから、それって嫌だよねって話じゃないの?
71: デフォルトの名無しさん [sage] 2025/08/24(日) 19:32:58.00 ID:lcXQ4DrV(1) AAS
>>70
そうそう
AIに生成させるにしても、fooが別のパッケージだったりするとシグネチャだけで要素の意味を推測できないのは辛いわな
72: デフォルトの名無しさん [sage] 2025/08/24(日) 19:44:34.69 ID:PRkNyipX(1) AAS
別なら構造体を定義しろ
73: デフォルトの名無しさん [sage] 2025/08/24(日) 22:32:48.16 ID:O8wAGFa3(1) AAS
>>68
どっちかというと真逆でRustの場合は1mmでも名前でアクセスしたいと感じるものは構造体を定義しないといけない

>>69
中途半端に感じるのは当然
事前に構造体を定義しておくほどではないが要素には名前でアクセスしたいというものすごく中途半端な状況にこそ求められる機能だから
74: デフォルトの名無しさん [sage] 2025/08/25(月) 06:47:36.11 ID:E2rxLwdP(1) AAS
>>59
59(1): デフォルトの名無しさん [sage] 2025/08/24(日) 13:56:11.80 ID:fUN48E4b(2/2) AAS
取得から消費までのコード上の距離が離れるほど人間の短期記憶の負担になり可読性が低下する
複おじは特に頭悪いから実感してるんじゃない?
>>60
60(1): デフォルトの名無しさん [sage] 2025/08/24(日) 14:11:41.28 ID:0UxuBUhy(1) AAS
let (unko, chinko) = unkochinko
とか突然出てきてunkochinkoの宣言が離れてたら、合ってるのか不安を感じてつい宣言までスクロールしちゃうわ
離れた場所での位置依存は普通に可読性最悪
それらは古典的プログラミングだから無関係な処理が間に挟まったり流れが乱されるため可読性が落ちる
Rustでは抽象化したプログラミングによりメソッドチェーンで繋ぐことが多い
チェーンの間はタプルのまま旅を続けたとしても一つの流れなので可読性は落ちない
チェーンの途中もしくは最後のforやfold系でパターンマッチングされてタプルが解消されればよい
75: デフォルトの名無しさん [sage] 2025/08/25(月) 08:15:32.90 ID:foAG4KWU(1) AAS
多値戻しは_をサポートしてなければコーダーにとってはどうでもいい話じゃないんかね。
最適化機会を明示できるかどうかくらいじゃね?
76: デフォルトの名無しさん [sage] 2025/08/25(月) 10:18:01.04 ID:hSk6qQ9G(1) AAS
ながめてるとたしかに_多いな

>fn f(init: &str, n: usize) -> String {
> let mut list = init.chars().rev().collect::<Vec<_>>();
> for _ in 1..n {
>  if let Some((pre_index, (_, old))) = list.iter().tuple_windows().enumerate().find(|(_, (pre, cur))| pre > cur) {
>   let old_index = pre_index + 1;
>   let (new_index, _) = list.iter().enumerate().find(|(_, cur)| cur > &old).unwrap();
>   list.swap(old_index, new_index);
>   list[..old_index].reverse();
>  }
> }
> list.into_iter().rev().collect()
>}
77: デフォルトの名無しさん [sage] 2025/08/25(月) 12:25:47.76 ID:lo8Kz+ZF(1) AAS
タプルの片方は途中不要で最後に必要だが、もう片方はその逆とかよくあるある。
後者のfind()はposition()に置き換えられるが、二つのfindが対称形の処理ぽいのでそのままでもいいか。
78: デフォルトの名無しさん [sage] 2025/08/25(月) 15:50:58.87 ID:4Ejmg1ls(1) AAS
まだ多値の話してる・・・
79: デフォルトの名無しさん [sage] 2025/08/25(月) 16:13:59.05 ID:M76UE5qm(1) AAS
このスレはあくまで複おじのファンスレッドだから
複おじの興味が続けばその話題が続くんだよ
80: デフォルトの名無しさん [sage] 2025/08/25(月) 21:09:46.97 ID:KzDmCwhz(1) AAS
ファンじゃなくて自演スレだから
81
(2): デフォルトの名無しさん [sage] 2025/08/27(水) 18:45:58.51 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<_>)>();
82: デフォルトの名無しさん [sage] 2025/08/28(木) 10:55:22.21 ID:OS0cfYx9(1/2) AAS
抽象なんて「見たいものだけを見る」という程度の意味だからね
もしメモリ管理が最大の関心事なら
抽象度が最も高いIUnknownにリファレンスカウント機能をつけていい
83
(1): デフォルトの名無しさん [sage] 2025/08/28(木) 11:58:26.45 ID:1IatnfJ+(1) AAS
>>81
左辺に型を書けばいいんだよ
そのほうが読みやすいしタイプ数も少ない
あとunzip/multiunzipはcollectでも代用可
84: デフォルトの名無しさん [sage] 2025/08/28(木) 15:40:44.35 ID:OS0cfYx9(2/2) AAS
なんで掛け算の引数には名前がないんだろう
順序を逆にできない理由が一目でわかるような名前があるなら名前をつけるべき
85: デフォルトの名無しさん [sage] 2025/08/28(木) 20:43:02.31 ID:fdP0HyCm(1) AAS
>>81
unzipはトレイトを使っていないため余分なパラメタが露出してしまってる
multiunzipはトレイトMultiUnzipを
collectはトレイトFromIteratorを使っている

>>83
今年のRust 1.85からタプルもcollectできるようになったね
86: デフォルトの名無しさん [sage] 2025/08/30(土) 05:57:20.14 ID:JBC8dN2M(1) AAS
a * b * c
は b や c のすぐ隣に目印があるからキーワード引数は不要だ

mul(a, b, c)
(* a b c)
このような記法だけが、b c 付近で文法的サポートが不足している問題を抱えている
87: デフォルトの名無しさん [sage] 2025/08/30(土) 23:22:46.71 ID:6bFj+97W(1) AAS
>>55
namedtupleは廃れて今はdataclassを使う
Rustでの#[derive(Debug, Hash, Ord)]付き構造体相当
結局Pythonでもそのへんはちゃんとしてほしいことになった
88: デフォルトの名無しさん [sage] 2025/08/31(日) 09:51:10.58 ID:cF2U6lLu(1/2) AAS
ハッシュ関数を使えば保守的GCが廃れる
確率を見たらカオスと思え
89: デフォルトの名無しさん [sage] 2025/08/31(日) 10:00:25.50 ID:mJd+1ya1(1) AAS
>結局Pythonでもそのへんはちゃんとしてほしいことになった
誰か日本語に翻訳して
90: デフォルトの名無しさん [sage] 2025/08/31(日) 10:52:20.39 ID:QUPYnWaR(1) AAS
足りない頭で必死に調べた複おじの努力を認めて差し上げろ
それはともかく、一般にスクリプト言語ではタプルはあまり好まれず、辞書が好まれる傾向がある
- ユーザーが辞書データ構造を使ってレコードを扱うことに慣れている
- 辞書を扱うための簡便な構文が存在する場合が多い
- 辞書と配列の速度やメモリ使用量の差が問題にならない
- 値が増えた場合にランタイムエラーを引き起こす
なお、dataclassは辞書に対する型付きのラッパーに過ぎない
あくまでこれはスクリプト言語の事情であり、Rustのような静的言語においてはレコードはタプル(構造体は名前付きのタプルの一種)として実装することが基本であることに注意しなければならない
1-
あと 151 レスあります
スレ情報 赤レス抽出 画像レス抽出 歴の未読スレ AAサムネイル

ぬこの手 ぬこTOP 0.026s