One of the things that attracted me to Go in the first place was its lack
of function/method overloading!
Having programmed for many years in other languages that had this feature,
I'd concluded that it was both confusing and difficult to compile because
of potential ambiguities in deciding which overload should be called,
particularly where literals were being passed as arguments. This required
the compiler to follow very complex rules to determine 'the best fit' and
the user needed to have at least some knowledge of these rules to avoid
falling into the trap of calling the wrong overload.
Most of the reasons why people want function overloading at all can be
satisfied by the simple expedient of allowing optional parameters and, as
long as these always occur at the end of the parameter listing, they're not
particularly confusing or difficult to compile. However, even optional
parameters have their problems. For example if you've written a library for
other people to use and you decide to change the default value of an
optional parameter, then this may break their code.
So on balance I think it's best to be explicit and not allow even optional
parameters. If you're designing a function which will need to take a lot of
parameters, then you can use a struct for some of them which can of course
be initialized by setting only a few of its fields and leaving the others
with their 'zero' values.
If you think of an operator ('+' for example) as being shorthand for a
system defined method (say _plus), then what we currently have in Go is
basically a form of generic programming where the type parameter represents
one of the built-in types which supports that particular operator. So you
can add two ints, two float64s and so forth. So operator overloading is not
really the same as function overloading at all
However, sometimes a bit of function overloading creeps in as '+' can be
used not only as a binary operator but also as a unary operator (i.e. a ==
+a).
Now this is both convenient and unsurprising for the built-in types but it
can be confusing if you allow people to define operators for their
user-defined types where their use may be surprising and unintuitive for
other people reading or maintaining the code. In my experience with other
languages, operator overloading is best restricted to mathematical objects
where those operators are in common use and therefore unsurprising to
programmers in such disciplines.
The trouble is, of course, that once you allow operator overloading, you've
let the cat out of the bag and folks will use it for all kinds of stuff for
which it's not really suitable. I'm not therefore surprised that the Go
designers decided to disallow it.
I'm not even sure that it would help all that much with the Go 2 generics
design as there are some aspects even with the use of operators for the
built-ins which are difficult or tedious to express in any generic
constraint system.
Alan
On Sunday, September 9, 2018 at 2:58:24 AM UTC+1, Rick wrote:
>
> With recent discussion concerning the possible introduction of generics in
> Go 2, it occurs to me to ask about support for operator overloading in Go
> 2. By this I mean support for functions having the same name but different
> signature:
>
> func foo(x int) int ...
>
> func foo(x string) bool ...
>
> func foo(x int, y string) ...
>
> etc.
>
> Is support for operator overloading implied by support for generics? Is it
> possible to have one with the other? To be honest, I've been more bothered
> by the lack of operator overloading than by the absence of generics. And (I
> assume) no new syntax would be required to support overloading. Or would
> there?
>
>
>
--
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.
