spec: shift string(1 << s) should be invalid

[griesemer]

package p
var s uint
var _ = string(1 << s)

is not accepted by the compiler:

bug.go:3:15: invalid operation: 1 << s (shift of type string)

Per the spec (https://golang.org/ref/spec#Constant_expressions):
"If the left operand of a non-constant shift expression is an untyped constant, it is first implicitly converted to the type it would assume if the shift expression were replaced by its left operand alone."

In this case, the left operand would be converted to int (not string). This is different from cases such as, say float64(1 << s) where 1 is implicitly converted to 1.0 because it can be done without loss of precision. It seems a bit far-fetched to claim that a 1 can be converted to a string without loss of precision. (That said, the spec is notoriously difficult to decipher with respect to shifts and implicit conversions.)

As an aside, there's still #3939 which is proposing to prohibit string(int_value), and go vet is checking for this. So we're not permitting a new category of programs by making string(1 << s) valid.

Both go/types and types2 accept this code.

The test $GOROOT/test/fixedbugs/bug193.go assumes that this code should fail.

[griesemer]

cc: @findleyr

[ianlancetaylor]

My vote is to change the spec, since cmd/compile, gccgo, and GoLLVM all reject this. I'm assuming that nobody is clamoring for this to work.

[griesemer]

Fair enough. If anything, we need to clarify the spec in that regard.

[gopherbot]

Change https://golang.org/cl/303094 mentions this issue: test: enable fixedbugs/bug193.go for -G compiler option

[gopherbot]

Change https://golang.org/cl/379256 mentions this issue: cmd/compile/internal/types2: report error for invalid string(1 << s)

[griesemer]

See #45117 for the implementation issue.

[gopherbot]

Change https://golang.org/cl/379275 mentions this issue: spec: add another example for an invalid shift change