The thing that people are concerned about is creating a construct that
enables you to write legal but confusing and unclear code. Let's say we
steal triple equals ===, and then use it to mean some kind of special
assignment operation. Or we make = become an addition operator infix for a
string-related type.
Interfaces don't cover the case of operator precedence, interfaces are all
verb subject object. Operator precedence is a syntactic layer that does not
have at least an easily inferred type and require deeper analysis of the
AST before you can get the types right. The bigger reason to not allow
constructs like this in Go is because one of its main advantages is simple
parsing, which means tooling and nearly interactive speed testing. Go even
can use spaces (or not) to override precedence. Either the implementation
forces each operator symbol to be of only one precedence relation to
others, or you are leaving out milk and cookies for the kinds of
programmers that make people want to invent a language like Go.
The case for equality operators is a pretty good one though. The reason why
an infix operator is preferable for equality operations is because both
operands are being tested for equality. It doesn't matter which order,
unlike verb subject object of function notation. + is already used for
string concatenation, logically it could and probably should also apply to
any type of sliceable array type.
I am against a wide open operator override system, most especially one that
allows the disruption of the conventional order of precedence for the
operator. But a small set that is declared like an interface and only
covers a very small subset, the most useful ones, like +, ++, --, !=, ==,
<, >.
A central pillar of the design process of Go is all about avoiding
complexity where flexibility can substitute and not add an excessive and
questionable cost for an operation that is not that commonly used
especially when it decreases the approachability of code. Overloaded
equality, increment and comparision operators would not increase the
ambiguity for either humans or the source code. If you can assert the type
of an operator from only one of its operands this is less parsing than a
case where you have to disambiguate both. Type casting should never be
implicit, so for a Go version of operator overloading, there would not be
conversion involved - a full parse showing differing types on an operator
operand would thus be illegal. Unless both operands are both implementors
of the same countable interface, for example, and they either use
interface{} or a defined interface name as returns/inputs. I think that
this is a step further on from just allowing redefinition of (some)
operators to bind to new types, and to allow those types to create
assignment channels, for example. And this is where the big syntax bugbear
appears. Overriding an operator is one thing, but defining two types as
being comparable and assignable with each other will pretty quickly grow
into a hella boilerplate for a shortcut used 10 times in a 1000 line
project, and ever growing compilation times.
Go is a simple language, and anything that will take away the simplicity,
with its benefits in learning, reading and compiling, will and should be
rejected as an addition to the language spec. I would argue that a small
set of infix operators and maybe some unarys would not create such
complexity. Especially if we restrict it to unary post/prefix, addition,
subtraction equality and assignment, and don't change the precedence rules.
Really, precedence would not be relevant, and there should not be any
ambiguity allowed in how an overridden symbol can be used. Precedence
really only irritates everyone between add/subtract and multiply, square,
and only for countable types. To stop complexity creeping into the parser,
also, no change in the rule about casting. No implicit casts. Implicit
casts are probably one of the most irritating and pervasive features of C
type languages. I always have to double and triple check. Even between some
version changes C++ has substantially disrupted the rules about it and I
just don't think that implicit casting is a good construct in a language.
Implicit typing through inference does not have this problem.
On Sunday, 23 September 2018 08:35:15 UTC+2, Robert Engels wrote:
>
> Issues like these highlight the deficiencies of Go compared to Java. The
> Java designers understood languages far better, and from the start realized
> that identity and reference equality were different concepts. Everyone in
> Go land are debating these solved issues. Pick and chose what you want to
> implement but there doesn’t really need to be a debate on how to do it.
>
> Sent from my iPhone
>
> > On Sep 22, 2018, at 8:52 PM, Ian Denhardt <i...@zenhack.net
> <javascript:>> wrote:
> >
> >> On Saturday, 22 September 2018 16:47:00 UTC+2, Louki Sumirniy wrote:
> >>
> >> 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).
> >
> > My own reason for wanting this is not really about syntax, so much as
> > being able to define functions etc. which e.g. check for equality,
> > without having to write too versions -- one that uses `==` and one
> > that calls some method custom types. The syntax isn't really the point;
> > there's an underlying notion of equality that we want to be able to talk
> > about for more than just built-in types. We could define an interface
> > for this:
> >
> > // The Equatable interface wraps the basic Equals method.
> > //
> > // x.Equals(y) tests whether x and y are "the same." The predicate
> > // Equals should obey a few common sense rules:
> > //
> > // 1. It should be reflexive: x.Equals(x) should always return true
> > // (for any x).
> > // 2. It should be symmetric: x.Equals(y) should be the same as
> > // y.Equals(x)
> > // 3. It should be transitive: if x.Equals(y) and y.Equals(z), then
> > // x.Equals(z).
> > //
> > // It generally does not make sense for a type to implement
> > // Equatable where the type parameter T is something other than
> > // itself.
> > type Equatable(T) interface {
> > Equals(T) bool
> > }
> >
> > What I am suggesting is merely that `==` desugars to a use of this
> > interface.
> >
> > An important litmus test for any operator we consider for overloading is
> > whether we can come up with a clearly specified interface for it like
> > the above. If not, it does not make sense to allow the operator to be
> > overloaded, since it is not clear what overloaders should do. I believe
> > this is the source of most of the problems with operator overloading in
> > other languages.
> >
> > I think if we stick to this things will stay under control; there's
> > currently nothing stopping folks from defining an instance of
> > io.Writer that does something utterly in conflict with what is described
> > in its documentation -- but that hasn't seemed to be a problem in
> > practice.
> >
> > Quoting Michael Jones (2018-09-22 13:14:21)
> >> the reason i wrote something like "...operator overloading, but wait,
> >> don't get excited..." was to bring awareness of a core problem
> without
> >> (hopefully) having people bring the burden of experience. i say
> burden
> >> because bad experiences can shadow the 'why' that was good with the
> >> 'how' that was bad. let the why foremost to "break these chains, rise
> >> up, and move beyond" as in Callicles' famous speech.
> >> the essential meaning of operator overloading and go interfaces and
> >> Smalltalk messaging is a way to bind code to intent. (in general
> intent
> >> is named uniquely ("==") for simplicity but that is independent.)
> >> Generics raise the need a way to say how the standard intentions play
> >> out for our types. Imagine our gopher attired as a waiter, politely
> >> asking questions of a custom type:
> >>
> >> gopher: Will you want to test for equality, madam?
> >>
> >> type: Yes, thank you.
> >>
> >> gopher: How would you prefer that test to be done?
> >>
> >> type: Hmm... I'll try 'IsEqualWithOddName(a, b *type)" for now.
> >>
> >> gopher: very good, madam.
> >>
> >> This mutual understanding needs to happen. how is open to discussion.
> >> go interfaces use standard method names. operator overloading uses
> >> standard symbols. macro expansion uses arguments. no matter how it
> >> manifests, the power of generics relies on understanding related
> parts.
> >> we should talk about what kinds of parts deserve awareness.
> >>
> >> On Sat, Sep 22, 2018 at 8:46 AM Lucio <[1]lucio...@gmail.com
> <javascript:>> wrote:
> >>
> >
> >>> It's good that you brought that up, because another issue I
> > remember
> >> from C++ V1.0 days, is that operator overloading did not allow for
> >> changes in operator precedence, an arbitrary sop to some weird
> >> decisions taken in earlier centuries. What I see as pertinent here,
> is
> >> that precedence is yet another "type" property, this time not of the
> >> arguments to an operator, but the operator itself.
> >> As I pointed out in private correspondence to Ian Taylor, the entire
> >> mess of arithmetic operations ought to be delegated to an APL-like
> >> interpreter and all the complexities, of which being "generic"
> >> functionality is not the only one, becomes one less problem for the
> Go
> >> compiler. If APL is too obscenely obscure in the Go context, no doubt
> >> there will be alternatives: it did not take Rob Pike long to produce
> >> Ivy.
> >> Of course, we also have indexing, indirection and a few other
> features
> >> of Go whose role could be examined and formalised, perhaps more
> >> successfully once the obscurity contributed by the arithmetic
> features
> >> is expelled from the language.
> >> Ian's response will remain with me for as long as I live, as I think
> it
> >> is very apt summary: that would not be Go. I entirely agree with him.
> >> �
> >>
> >> 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.
> >>
> >> Once we treat mathematical expressions as orthogonal to the language,
> >> we get brand new choices, possibly opportunities: what is Boolean?
> What
> >> is a string that is not an array? Etc. A whole new chapter opens, for
> >> better or for worse.
> >> 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 [2]golang-nuts...@googlegroups.com <javascript:>.
> >> For more options, visit [3]https://groups.google.com/d/optout.
> >>
> >> --
> >>
> >> Michael T. Jones
> >> [4]michae...@gmail.com <javascript:>
> >>
> >> --
> >> 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 [5]golang-nuts...@googlegroups.com <javascript:>.
> >> For more options, visit [6]https://groups.google.com/d/optout.
> >>
> >> Verweise
> >>
> >> 1. mailto:lucio...@gmail.com <javascript:>
> >> 2. mailto:golang-nuts+unsubscr...@googlegroups.com <javascript:>
> >> 3. https://groups.google.com/d/optout
> >> 4. mailto:michae...@gmail.com <javascript:>
> >> 5. mailto:golang-nuts+unsubscr...@googlegroups.com <javascript:>
> >> 6. https://groups.google.com/d/optout
> >
> > --
> > 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...@googlegroups.com <javascript:>.
> > For more options, visit https://groups.google.com/d/optout.
>
>
--
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.
