Blockrng: add associated error type

[dhardy]

Another thing suggested by @burdges

@pitdicker this uses the early return on inner RNG errors you didn't like, but it's only implemented if the internal RNG can actually produce an error.

This does not return any errors from reseeding. I don't really know which is better, Transient errors or no errors.

Unfortunately I can't get generate(..)? syntax to work since:

error[E0277]: the trait bound `error::Error: std::convert::From<<R as BlockRngCore>::Error>` is not satisfied
   --> rand-core/src/impls.rs:285:13
    |
285 |             self.core.generate(dest_u32)?;
    |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `std::convert::From<<R as BlockRngCore>::Error>` is not implemented for `error::Error`
    |
    = help: consider adding a `where error::Error: std::convert::From<<R as BlockRngCore>::Error>` bound
    = note: required by `std::convert::From::from`

I tried adding a where bound on the associated Error type; strangely this is allowed by the compiler but doesn't seem to help.

Note: maybe we should investigate what @burdges suggested a long time ago, associated error types on RngCore.

[pitdicker]

I think it is an ingenious solution. But aren't we over-designing here? I still have trouble imagining when a PRNG can error.

[dhardy]

Perhaps you are correct. I was intending to use the error type in ReseedingRng to return reseeding errors, but decided against doing that, which means normally the error type will be Void.

[burdges]

I've actually forgotten our long discussions on PRNGs throwing errors, but maybe we concluded they should never do so if you cannot seek around the stream, thus making panicing okay. I brought it up here just because BlockRng seems so low level.

[dhardy]

If we do decide to merge #307 then I think we should definitely merge this, otherwise I'm not really sure.

I'm also not quite sure about adding the Void error type or why std's From conversion doesn't appear to work.

[pitdicker]

I know an opinion without arguments is not worth much, but I am all for the somewhat simpler system we have now, and don't see much advantage in making Error an associated type.

Just to make sure, what are the advantages? I can think of only one: that you can spell out through the type system that some RNGs can never error.

[dhardy]

Without #307 this has less merit. I'm going to go with @pitdicker's suggestion that since most PRNGs are infallible anyway it adds extra complexity for very little expected benefit.