I don't think that a race between competing genetics container collections will necessarily be a bad thing. It will allow flexibility, experimentation, innovation, and it will allow the community to vote with its feet in terms of eventually coalescing around a de-facto standard.
On Wednesday, 17 March 2021 at 08:22:04 UTC markus....@gain.pro wrote: > On Tuesday, March 16, 2021 at 11:27:12 AM UTC+1 Haddock wrote: > >> >> >> Therefore I wonder whether it would make sense for the Go core >> development team to define a couple of generic interfaces for sets, lists, >> queues, maps, etc. that are part of the standard library to prevent some >> uncontrolled growth of all kind of generic collection libraries from >> setting in. So I wanted to ask whether there are any plans that go in that >> direction. >> >> > What about the Heap and List containers in the current stdlib? And in > addition since the math.Max (and friends) function were often given as top > examples of why generics are desired, I wonder if their generalised version > are part of in the planned generics implementation path? > > Since both are not stated in the current design specification (or github > proposal), I am assuming the answer is "no" to both questions. It would be > wonderful though. Maybe initially as golang.org/x repos to not lock-in > the design from the start? > > -Markus > > > >> Thanks, Archilbald H. >> > -- 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 on the web visit https://groups.google.com/d/msgid/golang-nuts/823682d5-06e9-41a4-8353-fdbe578f2541n%40googlegroups.com.
