I think the thing everyone who likes operator overloading like mainly is
being able to do infix and postfix syntax, instead of only prefix
(function). But then also what do you do about interfaces that also
implement an operator interface? I'd guess biggest reason to not do it is
1) no human readable distinction between actual operations and one has to
decompose the code quite a lot as both types have to be known before you
can attach it to an interface
2) there is very few cases where being able to use infix operators makes
that much difference to readability, it's like you want some mathematical
notation but it's still all in lines. Chaining pass-through methods works
just as well and the types are much easier to identify before you even
fully parse it.
On Saturday, 22 September 2018 14:30:27 UTC+2, Ian Denhardt wrote:
>
> 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.
