History of the question. Go's map is implemented as a hash table with growable buckets. When the load factor exceeds a threshold, the runtime initiates a growth phase where entries are rehashed and redistributed into new, larger bucket arrays.
The problem. If the language allowed expressions like &m["key"], the resulting pointer would reference a specific memory location within a hash bucket. During map growth, entries are copied to new buckets and the old buckets are freed, rendering any existing pointers dangling and unsafe.
The solution. The Go specification explicitly prohibits taking the address of a map index expression. The compiler treats &m[k] as an invalid operation, ensuring that no program can hold pointers to map internals. This allows the runtime to freely relocate entries during growth or shrinking without managing pointer updates or invalidation.
Problem description. In a high-throughput telemetry service, engineers needed to update a counter field within a large configuration struct stored in an in-memory cache map. Initial attempts used cfg := &configMap[deviceID]; cfg.Counter++, which failed to compile with the error "cannot take address of map element". This pattern was common in C++ codebases the team migrated from, where std::map iterators remain stable.
Solution 1: Store pointers in the map. Change the map type from map[string]Config to map[string]*Config. This allows retrieving the pointer and modifying the underlying struct directly without reassignment. Pros include enabling direct modification and avoiding struct copying, while cons include increased heap allocations, reduced cache locality, and the need for nil checks.
Solution 2: Copy-modify-reassign. Retrieve the value into a local variable, modify it, and write it back using cfg := configMap[deviceID]; cfg.Counter++; configMap[deviceID] = cfg. Pros include working with value types and zero additional allocations, while cons include the performance overhead of copying large structs on every update.
Solution 3: Use a sync.RWMutex with a struct wrapper. Protect the map with a mutex to allow safe read-modify-write cycles in concurrent environments. Pros include explicit synchronization for concurrent access, while cons include potential lock contention and the continued necessity of reassignment.
Chosen solution and result. For small structs (<64 bytes), Solution 2 was adopted for its simplicity and zero-allocation properties. For large, frequently updated structs, Solution 1 was used with pool allocation to mitigate GC pressure. The system achieved stable performance without relying on unsafe pointer hacks.
Why can I take the address of a slice element but not a map element?
Taking the address of a slice element &s[i] is valid because a slice's backing array has a stable memory address unless the slice is reallocated (e.g., via append exceeding capacity). The pointer remains valid as long as the underlying array is not reallocated. In contrast, map buckets are routinely relocated during growth operations. If addresses of map elements were permitted, they would become dangling pointers after rehashing, violating memory safety.
Does using a map of pointers allow modifying the stored data without reassignment?
While you cannot take the address of the pointer slot itself (&m[key] is invalid even for map[K]*V), you can copy the pointer value out and dereference it: p := m[key]; p.Field = newVal. This works because you are modifying the heap-allocated struct through a copy of the pointer, not the map's internal storage. The distinction is subtle: the map stores the pointer value (an address), and while that address value cannot be addressed directly, it can be read and used to access the heap object.
How would map growth work if addresses of elements were allowed?
If the language permitted &m[key], the runtime would need to ensure pointer stability during bucket migration. This would require either indirection (storing pointers to entries in buckets, doubling pointer overhead), never freeing old buckets (memory leak), or implementing a read barrier to update pointers during relocation (significant performance cost). The current design optimizes for the common case of map operations by sacrificing the ability to take element addresses, avoiding these overheads.