Why doesn't Go allow taking the address of map value?

Question

This is the same as Why does go forbid taking the address of (&) map member, yet allows (&) slice element? but I'm not satisfied with the accepted answer: "Slices are backed by a backing array and maps are not."

Note: I have now added my own answer to the referenced question above.

The question Access Struct in Map (without copying) is even better, but its accepted answer says you can't modify a field of a struct value in a map because you cannot take its address (which is my question).

Maps are backed by memory structures (possibly including arrays) just like slices are.

So what is the real reason why I can't take the address of a map value?

I wanted to modify a map struct value in place. Numeric values in maps can be modified in place using operators like ++ or +=

     func icandothis() {
        cmap := make(map[int]complex64)
        cmap[1] += complex(1, 0)
        fmt.Println(cmap[1])
     }

But struct values cannot be modified:

type Complex struct {
    R float32
    I float32
}

func (x *Complex) Add(c Complex) {
    x.R += c.R
    x.I += c.I
}

func but_i_cannot_do_this() {
    cmap := make(map[int]Complex)
    //cmap[1].Add(Complex{1, 0})
    fmt.Println(cmap[1])

}

func so_i_have_to_do_this() {
    cmap := make(map[int]Complex)
    c := cmap[1]
    c.Add(Complex{1, 0})
    cmap[1] = c
    fmt.Println(cmap[1])

}

Answer 1

Let's start with this misconception:

I wanted to modify a map struct value in place. Numeric values in maps can be modified in place using operators like ++ or +=

 func icandothis() {
    cmap := make(map[int]complex64)
    cmap[1] += complex(1, 0)
    fmt.Println(cmap[1])
 }

---

Let's expand the shorthand form:

package main

import (
    "fmt"
)

func icandothisShort() {
    cmap := make(map[int]complex64)
    cmap[1] += complex(1, 0)
    fmt.Println(cmap[1])
}

func icandothisLong() {
    cmap := make(map[int]complex64)
    // An assignment operation x op= y where op is a binary arithmetic operator
    // is equivalent to x = x op (y) but evaluates x only once.
    // cmap[1] += complex(1, 0)
    v := cmap[1]          // v = zero value = complex(0, 0)
    v = v + complex(1, 0) // v = complex(0, 0) + complex(1, 0) = complex(1, 0)
    cmap[1] = v           // cmap[1] = v = complex(1, 0)
    a := cmap[1]          // a = complex(1, 0)
    fmt.Println(a)        // complex(1, 0)
}

func main() {
    icandothisShort()
    icandothisLong()
}

Playground: https://play.golang.org/p/1OgmI_AD9uN

Output:

(1+0i)
(1+0i)

As you can see in icandothisLong(), the expanded form of icandothisShort(), there is no update in-place.

---

---

The next misconception,

Maps are backed by memory structures (possibly including arrays) just like slices are.

So what is the real reason why I can't take the address of a map value?

---

Maps are backed by bucket memory structures. A map key, through an imperfect, dynamic hash, identifies a current primary bucket. The map keys and values are stored in the primary bucket or an overflow bucket. The map buckets are constantly reorganized as map entries are created, updated, and deleted. A map entry has no fixed location in memory.

Here is a fairly detailed explanation of how maps work:

GopherCon 2016: Keith Randall - Inside the Map Implementation

Answer 2

Because an alternative would be to not have delete function. Consider a following example.

m := map[int]int{1: 2}
v := &m[1]
delete(m, 1)

What v points to?

There are four possible answers (well, more, but they are just as bad), none of which are satisfactory.

• A tombstone marking an missing entry. This wouldn't allow for reusing an entry after it was removed from a hash table which would require more common resizes and would waste memory in maps where elements are often deleted.

• A dangling pointer, which is incompatible with Go memory safety requirements.

• This is an invalid code. Would require runtime checking for all pointer accesses or implementing Rust style borrow checker.

• Require values to be behind a pointer which adds an indirection. You can do it yourself by using types like map[int]*int.

You may say that a program shouldn't access pointers to a map element after it was deleted. This would be fine in memory unsafe programming language, which Go isn't.

By the way, for reference purposes, other map operations are definitely possible to implement while allowing to take a reference to a map element. A map implementation following C++ iterator invalidation requirements will get those easily - although there is a cost as C++ maps are relatively slow. But if most C++ programs can manage this cost, so can Go.