Should the "custom" feature take precedence over the "js" and "rdrand" features?

[josephlr]

Currently the "custom" feature is last in our precedence order for selecting implementations. The original idea behind this was to ensure that a crate couldn't (accidentally or intentionally) change the RNG source for a program.

However, we've gotten multiple issues that might be solved by reevaluating this rule.

Some folks want to use a custom implementation even when rdrand is enabled #230

Sometimes folks are targeting wasm32-unknown-unknown, bu they are not targeting the web, but their deps are enabling the js feature. #342 CC: @nickray

I would propose the following new precedence order:

• If on a supported target, use the standard implementation
• If custom feature is enabled, use the custom implementation
• If on x86 and rdrand is enabled (or on SGX), use the rdrand implementation
• If on wasm32-unknown-unknown and js is enabled, use the wasm-bindgen implementation.

[newpavlov]

And what will happen when someone sets the custom feature (e.g. by erroneously adding a custom crate to [dependencies] instead of [dev-dependencies])? Enabling rdrand or js outside of binary crates is a clear misuse of the features, so such libraries should be fixed either way. Also, wouldn't it be technically a breaking change?

All in all, I am not strongly against the proposed reordering, but I can't say I like it either.

Ideally, we should use configuration flags instead of crate features (i.e. #[cfg(getrandom_rdrand)] instead of #[cfg(feature = rdrand)]). But my guess is that users who compile code for Web WASM will not be happy with such change...

[newpavlov]

Maybe we should raise compilation errors if more than one feature is used out of js, rdrand, custom list? We specify that those features should not be enabled in library crates outside of tests, so it should not happen in practice and if it does, then someone misuses the features.