> Are you sure that's the only edge-case? Because this thread is kinda long
> and there might even be things we are not thinking about.
In the original discussion above I see one opinion toward comparing headers
and four toward by element values (like strings). I didn't see any
additional edge cases listed.
The usecase you mentioned above seems - to me - to be served by a
> map[string]*T just fine. Did I misunderstand it?
Each path represented as a slice of coordinates could be easily encoded to
a string and compared that way.
As far as resource expenses go, we'd need benchmarks to say much. I
understand looking at expensive cases too, but that doesn't mean that there
aren't smaller regular use cases. Goroutines can be overused too.
On Wednesday, January 31, 2018 at 10:24:30 AM UTC-6, rog wrote:
> >> - When slices can be compared, they can be used as map keys. What
> >> if the contents of a slice are changed after it has been added to a
> > I’m not too familiar with Go map internals, but my thought is the key
> > would depend on the backing array values. Go maps also allow reading the
> > keys back using iteration so the slice backing array (up to length)
> > have to be copied. If the slice contents are changed then that would be
> > different key and the original key would be intact.
> Note that copying the slice contents to make a map key implies
> that using a slice as a map key might imply copying a whole tree,
> which seems rather expensive to me (especially as it might end up
> using more memory than the original if some elements are duplicated,
> unless an alias-aware copy algorithm is used which would be
> more expensive still)
> BTW you can already do something like this:
> You can even do it without reflect, which I'll leave as an exercise
> for the reader :)
You received this message because you are subscribed to the Google Groups
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/d/optout.