Rust part8

**デフォルトの名無しさん** · 2020/01/24(金) 11:47:52.41

Mozilla発のRust言語のスレ

公式
https://www.rust-lang.org/
https://blog.rust-lang.org/
https://github.com/rust-lang/rust

Web上の実行環境
https://play.rust-lang.org

前スレ
Rust Part7
http://mevius.5ch.net/test/read.cgi/tech/1563114707/

**デフォルトの名無しさん** · 2020/07/01(水) 21:27:38.74

>>824
By default, HashMap uses a hashing algorithm selected to provide resistance against HashDoS attacks. The algorithm is randomly seeded and …
https://doc.rust-lang.org/std/collections/hash_map/struct.HashMap.html

**デフォルトの名無しさん** · 2020/07/01(水) 21:35:15.59

ハッシュの生成はアルゴリズムに対して決定的なんだからハッシャーがどうのなんて馬鹿げてる

**デフォルトの名無しさん** · 2020/07/02(木) 00:00:35.12

Result<T,E> を要素とするイテレータを Result<Vec<T>,E> にしたくて、
よくありそうなパターンだと思うんだけどさらっと上手くやる方法ってないもんかな？

**デフォルトの名無しさん** · 2020/07/02(木) 00:03:26.32

>>828
collectがいい感じにやってくれるよ。

**デフォルトの名無しさん** · 2020/07/02(木) 01:46:12.20

collect::<Result<Vec<_>, _>>()

**デフォルトの名無しさん** · 2020/07/02(木) 10:10:47.16

毎回乱数使ってるなら画面更新するたびにハッシュ変わるはずだよね？
https://play.rust-lang.org/?code=%23!%5Ballow(unused)%5D%0Afn%20main()%20%7B%0Ause%20std%3A%3Acollections%3A%3Ahash_map%3A%3ADefaultHasher%3B%0Ause%20std%3A%3Ahash%3A%3AHasher%3B%0A%0Alet%20mut%20hasher%20%3D%20DefaultHasher%3A%3Anew()%3B%0Alet%20data%20%3D%20%5B0x01%2C%200x23%2C%200x45%2C%200x67%2C%200x89%2C%200xab%2C%200xcd%2C%200xef%5D%3B%0A%0Ahasher.write(%26data)%3B%0A%0Aprintln!(%22Hash%20is%20%7B%3Ax%7D!%22%2C%20hasher.finish())%3B%0A%7D&edition=2018
変わらないよ？

**デフォルトの名無しさん** · 2020/07/02(木) 10:42:54.83

>>831
HashMapと同じことをしたいなら、RandomStateからbuild_hasherでhasherを得ればよい。別に画面更新しなくてもRUN押す度に変わるよ。

**デフォルトの名無しさん** · 2020/07/02(木) 10:47:40.50

ちなみにDefaultHasher::newで変わらないのは、単に内部的にSipHasher13::new_with_keys(0,0)を呼んでるから。
RandomStateがその0,0をランダムに変えている。

**デフォルトの名無しさん** · 2020/07/02(木) 12:36:00.56

Hash値の計算そのものも、本当はかなり速度が求められるものなので、それを
自在に変えるというのはどうやっているのか興味が有る。
Hash値そのものの計算は、遅いわけではないが、それでも膨大なデータを処理する
場合には、その問題になることがある。

**デフォルトの名無しさん** · 2020/07/02(木) 14:34:38.77

SipHasher13::new_with_keys(0,0)はソルト？シード？

**デフォルトの名無しさん** · 2020/07/02(木) 18:18:58.79

>>830
えっ、それでいけたんだ……。
知らんかった。

**デフォルトの名無しさん** · 2020/07/02(木) 20:30:51.40

collect() があれば何でも出来る

**デフォルトの名無しさん** · 2020/07/02(木) 21:18:08.94

>>835
https://131002.net/siphash/siphash.pdf
これを読んだうえで好きに呼べばいい。

**デフォルトの名無しさん** · 2020/07/02(木) 22:08:07.26

collectが中でやってる事って std::convert::from か？

