At the beginning of September 2016, the spec simply said

the key must be a constant integer expression.

Which was vague but -as I read it- allowed things like const k float64 = 3.0 to be keys, since k is, arguably, a "constant integer".

The spec was updated in CL 30474, fix to issue #16679, and now says:

The key must be a non-negative constant representable by a value of type int; and if it is typed it must be of integer type.

This seems more "strict", in the sense that it explicitly says that typed constants need to be of integer type, and looking at the spec, the part about constant declarations:

If the type is present, all constants take the type specified,

it seems to me that a constant declared with type specifier (as float64 above) is not an untyped constant, which means it is typed, which means that if we follow the new spec phrasing, it should not be allowed to be used as an array key.

So it seems that the new spec phrasing introduced in September 2016 made the rules more strict, but the compiler was not updated accordingly.

cc @griesemer

What does gccgo do, @ianlancetaylor?

This seems to me like an oversight (== bug) in the compiler. The index key is supposed to follow the exact same rules as an index for a slice/array. It's not valid to use a float64 index i in s[i] even if the value of i is representable as an integer.

go/types complains in all these cases.

Btw I just tried with gccgo (7.2) and, like gc, it accepts the program above without complaints.

I'm worried that we can't fix this in the compilers at this point, as it might break existing programs (unless they were checked also against go vet, which complains). This will need a decision.

cc: @ianlancetaylor @rsc

@griesemer couldn't go fix mitigate the problem by redeclaring the constant as untyped in blocks where the constant is used for indexing?

@j7b Yes, but that would still require that source to be changed and thus possibly brake existing programs. Or perhaps I misunderstood what you meant.

What I was thinking is mechanically complicated, it'd be easier to have go fix explicitly convert non-int constants to int, that shouldn't break anything that would compile otherwise.

Vet is going to start yelling about this (because it uses go/types) at some point (maybe Go 1.11; Go 1.10 ignores go/types failures unfortunately). After that point maybe we can fix the compilers.

@griesemer @rsc go/types misses the case where the index to an array/slice is a typed constant with an underlying type int - same with composite array/slice literals. This should not work according to the spec:

https://play.golang.org/p/dn62_WXGxem

type foo float64
correctly produces an error while indexing the array - non-integer array index bar

@ak2196 I'm sure I'm missing something but why do you say that your example should not work? A type defined to int is still an integer type.

@ianlancetaylor maybe I am confused or reading the spec wrong

bar's type is foo, foo's underlying type is int but the spec says for array literals:

"An element with a key uses the key as its index. The key must be a non-negative constant representable by a value of type int; and if it is typed it must be of integer type."

In this case the key is typed - the type is not 'int' it's foo but foo's underlying type is int. I guess it depends on what "integer type" means. Does it mean just int or anything that has int as the underlying type?

@ak2196 "integer type" does not mean just int. The spec does not seem to define it clearly (though I may be missing something) but certainly wherever the spec says "integer type" it accepts int, int8, int16, uint, etc., as well as any other type defined to one of those types.

@ianlancetaylor That definitely makes sense. Thanks for clearing it up.

Revisit to see if there's anything to do here.

It looks the behavior has been changed since 1.17.

Both the 1.17 and 1.18 compiler correctly report an error here and follow the spec. This is now working as expected. Closing.