Change:
/// Converts to degrees, assuming the number is in radians. #[inline] fn to_degrees(self) -> f64 { <ins> // The division here is correctly rounded with respect to the true // value of 180/π. (This differs from f32, where a constant must be // used to ensure a correctly rounded result.) </ins> self * (180.0f64 / consts::PI) }

Discussion:
That computed answer is just one bit wrong. The above case would be addressed by having the 180/pi value used in the conversion being a correctly rounded constant, rather than computed as , although I'm not sure this will get the right answer in all cases. If we decide to care about this, then we'll need an exact multiplication algorithm such as . Let be the exact (i.e. infinite precision) value of 180 / pi, then: (There's some conditions on the constant for this to work for all , and I don't know/haven't yet checked if 180/pi satisfies them.) This will is noticably slower than the naive method, especially if there's not hardware support for FMA (), however, if we do implement this, people who don't care about accuracy can use the naive method trivially. That said, is almost always used for output for humans, and is often rounded to many fewer decimal places than full precision, so loss of precision doesn't matter... but also, speed probably doesn't matter so much (the formatting will almost certainly be much slower than the multiplication). On the other hand, won't be used for human output, typically. (It's likely that suffers similarly, since pi / 180 is just as transcendental as 180 / pi, but I haven't found an example with a few tests.) This issue is somewhat of a policy issue: how much do we care about getting correctly rounded floating point answers? This case is pretty simple, but we almost certainly don't want to guarantee 100% precise answers for functions like / etc., since this is non-trivial/slow to do, and IEEE754 (and typical libm's) don't guarantee exact rounding for all inputs.
This seems to not be super important based on: Unless someone finds some really degenerate precision loss. While I agree that the perf hit isn't a big deal, I don't see a reason to take the hit unless someone's really hurting for the precision (and then they can of course roll their own in the worst-case).
Although the vast majority of code I have contributed to Rust so far is dedicated to correct rounding of floats, I agree. If it's always within 1 ULP, then it's most likely perfectly okay.

Theoretically some badly-written code might round-trip between degrees and radians n times, but that is a silly thing to do and dangerous anyway: You're bound to mess up with the units, unless you use a newtype wrapper, but a newtype wrapper can easily be augmented with a custom, correctly-rounded implementation of the conversions.
Ok, I did an exhaustive test of all , and the maximum error (for values for which there's no overflow/underflow) seems to be 2 ulp: (Warning, this program requires ~11GB of RAM to finish.) (I've now checked, and it does in single precision, and for all doubles except * 2<supn</sup.)
Thank you for testing this! 1 ULP vs 2 ULP does not make a big difference IMHO. Obviously using the correctly rounded constant in place of is an unconditional win, but halving performance just for a couple of bits of precision is not worth it IMHO. What would be really bad would be catastrophic failure that can result in almost unbounded error (measured in ULP) for sufficiently extreme inputs.
Yeah, I agree. (I believe there is infinite (absolute and relative) error for two (positive and negative) cases for : let be the float after , then I believe should round to something slightly less than , but (the naive version) overflows to infinity. I don't think this affects , and I don't particularly think this matters.)
Still repros.
I suggest closing this as "wont fix", honestly.
One thing someone could do with little effort is replacing with the correctly rounded constant, which would hopefully improve accuracy slightly in some cases. Other than that, I agree with WONTFIX.