nostd feature

[roblabla]

Hey, it'd be nice if this crate could support nostd. My use-case is that I'd like to use this crate on a platform that doesn't provide an std, but still has an allocator (which I think is the only required bit for most of the crates in here ?). Is this something you'd be willing to accept PRs for ?

[cuviper]

We tried this already for num-traits -- #296, then had to yank it -- #297. It was gating Float from no-std because of missing trig functions, IIRC, but it's a breaking change to add a #[cfg(feature=...)] on something that was formerly unconditional. If we can find a way to implement no-std num-traits without any loss of functionality, I guess that would be OK. Refer now to rust-num/num-traits#16.

(I don't think a breaking semver bump to num-traits is likely any time soon. It's so much of a public dependency that I expect that would be very painful for everyone to migrate.)

It might actually be OK to do no-std in num-bigint (with alloc::vec::Vec) before all that, if it doesn't implement num-traits in that case. Other crates would be a lot harder without the traits.

[cuviper]

I'd like to use this crate on a platform that doesn't provide an std, but still has an allocator

Just curious, if you can share, which platform is that?

[roblabla]

Currently running rust on an ARM microcontroller, where I provide my own allocator. I'm not sure why adding a feature would be a breaking change. If it's on by default, surely nobody would notice ?

…

On December 23, 2017 4:21:32 AM GMT+01:00, Josh Stone ***@***.***> wrote: > I'd like to use this crate on a platform that doesn't provide an std, but still has an allocator Just curious, if you can share, which platform is that? -- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: #360 (comment)

-- Sent from my Android device with K-9 Mail. Please excuse my brevity.

[hcpl]

It will break crates that use num with no-default-features.

From @cuviper's link's link (servo/euclid#210):

the latest release of num_traits adds a new std default feature. euclid is using no-default features of num_traits, in which Float is not available.

[roblabla]

Well, I can see two solutions then :

• Using a nostd feature instead, that disables std support.
• Using the semver trick to add the feature without splitting the ecosystem.

[cuviper]

Features need to be additive. Otherwise, one crate which uses num-traits/nostd would break any other crate in that build that needed the disabled functionality.

The semver trick might be perfect though. Publish 0.2 with the feature changes, then re-export it with full std support in 0.1.