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.
