Make NewRng::new() return Self without Result wrapper

[dhardy]

Advantage: more convenient way to call an fn which almost never fails.

[pitdicker]

Looks good to me!

As you argued, new() is extremely unlikely to fail, a convenience function, and an alternative that does return errors is easily available.

[nagisa]

the comment that directs users to use RNG::from_rng should instead say SeedableRng::from_rng instead.

…

On Mar 15, 2018 10:41 AM, "Diggory Hardy" ***@***.***> wrote: Merged #302 <#302>. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#302 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AApc0jI70lJQLasyAjEwzIgsQ_6k4GRNks5teikngaJpZM4Sq8Lz> .

[dhardy]

Do we need to use UFCS here? RNG::from_rng works just so long as SeedableRng is in scope, and I hope it's obvious to readers where from_rng comes from.

[nagisa]

It wasn’t obvious to me (although I haven’t taken time to familiarise myself fully with new trait hierarchy yet), and first look at the recommendation seemed to imply that RNG is a concrete type, rather than a generic variable and that there is no way to generically construct a fallible rng without panicking anymore.

It seems to me that users who will be reading this comment will be operating in the generic context anyway, so their code will be something like this:

fn foo<R: NewRng>(...) -> Result<...> {
    let rng = R::new(); // Hmm, I *really* want to not panic here.
}

Then recommending to use SeedableRng::from_rng makes it pretty obvious what has to change (note that changing the bound from NewRng to SeedableRng in this case is prudent thing to do, even if not strictly necessary):

fn foo<R: SeedableRng>(...) -> Result<...> {
    let rng = R::from_rng(hmm)?; // great!
}

[dhardy]

Ah, sorry, I should have left this open for comment longer. We have quite a lot of PRs at the moment.

I'm assuming actually that many people will not be using generic types, though sure, sometimes they will, so for example:

use rand::{Rng, NewRng, SmallRng};

// This will only fail if something is quite wrong with the platform;
// in this case better just to die anyway:
let mut rng = SmallRng::new();

But sure, your generic version works too.