On Tue, 14 Mar 2017 07:12:01 -0700
Ian Lance Taylor <i...@golang.org> 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?
>
> Well, there are also uses for modulo arithmetic. If we make this
> panic, writing the equivalent operation that doesn't panic seems
> awkward. I think there is a better case to be made that signed types
> should panic on overflow, the main question there being the run time
> efficiency cost.
I think I might have asked this already but wouldn't it be possible to
add (in the future) a two-argument form for integer arithmetic
operations and bit shifts, so that the second argument, if used, is set
to the overflow status?
Like in:
var x uint
if x, of := x-1; of {
panic("Integer underflow");
}
var y uint32
if y, cf := x << 33; cf {
panic("Bit carrying detected");
}
I'm not too much versed in CPU hardware, so offhand I can only say that
Z80 and x86 do support overflow and carrying detection.
--
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.
