←back to thread

Pitfalls of Safe Rust

(corrode.dev)
168 points pjmlp | 4 comments | 04 Apr 25 17:55 UTC | HN request time: 0.668s | source
Show context
woah ◴[06 Apr 25 17:56 UTC] No.43603395[source]▶
Is "as" an uneccesary footgun?
replies(4): >>43603560 #>>43603887 #>>43603998 #>>43605135 #
whytevuhuni ◴[06 Apr 25 18:15 UTC] No.43603560[source]▶
That was my first impression as well. So much of Rust’s language and standard library enforces correctness, that gaps start to feel way more visible.

“as” is a good example. Floats are pretty much the only reason PartialEq exists, so why can’t we have a guaranteed-not-NaN-nor-inf type in std and use that everywhere? Why not make wrapping integers a panic even in release mode? Why not have proper dependent types (e.g. to remove bound checks), and proper linear types (to enforce that object destructors always run)?

It’s easy to forget that Rust is not an ideal language, but rather a very pragmatic one, and sometimes correctness loses in favour of some other goals.

replies(6): >>43603934 #>>43604031 #>>43604722 #>>43604743 #>>43605449 #>>43609077 #
1. adgjlsfhk1 ◴[06 Apr 25 20:31 UTC] No.43604722[source]▶
The other option would be to change how floating point works. IEEE specifies operations, not names, so it would be totally valid to have <= on floats be a total order (using integer cpu instructions), and make a function called IEEEAreIdiotsWhoThinkThisIsFloatingPointLessThan which is the partial order that sucks.
replies(2): >>43605401 #>>43605437 #
2. wongarsu ◴[06 Apr 25 22:13 UTC] No.43605401[source]▶
For purposes of sorting, Rust does offer a non-IEEE order as f64::total_cmp. You can easily build a wrapper type that uses that for all comparisons, or use a crate that does it for you

https://doc.rust-lang.org/std/primitive.f64.html#method.tota...

replies(1): >>43605489 #
3. ◴[06 Apr 25 22:18 UTC] No.43605437[source]▶
4. zozbot234 ◴[06 Apr 25 22:25 UTC] No.43605489[source]▶
total_cmp is precisely IEEE's separately specified total order for floats. It's just that the more common operators do something different, and that's perhaps better for most uses where NaN are inherently unexpected and generally indicate that some kind of error condition has occurred.