We have integer madness here and no one is commenting on it. Why making this int change and why now? I don't like Java, but well-defined integer types sizes is a good thing. Most of the world uses intXX_t typedefs in C and C++ too.
If the size of an integer is critical to the execution of your program, then you should be using int16 or one of the many other types that specify the number of (un)signed bits.
The int type is designed to be platform specific to optimize on execution speed when the maximum size of the integer isn't an issue.
And regarding optimization. Language-defined integer type size is one thing and CPU register sizes used in calculations is different thing. It's not like having 32-bit int forces you (or compiler) to use 32-bit registers.
For every int we (i.e. programmers) should be aware of possible min and max values that can be stored in it. Thus we can easily use fixed-size ints everywhere, paying attention to signedness too of course. The problem is that there is high temptation of using int most of the time, because it's easier to write (it's shorter). For the same reason many C programs use int instead of unsigned short or uint16_t for instance. Well-defined int size is part of self-documenting code, as it shows mindfully applied constraints.
My point is this: the problem when talking about "best practices" is there's some approaches that actually doesn't make a huge deal of practical difference, so it's more subject to specific circumstances (eg developer time constraints) or even just personal preferences (eg the arguments between ()\n{\n\t and (){\
Anyhow, in answer to your other post, the intn and uintn types have been available in Go since day one. So (and in answer to your original post as well), this int issue you raise isn't an issue unless developers have written extremely bad code to begin with (ie written counters which they know will exceed a 32bit integer and not cared enough to write an error handler nor specifically use an int64 type). Go does do a lot more to protect the developer from shooting his own foot off (more so than C/C++), but if we're completely honest, if the developer is crap then no amount of hand-holding from language design will help.
Actually, memory is even more of a luxury than ever, since your caches have limited size and main memory bandwidth is atrocious, compared to the speed of your execution units. Using 32 bit fields for stuff that safely fits into 16 bits can cost you for that reason alone.
I'm all for performance tuning and writing efficient code (like I said, I learn to program back in the 80s when every bit of data mattered and various tricks were used to work around the limited power of those systems), but let's be clear about one thing, memory these days is not "more of a luxury than ever". The exact opposite is true.
In practice, as noted in the link, this is not a big deal as most people will use a specific type to avoid any potential issues, particularly when dealing with bitfields etc. you should be doing this anyway.
In practice, only when you're writing some loops with small number of iterations etc., you don't care whether your counter for instance is 24-bit integer or 48-bit, because 16-bit or maybe even 8-bit would be enough. In most other cases you care whether 64-bit value will fit into your value or not and whether it can be there at all. And if you care about memory you use smaller ints in your structures when bigger ones aren't needed.
So, to some extent, it is indeed not a big deal. But it still isn't "not an issue". We gain more than 2^31-1 elements in slices on 64-bit platforms, true, but it should be possible from the beginning, without need to redefine int on such platforms.
> Previous Go implementations made int and uint 32 bits on all systems.
> Among other things, this enables the allocation of slices with more than 2 billion elements on 64-bit platforms.
If they truly wanted to have platform-dependent int, then why 64-bit int on 64-bit platforms wasn't introduced from day 0? It's a valid question, because it would avoid this big (implementation) change at all.
> However, programs that contain implicit assumptions that int is only 32 bits may change behavior.
I can agree that this assumption is wrong, but why changing int implementation now?
> Due to the change of the int to 64 bits and some other changes, the arrangement of function arguments on the stack has changed in the gc tool chain. Functions written in assembly will need to be revised at least to adjust frame pointer offsets.
My main point is that variable-sized int implementation and usage gives more problems than we get profits in return, even more when previous and widely used 1.0 version, which 1.1 is going to be backward-compatible with, did it differently.
Again, I wouldn't comment if variable-sized int was in Go 1.0 implementation, but it wasn't.
It has always been in the Go 1.0 specification:
"There is also a set of predeclared numeric types with implementation-specific sizes:
uint either 32 or 64 bits
int same size as uint"
http://golang.org/ref/spec#Numeric_types
It's just that the Go 1.1 implementation now takes advantage of this freedom.
Because we have finite time, and it was easier to implement at the time. This property has been in the language spec since day 1. It should not come as a surprise to anyone.
How much of my hundreds of thousands of lines of Go code have I needed to change because of this implementation change? None.
And quite frankly, if your code relies on a an integer to be 32 or 64 bits, you should be using int32 or int64.