Quoting Lucio (2018-09-21 16:15:19)
> The other thought I had, but is very poorly baked, is that the
> "essence" of polymorphism in Go operators is analogous to the informal
> definition of interfaces: it can be determined by the compiler, even
> though it is not expressed in a formal notation (the magic of
> super-types like for example "numerics" to which the addition operator
> applies).
This is a very good insight. There's no technical reason why Go couldn't
define a built-in interface, much like `error`, for various operators,
e.g.
type adder(type T) interface {
Add(T) T
}
..and then the `x + y` just becomes a shorthand for `x.Add(y)`. Note
that to express this we need the generics, because we need e.g. `int` to
implement `adder(int)`, while `uint8` implements `adder(uint8)`.
Michael Jones's reply articulates a concern that I don't see a clean way
around other than something like operator overloading: the current
proposal leaves us with redundant interfaces; you have two ways of
talking about equality, one for basic types and one for user-defined
types. Same thing for comparison (people will want to sort both ints and
user-defined types), and many of the other standard operators.
It seems like the proposal would be massively simplified by operator
overloading. Many people seem to have a general aversion to the idea,
but I haven't yet seen the problem articulated in a way that makes sense
to me. Why is it okay for `Write` to do anything from putting bits on a
disk, to sending them around the world, to adding them to the state of a
cryptographic hash function, but not okay for `==` to express equality
on anything but a small handful of types?
I have a suspicion that for many people (not necessarily), part of the
concern comes from bad experiences with the way C++ does overloading.
One problem is that it allows you to overload essentially *any*
operator, including things like `&&` and `||` whose short-circuting
semantics can't be replicated by a method. Thinking of `+` as a method
call on the other hand is an abstraction that doesn't leak.
I would like to hear a clear argument as to what is actually wrong with
operator overloading, as it isn't obvious to me and it seems like folks
are discarding a solution that has the potential to substantially
simplify the proposal, without a well-articulated reason.
--
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.
