ahash features are non-additive about ahash

[tkaitchuck]

In other words, the feature compile-time-rng means the lack of randomness.

It does not. You misunderstand the design. The flag merely indicates the source of the seed for the generator of the random keys used in the maps. If your map is created by HashMap::default() it will always (regardless of flags) have a unique set of keys. So even if there were no other flags anywhere on your path, each hashmap would have a unique set of keys.

You can alter this behavior, but not using flags. See the documentation here:
https://docs.rs/ahash/0.8.1/ahash/random_state/struct.RandomState.html
and here:
https://docs.rs/ahash/0.8.1/ahash/random_state/trait.RandomSource.html

[schungx]

I have recently been hit by this.

I have specified default-features = false and compile-time-rng for ahash, only to find that it didn't work. After a lot of trouble-shooting, I discovered that another dependency crate has ahash deep down its dependency tree (I used cargo tree to find it), and that ahash has default. Which means the default features get merged into my ahash.

There is no easy solution to this. Even renaming the crate to, say, ahash2 doesn't prevent this merging of features. It must be separated into different source repo's in order to bypass this.

[tkaitchuck]

I am not sure how this can be observed externally, or in what sense it violates policies.

To clarify the difference between either of the flags being set or neither is just where the fixed random seeds come from. If runtime-rng is on they are statically initialized to values from getrandom. If compile-time-rng is enabled they are from constants embedded at compile time. If neither are enabled, fixed constants are used. There are two apis which are enabled if either compile-time-rng or runtime-rng are enabled. So if runtime-rng is turned on by another package, there is no change to the API surface.

Depending on which flag is set it will either use getrandom or a random constant for the fixed seeds. But that is an internal implementation detail that can't be observed in any way. (How could you tell the difference between two sources of random numbers?)

This could be noticed because getrandom is downloaded a dependency. But that would happen no matter what if there is another package depending on the runtime-rng feature.

So, @schungx I am not sure what you mean by "only to find that it didn't work". What didn't work?

In theory if both flags are enabled I could have the compile-time-rng generated fixed constants in the code, but then at runtime immediately replace them with values from getrandom. But what would be the point? It would just embed random constants into the binary that are never used.

[schungx]

So, @schungx I am not sure what you mean by "only to find that it didn't work". What didn't work?

What I mean is that the features are not strictly additive. As one overrides the other. That's not additive.

In other words, the feature compile-time-rng means the lack of randomness. Remember the lack of functionality is by itself a functionality, if that lack is depended upon. You cannot merge a "minus", so that makes it non-additive.

I have seen a crate being very careful to only specify compile-time-rng because it needs one and won't work without a random generator. Yes, this is a niche use case.

However, some dependency down the tree also uses ahash with default, which is runtime-rng. This overrides the other feature when cargo merges them.

So that crate no longer works properly and this is very hard to debug. In fact, many non-additive cargo feature issues are hard to debug .