Expose some more functions from libc #25780
Conversation
|
r? @brson (rust_highfive has picked a reviewer for you, use r? to override) |
|
r? @aturon I don't know whether these are desired - some of them have definitely been removed in the past. At the least they need be marked unstable before entering the tree - you can see the unstable attribute syntax elsewhere in std. |
alexcrichton
added
the
T-libs-api
| #[unstable(feature = "std_misc", | ||
| reason = "unsure about its place in the world")] | ||
| #[inline] | ||
| pub fn rem(self, other: f32) -> f32 { |
There was a problem hiding this comment.
I believe that this is already exposed through the Rem trait (LLVM lowers % operations to calls to this function I believe).
|
This is an area where we may not want to follow the conventional C names and instead choose a more rustic/descriptive name as well. |
|
Thanks @alexcrichton and @brson . I'm totally open to suggestions on names. |
| /// | ||
| /// assert!(abs_diff <= f32::EPSILON) | ||
| /// ``` | ||
| #[unstable(feature = "std_misc", |
There was a problem hiding this comment.
Could these functions also be introduced under a new feature name? We're trying to cut down on the number of members of the std_misc feature, and something like float_extras may work well here.
|
FWIW, the names of the methods currently available are a bit of a mixed bag. For the most straightforward cases, we tried to hew toward Rust-style names, but for more obscure things like |
|
Thanks all. The doc tests are not passing yet, working on it. |
|
@alexcrichton the doc tests were not passing when I last tested this on my box. I did not have time to debug this further. Is it okay to merge in this state? |
|
@bors: r- Ah no those will need to be fixed before merging. |
|
Guessed so. Please give me some time to get back to this. |
|
We actually had some time to discuss this in triage today and the conclusion was actually to not merge this at this time. The current bindings to libm are unfortunately not the best thought out and it's not clear that we actually want to continue providing them. At this time we think that stemming the flow of new bindings to libm is the best route to take for now while we take some time to work out a concrete story for the functions here. I'll open an associated issue for this, but for now I'm going to close this. Sorry for the delay! |
#18271
I noticed this issue was moved to the rfc repo after I opened the PR. Should this be closed now and prioritized later?