If the std and no_std features are enabled at the same time the crate fails to compile

[JSorngard]

This can be seen by running cargo test -F std,no_std.

This is a problem since if a crate depends on crates A and B that in turn depend on special, and A uses special/std and B uses special/no_std the crate will fail to compile since the compiler assumes that features are additive and will only compile a single version of special with both features enabled.

[IvanUkhov]

Yes. One has to be careful to keep on propagating the features in dependent crates to leave the choice up to the end user.

[IvanUkhov]

One could perhaps do the same as what you did in lambert_w:

https://github.com/JSorngard/lambert_w/blob/main/src/elementary.rs#L33

It will favor one over the other if both are enabled. I am just not sure which one should get priority. Spontaneously, I would see that portability (no_std) should take precedence over speed (std).

[JSorngard]

Yes, it's really tricky!
I think the reason I made std take precendence in lambert_w is because if a crate has two different dependencies that in turn depend on lambert_w, and one of them has enabled the std feature (which is disabled by default), that dependency is most likely not no_std compatible anyway, and so letting no_std take precendence in that situation wont make the crate no_std compatible in turn.

[IvanUkhov]

Hm, that is a good point! I have changed my mind.