related: #80 (comment)
So, we could stop exporting rand. Not sure if it's a good idea.

... and depends on the outcome of rust-bitcoin/rust-bitcoin#206

What would this increase the minimum rustc version to?

according to their README, "Since version 0.5, Rand requires Rustc version 1.22 or greater." So we can't do this if we stick to 1.20. rust-bitcoin/rust-bitcoin#210

So as rust-bitcoin requires 1.22 now, there is nothing that prevents us from taking this update.

Do we want to keep exporting rand? If we don't export, this will break downstream code but we'll break that code probably anyway due to update. It's just possible that we'll need to export it again in a few months when rand upgrades requires a newer Rust again...

What do you mean "we'll need to export it again"? We should keep exporting rand so that users don't have to manually keep track of what version dependencies we're using and change boilerplate code in response to it.

Also, importantly, if users want to use their own version of rand but are required to have access to rand 0.6 types for use with rust-secp, the only simple way to get it is if rust-secp re-exports it. Then they can use rand for their stuff and secp256k1::rand for our stuff.

Yes, so we should just keep it.

@huitseeker Thanks for your PR again! So this requires us to bump to to rust 1.22.0. Can you additionally

• bump 1.14.0 to 1.22.0 in https://github.com/rust-bitcoin/rust-secp256k1/blob/master/.travis.yml#L8,
• revert 9a4961c, and
• bump the minimum Rust version in the README.md?

(or alternatively, make sure that we can make those changes
https://help.github.com/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork/ )

I could have sworn @sgeisler had diagnosed the Windows failure and merged this. Anyway, @real-or-random any thoughts on whether we should include the reversal of 9a4961c?)

I don't think that the changes to BadRng are necessary:

• next_64 is fine but we could also just stick to next_u32.
• There are helper functions provided to implement the other functions: https://docs.rs/rand_core/0.3.1/rand_core/impls/index.html. So we don't need our own implementation of fill_bytes and would not rely on transmute.
• Also try_fill_bytes can just implemented using Ok(fill_bytes(...), which is also just a single line of code.

I mean in the end this is just a debugging Rng, so there is nothing wrong with changing it but I feel we should not use transmute unless we really need to.

For the Windows build: Yes, that's unfortunate, The reason is that the cc crate uses a function on Windows, which requires Rust 1.27. (https://doc.rust-lang.org/std/option/enum.Option.html#method.filter). So you're right, we shouldn't revert 9a4961c but instead change the comment in the Travis config to explain that cc is the reason for disabling Windows builds on 1.22, and note in the README that the restriction to 1.22 is only for the Linux target.

With those two points addresses, this is good to merge for me but I'd like to see an ACK from everybody due to the rust version bump, not only on Linux to 1.22 but in particular on Windows to at least 1.27 (maybe it's in fact even higher, who knows...). @TheBlueMatt? @apoelstra?

Ok what I'm saying is wrong. We're not bumping on Windows; I guess the build fails already now. But it still will be good to hear your thoughts.

I'll make a few changes along the lines of your suggestions later today.

Thanks for the updates! And sorry that I'm so slow at responding here.

Hm, to be honest, now that I see that we need another rand_core then (which is needed by rand anyway though) I'm not convinced anymore that what I suggested is the best approach. But before I ask you to do even more changes and create even more back and forth, I'll suggest waiting for @apoelstra and @TheBlueMatt's opinion on that issue and on the PR in general.

I'm happy with a 207acef like style where the relevant rand_core functions are pulled within the PR. Just let me know @apoelstra @TheBlueMatt (making a few fixes at the moment, test results are less bad than on master).

concept ACK. I think we need an analagous PR for rust-bitcoin which is using rand 0.3 (lol!!) to update to 0.6 or maybe just drop it.

I'm a bit apprehensive about these new default functions...or rather, about the new functions that they call. I'm unsure whether the library will interact well with instances of these types which are all-bits-zero. I'm OK with this PR but it may be that a future PR removes these things because they can be used to trigger assertation failures or something.

@apoelstra

• will drop min-rust-version reason as suggested in Bumps rand to 0.6.X & associated updates #92 (comment)
• the new() functions are already public and untouched by this PR. The Default impl materializes the existence of this public no-argument constructor (and pleases clippy). Happy to tweak.