Thanks for these responses.
On Tuesday, 6 August 2013 22:06:38 UTC+1, Ian Lance Taylor wrote:
>
> On Tue, Aug 6, 2013 at 1:57 PM, Jakob Borg <ja...@nym.se> wrote:
> > 2013/8/6 Ian Lance Taylor <i...@golang.org>:
> >> It is designed that way because we want to permit setting a new key in
> >> a map to grow the hash table if necessary, moving the map around in
> >> memory. That means that the language can not permit taking the
> >> address of an entry in a map--if it could, it would not be possible to
> >> move a map in memory.
> >
> > How come append to a slice doesn't ever need to move the contents in
> > order to grow the slice?
>
> When append needs to move the contents, it gives you a slice that
> refers to a new backing store. The old backing store still exists and
> pointers to it are still valid. And a program could even reasonable
> use it.
>
> This does mean that whether a function like this prints 2 or 100
> depends on the details of the implementation of append.
>
> func main() {
> a := append([]int{}, 1, 2, 3)
> a = append(a, 4)
> p := &a[1]
> a = append(a, 5, 6, 7)
> a[1] = 100
> fmt.Println(*p)
> }
>
> Ian
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/a6acb447-ac6d-47e5-a2e8-eaa49e1b732a%40googlegroups.com.
