In my opinion the interface represents the simplest way to allow operator
overloading. With an inbuilt interface that covers all the symbols and some
sort of category to break them down (boolean logic, binary logic,
arithmetic, misc unary, prefix infix and postfix). Then you can have the
built in interfaces for 'countable', 'comparable', etc etc.
The thing that is the sticking point for me is that when I look through c++
code very often all of these things are implemented in a type but never
used, only constructors and sometimes destructors. I would think that
creating a special named function for classes, like a built in interface,
for initialisation and cleanup would be useful, something that triggers at
the end of scope unless the pointer is owned by another name somewhere, and
satisfy a lot of these issues. As for being able to take a big.Int and + it
with another thing, honestly, the amount of code you have to write with
these types is really so small the benefit probably doesn't even pay off
unless you are doing a LOT of big number math in a long algorithm, for the
cost in declaring the operators compared to just using the function
notation.
On Saturday, 22 September 2018 08:53:14 UTC+2, Lucio wrote:
>
> "Google ate my homework, sir!"
>
> Let me try again...
>
> On 9/22/18, Ian Denhardt <i...@zenhack.net <javascript:>> wrote:
> >
> > 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)`.
> >
> This seems itself a very neat approach, in the light of my own intuition.
>
> > 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.
> >
> The concern I have heard voiced (and agreed with) since the first
> release of C++ is that operator overloading creates too great an
> opportunity for obfuscation and some may find it irresistible, not
> only intentionally, but with malicious intent.
>
> It is a civilising feature of human nature not to release weapons of
> mass destruction upon an unsuspecting audience. One also does lose
> opportunities in the process and we may be on a cusp right now in
> exactly this way.
>
> > 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.
> >
> Operator overloading, perhaps even a more disciplined equivalent, does
> not seem to be sufficient to encompass the entirety of the generics
> problem, but it helps to identify the need for an extension to the
> "type" concept that the C++ "class" does not define adequately, but
> almost certainly aspires to.
>
> I think the approach by Ian above is a step in the right direction: a
> formal description not just of a "type" concept, but of practically
> any language element in Go that permits us to add attributes to
> objects that are not yet covered by existing notations. That is Go's
> contribution to programming notations, a disciplined approach such as
> would be essential to discourage, not prevent, the obfuscation made
> possible by "operator overloading".
>
> In a way, after all, generics are exactly that: each a unique
> operation applied to different "type instances" (in defined
> combinations) that are expected to have specifically *that operation*
> in common. Or, more appropriately, *that operation* is conventionally
> believed to serve analogous purposes in different, but also similar,
> "namespace" described by their parameters.
>
> In seeking to formalise the mechanism to declare the common
> properties, we also identify the differences, such identification
> being itself a formalisation. That is the uncharted territory we can
> no longer ignore and Go is a door opening into that territory. I don't
> think what will be discovered there will leave Go unscathed: I think
> there will have to be incompatible adjustments, I'm not sure that the
> Go developers have a fall-back plan when their stated intention to
> retain backwards compatibility with Go 1 is proven (if it is) to be
> impossible to attain.
>
> But the core essence of Go is its simplicity. As long as it remains an
> objective and everything possible is done to retain such simplicity as
> far as possible, Go will remain the pioneer in its field.
>
> On personal note, at this point there has been a lot of talk around
> generics, one may well be led to believe that Go 2 is "just Go with
> generics" (error handling in Go 1 is quite good enough for me, I only
> gave a cursory glance to the proposal on enhancing that aspect of Go -
> nothing else has caught my attention), which does not do the language
> and its inventors and developers justice.
>
> I feel Go 1 missed an opportunity to assimilate the principles
> espoused by E.J. Dijkstra, in return for which they have provided the
> eminently pragmatic language we can actually use without being
> mathematically minded. I am hoping a second generation Go, or maybe
> even a fork of it, will find more in "The Discipline Of Programming"
> to incorporate. It is not the Gospel, it was at the time mere prophesy
> :-). Today, we can put it to the test and also improve on it even
> further than Go did ten years ago.
>
> Lucio.
>
--
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.
