There is a difference between "failing to provide one" and "waiting with its design until generics have been implemented".
One addition to my last mail: There are some drafts of generic packages in the dev.go2http://dev.go2gohttps://github.com/golang/go/tree/dev.go2go/src/cmd/go2go/testdata/go2path/srcgo <https://github.com/golang/go/tree/dev.go2go/src/cmd/go2go/testdata/go2path/src> branch. I believe they are best understood as "example code to understand how generics will work" and not "candidates for inclusion in the stdlib". But for completeness sake, it does reflect work that has been already done on what kind of APIs might be sensible to provide. On Tue, Mar 16, 2021 at 1:05 PM Robert Engels <reng...@ix.netcom.com> wrote: > Failure to provide a standard “collections” package would be a huge > mistake. It is certainly a top 3 reason for the success of Java. > > On Mar 16, 2021, at 6:52 AM, 'Axel Wagner' via golang-nuts < > golang-nuts@googlegroups.com> wrote: > > > The very detailed design doc > <https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md> > is linked in the proposal issue > <https://github.com/golang/go/issues/43651>. That's the design that is > currently targeted for implementation. It is possible that it still changes > in a couple of details, but you should assume that this is mostly what's > going to land, eventually. > > As for implementation, there are three design docs describing possible > approaches: > > https://github.com/golang/proposal/blob/master/design/generics-implementation-dictionaries.md > > https://github.com/golang/proposal/blob/master/design/generics-implementation-gcshape.md > > https://github.com/golang/proposal/blob/master/design/generics-implementation-stenciling.md > I don't think any of them has been committed to. Personally, I would > suggest leaving the implementation decisions up to the people doing it. The > semantics (from the general design doc) are really what's interesting for > the community. > > > Once generics are there I guess there will be a race between a lot of >> libraries with generic collections, which will be first, have the best API, >> most functionality, etc. >> >> 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. >> > > I don't think there are many specific plans. I'm also not sure it's a good > approach to the problem. > Defining a general API for these things is surprisingly hard - there are > many different use-cases with different requirements. For example, maps can > be implemented as hash sets or trees, requiring different constraints on > the contained type. They might remember the order of insertion or they > might not. Defining an API for maps would thus require us to decide what of > these cases to cover - but they might be mutually exclusive. As the > constraints and methods they offer are different, they can't really be put > into the same abstraction. > > So for most cases, it seems better to let the community design options and > then, if it turns out we need standardization, decide based on the patterns > that seem most needed. > > In general, I would also advise to view the process as a slow one. We are > still at least a year away from an actual implementation of generics - if > we line up a lot of changes, to the stdlib or to how generics will work, > for immediate inclusion after that, we are likely to make decisions we > regret. Note, in particular, that applying generics to all code out there > and thus fundamentally changing the feel of the language is probably the > single largest objection to adding them in the first place. It seems > prudent to be considerate with that. > > >> >> 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/f5be31c7-1bba-41de-acae-ea46b4c744f3n%40googlegroups.com >> <https://groups.google.com/d/msgid/golang-nuts/f5be31c7-1bba-41de-acae-ea46b4c744f3n%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 on the web visit > https://groups.google.com/d/msgid/golang-nuts/CAEkBMfHG0wZ-qX_E3ZAhmKvS8FAESHpcjHz8iKEK6q1d3s5Wnw%40mail.gmail.com > <https://groups.google.com/d/msgid/golang-nuts/CAEkBMfHG0wZ-qX_E3ZAhmKvS8FAESHpcjHz8iKEK6q1d3s5Wnw%40mail.gmail.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 on the web visit https://groups.google.com/d/msgid/golang-nuts/CAEkBMfHmnz97u_paqqcj_QOQyzLaRzAve8YouZ0iuqvx_fJpeA%40mail.gmail.com.