**デフォルトの名無しさん** · 2020/07/03(金) 01:32:48.51

>>839
FromIterator::from_iter呼んでる
From呼ばれるかどうかはFromIteratorの実相次第だけど
普通はIterator::Itemがそのままコレクションのデータ型になるから呼ばれないと思う

**デフォルトの名無しさん** · 2020/07/04(土) 01:28:15.59

これがコンパイルエラーになる（sum::<i64>()としないといけない）のってなんでですか？
let s: i64 = (0i64..10).sum() + 10i64;

推論できる材料は十分に見えるんですけども

ちなみにこれなら通ります
let s: i64 = (0..10).sum();

**デフォルトの名無しさん** · 2020/07/04(土) 07:36:29.64

rangeはusizeだから

**デフォルトの名無しさん** · 2020/07/04(土) 15:11:36.89

>>841
ここに理由書いてるけど、詳しくはわからん

At the moment, we always refuse to guess the "self" type, so we just stop there.
For other type parameters, if Self is known, we will sometimes infer them based on Self
https://github.com/rust-lang/rust/issues/25094#issuecomment-304079316

**デフォルトの名無しさん** · 2020/07/04(土) 22:58:43.94

>>843
下位互換失うからじゃね？

>because it leads to regressions when new impls are added.

**デフォルトの名無しさん** · 2020/07/05(日) 01:30:45.53

今までターボフィッシュで型指定しなくても動いてたものが
新しいimpl追加によって型指定がないと動かなくなるケースがあるというのは理解できる

ただ(0i64..10).sum()のケースはiter::Iterator::sumやiter::Sumの定義から
各要素がi64だと決まってる限り新しいimplが追加されても結果の型もi64にしかならないと思うんだよね

//iter::Iterator::sum
fn sum<S>(self) -> S where Self: Sized, S: Sum<Self::Item>
{
Sum::sum(self)
}

//iter::Sum
pub trait Sum<A = Self>: Sized {
fn sum<I: Iterator<Item = A>>(iter: I) -> Self;
}

**デフォルトの名無しさん** · 2020/07/05(日) 23:04:09.03

>>845
まず、

1) inference type（推論された型）と宣言時や実行時の型は別なんで、実行時の型はあくまで推論された型の外延でしかない。
すると、別の型互換のルール（たとえば、部分多相とか）がないと互換の型とみなせない。

2) 公開された部分を推論すると将来の変更で1)から互換性を失う場合がある。
最近型推論導入した言語が公開関数のシグネチャ等を推論しないのはこの問題が理由だと思う。

>ただ(0i64..10).sum()のケースはiter::Iterator::sumやiter::Sumの定義から
>各要素がi64だと決まってる限り新しいimplが追加されても結果の型もi64にしかならないと思うんだよね
これは単にメソッド呼び出しの生成規則:　expr0 ". " expr2　[Turbofish] "()"　のexpr0から推論しないルールが既にあるからできないだけじゃないの？
これを拡張すると2)から互換性を失う可能性がある。公開された型と関数のシグネチャに依存してるんで。

**デフォルトの名無しさん** · 2020/07/06(月) 00:48:42.43

ぶぶんたそー
まれいたそー

**デフォルトの名無しさん** · 2020/07/09(木) 06:01:23.92

Rustの構文を自分でPython風にしてるんだけど、このwhereのとこの構文がどうも末尾:と相性悪くてどうしたら綺麗になるか教えて欲しい。
問題点
* Self: Sizedの型指定の:と被る(引数の型はかっこに埋まってるからいい)
* 一行目の関数宣言の:があるのに二行目でもwhere使うために:がある(二行続くのは英文法的にもおかしい)
* whereの構文ルールが曖昧(改行入れたりできる) -> だから統一したい
fn sum<S>(self) -> S:
where Self: Sized, S: Sum<Self::Item>:
Sum::sum(self)

**デフォルトの名無しさん** · 2020/07/09(木) 19:57:31.40

Rust にトランスパイルされる Python 風構文の言語を作っているということかな？

fn sum<S>(self) -> S
where Self(Sized), S(Sum<Self::Item>):
Sum::sum(self)

