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)
}
On Tuesday, April 18, 2017 at 7:16:25 AM UTC-7, Ian Lance Taylor wrote:
>
> On Tue, Apr 18, 2017 at 7:02 AM, Jesse McNelis <jes...@jessta.id.au
> <javascript:>> wrote:
> > On Tue, Apr 18, 2017 at 10:04 PM, Tad Vizbaras <eta...@gmail.com
> <javascript:>> wrote:
> >> I am just curious what is the reason behind not making zero maps more
> >> useful? Is it space?
> >
> > The problem is that maps are mutable.
> >
> > var a map[int]int
> > a[1] = 1 // could be fine and useful.
> >
> > var a map[int]int
> > someFunc(a) // Does someFunc need to return the map or not?
> >
> > If someFunc() allocates the map(because it got nil) by adding
> > something to it then it needs to return the map it allocated to it's
> > caller.
> > But if it didn't need to allocate because it got a valid map it
> > doesn't need to return the map.
> >
> > The possibility that a function might be passed a nil map would then
> > mean that all functions that work with maps would need to always
> > return the map.
>
> And another reason is that it's very convenient for the zero value for
> all types to be literally a sequence of zero bytes. We could never
> figure out how to preserve that property while not requiring the make
> call for map values. In the very early days what we call maps now
> were written as pointers, so you wrote *map[int]int. We moved away
> from that when we realized that no one ever wrote `map` without
> writing `*map`. That simplified many things but it left this issue
> behind as a complication.
>
> The most plausible fix that I know for this is to invent a map
> function that is similar to the append function, but I haven't yet
> seen a good design for that.
>
> 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.
For more options, visit https://groups.google.com/d/optout.
