Yes, there are cases for integer domain wraparound just as there are cases for exception at the limits.
The argument FOR is that "computers work that way." Since ENIAC, there have been overflow condition flags, but there have rarely been overflow/underflow panic traps. (Either no support, or support but universally disabled by high-level languages and their runtime infrastructure.) The defining characteristic of BCPL / B / C is that the machine virtualized by the language has the natural behaviors of the underlying hardware. (This both overstates and understates the 'FOR' argument--more below) The argument AGAINST is that mathematics does not work that way. Niklaus Wirth was a champion of this mindset and you'll see that PASCAL and later languages from him were more serious minded about the legitimacy of computing as a mathematical abstraction. (0 - 1 => some giant number is obviously illegitimate in this worldview.) Now, the FOR side has an interesting historical basis: very many algorithms expect faulty-style computer arithmetic for their operation. Imagine computing a hash code where multiplying, adding, or shifting a bt off the high or low end caused a panic on the scale of divide by zero. There are many tasks performed by computers where falling off the end, or wrapping around, are the most natural and only workable meaning (multiple precision arithmetic and CRC checksums as other examples). Wirth had some challenges with such things and resorted to awkward coding strategies in response. You can see other examples in Knuth's original Pascal TeX source code vs the prior SAIL version. On the other hand , Wirth's languages were amenable to proof-style assertions about ranges and domains because violations were errors. So, there are reasons both ways and reasonable people can disagree. The balance of the programming craft has a bias toward wraparound. The balance of CPUs make that mode best supported in response. That's the story. Now, for personal opinion, I would share a tremendous frustration that programmers often don't think at all about these issues and thereby allow their thinking to be shallow. My clearest example is code like "k=i+j" or "k = i*j" both of which are common. Stop and ask yourself "how frequently is this successful?" that is, in what percentage of the possible I and J combinations is the result wrong? Think about it. Here is the answer: https://play.golang.org/p/xc8TdVBgmf Maybe you can feel my horror that something could be wrong in 49.8047 or 96.9971% of the cases and only "weirdos like me and Wirth" even see it as a topic worthy of thought. He took this as an argument AGAINST and fought the system. I'm cool with FOR, but I wish I had at least one language other than assembler that respected my desire to say what I want in all such cases: to exploit overflow/underflow flags when desired, to use multiple rounding modes in expressions, etc. The transistors are there. It is language designers who are the weak link in the chain. On Tue, Mar 14, 2017 at 6:48 AM, Eyal Posener <pose...@gmail.com> wrote: > I was thinking about the type safety of uint in go, and comparing it for a > similar problem. > > If I have this go code: > > var x uint > x-- > > The value of x is then the maximal value of uint, which is probably not > what the gother wanted (I think, is there any particular use cases for that > that you know of?) > > So my question is: why does go allow that, and for example panics on index > out of range of an array? Doesn't it make sense that it also should panic > in this case? > > Cheers, > Eyal > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- Michael T. Jones michael.jo...@gmail.com -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
