var a [10]int                         // valid and accepted
var b [10.0]int                       // valid and accepted
var c [float64(10)]int                // invalid but accepted
var d [complex(10, 0)]int             // valid but not accepted
var e [complex128(complex(10, 0))]int // invalid and not accepted

(http://play.golang.org/p/YYb-ApQgjj)

The declaration of c is not valid because the length is of type float32. The spec says:
"The length is part of the array's type; it must evaluate to a non-negative constant representable by a value of type int."

(In other parts of the spec where we use similar wording, e.g. for array/slice indices, we do permit untyped constants representable as ints, but we reject non-integer-type values even if their values happen to be representable as integers.)

The declaration of d is valid because complex(10, 0) is an untyped constant that is representable as an int.

The declaration of e is correctly rejected and in contradiction to the acceptance of c; i.e., the compiler is not consistent.

For comparison:

• go/types correctly rejects c and e and accepts the others
• gccgo dies with an internal compiler error for type c [float64(10)]int and type e [complex128(complex(10, 0))]int, but accepts d.