Is there a final document on generics?

[Haddock]

Hello,

I have lost a bit oversight how generics will look now in the final proposal that was accepted and is serving as the guideline to implement generics for Go 1.18 or later. There were too many proposals and discussions about them that I lost track.

Is there some final document that describes how generics will be implemented in the end? Couldn't find any searching the Internet.

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.

Thanks, Archilbald H.

[Axel Wagner]

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...@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.

[Robert Engels]

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 <golan...@googlegroups.com> wrote:



To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAEkBMfHG0wZ-qX_E3ZAhmKvS8FAESHpcjHz8iKEK6q1d3s5Wnw%40mail.gmail.com.

[Axel Wagner]

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 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.

[Jan Mercl]

On Tue, Mar 16, 2021 at 1:10 PM 'Axel Wagner' via golang-nuts
<golan...@googlegroups.com> wrote:

> On Tue, Mar 16, 2021 at 1:05 PM Robert Engels <ren...@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.

It would be probably a huge mistake to follow the views of anyone
constantly preaching Java in a Go mailing list. Sometimes with little
understanding of the rationale behind the differences.

[Robert Engels]

Your snotty attacks are duly noted. Says a lot about you. Find me an engineer that doesn’t build on the backs of others and I’ll show you a very poor engineer.

The collections api was provided along with the delivery of generics in Java for two main purposes: it dissuaded the proliferation of competing packages (Guava and Apache not with standing) to provide consistency in learning and usage and the code served as a reference example of how best to do generics as it was written by language experts intimately familiar with the design/implementation.

> On Mar 16, 2021, at 7:22 AM, Jan Mercl <0xj...@gmail.com> wrote:
>
> On Tue, Mar 16, 2021 at 1:10 PM 'Axel Wagner' via golang-nuts

[Haddock]

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 branch.

This is a good link, pretty much the those generic collections I was looking for.

[Markus Heukelom]

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.

[Amnon]

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.