Add tau to the f64 and f32 constants.

[x13machine]

Maybe even phi. I dunno

[nagisa]

τ is available as FRAC_2_PI Err, wait no. I’m pretty sure we used to have 2*π, but seems like we don’t anymore.

[huonw]

Tau was proposed (and not landed) in rust-lang/rust#15248.

τ is available as FRAC_2_PI

(Tau is 2 pi, not 2/pi.)

[cpeterso]

FWIW, TC39 rejected a proposal to add Math.TAU to ES6:

https://esdiscuss.org/topic/math-tau
https://esdiscuss.org/notes/2014-07-31#5-1-math-tau

[insaneinside]

👎 Rust is supposed to be a practical -- not esoteric -- language. If I have to be a mathematician (or resort to using a search engine) to know what you mean by "tau" and "phi", it's probably not appropriate for Rust.

[kbknapp]

I'd +1 this. I get the comments above, but what does it hurt including a few "common" math constants?! Does anyone seriously subtract points from a PL for having too many math constants? The argument about it not being known is silly IMO because the samw could be said about literally anything in std which isn't familiar to the programmer. They'll either gloss over it or if interested do some quick googling.

...full disclosure I've got a project where I could use this 😉

[1011X]

Seems to me that the main sources of friction for implementing something like TAU are:

• Wanting to keep PI and related constants as the only ones used for equations related to angles. Why? Probably tradition, since they already know it and don't have to learn anything new. In my experience though, using a tau constant made equations simpler, and easier to reason about, e.g. half-tau is half a circle, or 2 tau is 2 whole rotations.
• Waiting to see if tau gets traction in other languages. But if no one implements it, how will it? At least if it's implemented, the user can find it and choose one or the other.

There's also the "too many constants" argument, but compared to the size of the standard library, a few more constants is barely anything.

Either way, there's clearly a desire from people to include TAU, so the best decision would be to have both TAU and PI, and let them choose which to use. In the end, it's purely a personal choice.

Regarding PHI: it would certainly be useful in visual design.

[x13machine]

I don't understand why having a lot of constants would be a problem. It's not like anyone would have to maintain them. We also don't have a disk space shortage. (apologies to people still using floppy disks)

[insaneinside]

TAU I can at least understand, but in my opinion PHI is a very domain-specific symbol and should probably be bikeshed in a separate discussion.

[1011X]

I think that's fair. Let's stick to discussing TAU.

[tbu-]

Tau is pretty niche, it doesn't even have its own Wikipedia article. https://en.wikipedia.org/wiki/Turn_%28geometry%29#Tau_proposals

[x13machine]

https://www.youtube.com/watch?v=83ofi_L6eAo

[ticki]

@x13machine Oh, please no.

[nagisa]

I wanted to point out that we’re arguing about the wrong thing and what this whole discussion should’ve been about all along is addition of constant ::std::f*::consts::2_PI instead.

That being said, 2 * std::f*::consts::PI is as accurate as it gets down to the least significant bit and should be const-folded by the compiler even in the no-optimisations mode, so I do not see much purpose in adding the constant.

[Diggsey]

I really hope we get a 2_PI or TAU constant - regardless of the arguments for/against Tau, it's IME a far more useful constant than many of the others. You can write 2*PI but in an already complex formula it can make the code harder to understand. For example, when you have other constant factors in front, it's tempting too multiply them out, and this disguises the original meaning of a "full turn".

WRT 2_PI vs TAU I'm more in favour of TAU because it doesn't contain a number and so interferes less when reading a formula, and because I find the arguments of the Tau manifesto far more convincing than the Pi manifesto, which seems to miss the point entirely.

[bluss]

π or 2π is not exactly going to go away any time soon. A sensible proposal would be to add either just PI_2 or both PI_2 and TAU.

[johnthagen]

FWIW, Python recently added math.tau.

[porky11]

Adding 2_PI or similar seems useless, since 2*PI looks clearer and can also be calculated at compile time very fast.

[burdges]

Happy Pi Day! ;)

[Dylan-DPC-zz]

Closing this as it is easier to create a tracking issue when the rfc is accepted

[Dylan-DPC-zz]

Closed the rfc instead of the issue 😂

[m-ou-se]

FWIW, Python recently added math.tau.

Seems like it's gotten quite popular in Python since then: https://github.com/search?l=Python&q=%22math.tau%22&type=Code

[m-ou-se]

This issue has been open for almost four years now. What needs to happen to move it forward? Does the library team have to discuss this? Does it need more motivation or support first, and if so, in what form? Something else?

[CryZe]

This seems like a minor thing to the point where you could probably just send a PR and the libs team then decided whether to merge it or not.

[m-ou-se]

Okay, sent rust-lang/rust#66769.