Cargo features are designed to be additive

[bluss]

Cargo features are designed to be additive (they add features, don't change them in a way that breaks a library). This is evident since cargo automatically uses the union of all requested features in a build.

Consider if App depends on library X that depends on nphysics, and App depends on library Y that depends on nphysics.

If library X selects the f64 feature, this changes how nphysics is compiled for the whole App's build, so Y will not compile (it was written to use f32).

[sebcrozet]

I have the feeling this is a very unlikely scenario (why would an user depend directly or indirectly on nphysics twice but with different precision?) but I agree this is an abuse of Cargo feature system that has to be removed.

I guess the cleanest and most idiomatic alternative is to parametrize everything wrt. the floating-point number type. Now that 2D and 3D are on two different crates, this change should not be too complicated.

[bluss]

Yes I think it will be unlikely, mostly will show up when more than one user is involved of course to induce the lack of coordination. Imagine if library X and Y are separate projects by separate authors.

[sebcrozet]

Yes, lack of coordination, of simply inattention. The most problematic consequence in a similar configuration (where the binary A uses nphysics f64 and depends on a library B that uses nphysics f32) is that compilation errors will show up for the library B instead of on the user code directly. In that case the user might mistakenly assume that the library B is faulty instead of getting that he is simply using the wrong feature.