I’m sorry. I did not mean to offend anyone. It came out wrong and I apologize.
Sent from my iPhone
> On Sep 23, 2018, at 5:01 AM, Louki Sumirniy
> <louki.sumirniy.stal...@gmail.com> wrote:
>
> 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> 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> 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.
>> >> For more options, visit [3]https://groups.google.com/d/optout.
>> >>
>> >> --
>> >>
>> >> Michael T. Jones
>> >> [4]michae...@gmail.com
>> >>
>> >> --
>> >> 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.
>> >> For more options, visit [6]https://groups.google.com/d/optout.
>> >>
>> >> Verweise
>> >>
>> >> 1. mailto:lucio...@gmail.com
>> >> 2. mailto:golang-nuts+unsubscr...@googlegroups.com
>> >> 3. https://groups.google.com/d/optout
>> >> 4. mailto:michae...@gmail.com
>> >> 5. mailto:golang-nuts+unsubscr...@googlegroups.com
>> >> 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.
>> > 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.
--
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.
