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.
When maps was moved from x/exp to the standard library, the Keys and Values methods were not added until 1.23.0 when iterators became available. This way it was not necessary to add new method names. The Go team are perfectly at liberty to change the API of packages in x/exp, especially when these packages migrate to the standard library. This is why x/exp exists in the first place, to allow experimentation, in a way which does not lock mistakes in to all future releases. And yes, it would be possible to add KeysAsSlice and ValuesAsSlice methods to the stdlib. But this would increase the API surface of the package for no real benefit. On Tuesday, 24 December 2024 at 18:09:19 UTC Def Ceb wrote: > x/exp/maps.Keys() returned a slice, while stdlib maps.Keys() returns an > iterator. Can't just switch between them transparently in almost all cases. > Sebastian was simply saying that slices.Collect() could be used as a > stop-gap solution for moving from x/exp/maps to stdlib maps, since every > current occurrence of maps.Keys(foo) could be converted to > slices.Collect(maps.Keys(foo)) to restore previous behaviour. Then you > can check that it still compiles and the tests still pass. Then maybe > consider reworking the code to use iterators instead of slices altogether. > > Anyway, x/exp is explicitly experimental and not to be relied upon. This > interface change could just as easily have happened within x/exp itself > in a version bump rather than during its move to the standard library. > If iterators had been added after maps was moved to the standard > library, then the iterator variant definitely would have appeared as > maps.KeysIter(), but they have no promises to keep with x/exp code. And > since converting an iterator to a slice is as simple as wrapping the > iterator in slices.Collect() if a slice is really needed, it's not a big > issue. > > Jason Phillips: > > Both maps.Keys and maps.Values exist in the standard library, https:// > > pkg.go.dev/maps#Keys > > > > Perhaps I'm missing some nuance about the difference between x/exp/maps > > and the standard library implementation? > > > > On Tuesday, December 24, 2024 at 2:31:04 AM UTC-5 Sebastien Binet wrote: > > > > Hi, > > > > If you want a slice in lieu of an iterator, you can use the slices > > package and its Collect function : > > > > https://pkg.go.dev/slices#Collect <https://pkg.go.dev/slices#Collect> > > > > hth, > > -a > > > > Dec 24, 2024 05:08:01 fliter <imc...@gmail.com>: > > > > > > > > Since the x/exp/maps era, I have used maps.Keys and > > maps.Values extensively. They are very useful and avoid users > > from doing loop iterations. > > > > I remember that they were added to the standard library, but I > > used maps.Keys in the latest go version and was surprised that > > it could not compile. By looking at the source code, I found > > that their behavior seemed to have changed for iter? > > > > Related discussions: > > > > https://github.com/golang/go/issues/57436 <https://github.com/ > > golang/go/issues/57436> > > > > https://github.com/golang/go/issues/61538 <https://github.com/ > > golang/go/issues/61538> > > > > Maybe I have limited information and less knowledge than the > > members of the go team, but if it is to support the functions of > > the iter package, why not add two new function names, such as > > maps.KeysIter and maps.ValuesIter, instead of changing the > > behavior of the previous method? > > > > In addition, how do you deal with the scenarios previously > > handled by maps.Keys? Do you do it manually with > > for ..range..append, or use golang.org/x/exp/maps <http:// > > golang.org/x/exp/maps>? Is it necessary to propose a proposal to > > add these two methods back to the standard library, but with > > different names? > > > > -- > > 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. > > To view this discussion visit https://groups.google.com/d/msgid/ > > golang-nuts/4f95be15-1a7d-4cb8-a19d- > > eb33a1736d68n%40googlegroups.com <https://groups.google.com/d/ > > msgid/golang-nuts/4f95be15-1a7d-4cb8-a19d- > > eb33a1736d68n%40googlegroups.com? > > 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...@googlegroups.com <mailto:golang- > > nuts+uns...@googlegroups.com>. > > To view this discussion visit https://groups.google.com/d/msgid/golang- > > nuts/e249451f-21a7-4e61-9df2-875c712a92ccn%40googlegroups.com <https:// > > groups.google.com/d/msgid/golang-nuts/ > > e249451f-21a7-4e61-9df2-875c712a92ccn%40googlegroups.com? > > 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/f4f63fb2-f136-4324-a5de-9923cf43a774n%40googlegroups.com.
