Rust part23
■ このスレッドは過去ログ倉庫に格納されています
>>164
Deref coercionの定義を理解しよう
Deref T→Uが実装されている時に
(つまり*TがUとなる時に)
&T→&UのDeref coercionが自動適用される
&String→&str (by Deref String→str)
&Vec<T>→&[T] (by Deref Vec<T>→[T])
&Box<T>→&T (by Deref Box<T>→&T)
&&T→&T (by Deref &T→T)
これらはすべてDeref coercion >>165
Deref T→Uが実装されている時に
(つまり*TがUとなる時に)
&T→&UのDeref coercionが自動適用される
U＝*T
↓ &Tから出発すると
U＝**(&T)
↓ 両辺の参照をとると
&U＝&**(&T)
つまり
Deref coercionとは&**の自動適用のこと *xが左辺値なら代入、*xが右辺値なら複製とかいう演算に
ビルトインderefみたいな名前をつけるのが間違っている >>170
mutabilityを除けば左右どちらも同じ型だから形が同じであることは問題ない
左はmutabiltyが必要だからderefではなくderef_mutと区別されていてその点でも問題ない 判りにくい仕組みだけどこれから開発が進むと
文法変えたりするのかな？ これほど分かりやすくて便利な明確な仕組みはない
他の言語と比較すれば明らか 他の言語でこれより良いものが存在しないね
RustのDeref
・自動適用されプログラマーの負担を軽減し利便性も良い
・魔法ではなくtrait Derefの実装に基づき動作して分かりやすく自作の型にも適用可能
・コンパイル時に静的に解決され実行時の付加コストゼロで高速動作 >>172
Pythonが分かりやすいのは知ってるけど
RustとPythonは両極端だから文法を微調整してもしょうがない
文法を変える必要があるのは両極端を否定する言語だけだ Derefなのに&が消えてない（小並感）
背景を理解しないと引っかかりやすいRustの七不思議候補 この仕組みがベストであるという主張は3種類ある
一つは馬鹿な信者が言ってるだけという可能性
一つは本当にこの仕組みがベストである可能性
最後は信者ではないけど素直な馬鹿だからもっと良い仕組みを知らない可能性
このどれであるかは賢い人間がもっと良い仕組みを教えてあげると判別できる
馬鹿な反論が返ってきたら馬鹿な信者
合理的な反論が返ってきたら本当にこの仕組みがベストかもしれない
意見を翻されたら素直な馬鹿 この仕組みがない方が良いということ？
下手で全部書くべきと？ RustのDerefとそのcoercion枠組みの利点
・プログラマーの負担が減る
・コードが見やすくなる
・枠組みはDerefトレイト利用で明白かつ汎用的になっている
・自分で作った型にも実装して作動させることができる
・静的に解決しているためミスしてもコンパイル時にわかる
・実行時に付加的な動作がなく高速に実行される
これらの利点を上回る方法があるならば知りたい
既存の言語でも新規の方法でも >>179
>下手で全部書くべきと？
どこかの方言？ >>178
いずれにせよRust信者は自分の信仰を他人に押し付けるために検証可能性を潰すから、科学とはほど遠い姿勢かと。 Rustの方式の利点は>>180に挙げられているから
もしRustより良い言語が存在するならば
その方式およびRustの利点を上回る利点を挙げればいいんじゃね？ 検証可能とはコンパイラが無謬であることではない
ここが難しい
コンパイラが未完成の状況でも人間が正解の一部をなぜか知っていること
これが検証可能 単に理解できないから難癖つけてるだけだよねこの人
自分の主張も一切ないし 誰かの難癖を自分が思い付いたかのように言ってるだけで
何一つまともな批判はない 全く相手にすべき人間ではないと判断する
よって今後無視する >>184
それは「批判するなら代案出せ」と同じ議論を潰すだけの態度なのでやめよう
技術者なら自分が使っている道具の限界や弱点とは真摯に向き合うべき
その際他の道具との比較も必須ではない 技術的選択は突き詰めれば必ずトレードオフが生じるもの
利点だけを見て欠点に目をつぶったまま良し悪しを論じるのは愚の骨頂 Rustの方式の利点は>>180に挙げられているから
もし仮にRustより良い言語が存在するならその言語の方式の利点を挙げればいいんじゃね？ >>191
>それは「批判するなら代案出せ」と同じ議論を潰すだけの態度なのでやめよう
議論を潰すというよりも批判から逃げたいだけだろう 物的な代案や物的証拠により人の心を折ることが検証だと思っているんじゃないか わざわざRustスレにまでやって来てRust叩きやってる人だから心の病気なのかもな >>167
>&&T→&Tの場合
これ調べてみたんだけどビルトインderefが優先的に動いて
Deref for &Tの実装は使われてなかった ビルトインは*を明示指定しないといけなくない？
coercionは何も指定しなくてもDeref実装があれば自動的に多段に適用してくれるけど impl Deref for &T
はtrait境界を満たすためだけに定義されてるんだろうな
標準だとDeref境界はPinくらいしか使ってないけど >>199
*演算子のときもDeref CoercionのときもビルトインderefがDeref::derefよりも優先して使われるよ derefの仕方は状況によって使い分けかな
例えばVec<T>からスライス&[T]にする場合
// deref operatorを使う方法
// 一番短く頻出
let slice = &*vec;
// RangeFull Indexを使う方法
// Rangeを変えて汎用的に範囲指定ができるメリット
let slice = &vec[..];
// deref coercion先の型を明示する方法
// 関数呼び出しは引数の型が明記されてるのでこのパターン
let slice: &[T] = &vec;
// deref()メソッドを使う方法
// ただしDerefトレイトのuseが必要
use std::ops::Deref;
let slice = vec.deref(); uv、めちゃ速いな
今までの処理時間はなんだったのか
これはRustの印象を良くするツールになるわ uvというとCで書かれた非同期マルチプラットフォームライブラリ(Rustにはmioがある！)が有名だが
そのuvはRust製のPythonパッケージマネージャーなのか JavaScriptでも遅いBabelを速いSWC(Rust製)に換えると爆速 Pythonの管理ツールまたなんか出たの！？という気分 uvはPython版のcargoを目指しているらしい nvidiaのど汚なさを理解してなさげで不安しかないわ RustでDB使う時の定番ライブラリって何ですか？ ORMが好きならdiesel
ORMが嫌いならsqlx 最近RDB以外のDBの存在を知った人にありがちな反応だよな Rustで一通り文法や機能紹介した入門書の次に読むような定石本ってどのようなのがありますか？C++でいうEffective C++みたいな >>216
Rust for Rustaceans >>219
Rustはデフォルトのハッシュ関数が最強最善の暗号学的ハッシュ関数であるSipHashを採用しているため衝突にも強くハッシュDOS攻撃に対しても安全
もし強い衝突耐性を必要としない用途ならばFxHasherなどの速さ重視のハッシュへと簡単に置き換えられる
type Hasher = std::hash::BuildHasherDefault<FxHasher>;
let mut map = HashMap::<Foo, Hasher>::default(); こうね
HashMap::<Key, Value, Hasher> 解決案としてはそうなのだが、デフォルト挙動が罠すぎる
デフォルトいらなかったのでは Rustは利用者はアホだと思ってる
だから徹底的に厳しくしてくる 雨が降ってなくても傘を持つように言って来て外出すらさせてくれない デフォルトのハッシュ関数が遅くて困るってことはよく知らずに使ってたってことでしょ？
そう考えると初心者向けにデフォルト厳しくしておくのは正解な気がするわ、セキュリティに関わるし
まあ言語側はそんな事考えずにとにかく一番スタンダードなものデフォルトにしろって考え方もわかるが Rustはimpl std::hash::Hasherで必要なら自由に独自のハッシュ計算器をすぐ作れるし
逆にそれと独立にimpl std::hash::Hashで自分の各型に対してハッシュ計算法を指示できるし
この2種類のトレイトを標準で用意してくれているRustは非常に好環境 「最悪の場合でもほどほど」なやつをデフォルトにするのは妥当だと俺も思う。
状況に合わせて選択できたり自分で作れたりする人はそうするんだから、
デフォルトではそうでない人を想定するだろ。 いやそもそもデフォルトいらんくね？
なんでデフォルト欲しいんだ？ 掃除機はAI搭載して吸ってはいけないものを吸ったら止まってくれよ デフォルトを用意するかしないかは言語思想によるから正解不正解では語れないよな
rustの場合は何事も「安全」に基づいて設計されてると認識してる 適切なハッシュ関数を選択するのってそんな簡単なことじゃないからな
ハッシュ関数の特性だけじゃなくhashbrownの特性も知らないといけないしその両方を組み合わせた際のハッシュDoS耐性の程度も評価できないといけない
HashMapのように基本的なデータ構造を使うのにどんな場合でもいちいちユーザーがその選択しなきゃいけないようだと辛すぎるわな HashMapで使われるHashに重いものを使う必要がある局面は限られてる
でも他人のライブラリの外から必要な時にハッシュアルゴリズムを変えることなんかできないので悩ましい人もいるだろう 僕が美少女とセックスするためのプログラムはRustで作れますか >>233
ライブラリを作成する時にその用途に応じた適切なハッシュを用いればよい
用途により異なるならば安全側に倒すか指定する方法を提供すればよい とりあえずデフォルトを使って、必要になったら差し替えればいいんじゃないの？
Rustだとなんか問題あるんだっけ？ >>236
ライブラリのハッシュを差し替えられない
デフォルトハッシュを使うような人間がどんどん参戦してきてcratesの名前空間を埋め尽くしていく ハッシュ衝突強度安全性が必要かどうかの判断ができない者がRustデフォルトの安全なものを用いることになるのは正しい
そこまで必要としない用途であると判断できた者だけがFxHashなどを用いればいい
RustコンパイラもFxHashを用いている
https://github.com/rust-lang/rustc-hash 安全で高速を名乗ってるくせにライブラリがおっせえ言語だなあ
これ治すにはいちいち依存ライブラリ全てをcloneしてきてチマチマ変更していかないといけないってマジかよ 言語とは関係ない
外部からのデータを扱うなど攻撃耐性など必要となる部分には攻撃耐性のあるハッシュが必須
そうでない部分には攻撃耐性は必要ない
各プログラムの中にこれら両者はは共存しうる
この使い分けができているかどうかは各言語の問題ではない ライブラリやその管理が言語と関係がないとする主張は可能だが、その主張をするとcargoやcratesの存在が言語と関係ないことになり、Rustの良さを支えている理由の大きな割合を失うことになる
やはりエコシステムやそこにある資産も含めての言語の評価だろう
それにユーザーの問題を言語が引き取らないのであればコードを書く人が充分賢いことを仮定することになり、C++で良いということになる >>241
C++だけでなくスクリプト言語であろうがすべて同じ
攻撃耐性が必要となるところで強度の高いものが使われてなければ欠陥プログラム >>242
だからデフォルトなんかいらないんだよ
ハッシュごとき使うのにデフォルトがないと使えないような人間がcratesの名前空間を埋めていくのはヤバいよ >>243
ほとんどの言語の連想配列(hashmap)のハッシュ関数はデフォルトがありますよ
指定しないと使えない言語がもしあるとしてもレアじゃないですか？ >>244
それはJavaScriptやPythonのような馬鹿がライブラリを書いて馬鹿が馬鹿の再生産をすることを推奨している言語の話でしょう？
もしくは仕様だけ緩く決めて実装には何の責任も取らない言語か スクリプト言語だと速度は求められないという了解があるし Rust や C++ の思想でいう速さはゼロコスト抽象のことだよ。
抽象化にはコストはない (または十分に小さい) が実行すれば実行内容に相応の実行コストが生じるのは当たり前のことだし、実行内容を最小限にすることを目指したって単に不便になるだけだ。 あらゆる言語のあらゆるプログラムについて以下が成り立つ
【必須】信頼できない外部入力データに対しては攻撃に強いハッシュ関数を用いなければならない
【自由】そうでないデータに対してはどのハッシュ関数を用いてもよい
この状況で安全な言語はデフォルトとして攻撃に強いハッシュ関数が適切
そして後者と判断できるプログラマーのためにハッシュ関数を指定できる仕様が適切
Rustはこの適切な仕様となっている 外に出るときはヘルメットを被って110をすでに入力したスマホを持ちながらおむつをしてコンドームつけてるのがRust デフォルトとFxHasherで比較してみたけどHashMapへのinsertのみで実行時間1.7倍
現実のプログラムだとそれ以外の部分が大量にあるためそれ次第で誤差だね
これはデフォルトが安全側に倒す形を取っていて正解と思う >>248
>【自由】そうでないデータに対してはどのハッシュ関数を用いてもよい
いやーそれはどうだろう？
ハッシュDoS耐性は不要でも例えばFxHashを使うべきじゃないユースケースも普通にあるよね？
stdに1つしかHasherが用意されておらずサードパーティ頼みな現状は言語的には結構不親切 hash自体は基本的にアホでも作れる
それが適切なのかどうかは不明 Rustはデフォルトハッシュ関数が用意されていておかしいと言うけど
すべての言語で用意されてるでしょ？
Rustは様々なハッシュ関数が標準ライブラリにないと言うけど
それが普通でしょ？
さらにRustの標準ライブラリはなるべく小さくする方針ね >>255
ここまで読んでそういう解釈になってるなら理解する力が足りてない
重いハッシュ関数がデフォルトになってるのがどうなのかと言う話 普通に考えて攻撃に強いハッシュ関数がデフォルトとなってるのがベストだよね
攻撃の可能性のない部分のみを後でチューンアップつまり弱いハッシュ関数で置き換えるだけだから
これより良い策があるの？ >>258
バカなの？
それだとチューンアップする前が攻撃耐性ないじゃん 江戸時代士農工商の身分制度があって
雨の日だけ農民も下駄を履いてよかった みんなの言語思想発表会をするのはいいけどRustをそれに巻き込むなよ IDコロコロ全肯定君
攻撃されるかもしれないのに攻撃の耐性をつけてない人に
対するフールプルーフのために一律全てのコードを遅くする
そもそもその人が設計ミスってるんだろう SafeSlowHashMapみたいな名前にすれば良いのに >>264 >>265
Rustを使ったことすらない人が文句を言ってるのか
RustのHashMapはHasherに対しても多相であり型パラメータでHasherを指定する >>266
HashMap::new()すらしたことないのかな？ ■ このスレッドは過去ログ倉庫に格納されています
