cmd/compile: spurious "cannot use _ as value" error

[adonovan]

go version devel +af125a5 Thu Apr 28 17:56:28 2016 +0000 linux/amd64

https://play.golang.org/p/O_WijGjKJ7

[rsc]

It has been this way since as far back as Go 1.2. Doesn't matter for Go 1.7, and arguably low enough priority not for Go 1.8 either.

[odeke-em]

Interestingly a permutation of the code in the bug report
https://play.golang.org/p/hz5ePuCDlF

package main

type m map[string]string

var _ = map[string]string{}       // ok
var _ = map[string]string{"": ""} // ok

func main() {
	var _ = map[string]string{}           // ok
	var _ = map[string]bool{}             // ok
	var _ = map[string]string{"a": "A"}   // error: cannot use _ as value
	var _ = map[string]bool{"true": true} // error: cannot use _ as value
}

might allude to where the bug is:

• only within a function/closure
• objects of the same type whose left hand hand side identifier is _.

Sorry for the noise, was just marking bugs I wanna take a stab at for Go1.9.

[dmitshur]

I ran into this as well in #20484.

This also affects struct literals:

package main

var _ = int(5)           // ok
var _ = struct{ int }{}  // ok
var _ = struct{ int }{5} // ok

func main() {
	_ = int(5)               // ok
	_ = struct{ int }{}      // ok
	_ = struct{ int }{5}     // ok
	var _ = int(5)           // ok
	var _ = struct{ int }{}  // ok
	var _ = struct{ int }{5} // cannot use _ as value
}

https://play.golang.org/p/xpsxF1WC8z

The common theme seems to be that it cannot be in package scope, it has to be a var _ = rather than _ =, and the composite literal must be not empty.

[griesemer]

Moving to 1.10. There are work-arounds if this is important (perhaps in tests) and it has been like this for a long time. Should be fixed a part of the front-end rewrite.