Should pi be available as `f32::PI`, etc?

[pommicket]

Should the constants in std::f32::consts (and std::f64::consts) be made also available as associated constants (cf f32::NAN)?

f32::PI is much nicer to type & read than std::f32::consts::PI. I don't see why mathematical constants need to be relegated to such a long path ):

(There's always the possibility of doing use std::f32::consts as f32c; in every file but that's kind of annoying...)

I know you wouldn't be able to do use f32::PI; so perhaps std::f32::consts shouldn't be deprecated/removed like std::u32 is planned to be, & I don't know how people feel about having the same constants defined in multiple places (maybe that's one reason for not doing this).

Also: for what it's worth the popular crates half and fixed already do this for their types.

[josh]

@pommicket

I know you wouldn't be able to do use f32::PI

I would love to see that fixed.

[faern]

I would love to see all the mathematical constants available directly on the float types! This has been brought up in the past, but was shot down in the RFC that moved some float constants from the modules to the type: https://github.com/rust-lang/rfcs/pull/2700

But maybe people have changed their minds since then?

[kornel]

The reason seems to be that Rust doesn't support useing associated constants, so:

use std::f32::consts::PI; // works
use f32::PI; // not supported

short(PI);

[pommicket]

By the way I made an RFC for this: RFC for associated mathematical constants by pommicket · Pull Request #3418 · rust-lang/rfcs · GitHub