Why even have int/uint?

[Steven Degutis]

When are there ever cases in which you don't care about the precision of some variable? Surely this will encourage people to use int because they're confident they don't need to worry about an overflow because it's so unlikely even though it's theoretically possible, yet they don't realize that in a few weeks or months, that counter variable is going to increment to such a high number that it will overflow.

-Steven

[Jan Mercl]

On Tue, Aug 28, 2012 at 3:20 PM, Steven Degutis <sdeg...@8thlight.com> wrote:
> When are there ever cases in which you don't care about the precision of
> some variable?

It's not about not caring about the precision of some variable. it's
only about not caring if the variable is 32bit or 64 bit.

In many cases it doesn't matter (e.g. in almost any place where the
expected value fit in the 32 range):
- "Small number of loops" cycles are quite common.
- Value used to index many "small" arrays/slices/strings.
- The value_of_index from range statement 'var i int; for i = range blah {}'
- Many other, which don't come to my mind immediately.

And then, on some CPUs the 32b things/operations can be slower than
the same for 64b. OTOH, 64b on 32b CPU can be also slower. So isn't it
better to have 'int' tailored to the machine where the program is run?

-j

[Andy Balholm]

I think that overflows like you describe would be more likely if there weren't an int type. If people were forced to specify the size of all their integer variables, they would say to themselves, "Surely this will always fit in a byte (or 16 bits, or whatever)", and declare it as int8. But now it's so convenient to use int that they probably won't bother to do that—so they're safe till their numbers reach 2 billion.

[Jesse McNelis]

Because it's fast, it's a fixed size and numbers are
generally small and when they are big it's usually fairly obvious that
they will be.

--
=====================
http://jessta.id.au

[⚛]

On Tuesday, August 28, 2012 3:20:06 PM UTC+2, Steven Degutis wrote:

When are there ever cases in which you don't care about the precision of some variable?

There exist a lot of cases in Go programs in which it is possible to infer that a natural number never overflows a Go int/uint. For example:

   var array []T = ...

   array[i] = X

the variable 'i' cannot in this specific case overflow the size of the array. The maximum value of 'i' is in many cases tied to the length of some array or some slice that is used by the program. From the fact that it is impossible to create an array whose capacity overflows the type 'int' we can infer that variable 'i' cannot overflow.

It is convenient for the language to use int as the length and capacity of an array. So len(array) and cap(array) return an int. Because the maximum value of many variables in Go programs is tied to the length or capacity of some array, it is convenient for these variables to be of type int as well (in which case it is impossible for the values of these variables to overflow an int).

Note that in many cases variables in programs have the same type as the type of the result of len(array) and cap(array). Programmers are not choosing the type of these variables freely or out of the blue - the choice is in fact based on what len and cap return.   In short, the type of many integer variables in Go programs depends on the type of what exists in the Go language specification.

If Go specification made the choice to use either int32 or int64 as len(array) and cap(array) then it would cause issues because Go runs both on 32-bit and 64-bit CPUs. int32 is a suboptimal choice on 64-bit CPUs, and int64 is a suboptimal choice on 32-bit CPUs. int is the best choice because it delegates the final decision between int32 and int64 to the compiler and to the implementation of Go's run-time.

[Steven Degutis]

I wanna vote this "best answer". If only Googoverflow were a real thing.

-Steven