4 ms·

> both encoding/json and text/template guarantee sorted iteration order of maps. I don't think it's an edge case at all. That is literally the edge case exampl

> both encoding/json and text/template guarantee sorted iteration order of maps. I don't think it's an edge case at all. That is literally the edge case example I gave. Perhaps there is a better way to describe it than "edge case", but semantics is a silly game. > then the built-in map still seems like the right choice, and having a standard way to iterate it is a reasonable request. And, indeed, the standard library provides slices.Sorted(maps.Keys(m)) for exactly that. Ergonomic enough, while making the compromise being made reasonably explicit to help with readability – which is far more important than saving a few keystrokes. If typing is your bottleneck, practice will quickly solve that problem.

kbolino 2y ago
It's never really been about saving keystrokes, but about re-writing the same (fairly common) operation over and over again (and not necessarily the same way each time), and not being able to benefit from future optimizations. However, as examined in a sibling thread, there doesn't seem to actually be any missed optimization which could potentially be applied here.
- randomdata 2y ago
  In what way is the operation common? We obviously would never say that there is never a use for such thing as there are clear edge cases where it is necessary, but as jerf points out, it is probably not what you actually need in most cases. Even ignoring that in the most common case the map isn't the right structure to begin with, what even is the general case for the situations that remain? You mentioned the marshalling of arbitrary data case, but in that case you also have reflection details to worry about, and which you can optimize for with a custom implementation, and thus wouldn't likely use the built-in anyway. A sibling thread discussed the cache benefits of colocating the values with the keys if a map is exceedingly small, but as soon as the map is of any reasonable size the added overhead of the values is almost certainly going to blow the cache even where the keys alone might still fit. All of which is to say that the best approach is highly context dependent. How do you even begin to choose which is the general case if you were to include such a function?

kbolino 2y ago

It's never really been about saving keystrokes, but about re-writing the same (fairly common) operation over and over again (and not necessarily the same way each time), and not being able to benefit from future optimizations. However, as examined in a sibling thread, there doesn't seem to actually be any missed optimization which could potentially be applied here.

randomdata 2y ago
In what way is the operation common? We obviously would never say that there is never a use for such thing as there are clear edge cases where it is necessary, but as jerf points out, it is probably not what you actually need in most cases. Even ignoring that in the most common case the map isn't the right structure to begin with, what even is the general case for the situations that remain? You mentioned the marshalling of arbitrary data case, but in that case you also have reflection details to worry about, and which you can optimize for with a custom implementation, and thus wouldn't likely use the built-in anyway. A sibling thread discussed the cache benefits of colocating the values with the keys if a map is exceedingly small, but as soon as the map is of any reasonable size the added overhead of the values is almost certainly going to blow the cache even where the keys alone might still fit. All of which is to say that the best approach is highly context dependent. How do you even begin to choose which is the general case if you were to include such a function?