Re: [go-nuts] Zero value of the map

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

Re: [go-nuts] Zero value of the map

I can't speak for real-world speed, but algorithms with similar asymptotic complexity exist that work with immutable data. The hash map is not the only possible map implementation. Example from Haskell: http://hackage.haskell.org/package/containers-0.5.10.2/docs/Data-Map-Strict.html On Wed, Apr

Re: [go-nuts] Zero value of the map

On Thu, Apr 20, 2017 at 9:42 AM Will Faught 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: > >

Re: [go-nuts] Zero value of the map

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{}) { //

Re: [go-nuts] Zero value of the map

That's interesting, though quite different from the map implementation we're used to. Do you know (in any language) such an implementation, and would it really be as fast? Computing hash, accessing some bucket, and dealing with collisions seem unavoidable. But I have no idea of the extra

Re: [go-nuts] Zero value of the map

Thank you for detailed explanation. I find myself never using "var a map[int]int" or similar var like map. Maybe just my limited understanding. But I am glad we end up with map[int]int instead of *map[int]int. -- You received this message because you are subscribed to the Google Groups

Re: [go-nuts] Zero value of the map

On Tue, 18 Apr 2017, at 03:20 PM, Chris Hopkins wrote: > I'm not sure what you mean by the append doesn't modify the original. > Append will use the same backing store (if there is available capacity > in it) and by definition the address of the slice in question must be > invariant across its

Re: [go-nuts] Zero value of the map

I'm not sure what you mean by the append doesn't modify the original. Append will use the same backing store (if there is available capacity in it) and by definition the address of the slice in question must be invariant across its context. e.g.: https://play.golang.org/p/lBRpKSo-9P I think of

Re: [go-nuts] Zero value of the map

On Tue, Apr 18, 2017 at 7:02 AM, Jesse McNelis wrote: > On Tue, Apr 18, 2017 at 10:04 PM, Tad Vizbaras 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

Re: [go-nuts] Zero value of the map

On Tue, Apr 18, 2017 at 10:04 PM, Tad Vizbaras 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)

Re: [go-nuts] Zero value of the map

On Tue, 18 Apr 2017, at 01:04 PM, Tad Vizbaras wrote: > > The argument could be that slices are read-only too. Just that > "append" is special and it makes zero value slices useful. > var a []int > a[0] = 1 // Fails. > // panic: runtime error: index out of range > > I am just curious

[go-nuts] Zero value of the map

Making zero value useful is great idea. It works for slice, mutex and many others. var a []int a = append(a, 1) fmt.Println(a) This works and prints: [1] Sadly maps do not seem to have useful zero value. They require call to make() or literal to get to useful state. var a map[int]int a[1] =