For example, the Euler-Mascheroni constant γ appears in the formula for
a Bessel function of a second kind of order v [...] With the addition of the Euler-Mascheroni constant, it will become possible to numerically calculate the value of Yv using only the constants presented in this proposal and the C++ 17 standard functions.
So it does mostly boil down to "it's a less-common constant that some people still find useful".
I am really curious what the requirements for inclusion are. In principle it's easy enough to just invent infinitely many constants out of nowhere, or to find 20 vaguely interesting mathematical constants.
I mean, the "right" answer is to have a separate crate from the Rust folks that just defines constants that is free from the release cycle of std. Then people can PR their constants with glee once there is a reason to.
There doesn't seem to be a singular leading math/numerics crate in rust that would be Source of Truth for constant like these for consistent usage by other math crates.
This seems to fill out the current list of consts available in std f32f64.
I would guess that the goal is to reduce churn in the standard library, rather than trying to minimize the number of items in it. Putting something in there makes it really hard to make backwards compatible changes, or to make a sweeping improvements to the API. Even something that sounds simple, like the regex crate, in practice has 19 public structs and lots of subtle documentation, and went through many 0.x versions before reaching 1.0. I don't think the Rust core team has the person-power to have been able to design all of that interface and gotten it right the first time.
austreelis | 6 hours ago
Array windows are great. I don't really mind the potential added bound check of the slice-version, but in almost all instances I was just doing:
anyway, which does add a bunch of noise in simple closures.
mond | 9 hours ago
?. Why? Has anyone here ever used this one in their code? That feels very weird to me, like the opposite of a lean standard library
refi64 | 6 hours ago
It was because it's in C++, for completion purposes:
In turn, C++ added it with P0631:
So it does mostly boil down to "it's a less-common constant that some people still find useful".
mond | 3 hours ago
Oh, alignment with C++ is honestly a great reason for a simple change like this. Why not, sure. Thanks!
addison | 9 hours ago
In Rust, the inclusion of a constant makes zero change to binary size. If we can standardize such values, I am happier for it.
mond | 8 hours ago
I am really curious what the requirements for inclusion are. In principle it's easy enough to just invent infinitely many constants out of nowhere, or to find 20 vaguely interesting mathematical constants.
addison | 8 hours ago
I mean, the "right" answer is to have a separate crate from the Rust folks that just defines constants that is free from the release cycle of std. Then people can PR their constants with glee once there is a reason to.
aleyan | 9 hours ago
mitsuhiko | 8 hours ago
The constant was there also unstable since 2022.
justinpombrio | 6 hours ago
I haven't used it myself, though Wikipedia says it has a bunch of uses in number theory and analysis:
https://en.wikipedia.org/wiki/Euler%27s_constant
I would guess that the goal is to reduce churn in the standard library, rather than trying to minimize the number of items in it. Putting something in there makes it really hard to make backwards compatible changes, or to make a sweeping improvements to the API. Even something that sounds simple, like the
regexcrate, in practice has 19 public structs and lots of subtle documentation, and went through many0.xversions before reaching1.0. I don't think the Rust core team has the person-power to have been able to design all of that interface and gotten it right the first time.https://docs.rs/regex/latest/regex/struct.Regex.html
The Euler–Mascheroni constant, though, was discovered in 1734 and isn't changing any time soon.