On Thu, Mar 16, 2017 at 11:04 PM, Konstantin Khomoutov
wrote:
> On Tue, 14 Mar 2017 07:12:01 -0700
> Ian Lance Taylor wrote:
>
>> > I was thinking about the type safety of uint in go, and comparing
>> > it for a similar problem.
>> >
>> > If I
On Tue, 14 Mar 2017 07:12:01 -0700
Ian Lance Taylor 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,
Michael,
"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."
Are you shocked—shocked—to
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
On 14 March 2017 at 08:48, Eyal Posener 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
On Tue, Mar 14, 2017 at 9:23 AM, Eyal Posener wrote:
> Thanks for the answer. Very interesting.
> About the run time cost, does go always prefer safety over efficiency? or
> there is some kind of delicate balance between the two?
I would say that Go favors safety, but there is
Thanks for the answer. Very interesting.
About the run time cost, does go always prefer safety over efficiency? or
there is some kind of delicate balance between the two?
On Tuesday, March 14, 2017 at 4:12:31 PM UTC+2, Ian Lance Taylor wrote:
>
> On Tue, Mar 14, 2017 at 6:48 AM, Eyal Posener
On Tue, Mar 14, 2017 at 6:48 AM, Eyal Posener 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
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