enable std by default

[gnzlbg]

Closes #193.

[alexcrichton]

Er hang on before we do this, I don't think we want to do this by default, gimme a few hours though to get to a computer

[gnzlbg]

@alexcrichton take your time, we should clarify this before the next release but we don't need to do it exactly now. It doesn't block any other work either AFAICT.

[alexcrichton]

Ok I've got some more time now!

So in general enabling a default feature is very difficult to turn off. Cargo will union all features requested for a crate and the crate, when depended on, will by default enable all default features. This means that for you to actually disable the std feature of stdsimd it will require everyone to disable the std feature.

If stdsimd is a widely depended on crate (for example like libc at the extreme) then it's basically impossible to turn off default features as someone will have forgotten that they don't actually need it and they'll leave the default features activated (even though they probably don't need it). If stdsimd is not widely depended on, however, then this probably doesn't matter much as it's far easier to audit dependencies and remove any dependency where we find it.

So in that sense I just wanted to be sure to clarify this and make sure we're making the decision that "yes, stdsimd isn't that widely depended on so we can have default features". I personally think this is a reasonable conclusion (stdsimd is relatively niche and meant for "power users"). Additionally this will be moot when we integrate into libstd... somehow at least!

All in all sorry for the delay! Do y'all agree that this won't be super widely depended on? If so, let's merge!

[gnzlbg]

Do y'all agree that this won't be super widely depended on?

The answer to this question depends on how we want to ship stdsimd; maybe @alexcrichton can clarify this.

Do we need to build stdsimd twice, one for core and one for std ? If so having a std feature makes our lives easier because we can do everything in a single crate, and then by using std we just switch how we build it for core and std. In this case, std will be widely depended upon, and I would rather not enable it by default.

OTOH if we want to have a core-only library, and then a std-module that depends (and links) the core one, then it makes more sense to have these as different crates. In this case we should remove the std feature before the next release, by removing the dependency on std::os::raw, and splitting the ARM run-time detection support into a different crate. This is harder for us, because the std component depends on the core one, but for testing the core one we need the std one as a dev dependency to do run-time feature detection :/

[alexcrichton]

Ideally we'll have this crate split into two halves and one gets compiled into libcore and the other gets compiled into libstd. Precisely how that works though is... probably interesting. In any case though I don't believe we'll want to recompile everything twice

[gnzlbg]

Ideally we'll have this crate split into two halves and one gets compiled into libcore and the other gets compiled into libstd.

If we do it like that one crate will be no_std and the other crate will require std unconditionally.

So we can add std as a default feature for now, but ideally we should switch to this two crate model before the next release and remove it.

[gnzlbg]

I am closing this since it is superseded by #197 which removes the need of having std as a feature at all.