こんな感じで class の継承っぽく書くのはいかが

**デフォルトの名無しさん** · 2020/07/09(木) 20:52:03.73

そう、そういう言語作ってる最中。
たしかにその構文もいいね！でもstruct S(i32);に見た目上だけど被るのと、トレイトのfn name<T: Num>とかも構文変える必要でてくるなぁ
個人的にはトレイトベースの言語だからT: Numは変えたくないだよね
こういうのもいいかも
fn sum<S>(self) -> S,
(Self: Sized, S: Sum<Self::Item>):

whereと同じような機能でしっくりくる構文持ってる他言語とかないのかなぁ

**デフォルトの名無しさん** · 2020/07/11(土) 09:57:59.11

Haskell 風にするとかどうよ

**デフォルトの名無しさん** · 2020/07/11(土) 19:10:01.60

Winrtよく知らないんだけどWindows環境でGUI簡単にいじれるようになったの？

**デフォルトの名無しさん** · 2020/07/11(土) 19:28:45.72

どうせマクロ地獄だろ

**デフォルトの名無しさん** · 2020/07/14(火) 15:40:35.77

let delta = input[0] - input[1];
println!("{}{}", if delta == 0 { "" } else if delta > 0 { "-" } else { "+" }, delta.abs());
このif delta == 0 { "" } else if delta > 0 { "-" } else { "+" }の綺麗な順番とかの定石の書き方ってある？

**デフォルトの名無しさん** · 2020/07/14(火) 16:21:46.36

match delta.cmp(&0) {
std::cmp::Ordering::Equal => "",
std::cmp::Ordering::Greater => "-",
std::cmp::Ordering::Less => "+",
}

**デフォルトの名無しさん** · 2020/07/14(火) 18:24:58.52

n == 0の時だけ記号なしにしてそれ以外は{:+}でフォーマット
(n > 0の時だけ{:+}にするのでも結果は同じ)

**デフォルトの名無しさん** · 2020/07/14(火) 20:20:46.59

>>855
>>856
ありがとう、両方いいね！

**デフォルトの名無しさん** · 2020/07/15(水) 17:09:04.17

msvcとgnuってどっちにすべきなん？

**デフォルトの名無しさん** · 2020/07/15(水) 20:29:35.32

両方有るってことはどっちにでも出来るってこった。
どちらかが良いなんてことはない。

**デフォルトの名無しさん** · 2020/07/15(水) 21:20:40.13

rustコンパイルできないけどな

**デフォルトの名無しさん** · 2020/07/16(木) 01:35:03.21

以下のコードでクロージャclの引数に型推論が効かないのってなんでですか？
fn main() {
let vv = vec![vec![1, 2, 3]; 4];
let cl = |a, b, c, d| vv[a][b] + vv[c][d];
//error[E0282]: type annotations needed
println!("{}", cl(3usize, 1usize, 2usize, 2usize))

}
https://play.rust-lang.org/?version=stable&;mode=debug&edition=2018&gist=a49b194930fcdfd894c2be4fc078be80

クロージャclの引数のところを |a: usize, b, c: usize, d| とすればコンパイルは通るのですが、aとcだけ型注釈が必要になるのも意味がわからないです

**デフォルトの名無しさん** · 2020/07/16(木) 23:09:40.63

jsonをパースして、その中身に対して更に値を追加し
最後にはまたjsonでシリアライズということをやりたいのですが、
serdeだと事前に入力と出力の型を定義していないと難しいですか？

from_stringでValue型に入れて、mapのようにキー名で値を取れることは分かったのですが
そこに新たに値を追加する方法がわからないです

**デフォルトの名無しさん** · 2020/07/16(木) 23:23:19.49

as_object_mut
あたりかな

**デフォルトの名無しさん** · 2020/07/17(金) 00:05:43.64

https://blog.rust-lang.org/2020/07/16/Rust-1.45.0.html

予定通り来た
Rocketがstableの仲間入り

**デフォルトの名無しさん** · 2020/07/17(金) 01:59:14.04

>>863
ありがとう神様

