Floating-point abs() and friends not part of no_std prelude

[eefriedman]

#![crate_type="lib"]
#![no_std]
fn f(x: f32) -> f32 { x.abs() }

error: no method named `abs` found for type `f32` in the current scope
 --> <anon>:3:25
  |>
3 |> fn f(x: f32) -> f32 { x.abs() }
  |>                         ^^^
help: items from traits can only be used if the trait is in scope; the following trait is implemented but not in scope, perhaps add a `use` for it:
help: candidate #1: `use core::num::Float`

It is actually possible to write core::num::Float::abs(x), but I'm not sure that's actually supposed to be legal, and at that point, you might as well just write your own abs() function.

[hanna-kruppe]

That's because the inherent methods are in std. They're defined in libstd/num/f{32,64}.rs. The analogous files in libcore only contain a Float implementation, no inherent methods.

[eefriedman]

Yes, I know that... the exact same situation exists for SliceExt. That isn't the complete story, though: SliceExt is part of the prelude, so the methods are usable.

[hanna-kruppe]

I do not believe Float is in the same boat as SliceExt. The latter is documented, exposed, and although using it directly would be considered unidiomatic (and is unstable), its methods are intended to be widely used and stable. Meanwhile, Float and all its methods are not only unstable but also doc(hidden), and AFAIK not even remotely intended to be stabilized or otherwise normalized.

In other words, I deliberately did not address Float before because as far as I care it might as well not exist. It's an implementation detail, and the compiler's suggestion to use it a diagnostic issue. Some float methods should probably be available in core (though this is tricky since many useful ones currently delegate to libc), but Float is not the vehicle by which they should be exposed.

Edit: Huh, the tracking issue talks about both of these traits (and others?) as being in the same situation, so maybe my impression was wrong. Still, I find some factual differences in their API which I edited into the first paragraph.

[eefriedman]

core::num::Float::abs is stable, for what it's worth. The whole situation is kind of messy, though.

(though this is tricky since many useful ones currently delegate to libc)

We moved all of those to libstd; libcore just contains the ones which are implemented natively in Rust.

[hanna-kruppe]

Obviously libcore doesn't contain those which require libc, but for stabilization one would probably want a more sensible criterion for what's in core other than "everything that can be with the current implementation".

[Mark-Simulacrum]

So I think this is effectively now the tracking issue for core_float. Is that correct?

Edit: Since #27702 was closed in favor of #27701, which is also closed.

[kennytm]

This should be closed? Equivalent to #39473.

[Mark-Simulacrum]

Yes, I'm going to close this as equivalent to #39473, that is, the path here is to move to not using libm intrinsics for these functions.

[lvella]

The current open issue for this is #50145.