Not a strict requirement, but hashing pointer values.
In Go, a pointer's integer value may not be stable since the GC may move the underlying data. This doesn't happen with today's runtime, but it may in the future.
Why does this matter? What if I want to make a hash table with the key being a pointer? The built-in map can just go ahead and hash the pointer itself (i.e. a 32/64-bit integer) since it's a part of the runtime and will be updated if the GC is changed. But a user map cannot do this: it would have to hash the actual value itself. Depending on your data, this could be significantly more expensive.
This doesn't stop anyone from implementing a hash table, but it may mean that it can't be as fast as the built-in map.
Yes. "[]" would denote the operator for accessing element of collection associated with key/index k by [k] syntax. Similarly "[]=" would denote operator for storing element under a given key/index.
so if I defined my own map type (e.g. orderedmap[T] that kept things in the order they were added) then I'd need to write code for the [] operator to access an element, is that right?
I guess I'm not really sure how that differs from declaring orderedmap(T) (as it is in the proposal). Why do I need to overload one and not the other?