C#ならすぐなのに、
これは理解するのに時間がかかりそうだ。

**デフォルトの名無しさん** · 2020/07/18(土) 18:30:51.49

神がついてるから大丈夫

**デフォルトの名無しさん** · 2020/07/20(月) 13:18:08.21

actix-wevからRocketに移行します

**デフォルトの名無しさん** · 2020/07/21(火) 02:22:25.82

>>867
その理由は？

**デフォルトの名無しさん** · 2020/07/21(火) 18:35:05.91

スライスから差集合を作るの際にスライスをそれぞれhashsetにしてdifference呼ぶ以外で良い書き方ありますか？

**デフォルトの名無しさん** · 2020/07/22(水) 00:13:53.48

それぞれsortして先頭から比較していく

**デフォルトの名無しさん** · 2020/07/22(水) 01:18:16.47

>>869
シンメトリックじゃない単なる差集合なら
片方だけsetにしてもう片方の要素でループしながらチェックするのでもいい気がする
あと状況によってはBroom filterみたいなのを使うと高速化できるかも

**デフォルトの名無しさん** · 2020/07/22(水) 13:33:09.23

fn aaa(s: &str) {
if s == "aaa" {
compile_error!(r"If s is "aaa", compile error!");

}
}
fn main() {
// compile error!
aaa("aaa");
// can compile
aaa("aaaaaaaa");
}

こういう風にコンパイル時にコンパイルエラー出したいんだけど、実際はcompile_error!を書いてる時点でコンパイルになるんだけど回避方法ってないかな

**デフォルトの名無しさん** · 2020/07/22(水) 13:33:41.15

こういう風にコンパイル時にコンパイルエラー出したいんだけど、実際はcompile_error!を書いてる時点でコンパイルになるんだけど回避方法ってないかな
↓
こういう風にコンパイル時にコンパイルエラー出したいんだけど、実際はcompile_error!を書いてる時点でコンパイルエラーになるんだけど回避方法ってないかな

**デフォルトの名無しさん** · 2020/07/22(水) 15:44:52.79

>>870
>>871
㌧

**デフォルトの名無しさん** · 2020/07/22(水) 15:48:48.87

ダブルクォートがaaaの部分で外れてるのが原因とかじゃなくて？

**デフォルトの名無しさん** · 2020/07/22(水) 15:58:57.61

