What version of Go are you using (go version)?

1.10.1

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

I'm running this example on the Go Playground. Since the result is a syntax error, I don't believe operating system and processor architecture are relevant. (However, I can provide information about my machine if needed).

What did you do?

I attempted to run the following program (available on the Playground):

type T []int

func main() {
	for _, x := range T{1, 2, 3} {
		fmt.Println(x)
	}
}

What did you expect to see?

I would expect the code to compile and run.

What did you see instead?

The Go compiler produced a syntax error:

prog.go:10:29: syntax error: unexpected }, expecting := or = or comma
prog.go:13:1: syntax error: non-declaration statement outside function body

Additional Info

The Go Spec defines a RangeClause as:

RangeClause = [ ExpressionList "=" | IdentifierList ":=" ] "range" Expression .

The key point here is that an Expression is expected after the "range" literal. Following the definitions in the spec shows that:

1. CompositeLit is an Expression
2. The LiteralType component of a CompositeLit can be a TypeName ("T" in the example above).

There is nothing in the spec that I could find to indicate that this syntax is not allowed.

The following examples do actually compile and run as expected:

Playground Link

func main() {
	for _, x := range []int{1, 2, 3} {
		fmt.Println(x)
	}
}

Playground Link

type T []int

func main() {
	for _, x := range T([]int{1, 2, 3}) {
		fmt.Println(x)
	}
}

Playground Link

type T []int

func main() {
	list := T{1, 2, 3}
	for _, x := range list {
		fmt.Println(x)
	}
}

I believe this is happening because the '{' after the type name is being interpreted as the beginning of the BLOCK.

I've recently spent some time studying the code for the Go parser. At first glance it seems like it would be difficult to distinguish between the beginning of a block and a composite literal expression without arbitrary lookahead. One possible solution is to simply add a note to the spec indicating that this syntax is not allowed.

It is also possible that the Go Spec contains many such edge cases, and noting all of them in a public document is impractical. I just wanted to bring some attention to this particular case to see if it is worth doing something about.