Rust part33 (95ﾚｽ)
上下前次1-新
ﾘﾛｰﾄﾞ規制です｡10分ほどで解除するので､他のﾌﾞﾗｳｻﾞへ避難してください｡
1: 08/15(金)17:49 ID:N8TIzbWg(1/2) AAS
公式
外部ﾘﾝｸ:www.rust-lang.org
外部ﾘﾝｸ:blog.rust-lang.org
外部ﾘﾝｸ:github.com
公式ドキュメント
外部ﾘﾝｸ:www.rust-lang.org
Web上の実行環境
外部ﾘﾝｸ:play.rust-lang.org
※Rustを学びたい人はまず最初に公式のThe Bookを読むこと
外部ﾘﾝｸ:doc.rust-lang.org
省13
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) AAS
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<_>)>();
82: 08/28(木)10:55 ID:OS0cfYx9(1/2) AAS
抽象なんて「見たいものだけを見る」という程度の意味だからね
もしメモリ管理が最大の関心事なら
抽象度が最も高いIUnknownにリファレンスカウント機能をつけていい
83(1): 08/28(木)11:58 ID:1IatnfJ+(1) AAS
>>81
左辺に型を書けばいいんだよ
そのほうが読みやすいしタイプ数も少ない
あとunzip/multiunzipはcollectでも代用可
84: 08/28(木)15:40 ID:OS0cfYx9(2/2) AAS
なんで掛け算の引数には名前がないんだろう
順序を逆にできない理由が一目でわかるような名前があるなら名前をつけるべき
85: 08/28(木)20:43 ID:fdP0HyCm(1) AAS
>>81
unzipはトレイトを使っていないため余分なパラメタが露出してしまってる
multiunzipはトレイトMultiUnzipを
collectはトレイトFromIteratorを使っている
>>83
今年のRust 1.85からタプルもcollectできるようになったね
86: 08/30(土)05:57 ID:JBC8dN2M(1) AAS
a * b * c
は b や c のすぐ隣に目印があるからキーワード引数は不要だ
mul(a, b, c)
(* a b c)
このような記法だけが、b c 付近で文法的サポートが不足している問題を抱えている
87: 08/30(土)23:22 ID:6bFj+97W(1) AAS
>>55
namedtupleは廃れて今はdataclassを使う
Rustでの#[derive(Debug, Hash, Ord)]付き構造体相当
結局Pythonでもそのへんはちゃんとしてほしいことになった
88: 08/31(日)09:51 ID:cF2U6lLu(1/2) AAS
ハッシュ関数を使えば保守的GCが廃れる
確率を見たらカオスと思え
89: 08/31(日)10:00 ID:mJd+1ya1(1) AAS
>結局Pythonでもそのへんはちゃんとしてほしいことになった
誰か日本語に翻訳して
90: 08/31(日)10:52 ID:QUPYnWaR(1) AAS
足りない頭で必死に調べた複おじの努力を認めて差し上げろ
それはともかく、一般にスクリプト言語ではタプルはあまり好まれず、辞書が好まれる傾向がある
- ユーザーが辞書データ構造を使ってレコードを扱うことに慣れている
- 辞書を扱うための簡便な構文が存在する場合が多い
- 辞書と配列の速度やメモリ使用量の差が問題にならない
- 値が増えた場合にランタイムエラーを引き起こす
なお、dataclassは辞書に対する型付きのラッパーに過ぎない
あくまでこれはスクリプト言語の事情であり、Rustのような静的言語においてはレコードはタプル(構造体は名前付きのタプルの一種)として実装することが基本であることに注意しなければならない
91(1): 08/31(日)17:32 ID:qrCON/OK(1) AAS
辞書かどうかは本質ではない
辞書として用いないことが圧倒的に多いため例えばV8では静的解析で判明するプロパティを構造体フィールドのように扱い実行するため辞書実装とは異なり速い
92: 08/31(日)18:15 ID:IkR/a1qs(1) AAS
また的外れなレスだなぁ
結局複おじにもそのへんはちゃんとしてほしいことになった
93: 08/31(日)18:20 ID:yY4/9rZW(1) AAS
>>91
V8のプロパティアクセスの最適化は基本的には静的解析に依存しないよ
同じプロパティが同じ順序で追加されたオブジェクトは同じ型と見做してキャッシュされたプロパティの位置を利用する
あくまで辞書データ構造を前提としたままでキャッシュ戦略を工夫しているに過ぎない
94: 08/31(日)23:19 ID:cF2U6lLu(2/2) AAS
魔法の数字ではなく
ちゃんとenumを使うことになった
95: 08/31(日)23:24 ID:Dds/cnqW(1) AAS
Minimal Embedded FAT32 Driver - in Rust!
動画ﾘﾝｸ[YouTube]
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.229s