Re:Go 2, here we come
by johncolanduoni on Friday November 30, 2018 @12:23AM
(#18566920)
Rust does this in debug builds by default, and you can switch it on in production if you'd like.
Re:Go 2, here we come
by monocularvision on Friday November 30, 2018 @06:13PM
(#18573612)
Swift does this with the default operators. There are alternative operators if you want to get the more classical C-style treatment.
Re:Go 2, here we come
by greenleafjacob on Thursday November 29, 2018 @09:59PM
(#18566260)
> if this int or uint under or overflows, throw an exception
Overflow flags are supported on some architectures, so it would really just be a matter of checking that flag.
Except in Go, types are defined using modular 2s complement. Overflow is not considered a problem, it's a feature that code depends on.
The spec says:
> For signed integers, the operations +, -, , /, and << may legally overflow and the resulting value exists and is deterministically defined by …*
It does not go on to define the overflow values; that gets to be implementation defined.
This is in contrast to unsigned integers, which the spec does precisely define overflow for.
However, having made the mistake a few times now of trying to use "unsigned ints" for things that I want to assert are never negative, I've learned the hard way not to do that. The problem is, there's always some bug you have in the program that will drive the uint "negative", wrapping over to a huge number. Unfortunately, since you get no warning when that happens, it tends to take longer to show up, and without a clear cutoff to say "ah, this is clearly invalid" it can be hard to even program detection code, whereas checking for "less than 0" can be unambiguous.
I'd loooove it if I could easily, cheaply, and universally (i.e., not just in Go, but across all my programming languages) turn on a behavior that says "if this int or uint under or overflows, throw an exception instead of trying to do whatever stupid thing you're going to do". I get the sense this is heading down the road where in 20 or 30 years, this is just going to be common sense. However, we are very early on the road yet from what I can see. Whenever I bring it up, even today, even in this sort of context, it still is generally negatively received. (But not uniformly. A few other people agree. I think momentum is with me. I'm not sure my programming career will live long enough to see it, though.)