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 is linked in the proposal issue. 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. > > -- > 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. -- 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/ACAD1B96-010D-45DE-BECB-E02C46407E75%40ix.netcom.com.
