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.