Lucio <lucio.d...@gmail.com>:
> Method overloading opens the kind of can of worms Go has been very good at
> avoiding. Once the compiler needs to recognise the applicable instance of a
> method or function by its signature or even worse by parts of its
> signature, a lot of guarantees fly out of the window. I don't think I would
> like that.
I'm putting together an experience report on my large translation from Python
to Go. I list some minor additions to Go that are motivated by this experience
for readability and to narrow the semantic gap, but method and operator
overloading are *not* among them; in fact my draft calls out operator
overloading
as a feature best left behind.
I judge Go's mimnimalism is the right thing here.
--
<a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>
My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.
--
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.
