Thanks for the thoughtful response.
> I'm still strongly in favor of not having it. In particular, there is a large
> section of conceptual overlap between interfaces and constrained
> type-parameters. And at least as far as function parameters go, an interface
> parameter can always be re-written into a constrained type-parameter. At
> least as long as we live in this overlap, it seems very confusing to have two
> separate names for what is very much the same thing - specifying a subset of
> valid types to use. It also has technological downsides, because if you
> already have an `io.Reader` interface, you also need to have an equivalent
> contract (or whatever we call this constraint kind) and vice-versa, if a
> concept is more naturally translated one way or another.
You make some very good points. I'm inclined to agree (leaving type
lists aside for now).
> IMO the discussion about this is purely based on the idea of type-lists which
> exists purely so as to support operators on type-parameters. And personally I
> feel a better way to solve this solution would be to just drop that from the
> design. IMO, the utility of this isn't really worth the cost. Especially
> given that there's no way to write a function to work with *either* methods
> *or* operators, so the actual practical utility is pretty small. Arguably you
> need two copies of any function working with - one for "primitel types" using
> operators and one for "composite types" using methods. That seems… inelegant
> to say the least and I'm not convinced that it's better than to require
> people to add a method to "primitive types" to use them in generic code.
I also really don't like the fact you'll need two different versions
in a lot of cases (eg: Min for builtin types, and Min for complex
types). Given this, I think it's fair enough to want to drop type
lists from the design.
> And IMO a more orthogonal solution to allowing use with "primitive types"
> would be some form of operator overloading or endowing predeclared types with
> suitable methods - either would allow us to actually write generic code that
> could work with both primitive and composite types, without needing us to
> introduce a separate way to specify constraints.
Ian has said that adding operator overloading would be a "big change
to the language", which is true. But so is adding generics, so we
could try to do it "while we're at it", as it seems like these two
features (using interfaces as type constraints, and operator
overloading via methods/interfaces) would work really well together.
Alternatively, like you suggest, we could just drop type lists and
punt that problem for now. (I realize it doesn't allow using operators
in generic functions.) It seems much better to go with a restricted
feature set than to go with this whole new thing (type lists) that
just doesn't fit in very well. Go often punts useful features that
don't seem to fit, like handle {} for errors, or try(). We could
always add them in later once people have more experience with "basic
generics", or take a different track like operator overloading, or
maybe something completely different.
> I think that's very likely. So far, in the 6 weeks I've been thinking about
> how I'd use generics in Go, I have not considered a single use-case that uses
> operators - and they all either used no constraints at all or pre-existing
> interfaces or `comparable` (but even there, only for use as map-keys, not for
> the actual comparison operator).
Yeah, if we dropped type lists, "comparable" is the one constraint I
think we'd still need to be useful, because it enables you to use type
constraints for map keys, as well as for the likes of a slices.Equal()
function. So what about simplifying the proposal to only allow
interface constraints or the single built-in "comparable" constraint?
At least in my usage, being able to write type-safe generic containers
and channel functions would be a great start, and more important than
being able to write a Min() or an Add() function that works across
various built-in types.
> PS: Just for posterity, I do think this has been discussed at least a little
> bit:
> https://groups.google.com/forum/#!searchin/golang-nuts/type-list|sort:date/golang-nuts/jpw7ndLrjtQ/w20lhwVIAQAJ
> https://groups.google.com/forum/#!searchin/golang-nuts/type-list|sort:date/golang-nuts/CYMIK-Ojvi8/P6eos__vAAAJ
> https://groups.google.com/forum/#!searchin/golang-nuts/type-list|sort:date/golang-nuts/IABU_sD6SsA/xjMNy73kBgAJ
> (maybe others, this is just a very cursory search)
Thanks! Appreciate those links. I had seen Brent Mills'
"Orthogonalizing Type Lists" a while back, but I'll read it again.
-Ben
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CAL9jXCGmxjTqi49U3yhUfPDYvbSXQbkrUYBZ_N%3DxdOe3mMMxUQ%40mail.gmail.com.
