MSRV bump, module changes

[newpavlov]

Note that with this PR getrandom by default will not use anything from std anymore, so it will be possible to implement #4.

[dhardy]

Is there any reason not to use 1.31 as the MSRV? Also you need to update the note in the README.

[newpavlov]

extern crate std; and use std::<..>; in modules does not work on 1.31.0. It fails with "error[E0658]: imports can only refer to extern crate names passed with --extern on stable channel (see issue #53130)". I think we could fix it by moving extern crate std; to lib.rs, but it will add a sizable cfg attribute.

[dhardy]

Fair enough. 1.32 is barely over two months old, but there doesn't appear to be much demand for back compatibility. Perhaps we should not do the same for the main Rand project yet though just in case we need to revert this.

[dhardy]

error[E0468]: an `extern crate` loading macros must be at the crate root
  --> src/wasm32_stdweb.rs:11:14
   |
11 | #[macro_use] extern crate stdweb;
   |              ^^^^^^^^^^^^^^^^^^^^

Can we use Edition 2018 style macro imports?

[newpavlov]

I looks like stdweb does not work nicely with 2018 imports. I think I've worked around it, but ideally I would like to remove stdweb support in favour of wasm-bindgen. IIUC the necessary work on bindgen side is already done.

[dhardy]

Seems like your workaround does the job for now. It may require fixing again later, but both stdweb and wasm_bindgen are being actively maintained and with not so different usage numbers (both somewhat low actually), so IMO we shouldn't abandon either yet.

This is ready for merging then?

[newpavlov]

Yes, it's ready to be merged.

Regarding WASM, I think we should understand how future changes will be handled. Say we publish v0.1 and then stdweb becomes compatible with wasm-bidgen. Or new web/nodejs specific targets will be introduced. The most conservative way will be to publish v0.2 and propagate version bump across other rand crates dependent on getrandom, but I think it will be too much churn. Another approach is to state that both WASM features are experimental and not covered by backward compatibility promise. And the last approach is to move both WASM back-ends to separate crates and tell WASM users to use solution from #4. All three approaches have their own pros and cons, so maybe we should open a separate issue for discussing it.

[dhardy]

I think if both stdweb and wasm-bindgen features are enabled, then only wasm-bindgen will actually be used? So if the two libs become compatible, I don't think that's a problem for us.

As for our implementation, if we choose to deprecate one, we can simply add a stdweb feature depending on the wasm-bindgen crate and implementation, so no problem there either that I can see.