On Sat, Jan 11, 2014 at 5:49 PM, Nathan Myers <[email protected]> wrote: > No one would complain about a built-in "i128" type. The thing > about a fixed-size type is that there are no implementation > choices to leak out. Overflowing an i128 variable is quite > difficult, and 128-bit operations are still lots faster than on > any variable-precision type. I could live with "int" == "i128".
It's certainly harder to overflow a 128 bit type by accident, though I think you over-state it: iterating foo *= foo 128 times will overflow even if foo is initially just 1, but moreover overflow that arises by chance is not the only sort programs have to deal with: malicious parties trigger overflow to cause unexpected behavior. I think a bigger argument for range checked types is not related to how easy the overflow is to trigger but, rather, how likely it is that the software cannot actually handle it when it is triggered— the same problem with null pointers. In C a lot of software is not null safe, its difficulty to tell at a glance if any particular function is null safe, and difficult to tell if a function needs to be null safe, and (apparently) difficult for many to keep null safety in mind when writing software. "Surprise! this value can be null! Hope you weren't going to deference it!" is a lot like "Surprise! these integers can have crazy values! Hope you weren't going to square one of them". [Not that having a 128 bit type wouldn't be great since x86 has the lower and upper multiplies having a 128 bit type makes it easy to get access to 64x64->128 without using assembly. I just don't think adding larger types really makes a meaningful improvement with respect to safety... and the overhead is equal or higher than having a 64 bit type and a tag that indicates the the stored value is really a pointer to a multiprecision integer.] _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
