no_std does not impl sqrt for f32 and f64

[CasualX]

I tried the following code (compiled as a library):

#![no_std]
pub trait Float {
    fn sqrt(self) -> Self;
}
impl Float for f32 {
    fn sqrt(self) -> Self { self.sqrt() }
}
impl Float for f64 {
    fn sqrt(self) -> Self { self.sqrt() }
}

I expected to see this happen: The above code working and calling the correct sqrt function.

The core docs for the f32 primitive type 404s and unlike the integer types does not contain a link to f32's primitive type info page.

Instead this happened:

warning: function cannot return without recurring, #[warn(unconditional_recursion)] on by default
  --> src\unit.rs:58:2
   |
58 |    fn sqrt(self) -> f32 { self.sqrt() }
   |    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
note: recursive call site
  --> src\unit.rs:58:25
   |
58 |    fn sqrt(self) -> f32 { self.sqrt() }
   |                           ^^^^^^^^^^^
   = help: a `loop` may express intention better if this is on purpose

warning: function cannot return without recurring, #[warn(unconditional_recursion)] on by default
  --> src\unit.rs:61:2
   |
61 |    fn sqrt(self) -> f64 { self.sqrt() }
   |    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
note: recursive call site
  --> src\unit.rs:61:25
   |
61 |    fn sqrt(self) -> f64 { self.sqrt() }
   |                           ^^^^^^^^^^^
   = help: a `loop` may express intention better if this is on purpose

Is this intended?

Meta

rustc --version --verbose:

rustc 1.14.0 (e8a012324 2016-12-16)
binary: rustc
commit-hash: e8a0123241f0d397d39cd18fcc4e5e7edde22730
commit-date: 2016-12-16
host: x86_64-pc-windows-msvc
release: 1.14.0
LLVM version: 3.9

[nagisa]

Yes this is intended I think. sqrt() depends on libraries in platform in some cases and the whole point of core is to not depend on those.

[durka]

@nagisa the implementation of f32::sqrt and f64::sqrt in std seem to just call intrinsics.

[FenrirWolf]

From what I understand, many of those intrinsics get lowered to functions whose definitions usually live in libm.

[nagisa]

What @FenrirWolf said is correct.

[CasualX]

That's unfortunate but understandable.

[durka]

Maybe we could increase granularity by moving that kind of stuff to a libmath crate that pulls in libm?

…

On Feb 2, 2017 19:45, "Casper" ***@***.***> wrote: That's unfortunate but understandable. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#39473 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAC3n1m10X0xCE3N_xkE9saa3Bccpf7Yks5rYnixgaJpZM4L1t4b> .

[FenrirWolf]

Better yet would be implementations of those functions in Rust, similar to the compiler-builtins crate for compiler-rt intrinsics. There is a work-in-progress port of openlibm with this goal in mind.

[anatol]

@FenrirWolf big plus from me. math functions like those defined in libm can be fully implemented in Rust. There is no strong reason to link to libm C library.

[nagisa]

There’s no strong reason to include these in no_std builds either – you can link to software impls yourselves just fine by depending on a crate like math.rs or the already mentioned m.

[anatol]

@nagisa thanks for the pointer to your math.rs crate. It looks like it is the most complete math functions implementation in Rust.

For me it would make a lot of sense to replace existing Rust libm-based implementation with yours from math.rs. Having math library implemented fully in Rust is a great step towards C-free libstd.

[Mark-Simulacrum]

I propose that we close this issue since this is something that is intentional for now; should we ever move to Rust implementations of math functions, most likely all functions on f32/f64 should be reevaluated for inclusion in core. cc @rust-lang/libs

[CasualX]

I completely forgot about this issue! I agree with Mark, the subject seems settled that for now this is expected behaviour due to how core works.

[jhpratt]

Any updates on this? Documentation at a minimum would be great, since it's a very odd issue to run into given the present error message.

Some of the functions, like .abs(), .signum(), etc. seem relatively trivial to rewrite in Rust. Is this something that is desired? I'd be up for a PR if so.

@Mark-Simulacrum?

[Mark-Simulacrum]

This is pretty hard -- I don't have a link handy, but there are a bunch of considerations that need to go into doing this correctly. I believe some folks are working on it though... I recall a PR or two flying by in the past couple weeks.

[lvella]

The current open issue for this is #50145.