What are Go arrays indexed by?

I am some 'memory allocator' type code, by using an array and indexes rather than pointers. I'm hoping that the size of the index of the array is smaller than a pointer. I care because I am storing 'pointers' as integer indexes in an array rather than 64-bit pointers.

I can't see anything in the Go spec that says what an array is indexed by. Obviously it's some kind of integer. Passing very large values makes the runtime complain that I can't pass negative numbers, so I'm guessing that it's somehow cast to a signed integer. So is it an int32? I'm guessing it's not an int64 because I didn't touch the top bit (which would have been 2's compliment for a negative number).

Arrays may be indexed by any integer type.

The Array types section of the Go Programming Language Specification says that in an array type definition,

> The length is part of the array's type and must be a constant
> expression that evaluates to a non-negative integer value.

In an index expression such as a[x]:

> x must be an integer value and 0 <= x < len(a)

But there is a limitation on the magnitude of an index; the description of Length and capacity says:

> The built-in functions len and cap take arguments of various types and
> return a result of type int. The implementation guarantees that the
> result always fits into an int.

So the declared size of an array, or the index in an index expression, can be of any integer type (int, uint, uintptr, int8, int16, int32, int64, uint8, uint16, uint32, uint64), but it must be non-negative and within the range of type int (which is the same size as either int32 or int64 -- though it's a distinct type from either).

It's a very interesting question indeed. I have not found any direct rules in documentation too; instead I've found two great discussions in Groups.

In the first one, among many things, I've found an answer why indexes are implemented as int - but not uint:

> Algorithms can benefit from the ability to express negative offsets
> and such. If indexes were unsigned you'd always need a conversion in
> these cases.

The second one specifically talks about possibility (but possibility only!) of using int64 for large arrays, mentioning limitations of len and cap functions (which limitations are actually mentioned in the doc):

> The built-in functions len and cap take arguments of various types and
> return a result of type int. The implementation guarantees that the
> result always fits into an int.

I do agree, though, that more... official point of view wouldn't hurt. )

Arrays and slices are indexed by ints. An int is defined as being a 32 or 64 bit signed integer. The most common implementation (6g) uses 32 bit integers regardless of the architecture at this point in time. However, it is planed that eventually an int will be 64bit on 64bit machines and therefore the same length as a pointer.

The language spec defines 3 implementation dependent numeric types:

uint     either 32 or 64 bits
int      same size as uint
uintptr  an unsigned integer large enough to store the uninterpreted bits of a pointer value