On Thu, Mar 16, 2017 at 11:04 PM, Konstantin Khomoutov
<flatw...@users.sourceforge.net> wrote:
> 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.
See https://golang.org/issue/6815.
Ian
--
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.