aaa(r#"aaa"iiii"uuuuu"#)

**デフォルトの名無しさん** · 2020/07/22(水) 16:04:28.78

>>875
ごめん。ここに貼る用のデバッグコメ。
そこ直したら本題の条件分岐のコンパイルエラーにならないのがでてくる
compile_error!(r#"If s is "aaa", compile error!"#);

**デフォルトの名無しさん** · 2020/07/22(水) 18:44:16.24

compile_error!は条件付きコンパイルかマクロでしか使えないんじゃ？
compile_error!と記述してる行がコンパイルするコードに含まれることになったらコンパイルエラー

マクロを展開する段階では変数の値を評価できないから
文字列を受け取る関数に対して特定の文字列を渡すコードがあったらコンパイルエラーってのは無理な気がする

**デフォルトの名無しさん** · 2020/07/22(水) 22:19:16.93

aaaを手続きマクロにすればできるとは思うけど。

**デフォルトの名無しさん** · 2020/07/23(木) 01:38:31.65

最近RustのSlackでも出てきた福野泰介ってやつ声でかいよな
こいつどのコミュニティでも何かしら主張して目障りだわ

**デフォルトの名無しさん** · 2020/07/23(木) 01:41:56.15

Ubuntu Japanese Team に言いつけて潰してもらおうぜ

**デフォルトの名無しさん** · 2020/07/23(木) 18:56:28.53

環境はMacOS Catalina, Rustは1.45.0です
今弄ってる物(https://github.com/Nercury/rust-and-opengl-lessons)で
/lib/gl/src/lib.rs内に
include!(concat!(env!("OUT_DIR"), "/binding.rs"));
というのがあるのですがですがcargo buildすると
this error originates in a macro
error: couldn't read /Users/Path/target/debug/build/gl-71effbf83f5b03a9/out/binding.rs: No such file or directory (os error 2)
と表示されます
https://github.com/rust-analyzer/rust-analyzer/issues/1964
https://github.com/rust-skia/rust-skia/issues/10
などを見たのですが具体的な修正がわかりませんでした。
Rustは最近始めたばかりでincludeマクロやcargoの仕組みなどまだあまり詳しくありません
このinclude!を成功させる方法を教えてください
迷惑をかけてしまうかもしれませんがご教授お願いします

**デフォルトの名無しさん** · 2020/07/23(木) 19:05:44.31

福野泰介はたしかにどこでも目立つ。
自己顕示欲もあそこまでいったら面白い、反面教師として役立つ

**デフォルトの名無しさん** · 2020/07/23(木) 21:20:06.43

>>882
lib/gl/build.rsでOUT_DIRにbinding.rsを作成してる

ビルドスクリプトが意図した通りに動いているのか確認するために
build.rsを変更してbinding.rsのフルパスをprintlnでもするようにして
cargo build -vvしてみるといいと思う

ビルドスクリプトについて詳細知りたければこの辺読んで
https://doc.rust-lang.org/cargo/reference/build-script-examples.html

**デフォルトの名無しさん** · 2020/07/24(金) 00:48:59.83

>>884
ありがとうございます動きました！
非常に長文だった自覚はあるんですが分かりやすくすっきりした回答ありがとうございますm(_ _)m

**デフォルトの名無しさん** · 2020/07/24(金) 10:22:52.41

同じサーバー内でポート別にクライアント用サーバー(Nuxt)とAPI用サーバー(Rust)立ち上げるのってどう思う？
クライアント用サーバーは初回しか性能響かないからあれだけど、Rustの方が断然速いし、SPAだからルートの設定も全然しなくていいし、Rustの方でフロントページも返した方がいいんじゃないかと思ってるんだけども
要はRustを実行すればポート別に２つサーバーが立ち上がるようにするってこと

**デフォルトの名無しさん** · 2020/07/25(土) 18:01:19.70

RocketってRust公式サイトにも使われてるのか
迷ったらRocketで良さそうだな

**デフォルトの名無しさん** · 2020/07/26(日) 03:19:09.22

diesel使いづらくない？

**デフォルトの名無しさん** · 2020/07/26(日) 18:57:03.68

rustcの-C llvm-args=が取り得るオプションの説明ってどこかに書いてある？
clangのttps://clang.llvm.org/docs/ClangCommandLineReference.html#x86
あたりがそれっぽいけど説明が全くないのでデフォルト値も効果もよく判らない

**デフォルトの名無しさん** · 2020/07/26(日) 22:31:29.89

>>889
ここに書いてあるけど'--help'を渡せば一覧表示されるみたいよ
https://doc.rust-lang.org/rustc/codegen-options/index.html#llvm-args

$ rustc -C llvm-args='--help'

**デフォルトの名無しさん** · 2020/07/26(日) 23:02:23.88

あるモジュールクラスを別のモジュールで使いたい場合ってどう宣言するのが正しいの？

正直ドキュメント読んでも分からん

**デフォルトの名無しさん** · 2020/07/26(日) 23:58:47.45

>>890
サンキュ。そう使うのかよｗ　うちの環境では
>rustc -C llvm-args=--help　←'を付けると怒られる
でそれっぽいのが得られました。amd64で使用命令を選択するようなオプションは無いのか・・・

**デフォルトの名無しさん** · 2020/07/27(月) 00:46:16.95

--helpの最後に出てたけど
利用可能なオプションを全部表示するには
llvm-args=--help-hiddenってするみたい

**デフォルトの名無しさん** · 2020/07/27(月) 09:47:21.61

chronoのnext_monthないのってどう実現すればできる？

**デフォルトの名無しさん** · 2020/07/27(月) 10:10:01.73

>>894
そもそもnext_monthに何を期待するかによると思うが。30日後？31日後？翌月の同じ日？それが存在しない場合は？とか。その辺がはっきりすれば、その通りに実装すればいい。

**デフォルトの名無しさん** · 2020/07/27(月) 10:18:30.24

翌月の同じ日ならこれかな。
https://docs.rs/chrono/0.4.13/chrono/trait.Datelike.html#tymethod.with_month

**デフォルトの名無しさん** · 2020/07/27(月) 16:16:44.20

>>896
ありがとう、結局next_month自分で実装したけど、かなり頻繁に使われる類のメソッドだから正直きついな
with_monthもoptionで返すから31 -> 30の次月遷移したとしても安全だから実装しない理由が分かんないな
chronoは変なとこには手回ってるしよくわからん

**デフォルトの名無しさん** · 2020/07/27(月) 18:03:20.70

>>897
issueはあるけど別に誰かが反対しているわけでもなく、
単に誰も実装してないだけじゃない？
PR出してみればいいと思うけど。

https://github.com/chronotope/chrono/issues/290

**デフォルトの名無しさん** · 2020/07/28(火) 16:26:39.82

>>891
じけつ

main.rsでそれぞれのモジュールをmod宣言

**デフォルトの名無しさん** · 2020/07/29(水) 11:56:30.09

ed25519の公開鍵のssh-ed25519 ******の部分が欲しくて、ed25519_dalekっていうクレートで鍵作ってるんだけどPublicKey構造体のas_bytesでとってくるバイト列をstr::from_utf8でしてもエラーが出て秘密鍵の***部分にならないんだけど、どうすればいいか分かる？
https://docs.rs/ed25519-dalek/1.0.0-pre.4/ed25519_dalek/struct.PublicKey.html

**デフォルトの名無しさん** · 2020/07/29(水) 20:03:32.01

1byteずつ print!("{:02x}", b) するとかではなく？

**デフォルトの名無しさん** · 2020/07/29(水) 21:31:44.28

>>900
str::from_utf8でエラーになるのは
0~127までのUTF-8互換のASCII以外の文字が含まれてるからでは？

pemで見れる公開鍵のssh-ed25519 ******の部分は
keyの種別とDERエンコードしたkeyの値をBase64にしたものらしい

**デフォルトの名無しさん** · 2020/07/30(木) 13:54:57.65

>>901
やってみたらエラーはでないし、ハッシュっぽいものできたけど、大文字ないから >>902の方法っぽいかも
4ef6dcfda191770b64939c5657fc26e631c2caffa18e423c397d761d507ae82a%

>>902
ありがとう、やってみるわ

**デフォルトの名無しさん** · 2020/07/31(金) 22:54:06.06

bindgenにwindowsはllvmのプリビルドバイナリをインストールしなさいと書いてあるけど、
LIBCLANG_PATH設定し忘れるとwinのプリビルドバイナリには含まれてないllvm-configを使って<LLVM_ROOT>/binまでのパスを探すんで
llvm-configがないって怒られる罠がある。

LIBCLANG_PATHタイポして時間潰してしまった。

**デフォルトの名無しさん** · 2020/08/01(土) 14:02:57.08

やっぱactixよりrocketだな

**デフォルトの名無しさん** · 2020/08/01(土) 14:09:11.29

>>905
その理由は？

**デフォルトの名無しさん** · 2020/08/01(土) 15:02:20.03

なんか速そうじゃん

**デフォルトの名無しさん** · 2020/08/01(土) 15:19:22.53

>>906
ドキュメントがしっかりしてそう

**デフォルトの名無しさん** · 2020/08/01(土) 16:43:51.04

unsafeの個数が少ない方が勝ちって事でいいんじゃない？

**デフォルトの名無しさん** · 2020/08/01(土) 22:13:51.53

rocketってmultipartサポートしてないのか

**小石茶輝** · 2020/08/01(土) 23:31:58.80

unsafe という機能があるのは unsafe が必要だからです。
設計方針に対して必要以上に unsafe があるのはダメですが、
少なければ少ないほど良いというわけでもありません。

たとえば C++ を使っているときだって、
グラフィックドライバを書くときとかは
どうしたって (C++ 的には) 行儀の悪い書き方になってしまうでしょう。

行儀の悪い部分はなるべく低レイヤに押し込めて、
ロジック層が綺麗になるようにするのが望ましいなどといった習慣はありますが、
どの程度にするかの程度問題は設計方針によります。

actix は rocket よりも unsafe を多用してはいますが、
意図のはっきりした unsafe です。

あまりにも unsafe が多すぎるならもう Rust 使うのやめろよと思うかもしれませんが、
行儀の悪い書き方 (unsafe) がより明示的であるというだけでも
C++ よりは少しマシでしょう。

**デフォルトの名無しさん** · 2020/08/06(木) 21:31:08.70

rust案件が出てこないのは何で？

**小石茶輝** · 2020/08/06(木) 23:35:19.16

出てますよ。
あなたがそれをキャッチする立場にないだけです。

**デフォルトの名無しさん** · 2020/08/08(土) 01:19:04.76

stdの中でこれは外部ライブラリにした方がいいんじゃないかなって思うやつある？
逆に外部ライブラリからstdにした方がいいんじゃないかってやつとかもある？

**デフォルトの名無しさん** · 2020/08/08(土) 06:00:59.71

>>914
乱数ライブラリが標準ライブラリに入ってない言語とか他にあんの？

**デフォルトの名無しさん** · 2020/08/09(日) 00:20:40.65

乱数は用途によって必要な性質が色々だからなぁ。
どの分野を優遇すべきかってのは自明ではないでしょ。
全部盛りにするのも Rust 的ではないし。

でも、どの乱数ライブラリを使うにしても同じようなインターフェイスだとありがたいので、
乱数ライブラリが満たすべき標準的なトレイトが提供されて欲しいし、
そのサンプル的な位置づけでひとつくらいは乱数ライブラリが入っていてもいいかなとは思う。

◆QZaw55cn4c · 2020/08/09(日) 00:37:01.23

>>916
MT だけでいいと思うのですが

**はちみつ餃子** ◆8X2XSCHEME · 2020/08/09(日) 00:43:58.48

>>917
メルセンヌツイスタは統計的な性質は良いけど暗号的には使い物にならんしデカい。
常にベストと言えるほど良い選択ではないよ。

◆QZaw55cn4c · 2020/08/09(日) 01:29:16.04

>>918
確かに暗号にMTを使うのはダメですね、暗号用には crypt-MT がありますね

**デフォルトの名無しさん** · 2020/08/09(日) 20:40:18.77

今はもうMTもそこまで・・・って話じゃないっけ
randクレート見るとそんなこと書いてあったような

**デフォルトの名無しさん** · 2020/08/09(日) 20:55:04.69

他の言語だって完璧な乱数だと思ってなくても
利用者の利便性を考えて標準ライブラリに含めてるんだろ
それが無いRustは変

**デフォルトの名無しさん** · 2020/08/10(月) 00:22:38.94

今どきMT法なんか使わん。

>乱数ライブラリが満たすべき標準的なトレイトが提供されて欲しいし、
rand_coreがそれに当たるけどcoreだけだとバイト配列しか取得できんので分布器に生成器渡せん。
未知の生成器の実装すべて含めるのは無理、既知のものに絞っても要求する特性が人によって違うから標準にするのは無理。
結局はこうなるが、俺も標準ライブラリに乱数ほしい。

**デフォルトの名無しさん** · 2020/08/10(月) 01:32:59.38

cargo使ってるから別ライブラリでもあまり困らない
こと乱数に関してはデファクトスタンダードのcraete決まってるし迷うことないしね
標準ライブラリに入ってて欲しいのは初学者がcrate知らないとか探すのが手間だとか、コンパイルタイムが延びるのが嫌だとか、そういう理由？

**デフォルトの名無しさん** · 2020/08/10(月) 02:16:28.69

stdに入れて欲しいのはrandよりregexだな
標準ライブラリとして責任もってメンテされていくものなのかどうかが重要

**デフォルトの名無しさん** · 2020/08/10(月) 03:21:04.11

>>924
あちこちのcrateでregex使ってるから
コンパイル遅くする原因になってるわ