Daniel Micay <danielmi...@gmail.com> wrote: > On Sun, Jan 12, 2014 at 1:23 PM, Tobias Müller <trop...@bluewin.ch> wrote: >> Isaac Dupree >> <m...@isaac.cedarswampstudios.org> wrote: >>> In general, Rust is a systems language, so fixed-size integral types are >>> important to have. They are better-behaved than in C and C++ in that >>> signed types are modulo, not undefined behaviour, on overflow. It could >>> be nice to have integral types that are task-failure on overflow as an >>> option too. As you note, bignum integers are important too; it's good >>> they're available. I think bignum rationals would be a fine additional >>> choice to have (Haskell and GMP offer them, for example). >> >> Wrapping overflow is just as bad as undefined behavior IMO. > > Do you know what undefined behavior is? It doesn't mean unspecified.
True, but despite beeing so often cited it won't format your hard disk (even in C). The result of an integer addition will always be an integer in every compiler I know so in this specific case I don't fear the UB. >> I cannot remember a single case of using signed integers where wrapping >> would make any sense. > > It often makes sense in codecs, hashing algorithms and cryptography. I'm sure there exist many cases where _unsigned_ int overflow makes sense. For _signed_ integers I'm a bit sceptical but I am no expert in that field. In any case it should not be the default but rather 'opt-in'. But this is not what I meant. Let me rephrase it differently: Assume that signed int overflow is UB (like in C). That means, all actual overflows at runtime have to be considered bugs. Now I cannot imagine any such case (bug) where guaranteed wrapping would actually behave nicer. > If you don't have clear bounds and don't want modular arithmetic, you > need big integers. Or proper input validation. The type defines the bounds. >> And you lose some optimization opportunities. > > It's treated as undefined because there are more optimization > opportunities that way. That's what I wanted to say. If you guarantee wrapping overflow you lose those opportunities. >> So why not take the path of the rust memory management and enforce bounds >> statically? It would need annotations on the types, like lifetimes, but it >> would be very rusty. Like C but safe. > > Rust isn't supposed to be really hard to write. Complex dependent typing would I'm not sure that this would be so complex. At least not more than the lifetime system. Is simple arithmetics on the bounds. In reality (rust beeing a systems PL) fixed width ints _will_ be used, and I am sure that overflow will often just be neglected. So why not enforce it statically? Tobi _______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
