Summary (so far)

[burdges]

Apologies for my poor memory, but how did the separate fallible TryRng, etc. v infallible Rng traits get merged?

We felt the next_u32 v next_u64 distinction was fundamental to Rngs, but not TryRngs. Avoiding try_next_u32 and try_next_u64 cost us building an Rng from a TryRng. We therefore felt all the functions needed separate manual implementations. It is that somehow combining the traits made this more natural?

Instead maybe the reasoning went that we needed a "common currency" output for seeding new Rngs, etc. that we lacked if some objects were only Rng and some were only TryRng, and dependencies between them caused other issues? Is that more like it? In this vein, we avoided associated seed types because try_gen will not exist and we must seed respecting errors?

We lost associated error types possible with TryRng in combining the traits, or did that come earlier?

I'm asking this partially because I've forgotten or never understood, but also because concisely explaining the reasoning behind the decisions will help with RFCs and putting people on the same page.

[dhardy]

1. Obviously any TryRng should be able to support Rng too (to work with code using the latter) and Rng should be able to support TryRng also
2. It's undesirable for code implementing TryRng to have to implement all of Rng too manually; unfortunately though having a blanket impl<TR: TryRng> Rng for TR rule conflicts with the impl<R: Rng> Rng for &mut R rule we want to have so the only way to do this with two traits would be if Rng: TryRng and all Rng functions have default implementations
3. Same but vise-versa

So there's not much point using separate Rng and TryRng traits.

Separately, there's not much requirement for "try" variants of next_u*.

[burdges]

Right, it might've even been me who initially pointed out the impl<R: Rng> Rng for &mut R but I never understood all the consequences. lol