One thing I've always liked about Go is the ability to define your own
types based on the built-in ones. Although the built-ins don't have methods
themselves, you can still add them to your own types and satisfy interfaces
in that way.
This enables us to define simple collection types such as stacks and queues
whose underlying type is a slice of values and give them methods such as
Push, Peek and Pop. We then no longer need to think about how to achieve
these operations by operating on the slice directly.
The trouble at the moment is that if you want, say, a stack of ints or a
stack of strings, you either have to copy what is essentially the same
code for each type or use interface{}.
If generics is added, you'd just need to declare your variable to be a
stack(int), stack(string) or stack(whatever) and you'd then have a
type-safe, performant container without further ado.
Now, even if there was only one constraint - declaring that a type was
'Comparable' i.e. supported the == and != operators, I still think that
generics would be worth adding for all the scenarios which that would
enable.
You only need to look at the standard libraries of other popular statically
typed languages such as Java and C# to see what can be achieved with little
or no constraints.
However, in an ideal world, there's lots of other stuff you'd like to do as
well and this is where the problems start. To take a very simple example,
if you want to write a generic Sum function which can sum the values of a
slice of any numeric type, then you need to use the '+' operator and you
therefore need some way of telling the compiler that you only want to use
types which support that operator.
Now (ignoring 'string') the only types which do support '+' are the
built-in numeric types (integer, floating point, complex) and any types you
define yourself based on them.
There's no way that your generic Sum function can deal with big.Int because
it doesn't have a '+' operator and Go doesn't support operator overloading.
Using an 'Add' method instead won't work as int, float64 etc. don't have
methods.
So, when Thomas says in his post that numbers are a problem - he's right,
they are - and, in particular there's a dichotomy between the built-in and
user-defined numeric types.
However, I don't think this is a reason for giving up altogether on this -
it's still useful to have generics for the built-ins only. But you do need
to come up with a constraint system which is simple enough for everybody to
understand but expressive enough to do what you want and I have faith that
the Go team will eventually converge on such a system even if the initial
draft (IMO) falls short on the simplicity front.
In response to worries that a large Go team won't be able to work together
if some use generics and some don't, I would make these points:
1. In my experience of various other languages, most folks don't write
their own generic types/functions - they just use a library. I don't
necessarily see it as a problem if one programmer prefers to use a generic
library and another uses a non-generic library and, as I said earlier, I
suspect the latter might be less adverse to generics when they see how
convenient they are to use.
2. There is no way that the Go team are going to adopt generics in such a
way that it is not a good fit with the rest of the language. So any worries
that Go is going to end up like C++ (with everybody using a different
subset of the language) or Python (with the version 2/3 split) are
unfounded in my opinion.
Alan
--
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.
For more options, visit https://groups.google.com/d/optout.
