Another way to bridge the gap between builtin and custom types could be to
have a package op that has functions that delegate to either an operator or
a method. Then you could write generic functions like
func Min[type T op.Lessable](a, b T) T {
if op.Less(a, b) {
return b
}
return a
}
For each function Foo in op, op.Foo(a, ...) would delegate to either
a.Foo(...) or to a builtin operator, and there would be an associated
interface op.Fooable. For example
- op.Add(a, b) is equivalent to a.Add(b) or a + b
- op.Len(a) is equivalent to a.Len() or len(a)
- op.Get(a, i) is equivalent to a.Get(i) or a[i]
- op.Range(a, f) is equivalent to a.Range(f) or for k, v := range a {
f(k, v) }
I don't think op.Lessable is expressible with the latest proposal though.
On Monday, 10 August 2020 at 02:29:53 UTC+1 Ian Lance Taylor wrote:
> On Fri, Aug 7, 2020 at 4:33 PM Patrick Smith <pat42...@gmail.com> wrote:
> >
> > I like the second draft for generics. It seems to me a large
> > simplification and improvement over the first draft. Considering just
> > the state of Go today, I would be quite happy with this, even if it's
> > not perfect. Thanks to Ian, Robert, and everyone else for their work
> > on this.
> >
> > Also, I would vote for square brackets over parentheses.
> >
> > But I do have concerns related to the future development of Go. In
> > particular, if we think it likely that a future version of Go will
> > allow operator overloading, then perhaps type lists are not the best
> > choice.
> >
> > To my mind, the biggest defect in the design draft is that we can't
> > write generic functions and types that work transparently with both
> > builtin and user-defined types (that do not inherit appropriate
> > behavior from an underlying builtin type). For example, we can't write
> > a
> >
> > func Min[type T ...](a, b T) T { ... }
> >
> > that works both when T is int and when T is
> >
> > type BigInt struct { i *big.Int }
> >
> > Instead, we would use workarounds such as writing two versions of Min,
> > or passing in an adaptor function or object; in the case of Min, a
> > comparison function. And that's OK, especially in an initial version
> > of generics.
> >
> > But generics would be significantly easier to use if we could write
> > functions that work on both builtin and user-defined types. The two
> > most likely candidates for allowing this seem to be operator
> > overloading (where BigInt might have a method named "<", "operator<",
> > or some such, that allows it to be used with the < operator) and
> > methods on builtin types (where int might be given a method named Less
> > with the same behavior as the < operator). Of course, other solutions
> > could be imagined, but I'll confine my speculations to those two.
> >
> > Now let's try to imagine how sorting slices might be implemented in
> > the standard library in various futures. Of course, the current sort
> > package would have to be kept and maintained for a long time.
> >
> > If Go2 implements the current draft with type lists, then we might add
> > a sort2 package containing something to:
> >
> > func SliceBy[type T](s []T, less(T, T) bool) { ... }
> >
> > type Ordered interface { // Copied from the draft
> > type int, int8, int16, int32, int64,
> > uint, uint8, uint16, uint32, uint64, uintptr,
> > float32, float64,
> > string
> > }
> >
> > func Slice(type T Ordered)(s []T) {
> > SliceBy(s, func(a, b T) bool { return a < b })
> > }
> >
> > type Lesser[type T] interface { Less(T) bool }
> >
> > func SliceByLess(type T Lesser[T])(s []T) {
> > SliceBy(s, T.Less)
> > }
> >
> > All well and good. Now say time goes by and Go3 adds operator methods.
> > Nothing in the sort2 package expresses a unified sort using operator
> > methods, so we need a new package sort3:
> >
> > func SliceBy[type T](s []T, less(T, T) bool) { ... }
> >
> > type Lesser[type T] interface { <(T) bool } // Or whatever the syntax is.
> >
> > func Slice(type T Lesser)(s []T) {
> > SliceBy(s, func(a, b T) bool { return a < b })
> > }
> >
> > (We might just add sort3.Lesser and sort3.Slice into the sort2 package
> > under different names, but I suspect the aim would be to eventually
> > deprecate sort2.)
> >
> > The effects will ripple through other code, both in and outside the
> > standard library. Suppose some Go2 code has a chain of generic
> > functions A calls B calls C calls D, where each exists in two
> > versions, one for builtin types and one for user-defined types, and
> > the two versions of D call sort2.Slice or sort2.SliceByLess. When Go3
> > with operator methods arrives, if we want to unify these, we have to
> > write a third version of each of A, B, C, and D, where D calls
> > sort3.Slice.
> >
> > On the other hand, suppose Go2 has type lists and Go3 gives builtin
> > types methods corresponding to operators. Assuming the name Less is
> > used for <, sort2.SliceByLess now handles both builtin and
> > user-defined types, so we don't need a sort3 package. And in the ABCD
> > scenario, we can just keep the SliceByLess version of each, and
> > quietly let the sort2.Slice versions vanish as they become unused.
> >
> > [Important point===>] This means that if Go2 has type lists in
> > interfaces, there will be a strong incentive for Go3 to give builtin
> > types methods, even if we think that operator overloading is otherwise
> > a superior solution, because operator overloading will require much
> > more new code to be written.
> >
> > Instead of using type lists, suppose Go2 allowed interfaces to require
> > the presence of specific operators. Then the sort2 header might look
> > like this:
> >
> > func SliceBy[type T](s []T, less(T, T) bool) { ... }
> >
> > type Lesser[type T] interface { <(T) bool }
> >
> > func Slice(type T Lesser)(s []T) {
> > SliceBy(s, func(a, b T) bool { return a < b })
> > }
> >
> > type MLesser[type T] interface { Less(T) bool }
> >
> > func SliceM(type T MLesser[T])(s []T) {
> > SliceBy(s, T.Less)
> > }
> >
> > (Note that the first part is identical to the previous sort3 header.
> > But in Go2 we also need MLesser and SliceM in order to handle
> > user-defined types.)
> >
> > This leaves us more easy options in Go3. If Go3 implements operator
> > overloading, then sort2.Slice now handles both builtin and
> > user-defined types, and code using sort2.SliceM can be allowed to
> > wither away. If Go3 implements an int.Less method, then sort2.SliceM
> > is now the good version, and code using sort2.Slice can be allowed to
> > wither away as it becomes unused.
> >
> > So maybe the alternative of allowing interfaces to require specific
> > operators deserves another look, to see if it's really not viable in
> > Go2. I would suggest that perhaps the initial version of generics need
> > not support all operators; maybe it's enough to support only those
> > that apply to numeric types (string should be accepted by interfaces
> > requiring +, <, and other comparison operators). Or maybe a slightly
> > larger subset of operators would do.
> >
> > As a final note - this post, like all speculations about the future,
> > is rather fuzzy. I realize that. Nevertheless, I think it is important
> > to realize that the choices we make now carry consequences for our
> > options after a few years' time.
>
>
> Thanks for the detailed comment.
>
> I think the key statement in your argument is this one:
>
> > But generics would be significantly easier to use if we could write
> > functions that work on both builtin and user-defined types. The two
> > most likely candidates for allowing this seem to be operator
> > overloading (where BigInt might have a method named "<", "operator<",
> > or some such, that allows it to be used with the < operator) and
> > methods on builtin types (where int might be given a method named Less
> > with the same behavior as the < operator). Of course, other solutions
> > could be imagined, but I'll confine my speculations to those two.
>
> I think this is open to question. In C++, for example, std::sort
> takes an optional comparison class. In effect, the default if no
> comparison class is provided is to use operator<. That is a
> reasonable and appropriate choice for C++. But Go does not have
> function overloading and does not have default values for arguments
> (https://golang.org/doc/faq#overloading). So the natural way to write
> a sort function is to provide a comparison function. That is how
> sort.Slice works, for example. sort.Sort works differently because it
> needs three different functions, so they are passed in via a type
> rather than as an argument. In typical use, people will convert to
> that type when they call sort.Sort, so they are providing the required
> functions via a type conversion.
>
> If we accept this argument, then in Go it wouldn't be appropriate to
> write a single function that works on both builtin and user-defined
> types. Writing such a function would be relying on some sort of
> default comparison function, which is not the typical Go approach.
>
> So instead we need to ensure that it is very easy to pass a comparison
> function, regardless of whether you are using a builtin type or a
> user-defined type. And I think that that is already true.
>
> Ian
>
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/f60e0dc5-60ea-4c82-9309-d55fb1b9b3adn%40googlegroups.com.
