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.

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.

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.

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.

Another interesting example I've found:

var a = map[float64]int{math.NaN(): 42} // Works.
var _ = map[float64]int{42: 42}         // Works.
var _ = map[float64]int{math.NaN(): 42} // Error.

Is the following behavior correct in the context of a type?

package main

type A interface {
    fn(_) // cannot use _ as value
}

func fn(v _) {} // cannot use _ as value

func main() {
    var a _ // cannot use _ as value
}

I would expect an error along the lines of "cannot use _ as type"

@smasher164 Yes, the error message is fairly bad. It would be nice to get a better error message here. I'm not sure it's quite the same as the other cases in this issue, but it's similar.

Too late for 1.11.

Simpler reproducer:

package p

type E struct {
	f func()
}

var _ = E{func() {}}

This is okay.

var _ = map[bool]int{"aaa" != "": 1, false: 0}

This is not.

var _ = map[bool]int{"aaa"[:] != "": 1, false: 0}

These errors are gone with Go 1.18. Closing.