CC @griesemer

Nice pathological case!

I am missing what the pathology is, and why s/textual/lexical/ makes a difference. Please fill me in.

In the first example, simply repeating the last present RHS where it is omitted leads to a different result (than leaving the RHS away) because the iota on the RHS of B = iota (after manually filling it in) is the user-defined, not the built-in iota. This effect is only possible for local constant declarations; at the package level we get a cycle error due to the different scope rules at the package level (see the example for all four cases).

Agreed that I don't know how using "lexical" would make this clearer. But stating that"Such an empty list is equivalent to the textual substitution of the first preceding non-empty expression list and its type if any." seems not quite correct.

I just wrote,

"I still don't see the problem. You're created a new variable called iota, so of course it's different."

and in writing that saw the problem. Wow, nice corner case.

In fact, this is not an iota specific issue:

package main

const X = 3

func main() {
	const (
		X = X + X
		Y
	)
	
	println(X, Y)
}

Looking at this again, it turns out that in Go 1.18 (with the new type checker) we actually get exactly the result as prescribed by the spec. For this example:

package main

const X = 3

func main() {
	const (
		X = X + X
		Y
	)
	println(X, Y)
}

Running with Go 1.18 we get the result 6 and 12, which corresponds exactly to using textually X + X for Y as the spec prescribes.

Running with 1.17 we get the result 6 and 6, corresponding to a copy of the syntax tree for X + X with the variables X resolved to the outer `X.

We have two possibilities:

1. The spec is wrong and we have a regression in 1.18.
2. The spec is correct and 1.18 fixed a long-existing bug.

There is a backward-compatibility issue here but this is a pathological situation that is unlikely to occur in correct code in the wild, and since 1.18 is out we have not heard any complaints about this.

Thus I am inclined to go 2) and close this issue.

@ianlancetaylor @robpike @rsc for feedback.

Marking as release blocker in case we decide that this needs to be handled as a regression.

2

Current gccgo prints 6 6, like Go 1.17.

I'm fine with changing that.

Closing as working as intended since Go 1.18, per feedback.

We should add a test case or two for this if we don't already have one.

@ianlancetaylor Yes, I was planning to do that.

Change https://go.dev/cl/414795 mentions this issue: test: add more tests for const decls with ommitted RHS expressions