cmd/compile: provide a more explanatory error message on trying to take the address of an unaddressable value e.g. constants, integer and string literals

[deanveloper]

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

go version go1.11.1 linux/amd64

Does this issue reproduce with the latest release?

Yes

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

GOARCH="amd64"
GOBIN="/home/24G/.bin"
GOCACHE="/home/24G/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/24G/go"
GOPROXY=""
GORACE=""
GOROOT="/snap/go/2890"
GOTMPDIR=""
GOTOOLDIR="/snap/go/2890/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build434234612=/tmp/go-build -gno-record-gcc-switches"

What did you do?

https://play.golang.org/p/uU1XNXaFYG-

What did you expect to see?

This isn't a bug report, that's exactly what I expected haha. But the purpose of this issue is to get a more helpful error message.

What did you see instead?

cannot take the address of 5

This is quite repulsive toward beginners. People who encounter this error may not understand exactly how constant values work, and what the differences between constants and normal values (after all, they look a lot like variables). Pointers are extremely hard for beginners to deal with, and changing this error message will make the language a bit more approachable.

This is especially unintuitive because &StructValue{...} is okay, but &5 is not.

I propose instead that the message is changed to cannot take the address of the constant value <const>. This should at least explain a reason why the value is not addressable.

If there are cases where this is error message change would be unhelpful, that would be important to consider.

[odeke-em]

Thank you @deanveloper for filing this bug and welcome to the Go project!

Sounds like a plan, I've updated the title of this issue with the premise of providing a more explanatory error message for trying to take the address of an unaddressable value

Kindly paging @griesemer @mdempsky, what might you think of these error message suggestions?

a)

cannot take the address of integer literal 5

b)

cannot take the address of 5 (unaddressable because it is an integer literal)

I can work on this sometime soon when I get some free cycles.

EDIT:

const s = 5 is a still constant and &s would be still valid.

Oh my, I really need to start sleeping enough, I didn't mean to type that and even thought about it in my head as a counter example but mis-coordinated the typing

[mdempsky]

I'm sympathetic to making error messages more accessible to new users, but it's not obvious to me that this proposal accomplishes that.

I'm not sure I understand how "cannot take the address of the constant value 5" or "cannot take the address of integer literal 5" is clearer to beginners than "cannot take the address of 5", or how it explains why the value is not addressable. All it does is further emphasize that "5" is a constant value or integer literal, which I expect users already know. (If not, should we emphasize that every time they misuse 5?)

I also don't really like the "unaddressable because it is an integer literal." It's actually unaddressable because it's not one of the cases the Go spec enumerates as addressable: https://golang.org/ref/spec#Address_operators

Is there objective evidence that any of these error messages would be more intuitive to users? What error messages do compilers for other languages emit in similar situations?

[deanveloper]

It's also noteworthy that constants are not addressable, not just literals.

A better error message would be a lot more useful though in the following case, which is probably what I should have led with: https://play.golang.org/p/G_IxBn_xRz1

I don't have any objective evidence right now. Currently doing this from my phone, I'll look into it when I can though.

[mdempsky]

I'll admit named constants are a little more compelling, since names can also refer to variables, which are addressable. Similarly, for certain indexing expressions (map and string indexing, and indexing of non-addressable arrays), since other syntactically identical index expressions are addressable.

I think elaborating the error messages could be reasonable when syntax alone is insufficient to explain why the expression isn't addressable.

However, I'm curious what error folks suggest to use for:

var m map[int][10]struct{ f int }
_ = &m[0][0].f  // ERROR

Maybe something like:

cannot take address of m[0][0].f (m[0] is map index expression)

I.e., drill down past the field selections and array indexing to identify the root non-addressable expression.

[griesemer]

What @mdempsky said.

I think the error message is pretty clear, but we could go along the route chosen for binary operators. For instance, for "a" - "b" we get:

invalid operation: "a" - "b" (operator - not defined on string)

Analogously, here we could report:

invalid operation: &5 (operator & not defined on non-addressable 5)

But it really says the same thing, slightly less elegantly.

But I'm also not clear which part of the error message is "repulsive" to newcomers. If one is truly a newcomer, I suspect it's not even clear that & means "take the address" - so a peek into the spec is warranted anyway. If one comes from C, the error message seems "obvious". Maybe this is better:

invalid operation: &5 (constant 5 is not addressable)

Either way, this doesn't need to be a proposal. If a convincingly better error message comes along, I'm ok with changing this; but I don't see the current error as overly problematic.

[griesemer]

Closed by mistake. Re-opening.