Hi Everyone,
I saw the well written 16 June 2020 blog post The Next Step for Generics <https://blog.golang.org/generics-next-step> by Ian Lance Taylor and Robert Griesemer too. I agree, many people have said that Go needs generics, but we don’t necessarily know exactly what that means. If it means introducing generics into Go using interfaces as suggested by Arnaud Delobelle maybe that's OK. But If it means doing something like C++, Java, Erlang, Perl, Python, Lua etc then I hope it never ever happens. I also agree that it's important to ask if adding generics feels like Go? I thought Go was a reaction to the C++, Java, others etc programming languages of the 1990's where their use of generics added significant complexity to both semantics and implementation. I know for some Go users having no generics sucks, but in my limited experience this happens rarely. Maps, slices, channels and interfaces are built in generic data structures and address many of my common use cases. Go is the first language I've learnt. What I really liked about it is its “less is more” approach. So far I'm not missing user-defined generics. I have gotten on fine without it. But if it is added at some point I will be forced to implement it because everyone else is, and that is something I am not looking forward to. I see NOT having user-defined generics as a critical positive feature of Go and not something that is missing. Rather than focusing on what we can add to Go, maybe we should focus instead on how we can further improve Go by what else we can remove from Go? Tom On Wednesday, June 17, 2020 at 3:10:08 PM UTC+10, Ian Lance Taylor wrote: > > On Tue, Jun 16, 2020 at 1:54 PM Arnaud Delobelle > <arnaud....@sparx.co.uk <javascript:>> wrote: > > > > I noticed today the blog post about the revised Generics proposal. What > got me excited is this extract at the start: > > > > The biggest change is that we are dropping the idea of contracts. The > difference between contracts and interface types was confusing, so we’re > eliminating that difference. > > > > To me the lack of orthogonality between contracts and interfaces was the > major issue with the previous proposal and I have been musing with ways of > resolving it for a while, so I am very pleased that the proposal is going > down this path! > > > > Last month I decided to write a post about a way of introducing Generics > into Go using interfaces, which I called "Package Specialization". > > > > Headline features are: > > > > use interfaces to express parametric types; > > no new keyword; > > the only new syntax is “package specialization”: pkg(T=int, > Y=*MyType).Func(); > > generic code which doesn’t use the package specialization syntax is > already valid Go. > > > > The full post can be read here: > https://arnodel.github.io/marooned/go/generics/2020/06/06/go-spec2.html > > > > I was toying with the idea of submitting it here for feedback, to try to > move the discussion in that direction. Well, I guess today's updated > proposal steals my thunder! Essentially this is the same idea, but with a > different manifestation in the language - I thought that submitting it > anyway may provide a useful comparison point to help gauge the updated > proposal better. > > > > Note that sadly, I do not have much time to polish a proposal or to > follow discussions in general on this or other golang-related discussion > lists, so I apologize in advance if I am inadvertently re-hashing ideas > that have been put forward and dismissed in the past, or if my blog post is > a little low on detail (it was meant to be an exploration of a possible > approach). > > Thanks. I hadn't seen that before. > > A difficulty with package specialization is when you want to write a > List(List(int)). That is, a List where each element of the List is a > List(int). Or, when you want to write a transformation function as in > > https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#list-transform. > > > It would seem to require some modification of how imports work in Go, > and that leads into considerable complexity. See also > . > https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#why-not-put-type-parameters-on-packages > > . > > Ian > -- 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/3d3f261f-cc94-4346-b31b-c6f740b133e4o%40googlegroups.com.
