On Tue, Apr 18, 2017 at 7:02 AM, Jesse McNelis <jes...@jessta.id.au> wrote: > On Tue, Apr 18, 2017 at 10:04 PM, Tad Vizbaras <etas...@gmail.com> 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.
