spec: gotype accepts a[1.0<<s] though the compilers do not - which is correct?

[momchil-velikov]

The spec says (https://golang.org/ref/spec#Operators):

If the left operand of a non-constant shift expression is an untyped constant, it is first converted
to the type it would assume if the shift expression were replaced by its left operand alone.

Consider the following program (http://play.golang.org/p/LsZYy_l_hD):

package main
import "fmt"
func main() {
    s := uint(0)
    a := []int{1, 2}
    // A
    x := a[1.0]
    // B
    x = a[1.0<<s] // error
    fmt.Println(x, s)
}

According to the above part of the spec, it would seem that 1.0 in statement B should be converted to int, as it was converted in statement A, since A is what B looks like after, quote, "shift expression were replaced by its left operand alone."

However:

• go version devel +f2772a4 Tue Mar 15 19:57:40 2016 +0000 linux/amd64 reports an error:

./shift-5.go:11: invalid operation: 1 << s (shift of type float64)

• corresponding gotype produces no output
• gccgo (GCC) 6.0.0 20160314 (experimental) [master revision 96e5a1e:5a53517:1bd2aefdf63c38093e950d365c5b4fa9ed4a5197]

shift-5.go:11:7: error: index must be integer
x = a[1.0<<s] // error
^
shift-5.go:11:11: error: shift of non-integer operand
x = a[1.0<<s] // error

Indeed, the spec does not require the index in non-map index-expressions to be of or convertable to int. Nonetheless, one would expect either both or none of A and B to fail.

[martisch]

fmt.Printf("%T", 1.0)
float64

it is first converted to the type it would assume if the shift expression were replaced by its left operand alone

So it means untyped(1.0)<<s (index accepts untyped constants) which then becomes float64(1.0)<<s (1.0 takes default type for the operator) since slice index does not force a type of int as you say (spec: "the index x must be of integer type or untyped"). Which seems consistent with A and B since in A its just a 1.0 untyped (not converted to int but representable by int) and in B the operator is not defined on float64.

( deleted my ramble about conversion of untyped constants since it was wrong, sorry for the noise )

[ianlancetaylor]

I think the compilers are correct and go/types (which I gather does not give any errors) is wrong.

In A 1.0 is an untyped constant. In B 1.0 is not untyped, because s is not a constant. So your comparison between them is misleading. The correct comparison would be something like

f := 1.0
x := a[f]

[griesemer]

@ianlancetaylor According to the spec ("If the left operand of a non-constant shift expression is an untyped constant, it is first converted to the type it would assume if the shift expression were replaced by its left operand alone."), there's no difference in typing of 1.0 in A and B --- for typing purposes, it is as if the shift doesn't exist.

Specifically, in B, 1.0 is an untyped constant no matter the type of the shift count ("Except for shift operations, if one operand is an untyped constant and the other operand is not, the constant is converted to the type of the other operand."; i.e., shifts are special, and the shift count type has no influence on the type of the shift result whatsoever - nor does it matter here if s is constant or not).

We do accept a[1.0] and thus we should accept a[1.0 << s] since the type of this non-constant shift depends only on the type that the left operand would assume.

If 1.0 << s would indeed assume a floating-point result independent of context (in this case its use in an index expression), then an operation such as var m int = 1.0 << s would be invalid as well. However, this is explicitly permitted (see example in http://golang.org/ref/spec#Operators).

That is, it really depends on what the context is. The question is, for index expressions, does the context require an integer value? The spec says: "(If a is not a map) the (non-constant) index x must be of integer type or untyped" (http://golang.org/ref/spec#Index_expressions).

I believe the spec is vague here. But since we accept 1.0 as integer value (which would become a float64 in c := 1.0), it makes sense to accept 1.0 << s as integer value (which would become a float64 in c := 1.0 << s) since for non-constant shifts only the type of the left operand matters.

I argue that gotype is correct and the compiler(s) should accept this code. Alternatively, the spec could be made more restrictive in this case, but that would add extra rules which don't seem to be necessary.

[rsc]

I think we all agree that

func f(int64)
f(1.0<<s)

is OK and that

func g(interface{})
g(1.0<<s)

is NOT OK. (And the playground agrees too: https://play.golang.org/p/WS65K_B_hd).

The problem is:

var h []int
_ = h[1.0<<s]

Slice index is halfway between these: there's no one type dictated by context, but there are some types excluded, unlike interface{}.

I believe that the slice index here is disallowed by the spec. Ian agrees too (above), and Robert agreed in 2013 when I wrote these lines in test/shift1.go (https://golang.org/cl/7861045):

    // For now, the spec disallows these. We may revisit past Go 1.1.
    _ = a[1.<<s]  // ERROR "integer|shift of type float64"
    _ = a[1.1<<s] // ERROR "integer|shift of type float64"

It seems fine to revisit the spec, of course. It's not a big deal if we change this.

At this point, not for Go 1.8 though.

[bradfitz]

@griesemer, Go 1.9 or punt to Go 1.10?