maybe there's a simple explanation for that, but at least another Rustacean was confused by this, so maybe it hints to some implementation consistency or whatever..?
I have a no_std environment and was trying a f32 % f32 operation. Rather than a compile error, this results in a linker error like
error LNK2019: unresolved external symbol _fmod referenced in function _mainCRTStartup@0
does that make sense? the core::ops::Rem actually seems to be implemented (also (f32).rem(f32) does not give a compile error when I explicitly "use core::ops::Rem", but still.. that unresolved _fmod symbol.
I solved my problem with the libm crate, but this halfway-erroneous-behaviour feels odd. to me.
6 years ago there was a discussion about something like that, Floating point modulus has snuck back into the language · Issue #27824 · rust-lang/rust · GitHub , but I have no idea whether that's the end of that.