Recommended usage is impossible to satisfy

[orlp]

The recommended usage section in the README states the following:

Your library MAY provide a feature that will enable "allocator-api2/nightly". When this feature is enabled, your library MUST enable unstable #![feature(allocator_api)] or it may not compile.

This is impossible because of feature unification. Consider there are two crates a and b that depend on allocator-api2. a does not enable the nightly feature, b does. Now a project that contains both a and b will fail to compile, as b turning on the feature flag will also turn it on for a, but a does not contain #![feature(allocator_api)].

This does actually happen in the real world in a large complicated project which ends up depending on hashbrown twice: rust-lang/hashbrown#564. But as more and more crates start using allocator-api2 you don't even need such a complicated scenario.

[zakarumych]

It is easy to satisfy really. Just provide nightly feature if you depend on allocator-api2.

Then in case of large project stumbled on that library being added as dependency without enabling "nightly", large project can add that library as dependency and enable "nightly".

I guess better phrasing for the README would be

Your library MUST provide a feature that will enable "allocator-api2/nightly"

[orlp]

Your library MUST provide a feature that will enable "allocator-api2/nightly"

That's also not satisfactory because this would need to infect the entire dependency chain to work. If not the exact same example is problematic again, just with one extra dependency:

root
   ---> a ---> allocator-api2
   ---> b ---> c ---> allocator-api2

Here b does not know anything about allocator-api2 nor does it want to know, it's just a user of library c, so it does not expose the nightly feature from c. Now if the root crate turns on the nightly feature on a things are broken again.

[zakarumych]

Yes, but can be fixed in root crate, by turning on nightly in c

[orlp]

The root crate does not depend on c, and should not need to care about it or whatever feature flags it uses.

It's just not a reasonable system. Suppose allocator-api2 takes off in popularity and all data structure crates start using it. A root binary crate now might have to add dozens of nightly feature flag propagations for all kinds of dependencies of dependencies (or even further down the dependency chain) that it truly does not care about. And that is after encountering mysterious "enable feature(allocator_api)" errors that in no way point to the issue being a non-propagated nightly flag to a dependency-of-dependency.

[zakarumych]

Yes, but only if they want to build on nightly and enable "nightly" features in at least some of their dependencies that reaches allocator-api2.

I would love to be able to enable lang features based on features enabled in dependency alone. Without special feature enabled for the crate.
Unfortunately it doesn't work like that.

So enabling "nightly" in transitive dependencies root crate doesn't care about is the lesser evil.
Other solutions I found are worse.

Please share if you know how to make it work without such friction.