Quoting Patrick Smith (2018-10-16 19:21:35)
> If overloading [] were disallowed, how would one write a generic
> function taking a single argument of type either []int or a
> user-defined type with similar behavior, and returning the sum of the
> elements? Sort of the marriage of these two functions:
Right now there are some common conventions for "iterators" in go, that
if generics entered the language I would expect to end up being written
up and specified more explicitly; I could see some interface like:
type Iterator(type T) interface {
// Same idea as e.g. database/sql.Rows.Next
Next() bool
// Get the currently focused value.
Current() T
}
..and then:
sum := 0
for it.Next() {
sum += it.Current()
}
For slices, you'd end up writing something like:
it := IterSlice(s)
// ...
Where IterSlice returns an iterator for slices. While in general having
to wrap e.g. int, float in OrderedInt, OrderedFloat types sounds painful
to me, this doesn't seem too bad -- and it has a real advantage, as it
covers this use case while being a bit more generally applicable.
My instinct here is to be conservative; we've got a boatload of use
cases for < and ==, a few obvious ones for +, *, / etc, and a long-tail
for operators after that. Eric's proposal makes it trivial to add more
operators to the list of allowed ones, but it's always harder to go the
other way. So my inclination would be to implement this for operators
like `<` that are kinda screaming at us, and then build some experience
with that.
--
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.
