Error handling: Result vs panic

[dhardy]

The consensus on this seems to be that Result is better in general, but there is little point for the simple next_u* functions, resulting in the following members of Rng or similar traits

    fn next_u32(&mut self) -> u32;
    // other next_u* ...

    fn try_fill_bytes(&mut self, dest: &mut [u8]) -> Result<(), Error>;

    // possibly also a panicing fill function:
    fn fill_bytes(&mut self, dest: &mut [u8]);

[newpavlov]

A bit of bike-shedding: I am not sure about fill_bytes name, we have sort of convention which originates from the standard library: if we have try_foo method we'll have panicking foo counterpart as well, not foobar or something else. Plus fill will be 6 symbols shorter. :)

I understand the desire to keep names from the previous rand, but I don't think it warrants such inconsistency.

[dhardy]

Good point. I'm happy to rename to fill. Any objections?

[dhardy]

On second thoughts, fill_bytes is an existing function, so to avoid breakage it would be better to use fill_bytes and try_fill_bytes.

[burdges]

I'd say fill_bytes and/or try_fill_bytes to reserve fill/try_fill for a function that handles &mut [T] where T: Rand.

[dhardy]

@burdges I'm pretty sure that will never be part of the same trait (if my RFCs get accepted): Rng will be in a separate crate from the distribution code (which handles generation of values of other types).

[burdges]

I see. In fact, gen should already work fine for [T; N], while collections have rng.iter().collect() and replacing a &mut [T] sounds rare, so an explicit for (x,y) in slice.iter_mut().zip(rng.iter()) { *x = y } sounds fine.