Tracking issue for core::{f32,f64}::consts::TAU

[m-ou-se]

Tracking issue for the TAU constant added in #66769.

---

Before stabilization:

• Confirm that the numeric values we have are accurate.
• Decide whether we are comfortable using the name TAU or instead a longer but more widely accepted name like TWO_PI could be better.
• Wait for RFC that moves math constants from std::{f32,f64}::consts::.. to {f32,f64}::.. ?

[tesuji]

I don't think we should land this constant.
Acording to wikipedia:

It has also been used in at least one mathematical research article,[33] authored by the τ-promoter Peter Harremoës.[34]

However, none of these proposals have received widespread acceptance by the mathematical and scientific communities.[35

[qnighy]

Naming aside, such a constant would be definitely useful. 2π couples tightly in the mathematical notation where 2.0 * PI doesn't, like x / (2.0 * PI).

[m-ou-se]

• Confirm that the numeric values we have are accurate.

Sources:

• https://oeis.org/A019692
• https://www.wolframalpha.com/input/?i=2+*+pi
• https://tauday.com/tau-digits

Can someone other than me verify that I copied the number properly?

Edit: Done by dtolnay.

[m-ou-se]

• Decide whether we are comfortable using the name TAU or instead a longer but more widely accepted name like TWO_PI could be better.

Unfortunately, the constant TWO_PI or 2_PI has been used in several programming languages for 2/π instead of 2π:

• https://www.gnu.org/software/libc/manual/html_node/Mathematical-Constants.html
• https://ziglang.org/documentation/master/std/#std;math.two_pi
• https://dlang.org/phobos/std_math.html#.M_2_PI

Although I agree that having TWO_PI or 2_PI refer to anything other than 2π makes absolutely no sense, I do think it might cause confusion because of the existing practice.

[andrewrk]

* https://ziglang.org/documentation/master/std/#std;math.two_pi

Our std lib is still unstable, we're willing to change it to a more canonical, sensible API if you wanna lead the way here :)

[m-ou-se]

Regardless of what C or other languages call their constants, I'd name this one TAU and not anything with PI. In the past five years, quite a few people have asked for a TAU constant. Looking at the amount of thumbs-ups at for example #66769 or rust-lang/rfcs#1486, it seems quite some people are in favour of TAU.

[adamnemecek]

Yeah, TAU is way, way better than TWO_PI.

[andrewrk]

ziglang/zig@2ab7f31

[m-ou-se]

Can we make a decision for the name TAU based on the comments above? Or do we need more time/experience/comments/opinions/bikeshedding/something before we can make a decision?

[jonas-schievink]

Normally we leave new library additions unstable for a few release cycles. This one seems very trivial though. In any case, some libs team member has to kick off FCP to get this stabilized, and they might not have the capacity at the moment.

[LukasKalbertodt]

One thing worth discussing before stabilizing TAU, is whether or not we want to move all constants in std::{f32,f64}::consts to be associated consts of f32/f64. This is mentioned in the alternative section of RFC 2700. This issue is tracked and discussed here. If we indeed want to move to associated consts, it would be a good idea to not stabilize tau as normal constant first.

[m-ou-se]

Only things like MIN have been moved to associated constants, and there seem to be no plans yet to move mathematical constants like PI to associated constants as well. (RFC2700 explicitly didn't suggest moving the math constants.) I'd prefer to stabilize TAU without waiting for a possible RFC to show up which might move them.

[faern]

I have never coded with radians in Rust before, but I started a few weeks back and I instantly defined const TAU: f32 = 2.0 * PI; everywhere. So having this constant in the standard library feels really relevant to me. And I like the name.

However, I'm really really in favor of moving the math constants to associated constants. I liked the more full on version of RFC 2700 that is linked above. Because now I have to look at my import/const define section at the top of the file to know what resolution I have available. And it's cumbersome to use 32 bit and 64 bit resolution math in the same module. As a result, I'm only in favor of stabilizing std::fxx::consts::TAU if it does not make people less in favor of deprecating the entire std::fxx::consts module soon/later.

[LukasKalbertodt]

I don't have a hard opinion on whether math constants should live in consts or on the type, I think. But I was convinced by @m-ou-se's reasoning: we shouldn't wait with stabilizing TAU just because in the future we maybe want to move the constants to a different location. One additional constant in f32::consts won't make a difference.

@rust-lang/libs Does anyone of you want to start an FCP? From what I can tell, all questions have been resolved and this has been cooking on nightly for several cycles already.

[Amanieu]

@rfcbot fcp merge

[rfcbot]

Team member @Amanieu has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Amanieu
• @SimonSapin
• @dtolnay
• @sfackler
• @withoutboats

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[m-ou-se]

@SimonSapin @sfackler @withoutboats Friendly ping. Can this be stabilized before the next release?

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

The RFC will be merged soon.