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 <pos...@gmail.com > <javascript:>> 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. > > In any case it's not a change we can make now. > > 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.
