Why can't you call a pointer-receiver method on a Go map element or on a function's return value?

## Two rules that combine This behaviour comes from two separate rules meeting. **Rule one - the call-site shorthand.** If a method is declared with receiver `*T` and you write `x.M()` where `x` has type `T`, the compiler rewrites the call as `(&x).M()`. The shorthand is only legal when `x` is addressable. **Rule two - what is addressable.** Go's specification lists the addressable operands: - a variable; - a pointer indirection, `*p`; - a slice index expression, `s[i]` - always, because the element lives in a backing array; - an array index expression, `a[i]`, when the array itself is addressable; - a field selector `x.f` when `x` is addressable; - plus one special case: you may take the address of a composite literal, `&T{}`. Everything else is not addressable. The ones that matter in practice: - a **map index expression**, `m[k]`; - a **function or method call result**, `f()`; - a **type assertion result**, `v.(T)`; - a **string index expression**, `s[i]`, and constants and most literals. Put the two rules together and `m[k].inc()` fails while `s[0].inc()` succeeds, even though the two look identical. ## Why a map element has no address This is a design decision with an implementation reason behind it. A Go map grows and rearranges its storage as entries are added; the memory holding a given value may move. If the language handed out `&m[k]`, that pointer could be left pointing at storage the map has abandoned, and a write through it would be silently lost. Rather than define what happens, the specification simply makes map elements non-addressable, which pushes the problem to compile time. A slice element does not have this problem *for the duration of the expression*: the element lives in a backing array and `&s[i]` is a well-defined pointer into it. (Appending later may allocate a new array and leave that pointer aimed at the old one - a real hazard, but a different one, and not what the addressability rule is about.) ## The symptoms you will actually see Three failures, one cause: ```go byName["file"].inc() // pointer-receiver method on a map element byName["file"].hits++ // increment is an assignment to a map element's field byName["file"].hits = 1 // assignment to a struct field in a map ``` The last two report that you cannot assign to a struct field of a map element. The first reports that the method cannot be called because the operand is not addressable. Both are the same rule wearing different clothes: an assignment target must be addressable too. Note what still works: **reading** is fine. `n := byName["file"].hits` compiles, because reading a field only needs the value, not its address. And a value-receiver method call, `byName["file"].report()`, also compiles - it receives a copy, and copying needs no address. ## The two fixes **Copy out, mutate, put back.** ```go s := byName["file"] s.hits++ byName["file"] = s ``` This is explicit and correct, and it makes the copy obvious to a reader. It costs a copy of the struct in each direction, which is irrelevant for a small struct and worth thinking about for a large one. It is also not atomic - if two goroutines do this concurrently you have a lost update *and* a data race, but concurrent map writes are unsafe regardless. **Store pointers.** Declaring the map as `map[string]*stats` makes `byName["file"]` a pointer value, and calling a pointer-receiver method on a pointer needs no address-taking at all. Mutations are then visible to everyone holding the pointer, which may be exactly what you want for a registry of long-lived objects - or exactly what you do not want if you were relying on map values behaving like independent copies. It also means a missing key yields a nil pointer rather than a usable zero value, so lookups need an `ok` check before use. ## The call-result case ```go newStats().inc() // rejected ``` A function's return value is a temporary with no home; the language will not invent one. If `inc` has a pointer receiver, either assign the result to a variable first - `s := newStats(); s.inc()` - or have the constructor return `*stats` in the first place, which is the usual shape for a type with pointer-receiver methods. ## How to recognise it in review When someone reports "the compiler will not let me change this", ask what is on the left of the dot. If it is a map lookup, a function call or a type assertion, the answer is addressability and not anything about the method. The fix is mechanical; the design question underneath - should this map hold values or pointers - is the part worth discussing.