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 cost of dealing with a "versioned" immutable map, where each new version is not overwriting the previous one.
On Wednesday, April 19, 2017 at 4:12:20 AM UTC+2, Matt Harden wrote: > > It seems to me the equivalent of append for maps is merge, which would be > a very useful operation to have in its own right. A useful design for map > could have been an immutable structure supporting literals, merge, lookup > and delete operations, where all except lookup would return a new map > value. The obvious zero value would be an empty map. This can be made > efficient by sharing underlying data which would be safe since the map was > immutable. > > On Tue, Apr 18, 2017 at 7:59 AM Tad Vizbaras <eta...@gmail.com > <javascript:>> wrote: > >> 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 >> "golang-nuts" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to golang-nuts...@googlegroups.com <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > -- 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.
