Conversation
This is a port of @vks's rust-num/num#296, but without the feature- toggled changes to `Float`.
We don't have implementations for many of the methods in `no_std`. It's hostile to external implementors if some trait methods are conditional on a feature, as that feature could be added by anyone in a dependency tree. Instead, let's just live without these traits for now.
|
cc @termoshtt, since you had opened #24 before. |
|
If I understand this correctly, this is a regression for |
|
@vks, I wouldn't call it a regression. The previous But yes, I've come around that |
With pleasure, but it will be a breaking change if we introduce |
Yes, it needs to be independent, even if we did it right away here. I'm not making any API changes, so I can compatibly re-export everything back to 0.1. The only breaking change is the lost functionality under The |
|
Alright, then everything looks good to me! bors r+ |
|
🔒 Permission denied Existing reviewers: click here to make vks a reviewer |
|
bors r=vks |
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.
Build succeeded |
3 participants
This is a port of @vks's rust-num/num#296, but without the feature-toggled changes to
Float. NowFloatand the newerRealare completely dependent on havingstdenabled. In the future we can consider adding separate more-limited float/real traits that can work withoutstd, like theBaseFloatthat was originally proposed in the former PR.This is a breaking change with a bump to 0.2, since anyone currently using
default-features = falsewill 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 (withstd). Thus allnum-traitsusers should remain compatible even if they mix 0.1 and 0.2.Closes #16.