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.
In that case, the type of Max (and also the type of max) would be something like "[for_all T assignable_to Number] func(T,T) T".
"Number" would be something similar to a "built in psudo-interface type", and "assignable_to" would be a generalized version of the criteria at http://golang.org/ref/spec#Assignability
On Saturday, November 29, 2014 1:10:18 PM UTC+7, Dave Cheney wrote:
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'm sure it's interesting to others, but not to me; maps and slices
work just fine.
What is interesting to me is writing generic functions, the simple
example is Max. I want to write a Max function that _only works on
numbers_. It isn't sufficient to say
func Max(a, b T) T
Generics cannot be added to the language without also adding support for inheritance, aka subtyping.
--
How does an interface help me write a max function that only operates on numbers? Interfaces only specify behaviour, not data.
type Foo [T]interface {
Something() T
}
type Bar [T3][T2]interface {
Foo[T2]
Something2() T3
}
type NonGeneric interface {
Bar[int][string]
}
How does an interface help me write a max function that only operates on numbers? Interfaces only specify behaviour, not data.
--
Generics cannot be added to the language without also adding support for inheritance, aka subtyping. Go does not support inheritance so generics cannot be added.
Well said +1.Go team created Go to solve their problems in `Google` scale.If they needed generics, they should have implemented by now.Wonder what kind of real problems cannot be solved by not having generics.
On Sunday, November 30, 2014 6:00:38 AM UTC-5, Gyu-Ho Lee wrote:Well said +1.Go team created Go to solve their problems in `Google` scale.If they needed generics, they should have implemented by now.Wonder what kind of real problems cannot be solved by not having generics.Just for starters, code reuse.
> On Sat, Nov 29, 2014 at 9:23 AM, Dave Cheney <da...@cheney.net> wrote:
>>
>> Generics cannot be added to the language without also adding support for
>> inheritance, aka subtyping. Go does not support inheritance so generics
>> cannot be added.
>>
>> It's as simple as that.
>>
>>
>> On Saturday, 29 November 2014 14:21:06 UTC+11, Theemathas Chirananhavat
>> wrote:
>>>
>>> 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?
>>
Function overloading _is_ important to be able to support generic
functions, but without some notion of inheritance, it would be deeply
flawed.
The problems are:1. code reuse.
Right now I am editing the type information for the value of a Set struct everytime I use it within a project that uses a different type. Basically I'm using the original like a template. That is no good.
2. Set theory. Anywhere I feel the builtin types(array, slice, map) are not flexible enough.
3. This issue is common among all my work.4. Yes. Some class of generics would be useful. The problem is that every time this subject is broached it gets generalized into countless different models. The model I'm most interested about in regard to generic programming is type parameterization. And Yes, this would be the best solution, the only other solution would be to rewrite each package everytime I need to use a different type. Using the silly interface hack works but is very inefficient.
That's an intriguing approach.For that last bit:max := Max<int>How to handle it with multiple types in the func? I suppose Max<...argTypes, returnType>.Also, what about in the case of methods, or in the case of some parameters (or the return type) being concrete and some generic?
I think that one way to handle this would be to extend the structural
typing of interfaces. We could say that a generic function Max can
only be instantiated by types that support all the operations used in
the body of the function. So if you write
func Max(a, b T) T {
if a > b {
return a
}
return b
}
then Max can only be used with arguments whose types that support the
< operator (integer, float, string types). In other words the
permitted instantiating types are determined not only by the function
signature, but also by the function body.
You can just use a type coercion:
max := (func (int) int)(Max)
This is more or less what the compiler would have to do to handle, e.g., Max(5, 6).
> There are indeed many details to consider. This is really just the
> first level of detail.
Indeed.
It strikes me that Go doesn't have generics not because they're not useful, but because the designers don't like them! Which is basically what they've said in a number of forums and in other threads about generics.
We haven't yet found a design that gives value proportionate to the complexity, although we continue to think about it.