Change:
/// The full circle constant (τ) /// /// Equal to 2π. <del> #[unstable(feature = "tau_constant", issue = "66770")] </del> <ins> #[stable(feature = "tau_constant", since = "1.47.0")] </ins> pub const TAU: f64 = 6.28318530717958647692528676655900577_f64; /// π/2

Discussion:
Tracking issue for the constant in . Before stabilization: [x] Confirm that the numeric values we have are accurate. [x] Decide whether we are comfortable using the name TAU or instead a longer but more widely accepted name like TWO_PI could be better. [x]
We only open tracking issues after an RFC is accepted. Thanks!
asked me to open this tracking issue in
I don't think that's how the process is supposed to work at all but I'll defer to him (and I saw this before I saw that)
We've never required RFCs for simple libstd additions like this, so opening this tracking issue seems fine
I don't think we should land this constant. Acording to #Tauproposals):
Naming aside, such a constant would be definitely useful. 2π couples tightly in the mathematical notation where doesn't, like .
Sources: Can someone other than me verify that I copied the number properly? Edit: Done by dtolnay.
Unfortunately, the constant or has been used in several programming languages for 2/π instead of 2π: ; Although I agree that having or refer to anything other than 2π makes absolutely no sense, I do think it might cause confusion because of the existing practice.
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 :)
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 or , it seems quite some people are in favour of TAU.
Yeah, TAU is way, way better than TWO_PI.
Can we make a decision for the name based on the comments above? Or do we need more time/experience/comments/opinions/bikeshedding/something before we can make a decision?
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.
One thing worth discussing before stabilizing , is whether or not we want to move all constants in to be associated consts of /. This is mentioned in . This issue is tracked and discussed .

If we indeed want to move to associated consts, it would be a good idea to not stabilize tau as normal constant first.
Only things like have been moved to associated constants, and there seem to be no plans yet to move mathematical constants like to associated constants as well. (RFC2700 explicitly didn't suggest moving the math constants.) I'd prefer to stabilize without waiting for a possible RFC to show up which might move them.
I have never coded with radians in Rust before, but I started a few weeks back and I instantly defined 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 if it does not make people less in favor of deprecating the entire module soon/later.
I don't have a hard opinion on whether math constants should live in or on the type, I think. But I was convinced by 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 won't make a difference. 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.
fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [x] [x] [ ] [ ] 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 for info about what commands tagged team members can give me.
Friendly ping. Can this be stabilized before the next release?
:bell: This is now entering its final comment period, as per the .

:bell:
The final comment period, with a disposition to merge, as per the , 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.