Yes, you're right, the receiver should be a pointer.
What's bad about a double pointer dereference? Isn't that what, say,
bytes.Buffer does, more or less, at least conceptually?
On Thursday, April 20, 2017 at 1:22:56 AM UTC-7, Jan Mercl wrote:
>
> On Thu, Apr 20, 2017 at 9:42 AM Will Faught <will....@gmail.com
> <javascript:>> wrote:
>
> > Why couldn't maps be implemented as a pointer to the map implementation?
> If you try to use the map and the pointer is nil, then the map allocates
> the backing implementation. Pseudocode for a built-in implementation:
> >
> > type map struct {
> > impl *mapimpl
> > }
> >
> >
> > func (m map) set(k, v interface{}) { // used for m[k] = v
> > if m.impl == nil {
> > m.impl = newMapImpl()
> > }
> > m.impl.set(k, v)
> > }
>
> Without a pointer receiver the set method above is ineffective. With a
> pointer receiver every map operation is double dereferencing.
>
> --
>
> -j
>
--
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.
For more options, visit https://groups.google.com/d/optout.
