Why can't you assign to a struct field of a Go map element, as in m[k].Count++?

## Addressability, in one paragraph Go divides expressions into those that designate a storage location — variables, pointer dereferences, struct fields of addressable operands, slice elements — and those that merely produce a value. Only the first kind is *addressable*: you may apply `&` to it, assign to it, assign to a part of it, and have the compiler implicitly take its address when you call a pointer-receiver method. **Map elements are explicitly excluded from that set.** So for `m` of type `map[string]stat` where `stat` is a struct with a field `Hits`: ```go m["go"].Hits++ // compile error: cannot assign to struct field m["go"].Hits in map p := &m["go"] // compile error: invalid operation: cannot take address of m["go"] m["go"].Inc() // compile error, if Inc has a pointer receiver ``` All three are the same error wearing different clothes: each needs the address of the element. ## Why the language forbids it A map is a hash table that the runtime is free to reorganise. Inserting an entry can force the table to grow, and growing moves existing entries to new storage. If `&m[k]` were legal, that pointer would silently become a pointer to abandoned storage the moment some unrelated insert triggered growth — writes through it would vanish, and the garbage collector would be keeping stale storage alive. Rather than define when such a pointer stays valid (which would constrain every future implementation of maps), Go removes the possibility. Slices do not have this problem: indexing a slice never moves its backing array, and the operation that *can* replace the array, `append`, hands you a new slice header explicitly. ## What is still allowed The restriction is on writing *part* of an element, not on writing the element: ```go m["go"] = stat{Hits: 1} // fine: assign the whole element counts["go"]++ // fine: shorthand for counts["go"] = counts["go"] + 1 counts["go"] += 3 // fine, same reason _ = m["go"].Hits // fine: reading a field of a copy needs no address ``` That last pair surprises people who over-generalise the rule to "you cannot modify map elements at all". You can, wholesale. ## The two fixes **Read, modify, write back.** Copy the element into a variable — which *is* addressable — mutate the copy, and store it back: ```go s := m["go"] // s is a copy; if the key is missing this is the zero stat s.Hits++ m["go"] = s ``` This is explicit, works with a missing key (you get the zero value and then insert), and costs one copy of the struct in each direction. For small structs that is nothing. **Make the value a pointer.** With `map[string]*stat`, the element is a pointer value; `m["go"].Hits++` compiles because it dereferences that pointer, and the struct it points at lives in ordinary heap storage that the map never moves. The trade is that you must now allocate each value, a missing key gives you a nil pointer and the same expression panics, and every holder of the pointer shares the mutation — which is sometimes exactly what you want and sometimes an aliasing bug. A third option that is often the best one for counters: pick a value type where whole-element assignment is enough, such as `map[string]int`, and let `m[k]++` do the work. ## The related diagnostics The compiler messages are precise and worth recognising on sight: `cannot assign to struct field m[k].F in map` for the field write, `cannot take address of m[k]` for `&`, and `cannot call pointer method Inc on stat` for the method case. All three point at the same rule. The method-set version is the one that bites in real code. If `Inc` is declared on `*stat`, then `m["go"].Inc()` fails while `s := m["go"]; s.Inc()` compiles — and the second one silently mutates a copy that is then thrown away, which is a *worse* outcome than the compile error, because it looks like it works. When you see a value-typed map of structs with pointer-receiver methods, that is a design smell: either the methods should take value receivers and return a new value, or the map should hold pointers. ## What interviewers listen for The words "not addressable", the reason (entries may be relocated as the map grows), the fact that whole-element assignment and `m[k]++` remain legal, and at least one correct fix. Candidates who claim maps are read-only, or who propose `&m[k]`, have not internalised the rule.