Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Make std a feature, using #![no_std] otherwise #16

Closed
cuviper opened this issue Dec 19, 2017 · 2 comments
Closed

Make std a feature, using #![no_std] otherwise #16

cuviper opened this issue Dec 19, 2017 · 2 comments
Assignees
@cuviper
Labels
breaking change enhancement
Milestone
num-traits-0.2

Comments

@cuviper
Copy link
Member

cuviper commented Dec 19, 2017

cc rust-num/num#216

This was attempted before in rust-num/num#296, then yanked per rust-num/num#297. It's a breaking change to move functionality behind a feature flag.
This was referenced Dec 19, 2017
Closed
Closed
Closed
Closed
@cuviper cuviper added this to the num-traits-0.2 milestone Dec 20, 2017
@cuviper
Copy link
Member Author

cuviper commented Dec 20, 2017

There was also commit 415a9bf in the next branch that cleaned up sign behavior under no_std.

@cuviper cuviper mentioned this issue Dec 23, 2017
Closed
@cuviper
Copy link
Member Author

cuviper commented Dec 27, 2017

As pointed out in rust-num/num#360, this is probably a good candidate for the semver trick. In num-traits-0.2 we can make the feature change, then re-export everything with std enabled in 0.1.

@cuviper cuviper mentioned this issue Dec 31, 2017
Closed
@cuviper cuviper mentioned this issue Jan 11, 2018
Merged
@termoshtt termoshtt mentioned this issue Jan 12, 2018
Closed
@cuviper cuviper mentioned this issue Jan 13, 2018
Merged
@cuviper cuviper self-assigned this Jan 31, 2018
@cuviper cuviper mentioned this issue Feb 1, 2018
Merged
bors bot added a commit that referenced this issue Feb 2, 2018
@bors
Merge #30
afa81f8 
30: Re-introduce the std feature r=vks a=cuviper

This is a port of @vks's rust-num/num#296, but without the feature-toggled changes to `Float`.  Now `Float` and the newer `Real` are completely dependent on having `std` enabled.  In the future we can consider adding separate more-limited float/real traits that can work without `std`, like the `BaseFloat` that was originally proposed in the former PR.

This is a breaking change with a bump to 0.2, since anyone currently using `default-features = false` will lose functionality.  The actual API is otherwise unchanged, so my plan is to employ the "semver trick" -- publishing a new num-traits-0.1 that re-exports everything from 0.2 (with `std`).  Thus all `num-traits` users should remain compatible even if they mix 0.1 and 0.2.

Closes #16.
@bors bors bot closed this as completed in #30 Feb 2, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@cuviper cuviper

Labels
breaking change enhancement
Projects
None yet
Milestone
num-traits-0.2
Development

No branches or pull requests
1 participant
@cuviper