Repository navigation
Consider providing Rng methods as inherent methods #862
Description
Rng is almost always used, so maybe consider providing its methods to at least thread_rng.
Maybe using https://github.com/dtolnay/inherent ,
Rng is almost always used, so maybe consider providing its methods to at least thread_rng.
Maybe using https://github.com/dtolnay/inherent ,
Activity
dhardy commentedon Aug 9, 2019
Traits are a core part of the Rust language. Is adding stuff like this really in the best interests of users, or is it simply causing confusion (I don't need to import
Rngso why do I need to importSeedableRng)?The other angle on this is that we have been asked quite a few times to minimise dependencies.
newpavlov commentedon Aug 9, 2019
Note that it will cause duplication of methods in documentation, and if we'll add
doc(hidden), then I think it will only cause confusion. Personally I believe inherent trait implementations should be a language feature: rust-lang/rfcs#2375burdges commentedon Aug 9, 2019
Already addressed by
use rand::prelude::*;matklad commentedon Aug 15, 2019
Case point:
std::io::Stdinhasread_lineinherent method, which is a convenience overBufRead::read_line(stdin().lock()).I think a good design for maximizing usability is Python's
random: it re-exports methods on default global rng as module-level functions.randsort-of does this, but it only exportsrandom, which proxies toRng::gen, while other functions are not proxied. Additionally, the function is renamed, which seems less than ideal.With uniform paths, I think re-exporting all the methods as is will be nice:
dhardy commentedon Aug 15, 2019
We could do that. We have been more leaning towards suggesting users cache the
rnghandle at least within their current function.If we want to expand this to
chooseI guess we'd have to pick the more general implementation, for iterators. Performance isn't much different so long as size hints are available.A drawback is the arbitrary choice of which functions to make available this way:
choose_weighted?partial_shuffle?gen_ratio?Personally I don't think requiring a single import (
prelude::*orRng) is too bad.dhardy commentedon Aug 28, 2019
Proposed resolution: reject. This adds to API surface for only minor convenience, and the
rand::random→rand::gensuggestion would be a breaking change.In pursuit of open design, I will leave this topic open for discussion for some more time. Evidence-based arguments are preferred, but this is mostly an opinion issue.