You've missed a few years of discussion on the topic. A search through the group archive will be interesting for you.
You also missed "go generate", which is new scaffolding for the general task of generated code.
--
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.
For more options, visit https://groups.google.com/d/optout.
Most of the arguments for adding generic to Go is to support
collection types, sets, tries, etc. That isn't very interesting to me,
I think you have chosen a particularly problematic example there. I personally think that it would be fine to add generics to Go without providing the capability to perform arithmetic operations directly on generically typed values. That's the approach taken with interfaces (with the exception of ==) and it works well.
I don't see that subtype polymorphism is necessary or desirable in Go-with-generics.
My worry about generics is that everyone will instantly carry across their design patterns from other languages and we could lose the first order simplicity that most Go code currently exhibits.
But interfaces only specify behaviour, not data. This is the "boxing" issue that rsc referred to.
If Number was an interface that could hold any numeric type it would have to be 128 bits wide to accommodate the largest numeric type that Go supports.
Additionally if this Number interface was some sort of built in, how would it be extensible for other user declared numeric types like type Complex64 { real, image float32 }
Ultimately the reason I believe Go 1.x will not have generics is the overwhelming number of limitations and edge cades like these.
You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/smT_0BhHfBs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to golang-nuts...@googlegroups.com.
Right, so now you are talking about adding operator overloading to the language.
This is why Go does not have generics, not because they are useless or a bad idea, but because implementing them well (there is no interest in a half baked implementation) would be such a fundamental change to the language that it is likely the core values of the language would not survive.
If you think you can use interfaces to do anything practical, how do you write a type-safe function that reverses a slice of anything?
Seriously, I don't understand why is it so hard to add generics to go. You might say that you don't need it, but library writers would definitely want generics. A language cannot be successful without good libraries.From what I have read (e.g. https://golang.org/doc/faq#generics "Generics are convenient but they come at a cost in complexity in the type system and run-time."), there seems to be two types of problems about generics: (1) syntax and semantics (2) implementation and performance. However, both don't look like real problems to me.As for syntax and semantics, the go interface system is already pretty similar to haskell's typeclasses, so I think it should be relatively easy to model generics after haskell's polymorphism.As for implementation and performance, it probably wouldn't be much different from the existing implementation of interfaces, which is already sort of partially implemented generics.Did I miss anything? Is generics really that problematic?
Agreed! Generics is needed, and Go is not "sort of" generic. If it was, someone could implement something similar to LINQ.
Actually, that library demonstrates the problem caused by the lack of generics.From https://golang.org/src/pkg/sort/sort.go lines 233-237:(start code)type IntSlice []intfunc (p IntSlice) Len() int { return len(p) }func (p IntSlice) Less(i, j int) bool { return p[i] < p[j] }func (p IntSlice) Swap(i, j int) { p[i], p[j] = p[j], p[i] }(end code)
What if you want to sort "[]int16" or "[]int32" or "[]int64" or "[]uint16" or "[]uint32" or "[]uint64"?You would have to copy and paste most of that code. If you want to sort "[]Time"? One more duplication. For tasks more complicated than that, it would quickly become unmanageable.