I don't see a good argument for the lack of a suffix "naturally" implying returning a slice. I don't think `ValuesSlice` would be less natural than `ValuesSeq`.
At the end of the day, it's purely a question of what you think would be more frequently used. That should get the better name. `Values` (as is) composes naturally with `slices.Collect` and so you get both in one function and it seems a good choice for the default option. There *is* an advantage of a single `ValuesSlice` function over the composed version, because it can pre-allocate. But that seems a rather special advantage that can live with a special name. And either way, I'd argue that we could/should probably get rid of that advantage anyways, by inlining both `Values` *and* `Collect` and optimize the resulting `append` loop. In any case, the existence of this discussion is a historical accident. We added `x/exp/maps.Values` before iterators existed, as an experiment, so had to use slices. We *intentionally* waited with adding `maps.Values` until *after* iterators got added, to be able to give it the better name. If we would have never had `x/exp/maps.Values` or if we had added `range` over func before generics (and AFAIK it has been proposed before generics), we would have only ever had a `maps.Values` that returned iterators. No one would have even noticed. On Sun, 29 Dec 2024 at 03:56, Mike Schinkel <m...@newclarity.net> wrote: > On Dec 28, 2024, at 2:41 PM, Amnon <amno...@gmail.com> wrote: > > There are big advantages in maps.Keys and maps.Values returning iterators. > It allows us to iterate very big maps without having to allocate vast > amounts of memory. > > > I definitely agree there is a big advantage to have functions in the > standard library that return iterators for maps. > > What is a shame, however, is that those functions did not get a naming > convention to indicate them to be different from those that just return a > slice of keys or a slice of values much like how the suffix `Func` is used > as a naming convention to indicate that its parameters differ. As is they > squat on obvious names for functions that just return slices. > > It would have been less confusing to learn and remember had they named > them maps.KeysIterator and maps.ValuesIterator, maps.KeysSeq and > maps.ValuesSeq, maps.KeysRange and maps.ValuesRange, or with some other > suffix. But sadly, given the backward compatibility guarantee of Go, that > ship has sailed. > > -Mike > > -- > 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. > To view this discussion visit > https://groups.google.com/d/msgid/golang-nuts/8064C03C-51B9-4046-A5C2-88380A978FEE%40newclarity.net > <https://groups.google.com/d/msgid/golang-nuts/8064C03C-51B9-4046-A5C2-88380A978FEE%40newclarity.net?utm_medium=email&utm_source=footer> > . > -- 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. To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/CAEkBMfE0J_i6H5VtVewZFPsXtSvxvOOEPtPP%3DRso9n04Po98yg%40mail.gmail.com.
