The Go compiler seems to require an unnecessary type designation in composite literals. Note the following snippet:
package main
import "fmt"
type Vertex struct {
X, Y int
}
var (
v1 Vertex
)
func main() {
v1 = {1,2}
fmt.Println(v1)
}
If you try to compile this, you’ll get:
main.go:14: syntax error: missing operand
To fix it, you have to add the type of the struct, Vertex before the {1,2} literal. Why? From the var() declaration above, the compiler already knows that v1 is of type Vertex. Why do I need to tell it again at the assignment?
I might also modestly suggest that “missing operand” isn’t the clearest error message. What’s actually missing is a type name. It sounds like without the type name, the compiler doesn’t recognize the {1,2} as an operand at all. Why not?
Looks like this has been discussed with the Go team already; see this and this issue. According to these, one reason against untypted structure literals is decreased readability in more complex cases of struct initialization. Plus, it seems a non-trivial change, according to the closing comment of the second issue.
Thanks! That’s exactly the discussion I was looking for.
From the discussion, it sounded like a trivial change in terms of compiler implementation, but it was rejected for Go 1.x because of “implications”.
In all the examples provided in the discussion, I thought the type inference improved readability. I didn’t see any examples from those who said it decreased readability in complex cases. I’d add that letting the compiler infer the type is also easier for new Go programmers. Without reading that detailed discussion, it’s pretty difficult for a Go neophyte to see why the type should be required.
Finally, it seems to me that it’s a compiler bug that the error in the example above says “missing operand” instead of the much clearer “missing type in composite literal”. But, rather than address that, I hope they’ll decide to allow type inference in literals for Go 2.
Indeed the output is misleading. I agree this should be a bug but the compiler in general is not very chatty about the reasons of compile errors. Compared to other languages, the Go compiler error messages sometimes seem like “ack thbbft”.
I’ve come to recognize all the errors I usually cause so I no longer experience this, possibly Stockholm syndrome, but your comment made me laugh so have a “like”!
I think the one error message I have been bashing my head against is not from the compiler itself but json.Unmarshal's spectacularly unhelpful “cannot unmarshal value of type something into field of type something else”. Especially when dealing with megabyte-sized machine-generated JSON blobs… This being much improved in Go 1.8 is .
.