> On Dec 29, 2024, at 1:28 AM, Axel Wagner <axel.wagner...@googlemail.com> > wrote: > > 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.
In my projects I use the sequence versions less frequently so having maps.Keys() and maps.Values() return an actual slice would be preferable. As is, I am forced to use the far less better name of `maps.Collect(maps.Keys())` instead of just `maps.Keys()`. Why don't I use the sequence versions more frequently? Because I try not to create huge in-memory maps and instead prefer to move logic that manipulates large amounts of data into a proper database. But when I do it would use large maps it would make sense to call that out with maps.KeysSeq() et. al. > 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`. > > 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. Ironically you alluded to the good argument you did not see, in your third paragraph. The good argument is precedence and consistency. I do agree that had it not been for the historical "accident" things would be different, but history is not something you can merely hand-wave away; it exists and has significant influence even when there are those who would prefer to ignore it. Had that history never occurred I would agree that a lack of a suffix would not naturally imply a slice. But that history did occur, and naming is not good when it ignores the context that occurred before it. The decision to ignore precedence and consistency is taking steps toward the "fractal of bad design" that is PHP and its horrendous inconsistency in standard library function naming and parameter usage that people have complained about for decades. Anyway, I am not sure why you felt the need to add your voice to defend it because, as I wrote, "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/EA2F8137-8AA1-4E2A-AA72-710476DE54C9%40newclarity.net.
