Why value stored in an interface is not addressable in Golang

Question

Citing the golang wiki (https://github.com/golang/go/wiki/MethodSets#interfaces):

\"The concrete value stored in an interface is not addressable, in the same way, th

Answer 1

I think the answer is "because Go does not have references". If you call Foo(x) you know x won't be modified; if you call Foo(&x), you expect that it might. If what you request would be possible (in particular, if you want the value itself to be addressed, not the copy made in the interface), then that would break down:

func Bar() {
    b := 42
    Foo(b)
    fmt.Println(b)
}

func Foo(v interface{}) {
    // Making up syntax now
    p = takeAddressAs(v).(*int)
    *p = 23
}

Note, that it is possible (from a technical perspective) to address the copy stored in an interface and it definitely would be possible to build a language in which it would be allowed to modify the original value too (like you seem to want): This is basically how Python works. You could just make v = x be syntactic sugar for v = &x when v is of interface type. But that would add reference values to Go, which it intentionally lacks.

I think the root cause of the confusion here is that Go has syntactic sugar to call b.Foo(), even if Foo has a pointer receiver (as long as b is addressable). It's reasonable to be confused that you can call b.Write() but you can't do fmt.Fprintln(b, 42). Arguably, Go should just not have that sugar and instead require you to explicitly do (&b).Write or just make it a pointer to begin with (using, e.g. b := new(bytes.Buffer) instead of var b bytes.Buffer). But the answer to that is a) it's terribly convenient and b) it didn't seem that unexpected, that b.Foo() might modify b.

tl;dr is: a) Go does not have references, b) there is no technical reason it couldn't have them (contrary to the other answers' claims) but c) Go decided not to want them.