Quoting Dean B (2018-10-11 14:58:01)
> Yeah that's why I was about how operators were the primary reason
> interfaces couldn't work out. Your proposal doesn't include operators,
> which was the reason interfaces aren't used. Syntax in Go is pretty
> important, which I imagine is the reason that operators didn't work
> out.
As it stands, I don't really feel like the draft design's solution re:
operators is better than just punting on them. Much of this discussion
is already in my proposal, but:
You still have to either write different versions of your code for types
that support `<` and types that support `.Less()`, or only support one
of these.
Supporting the former means your code can only ever work with basic
types, and I don't feel like the meager extra expressiveness you get
is worth the complexity.
The extensible option is to only support the latter, and if you have
a function that expects something with a `.Less()` method, and you want
to pass it an int64, you define a wrapper type around the int64.
I would imagine in this scenario before long someone would write a
package with a standard set of wrappers around the basic types, covering
the boilerplate once and for all:
```
package ops
type Int64 int64
func (lhs int64) Less(rhs int64) bool {
return lhs < rhs
}
..
```
It probably makes sense in this case to just have part of the generics
design be to add methods to the basic types that are aliases for the
operators, so we can skip the above.
> I'm working on another proposal with a `self` type introduced which
> should be simple. The issue with a `self` type is that interfaces are
> comparable with every other comparable value, so it can't be used in
> that case... I'll figure something out haha.
I considered adding something like self, but my proposal is actually
able to cover the cases where you'd want self as is. Again, this is in
the proposal:
```
// The ordered interface is parametrized over another type. You could
// define a type A that implements Ordered(B), but see below.
type Ordered(type T) interface {
Less(other T) bool
}
// Sort is still able to constrain its parameter to only types which
// implemented Ordered *for themselves*, so it would not accept an A
// which implements Ordered(B). I believe this solves the problems
// that you would want 'self' for, without adding an extra construct.
func Sort(type T Ordered(T))(slice []T) {
// ...
}
```
--
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.
