@gopherbot please add go2

I do not like this idea. Because:

• It increase the complexity of syntax, compilers, tools that read the language.
• It also increase the learning cost of the language.
• It decrease the readable of the code. It is much more difficult to answer the question "where is the code defined?"

It increase the complexity of syntax, compilers, tools that read the language.

Of course it does, it's a new feature. All features inevatibly will do this. Although if we're worrying about complicating anything, it should be the spec. Luckily a lot of the rules remain the same, the only things that change are allowing more things to be "operated" together with arithmetic operators.

It also increase the learning cost of the language.

Again, so does every new feature, and I'd say the learning cost is very small. People typically don't need to write operator functions anyway, as there are meant to be used much more than they are written.

It decrease the readable of the code. It is much more difficult to answer the question "where is the code defined?"

That is a valid critique, but ideally you should not be worried about what it does. It doesn't matter how 1+2 works, you care that it adds properly and you get a 3 in return. Operator functions should not do anything other than what you expect the operator to do.

I'd say it actually increases readability as well. Again, look at literally anything that uses math/big like this quick example. People who need stuff like math/big or a future decimal64 library can take advantage of this. Honestly, APIs for these things are quite terrible, and need to be because we need workarounds for these operators.

Also, it's defined the same place that methods are. In the same package as the type itself! So really the question "where is it defined" is a question that we already have the tools to answer.

It also increase the learning cost of the language.

I would argue the opposite. The current implementation of the math/big package is confusing and very hard to use. A very big improvement would be if it would just support operators and would act like the base number types. That would make it very easy to learn and use.

It decrease the readable of the code. It is much more difficult to answer the question "where is the code defined?"

The code readability is greatly improved. Again, math/big clearly illustrates that. As for "where is the code defined", that has little to do with readability, and the answer, as is right now, is of course: https://godoc.org/math/big

Another area that may be improved with such operator functions is the current generics proposal.
As it stands right now, writing a function to add 2 numbers would only be limited to the current numeric types. A hypothetical Sum generic function will never be able to work with big.Int, for example, or say, a custom rational number type.

// each of the functions would have the following function body:
{
    return new(big.Int).Add(a, b)
}

I would prefer not to allocate a potentially large amount of memory for every arithmetic operation, especially if that operation looks like a normal arithmetic operation.

The package math/big is both well-designed and has a learning curve. The two qualifiers are conflated in some of the examples and comments here. The stated goal of this package was to provide efficient manipulation of big numbers. The current proposal should perform no worse than the current state of affairs.

I disagree. Only a small percentage of the math/big api can be replaced with the small set of binary operators defined in the language.

Yes, only a small percentage can be replaced, but what about how often those are used? (Also, this really isn't only for math/big, I mainly used it as an example because it has a very steep learning curve, and the code resulting from it is typically very messy and can be hard to maintain.

I would prefer not to allocate a potentially large amount of memory for every arithmetic operation, especially if that operation looks like a normal arithmetic operation.

The package math/big is both well-designed and has a learning curve. The two qualifiers are conflated in some of the examples and comments here. The stated goal of this package was to provide efficient manipulation of big numbers. The current proposal should perform no worse than the current state of affairs.

This is a good critique as well, but when all you want to do is to add numbers without having to worry about overflow, it could be extremely useful.

There could also be a separate type defined somewhere else with a less steep learning curve. After all, there is a pretty popular issue (#19623) to make int arbitrary precision. This could instead be a third party library (or in golang.org/x/) with operator functions defined for it.

Just as a quick demo as to how this could be implemented outside of math/big, which was a bad example (since it's designed to be efficient).

This could also of course be used for other mathematical constructs such as matrices, vectors, etc. Also for arbitrary-precision integers, a bigdecimals, a elliptical-point, etc.

A simple modular integer implementation:

// A modular integer.
//
// `Reduce` should be called if you ever modify `Val` or `Mod` directly.
// As long as this is done, the `==` operator will work properly.
type Int struct {
	Val int
	Mod int
}

// Adds two modular integers and reduces.
// Panics if a and b do not have the same modulus
operator(Int) (a + b) {
	if a == Int{} { // handle unary +
		a.Mod = b.Mod
	}

	checkMod(a, b)
	nextInt = Int{Val: a.Val + b.Val, Mod: a.Mod}
	nextInt.Reduce()

	return nextInt
}

// Subtracts a modular integer from another and reduces.
// Panics if a and b do not have the same modulus.
operator(Int) (a - b) {
	if a == Int{} { // handle unary -
		a.Mod = b.Mod
	}

	checkMod(a, b)
	nextInt = Int{Val: a.Val - b.Val, Mod: a.Mod}
	nextInt.Reduce()

	return nextInt
}

// Multiplies two modular integers and reduces.
// Panics if a and b do not have the same modulus
operator(Int) (a * b) {
	checkMod(a, b)
	nextInt = Int{Val: a.Val * b.Val, Mod: a.Mod}
	nextInt.Reduce()

	return nextInt
}

// sets i.Val to its least nonnegative residue
func (i *Int) Reduce() {
	if i.Val >= 0 && i.Val < i.Mod {
		return
	}
	i.Val = (i.Val%i.Mod + i.Mod)%i.Mod
}

// makes sure a and b have the same modulus.
// if not, it panics.
func checkMod(a, b Int) {
	if a.Mod != b.Mod {
		panic(fmt.Errorf("mod is not equal: a(%d) b(%d)", a.Mod, b.Mod))
	}
}

And of course the usage:

func main() {
	nine := modmath.Int{ Val: 9, Mod: 2 }
	ten := modmath.Int{ Val: 10, Mod: 2 }
	twentyOne := modmath.Int{ Val: 21, Mod: 2 }.Reduce()
	
	fmt.Printf("9 + 10 == 21 (mod 2):", x + y == twentyOne)
	// output: true
}

With operators there are 5 goals:

1. Disallow operating on different types
2. Not wildly exported to other packages, force re-declaring
3. Disallow mutating input args
4. Interact with generics well
5. Only one function that returns integer for operators <,>,<=,>=,==,!= negative positive and equal (zero)

I propose the following. Operators should be a function calls with functions that are in general:

type T struct{}
func MyCustomAdd(*T , *T) *T {...}
func MyCustomSub(*T , *T) *T {...}
func MyCustomMul(*T , *T) *T {...}
func MyCustomMod(*T , *T) *T {...}
func MyCustomShr(*T , uint) *T {...}
func MyCustomShl(*T , uint) *T {...}
func MyCustomBwAnd(*T , *T) *T {...}
func MyCustomBwOr(*T , *T) *T {...}
func MyCustomBwClr(*T , *T) *T {...}
func MyCustomCompare(*T , *T) int {...}

Comparison is special, it is the "default operator", and maps all of the operators <,>,<=,>=,==,!=

Comparison is written like:

op default MyCustomCompare

Next the user can define also the other operators:

op + MyCustomAdd

If MyCustomAdd does not match the generic signature func ( * , * ) (*) this would be a compile time error. This satisfies point 1. Also, defining operator on a type that already has it would be a compile time error.

If the function is capitalized then the operator can be exported but must be also declared in the remote package, like so:

op + otherpackage.MyCustomAdd

This satisfies point 2.

All functions linked to operator will go thru additional type checking, to detect cases where you write to args and where you return something else than pointer to your own variable (this rule bans returning nil, also bans returning a and b):

func MyCustomAdd(a *MyInt ,b *MyInt) *MyInt {
    var foo MyInt // this must exist
    a.x = 7 // cannot write to arg
    if (yadda yadda) {
        return nil // this cannot exist
    } else {
       return b // this cannot exist
    }
   return &foo // this must exist
   return //this cannot exist
}

Operators that passed the additional type checking, will be internally optimized to something like

func(a *, b *,ret *)

Those who did not won't.

Next, generic function Maximum:

func Maximum (compare func (*, *)int, ... things) (out *) {...}

Can be specially written as:

func Maximum2 (op default, ... things) (out *) {...}

Now comes the main point: Maximum requires either plain generic function or auto-passed "unoptimized operator".
Maximum2 requires optimized operator. If you pass optimized operator to function that requires unoptimized one, a wrapper code will be generated and the wrapper passed.

Operators can be auto passed, like this:

Maximum(_, T{},T{},T{},T{} )
Maximum2(_, T{},T{},T{},T{} )

And used inside the generic function:

func Maximum2 (op default, things ... ) (out *) {
   if things[1] > things[0] {
          return &things[1]
    }
    return &things[0]
}

And the best part: compiler takes care of the boring details.
Like: promoting values to pointers when passing to operator functions. Creating wrappers for operators. Typechecking operator functions and returning compile time errors when you pass unoptimizable operator function to a generic function that has op param.

Could you edit to have your examples in code fences?

like this

would be
```
like this
```

Maybe a simpler syntax is also okay?

func (a mytype) +(b mytype) (mytype) {
     return a.Add(b)
}

Just like a normal methods, but with an operator rune as name.

To make it sure that operators always return something, and are optimized (by writing it's result to a specific memory location using input argument as output), I revise my proposal to:

type T struct{}
func MyCustomAdd(*T , *T, *T) *T {...}
func MyCustomSub(*T , *T, *T) *T {...}
func MyCustomMul(*T , *T, *T) *T {...}
func MyCustomMod(*T , *T, *T) *T {...}
func MyCustomShr(*T , uint, *T) *T {...}
func MyCustomShl(*T , uint, *T) *T {...}
func MyCustomBwAnd(*T , *T, *T) *T {...}
func MyCustomBwOr(*T , *T, *T) *T {...}
func MyCustomBwClr(*T , *T, *T) *T {...}
func MyCustomCompare(*T , *T) int {...}

If operator is passed to a generic function, the operator function must return it's third argument: Example:

func DoAddition(op +, operand1 *, operand2 *, result *) (*) {
	*result = operand1 + operand2
	return result
}

type T struct {x int}
func AddCorrect(a *T, b *T, ret *T) (ret2 *T) {
	(*ret).x = (*a).x + (*b).x
	return ret
}

func AddIncorrect(a *T, b *T, ret *T) (ret2 *T) {
	r := T{(*a).x + (*b).x}
	return &r
}

this will work:

op + AddCorrect
DoAddition(_, &T{}, &T{}, &T{})
// okay

this won't:

op + AddIncorrect
DoAddition(_, &T{}, &T{}, &T{})
// COMPILE TIME ERROR: Operator + mapped to AddIncorrect on line 54,
//does not return it's third argument on line 87774,
//when passed to generic function DoAddition on line 45645

Okay, I think you're micro-optimizing a bit here. The syntax should be simple.

Also, as a minor point, you don't need to dereference before using the . operator. The compiler does that for you since it's part of the spec.

I'd also like to add that read-only types (I'd link the proposal if I weren't on my phone) would work well with this proposal, as operator functions could require that all inputs are read-only.

I think forcing redeclaration of operators may lead to an "operator poisoning" of sorts... It would be especially inconvenient for people who use Go for mathematics to use a matrix, vector, and arbitrary-size int, and need to redeclare 50 operators.

Calling the comparison operators "default" doesn't make any sense to me.

I like the rest of the first part of your proposal, though. The second part not-so-much.

I am not merely speculating, I have a very serious intention to add operator overloading to my experimental language, named go-li. In fact I plan to do it next week, exactly how I propose.

Comparisons: Calling them default is wrong you're right. IMHO Most people would want to map all of them to the same function, in the C language tradition that returns negative int when a<b, zero when a==b, and positive int when a>b.

take look at this line:

func Foo(op comparison) {...}

How do you know that it is operator comparison, rather than parameter named op of type comparison? You don't know. Backwards compatibility is not 100% bulletproof. For this reason at least one of the words has to be reserved keyword, I propose:

func Foo(op default) {...}

or something like this:

op <=> MyComparison
func Foo(op <=>) {...}

or, alternatively, not using "op" but the "map" keyword to map operators.

map + MyAddition
func Foo(map +, map -, map comparison) {...}

alternatively, not using any arg names:

map + MyAddition
map <=> MyComparison
func Foo( +,  -, <=>, actual_parameter int) {...}

To prove it, here is example of code that uses generics, and would benefit from operator overloading. Fenwick tree (a data-structure that allows you to quickly sum a continuous sub-sequence of a large array.).
Fenwick tree in go-li language
Fenwick tree in folang
Fenwick tree example on folang playground
It needs the addition operator and negation operator , currently implemented using those callback functions.

The thing you probably disliked, is how we pass operators to generic functions. Trust me this is needed, otherwise people who don't prefer operators will have no way to call into generic functions that use operators. In this way they can, by passing the required concrete function that matches the callback signature as the parameter the way it is.

If we don't do this, the use of operators would spread like a disease:
i need package A
package A uses operators
therefore I define operators in my package so A can use them
since i defined operators i start using them (why not? they're already here)
suddenly my code is full of operators
other people need my package
therefore they define operators ... and so on

I'm 100% okay with binding operators to existing function calls. What I don't like is redeclaring the operators in every package that's going to use them.

I really would like a new "op" or "operator" TLD. It would make sure source code stays readable. It could still be backward-compatible as it is a TLD and would only be used as one.

I think the best syntax would be something like

op + CustomAdd

func CustomAdd(*T, *T) *T { ... }

The only issue is that this would allow

op + func (*T, *T) *T { ... }

Sure, you could say "just don't allow inlining here", but I feel like that'd be against Go's simplistic design. Perhaps instead preventing that should just be a go vet check.

TL;DR
Dear "go community", please read how its implemented in C++, then come back to this proposal. Also, you will probably need generics. And this is not trolling. @go-li has actually already brought up many valid points from that ecosystem in this thread.

Long list of comments:

• Operator overloading beyond "i can do this" brings us to value semantics and abstract algebra, and requires several levels of constraints on types of the arguments to be done right. But it also allows to radically simplify all code dealing with Number-like object (i.e: the ones that have conceptual arithmetic operations available upon. E.g.: ints, floats, bigInts, matrices, complex numbers, quaternions, currency), and also provide convenience for things like Set operations (s1 + s2 == s1.union(s2)).
• without equality (==) and its siblings (ordering / comparison) operator overloading turns into weak syntax sugar at best. Comparison operator definitions are a quite wordy, and so C++ plans to introduce <=> (starship) operator to simplify them.
• while forcing totality on types (A, A)=>A sounds logical and cool, it will not let you implement [even such a simple thing as] multiplying matrix by scalar
• regarding developer ergonomics, if operators are defined on types, then only packages using those types will have new semantics, and so developers would not be surprised by behavior of the operator.

I also don't like the idea of re-declaration. If I import a package that defines operators on its types then I don't have access to those operators? That kinda makes them useless. The whole point of operator overloading is to give them to library consumers. I, as a library implementer, don't care about them and don't really need them.

Also, I don't think we should look at C++. It has too much complexity that's very specific to C++ - value semantics, rvalue/lvalue, move semantics etc etc etc. It looks, frankly, ridiculous how it works rights now and committee understands that. <=> tries to make it slightly better. There're better examples on how it can be done.

Operator declaration without overloading is very useful. With this feature decimals can be made usable, complex numbers can be took out of core, even thinking of a flexible number type gets live.
For me the absolutly useless decimal type today is the reason for woting for operator methods. Operator overloading is no must for me, cause I define a new type when I want to overload, but declaring a new type meens also I can declare new operator methods. Overloading is useful for languages like C++, but (in my opinion) not for Go.

// Barycentric returns the barycentric coordinates for a point in a triangle.
// The barycentric coordinates cna be used for interpolation of {a, b, c} to
// point p (such as normals, texture coordinates, colors, etc)
func Barycentric(a, b, c, p *glm.Vec3) (u, v, w float32) {
	var v0, v1, v2 glm.Vec3
	v0.Sub(b, a)
	v1.Sub(c, a)
	v2.Sub(p, a)
	d00 := v1.Dot(&v1)
	d01 := v0.Dot(&v1)
	d11 := v1.Dot(&v1)
	d20 := v2.Dot(&v0)
	d21 := v2.Dot(&v1)

	denom := 1 / (d00*d11 - d01*d01)
	v = (d11*d20 - d01*d21) * denom
	w = (d00*d21 - d01*d20) * denom
	u = 1 - v - w
	return
}

^ disgusting, error prone, entirely because I can't define +* on vectors

All geometry/physics libraries are full of unreadable code because this feature is missing.

@hydroflame Your example contains a lot of code with little context. Can you provide the example of imagined "non-disgusting, error minimizing" code where you are using the notation?

@ianlancetaylor can contradict me if he wants,

but I think the three-argument methods to perform arithmetic on arbitrary types (z.Add(a,b) etc.) are really the only reasonable way to go.
Self-assignment operators z += a; z *= b; z /= c can keep allocations quite under control (question: how do you rewrite z = a / z ?), but fail short of the (in my opinion) first main goal of operator overloading:

1. source readability and expressiveness: write simple, naturally-looking high-level source using operators, and let the compiler figure out the details

In other words, if operator overloading is ever implemented in Go, it would really better allow writing things like

z = a + b * c / d

The second goal (still in my opinion) of operator overloading is:

2. Go toolchain should compile such high-level source to reasonably efficient machine code - i.e. something that minimizes heap-allocation of temporaries, not code that heap-allocates one temporary for each operation.

Some time ago I wrote in this thread an analysis about how to reach both these goals at once.
It's somewhat complicated but feasible - it starts from three-argument methods z.Add(a, b) and analyzes what the compiler must do to minimize the number of temporaries.

I'm afraid anything simpler than that will fall short in at least one of these two (somewhat competing) goals. i.e. source readability/expressiveness and runtime efficiency.

Hi all, because we now have generic, can we utilize it?

for example,
we can define + and * operator as built-in function

func OpAdd[T interface{ OpAdd(T) T }](a, b T) T { return a.OpAdd(b) }
func OpMul[T interface{ OpMul(T) T }](a, b T) T { return a.OpMul(b) }

and also add OpAdd and OpMul method to basic types like

func (a int) OpAdd(b int) int { /* compiler intrinsic of a + b to avoid recursive call */ }
func (a int) OpMul(b int) int { /* compiler intrinsic of a * b to avoid recursive call */ }

and then we can convert the expression

a * b + c * d

into

OpAdd(OpMul(a, b), OpMul(c, d))

with that in place, we can easily implement an operator for a custom type like this one https://go.dev/play/p/h_SVp8-Gjl8

In summary:

• adding built-in function Op*** into language spec
• adding built-in method Op*** into language spec for basic type
• we need to change the compiler to convert the normal binary expressions into function calls into the built-in Op*** function (honoring the operator precedence)
• we need to change the compiler to generate all the built-in Op*** methods to the basic types

This, or something more or less similar, can be implemented without language changes now that we have generics.

The language changes are "only" needed to be able to write

a * b + c * d

instead of the more cumbersome (but explicit)

OpAdd(OpMul(a, b), OpMul(c ,d))

(although I'd still recommend three-argument operations, with the receiver being used to store the result, to avoid unnecessary memory allocations for large objects).

Clearly, this issue is a proposal for operator functions, so the OpAdd, OpMul and friends alone would not address it.

It has been fairly well established that the Go developers do not want general operator overloading in the language, and I'm inclined to agree with the reasoning given, namely that it can disguise an expensive operation as though it was just addition or something, and there's no way to know what it's really doing at the call-site anymore. With the exception of string + string, all operators in Go currently are O(1), which is actually very nice. While operator overloading could certainly be convenient in some situations, such as math/big, I don't think that it's worth the complication that it introduces.

Maybe infix functions would be a better approach, so that you could do a plus b. I don't think that it really gains much over a.Plus(b), though.

Maybe infix functions would be a better approach, so that you could do a plus b. I don't think that it really gains much over a.Plus(b), though.

what do you suggest to handle precedence @DeedleFake ?

It was just a random thought, not an actual suggestion, but probably just simple left-to-right would be the least surprising.

(although I'd still recommend three-argument operations, with the receiver being used to store the result, to avoid unnecessary memory allocations for large objects).

@cosmos72
I think for big.Int, we would only have Op***Assign family (with pointer receiver), but not OpAdd or OpMul (with non-pointer receiver)

EDIT:
after some thinking, I agree we should provide three-argument operator like @cosmos72 said,
so, provided big.Int with OpAdd and OpAddStore method, the compiler can use something like SSA analysis to know if a variable is only used once or not, if so, the compiler use OpAddStore for + operator, otherwise it uses OpAdd.
but yes, as @DeedleFake said, you can't distinguish whether some operator is O(1) or not at call-site

If being O(1) is an issue, we should probably remove operators from floats, as I'm pretty sure most people are not familiar with the fact that operations on some floats can be more than two orders of magnitude slower that operations on other floats.

Operator overloading, if added, will be abused. Not adding it and also not making types that'd benefit greatly from it (decimal, vec3, mat4, quaternion, big.Int…) native, so that they can use operators without overloading, just makes Go less useful in fields that need those types.

There's no avoiding the trade off.

many say that operator overloading will be abused to the point that the code is hard to understand.
but from what I learned from Haskell (I'm not saying I'm an expert on it), as long they form semigroup (in other words, the types must always be the same), I don't see how it will be abused.
so *T will only be addable to another *T but not T, and vice versa T is only addable to another T but not *T
operator overloading in other languages like C++, where you can define multiple of it and the types are not the same, of course, will make the code harder to understand
can someone give an example of how it is abused?

In Go today a * b always executes in roughly constant time, never allocates memory, and never panics. If we permit operator overloading none of those will be the case.

My understanding is that it is common to prohibit the use of operator overloading on large projects where code complexity is a concern, for example in game development (allowed for simple implementations) and mars rover environments (strict prohibition).

My experience: I have worked on several numerical libraries that deal with quat, vector and matrix operations, the whole lot of it. There has been only one case where I regretted the fact there was no operator overloading in Go, it was when I had to work with the big.Int type. This was early on in my Go career and today I think the reason I felt this was method API design of the big package. Having functions for operations instead of methods does so much more for readability.

So I'd rather not have operator overloading. It seems to be a language feature avoided by those who practice software engineering and I don't have a need for it to develop numerical libraries. There are other more pressing issues regarding Go in a numerical setting than the lack of syntactic sugar.

All I want is generic support in operator overloading, with full support for all operations, with generics support.

Let me overload any operator that is supported; Type constraints as I have seen them in go don't define these well enough because we are missing critical binary and logical operations, and are not able to do things like using constraints.Unsigned to write generic code that leverages operator overloading for binary operations.

Let me do that!

Let me program to interfaces so that I can write more dry and solid code by design.

operator overloading introduces a huge complexity, either in compiler implementation and code maintaibility, which is also the root of the expansion of C++ complexity IMHO.

I would love to be able to write code that can simply be leveraged with type sets that I've previously defined. Let me use the composition of objects to define what they are.

You can't tell me that you want to enable composition over inheritance as a core design constraint, and then tell me that I can't compose objects without begging the question if that violates the design by making custom composition harder. Not to mention, it seems kind of contradictory.. and unfair. The fact is, while operator overloading for things like (+) and (-) might seem odd, for distinct sets of data and various models in some very distinct domains, it makes a lot of sense and enables separation of concerns and DRYing that leads to cleaner code.

For example, I should be able to add a Money type to another Money type with (a + b). I'm possibly going to have to make sure the two currencies are the same, or I can enable functionality around exchange rates through. But the fact remains, no matter what I choose to do, it's kind of important that I have full control... if only for compliance and auditing.

I fully understand that people shouldn't be messing with operators in ways that could create bad code; But the community can't even agree on what that is half the time. I'm sure we can all point to tech that just seems wrong, but trying to design against bad code will only get you so far. And in many ways, it'll force people to create bad code to get around the artificial constraint that you imposed with good intentions that got in their way while they were just trying to do their jobs.

All I'm asking is that, if golang is truly about composition, that we truly go into and enable composition. Let me compose my objects. Not just to define the methods that are a part of an interface, let me define the operators that must be enabled for the interfaces used in the process/strategy I have defined, because they are effectively just function calls that the language is not letting me override right now.

The current solution only enables half of the problem; Operator overloading and operator functions would enable solutions for the other half and truly allow people to Go,

That operator overloading will never happen in GO was one of the very first design strategies.
If you as GO user feel that you are missing something then you can not resist the temptation to produce unreadable code (and should switch to one of the plenty languages in which such is possible and customary).
Sorry I don't want to be rude but operator overloading was one of the worst mistakes in computer history.
Operator overloading HIDES function calls (these are not visible in the source code) causing code that can only be read by those who created the program. It is like hiding easter-egg functionality in a program but at a large scale.
I'm a senior programmer with 40 years of experience in about any programming language and system that exists/existed including multiple self created scripting languages and I'm also the person who ported Python to the VAX/VMS platform.
Just take my word for it, operator overloading in GO may never happen and that is one of the foundations of GO.
This ongoing conversation ONLY exists to prevent future users from creating duplicate proposals here.

I apologize, but as respectfully as possible, I do not believe that opinion alone is worthy of accepting as fact. I'm bringing data and examples and asking questions; people are replying with insults and accusations.

It's fine for people to have opinions, and I welcome opinions with data to back them up, but we should be willing to admit when we don't have data to back them up.

I'm actually a big fan of DRY and SOLID and personally enforce these in my projects; So any incorrect assertion that this would generate bad code 100% of the time is flat out wrong. I gave a great example above: and I explicitly defined the concerned boundaries. I respectfully understand that if some disagree with me, that's one thing, But you shouldn't be making random arguments without data either, because with all respect, I'm bringing examples and data to you... and it feels like some of you are replying with opinion and insults.

Where is the data?

Only a small percentage of the math/big api can be replaced with the small set of binary operators defined in the language.

Looks like you have not tired the complex expressions!

Given the power of the fmt.Stringer interface in golang, its important to consider that effectively this is another perfect example of why you would want type conversion that you can inject your own code into as a form of operator overloading; in this case it's simply of a string composed of a Strategy taking the prior typed instance as input and returning a string.

What's important here is that we can inject that strategy ourselves. The value is that we have control over the code in the resulting callback; and the fact that it's used by so many things grants it even more utility.

I propose a comprehensive package of enhancements for Go, which includes operator overloading, lambda functions, as well as getter and setter methods similar to C#.

In order to control potential side effects - a prevalent concern with these features - my suggestion is to implement operator overloading, and getter/setter methods through lambda functions in Go. These lambda functions should only allow conditional expressions, effectively preventing side effects. This approach could provide a layer of control not currently available in Python due to possible side effects with lambda functions.

Furthermore, within these lambda functions in Go, I would suggest disallowing function calls. We should only permit further lambda expressions and constructors. This approach would ensure the purity of the lambda function and maintain a level of simplicity and straightforwardness in the code, which is in line with Go's philosophy.

This comprehensive package could open up new patterns and capabilities in Go, while effectively managing the risk of side effects. Each component must be carefully considered and implemented to ensure consistency with the existing language philosophy and objectives.

I understand that any change to the language needs to be meticulously planned and executed considering its potential impact on existing code and the learning curve for the community. However, these are my initial thoughts and I'm eager to hear feedback and insights from the community on this proposal.

Example:

Python code:

python

     // Implement Add Operator with a lambda
      class MyClass:
               def __init__(self, value):
                    self.value = value
         
               __add__ = lambda self, other: (
                            (lambda: NotImplemented),
                            (lambda: MyClass(self.value + other.value))
                         )[isinstance(other, MyClass)]()

Equivalent Go code (hypothetical, as Go does not currently support operator overloading or lambda-style functions):
go

 type MyType struct {
         value int
 }
              
 lambda (self MyType) __add__ (arg MyType) MyType {
       return MyType{self.value + arg.value} 
 }

Getter Proposal:

 type MyStructure struct {
           private int
 }
    
 // Define a getter for the private field
 getter (self MyStructure) Public int {
      return self.private
 }
         
 func foo(bar MyStructure) int { 
        return bar.Public
 }

in this proposal, Public is a getter function that acts like a public field, providing access to the private field private. You would access it directly, as if it were a public field (bar.Public), rather than using the usual method call syntax (bar.GetPrivate()).

Setter Proposal:

type MyStructure struct {
    private int
}

// Defining a setter for the private field 
setter (self *MyStructure) Public(value int) {
    if self.private == 1 {
        self.private = value
    }
}

func foo(bar *MyStructure, value int) {
bar.Public = value
}

In this case, Public is a setter method that you're using like a field, to set the value of the underlying private field.

That operator overloading will never happen in GO was one of the very first design strategies. If you as GO user feel that you are missing something then you can not resist the temptation to produce unreadable code (and should switch to one of the plenty languages in which such is possible and customary). Sorry I don't want to be rude but operator overloading was one of the worst mistakes in computer history. Operator overloading HIDES function calls (these are not visible in the source code) causing code that can only be read by those who created the program. It is like hiding easter-egg functionality in a program but at a large scale. I'm a senior programmer with 40 years of experience in about any programming language and system that exists/existed including multiple self created scripting languages and I'm also the person who ported Python to the VAX/VMS platform. Just take my word for it, operator overloading in GO may never happen and that is one of the foundations of GO. This ongoing conversation ONLY exists to prevent future users from creating duplicate proposals here.

Stephan Veenbeck presents some commonly expressed concerns about operator overloading: it can make the code difficult to read and hide its functions, leading to confusion and errors. These are valid concerns that should be considered in the discussion of potential enhancements for Go.

A potential approach to addressing these concerns might look like this:

Clarity and Readability:
Operator overloading needs to be implemented in a way that maintains the readability and comprehensibility of the code. Careful design and clear guidelines could help prevent misuse and restrict the use of overloaded operators to logical and easily understandable ways.

Use Control:
Operator overloading should be restricted to specific and appropriate use cases. A possible solution could be to allow it for certain types or in certain contexts to ensure that it does not unnecessarily complicate the code or hide what's actually happening.

Existing Practices in Other Languages:
While operator overloading has caused problems in some languages, it is effectively utilized in others. It's worth examining the practices and experiences from these languages to identify possible problems and find solutions.

Community Feedback:
It's important to consider the feedback and concerns of the community. A dialogue with users could help address concerns and lead to a solution that can leverage the benefits of operator overloading while also preserving the readability and comprehensibility of the code.

It's crucial to note that introducing such a change needs to be carefully thought out and planned to avoid unwanted side effects. Ultimately, any changes in the language should aim to enhance developer productivity and satisfaction without compromising the principles of simplicity and clarity that have made Go what it is.

There are a simpler solution to the operator implementation. Just allow more characters in the definition of the name of a function similar to what scala does it and allow for infix notation for single parameter functions and do not treat operators in any special way other than the way they are defined.

currently:
type MyValue struct {
value int
}

// Defining a + for the private field
func (r MyValue) add(v *MyValue) MyValue {
return MyValue{r.value+v.value}
}

use currently as:

val1.add(val2)

new:

type MyValue struct {
value int
}

// Defining a + for the private field
func (r MyValue) +(v *MyValue) MyValue {
return MyValue{r.value+v.value}
}

// Defining a ++ for the private field
func (r MyValue) ++() MyValue {
return MyValue{r.value+1}
}

use new as:
val3 := val1.+(val2) // normal
val3 := val1 + val2 // infix notation

this way anyone can add "new operators" such as:

~>() >>>() <--->() etc.

it will get interesting for the * and & operators for pointer references. Also := and = for assignment.

There is two cases in my develop experiences.

1. Add (operate) two same type value.

This case is simplify for developer:

type Point struct {
	X, Y int
}

func (p Point) Add(other Point) Point {
	return Point{p.X + other.X, p.Y + other.Y}
}

func main() {
	p1 := Point{1, 2}
	p2 := Point{3, 4}
	fmt.Println(p1 + p2) // Output: {4 6}
}

2. Compare two same type value.

type Block struct {
    PrevHash []byte
    Hash     []byte
}

func (b Block) Compare(other Block) bool {
    return bytes.Compare(b.PrevHash, other.PrevHash) == 0 &&
        bytes.Compare(b.Hash, other.Hash) == 0
}

func main() {
    b1 := Block{[]byte("p0"), []byte("h1")}
    b2 := Block{[]byte("p1"), []byte("h2")}

    m := map[Block]struct{}{
        b1: struct{}{},
        b2: struct{}{},
    }
}

At least we could implement a custom optionalChaining operator even though this was dismissed with such an option. Would love to see custom operators They can be limited but having the ability would come a long way.

I'm a little worried about whether this will turn golang into another python. For example, if we customize a symbol like @ for matrix multiplication, this is equivalent to inventing another operation, and its behavior is confusing. What I mean is that only by consulting the documentation can you know the difference between it and *.

I think it is okay if the operator symbol is not overloaded with existing ones.

if you encounter a weird symbol like *. or +., it just means that you need to look at the docs,
it is just the same when you encounter an unknown method name, you look up the docs.

an infix operator is just another form of method invocation, but it is more readable.

((a +. b) *. c) +. (d *. e)

vs

a.Add(b).Mul(c).Add(d.Mul(e))

you can know that if it is not a standard operator symbol, then it must be a method

NOTE: btw, it is just a matter of preference, I prefer the former, but someone maybe prefer the later

I don't personally think this serves any good purpose that solves a specific problem.
It's just syntactic sugar without making something more readable necessarily, neither serving any compilation or type-safety purpose.

From my understanding, which might be wrong,
I think this proposal about operator functions comes from other languages that may have this functionality on top of them.
But, why? What problem does it solve?

Okay, fair enough this example from @win-t is fair

((a +. b) *. c) +. (d *. e)
vs
a.Add(b).Mul(c).Add(d.Mul(e))

Although, I see a fair bit of prons and cons in this one where the cons are more than the pros

Pros

• Easier to write and read
• Easier to comprehend what this code is doing

Cons

• (in this specific example) The +. ... the dot (.) is simply just distracting. Now it makes it kinda even unreadable. For the sake of what? Having operator overloading? It can be fair, if operator overloading indeed serves a very good purpose, but let's go through that.
• When are you gonna actually ... do such big operation? Without encapsulating it inside a function or comments anyways? Like the example by itself, feels very-very rare case. It's an extreme example from my experience. I never ever had to see anybody write such big operation. Even in graphics programming, for which you usually do not use Go for, you're usually encapsulating such big operations into functions such that you don't need overloading, or the operation is already supported by the language. Or if you really need such big operation, probably Go is not what you need. Like, personally I wouldn't use Go for graphics programming and matrices. I would use some other language because of support for Arenas, very free use of allocators and such. Like, using the right tools for the right jobs.
• Give me a real life example, where you would actually use that? How frequent would that example be in real life? Why not just place such a big complex operation inside an object's function which also explains what it actually does? Is it so frequent that it becomes a struggle in everyday programming? Or is it a once in a year I may need that? And after all, it's just syntactic sugar. Not syntactic sugar like Assembly to C, or for i, n := range objects, but like a self-explanatory code being translated to literal keywords of the language itself. This breaks simplicity by nature. You have to know what those operators on those objects are actually doing. When with a function, its very easy to read the documentation or read the name of the function.
• Proposal of a feature that people may misuse for the sake of using it because "it's cool". It happens often. Hate me, but it happens often that people use features just because they exist. That what was the whole debate over generics anyways, wasn't it? For which I advocate for. But I agree that people may misuse generics. Difference is that generics have many real life examples and already the standard library starts using them because they are indeed useful.
• Proposal proposes a way to Add(), Mul() etc. an object, when the side-effects may not be apparent what they exactly do, and the user might expect something else from what is actually happening under the hood. People won't hover over +. to see what it does on these objects. But people will hover on what AddMatrix() does to ensure what it does. This offers safety and less bugs.
• Abstractions. Such specific abstractions are just purely syntactic sugar for the sake of making an abstraction. Yes sure, because some people may feel comfortable from other languages. But what is their purpose? What do they solve? When? How often?
• This ((a +. b) *. c) +. (d *. e) makes sense when you have Integers or any numerical types. This a.Add(b).Mul(c).Add(d.Mul(e)) makes sense when you have structs where you don't actually know what an operator actually may actually do and what side-effects it has.
• +, - * all these serve a very specific purpose in a language. And by overloading those operators, you're breaking that purpose. Now you're start doubting what an operator actually does. You're breaking a social contract that "hey I'm sure what these operators are doing". No, now you're never sure. You have to look if everything's an integer, or a float, or an object etc. This breaks simplicity and introduces bugs.
• In a.Add(b).Mul(c).Add(d.Mul(e)) you may just explain on top of what this chained functions are doing. It's not like ((a +. b) *. c) +. (d *. e) is easy to understand either on what exactly it is doing and why. So, you have the same problem here, in neither case, you know why you're doing that operation in the first place. So .... you're gonna have to place comments on top to explain to future programmers what this is doing anyways.
• Now I have to distinguish primary type operators with object type operators? This is just breaking simplicity of the language. Now I have to be aware of where there is a primary type operator vs an object type?

For the fairness of all, I agree, ((a +. b) *. c) +. (d *. e) is more readable.

Absolutely right it is.

But for numerical types.

When you're not dealing with numerical types, how are you gonna know what is that overloaded function is doing under the hood, how are you gonna differentiate easily between primary type and object type operators (no a simple +. [dot] is not doing it :P it's even more confusing because the difference is so small). What are the usecases of this and how often are they. What problem does it solve, when do we actually need huge computational operations between objects and why not just do them inside the objects themselves if they're so huge?

tl;dr; I see 100:1 problems/what it solves on this proposal and bringing much confusion. I'm not hating the concept, I just don't see what value does it serve and how often that value is shown in actual real-life code.

Hi, just want to clarify

• (in this specific example) The +. ... the dot (.) is simply just distracting. Now it makes it kinda even unreadable. For the sake of what? Having operator overloading? It can be fair, if operator overloading indeed serves a very good purpose, but let's go through that.

• +, - * all these serve a very specific purpose in a language. And by overloading those operators, you're breaking that purpose

the dot (.), is just an example, it doesn't need to be a dot, we can use any symbol that not distracting, but it's enough to communicate "it is not a normal operator, look up the docs", another alternative might be @+ @*.
I want to make it clear, you cannot overload existing operators, no overload for + - * /, +=, *=, ...

one may argue, that we will have multiple definitions of the @+ operator in the codebase, as everyone can define one for their type, it is not as uniform as the normal + operator that will have the same meaning anywhere in codebase.
But the same situation also arises with normal methods, everyone can define Add() for their type, and for both situations, you are expected to look up the docs to understand its purpose, does it have a side-effect, etc ...

But for numerical types.

I can argue, that the correct usage of the custom operators might be not just "numerical" types, but any types that resemble mathematical sense (group, semigroup, monoid, ...).

In the end, it is just a matter of using the proper "name" for what purpose: Add(), AddMatrix(), AddModularArith() Foo(), Bar(), @+, etc ... one must choose which one is the most make sense for the type they defining.
And sometimes @+ or +. is just the right name, because for some particular types, it behaves just like normal + but with slightly different behavior.
I've done some financial calculations using math/big.Rat, and it is a bit pain to work with.
It's hard to compare the code with the formulas assembled by the business/product team.
The Rat API might be defined with care so that you can reason about performance and memory usage. but most of the time, we don't care about performance, we care about correctness and readability.

Rob also has a comment about how the Int type probably should be done. We should strive for correctness first.

Personally, the operator function is not a feature that I miss the most in golang, I can live without it. I'm neutral about this issue, just want to add some comments.

But if we want to add to the language, I want it to be defined more like magma (in the mathematical sense). the operand and the result must have same type

It seems like most of the pushback towards this feature sounds a lot like the typical arguments for and against operator overloading. However, in general, it seems that operator overloading is most beneficial for numeric data types, things like BigInt, fixed-precision numeric values (ex. currency or other uses), Vectors, Matrices), while other types don't really use overloading, except for comparison and equality.

I think a good middle ground could be only allowing overloading of operators like comparison and equality, then having Go add support for numeric types like vectors, BigInt, fixed-point, etc. that would have first-class support for standard mathematical operators (though we may want some way to differentiate matrix multiplication vs element-wise, perhaps with an @ operator or some alternative), essentially locking those operators down to being available only on types that the language permits. This seems to give the simplicity, usability, and readability benefits that can come from operator overloading to the most common use case, while avoiding pitfalls of bad operator overloading.

Having equality and comparison be overrideable on any struct is valuable since it would allow a single, unambiguous method for equality and comparisons/ordering of all types. The language could even enforce that the operands must be the same type for an equals operator to return true. The fact that there are two different ways to do this (function for structs, operators for primitives) presently makes it less simple than it could be.

Arbitrary operator definition would most certainly complicate the compiler, and lead to possible confusion since it could easily result in operators that do not make much sense on their own. I don't see that happening considering that Go wants to keep the compiler as simple as they can.

I do, however, think operator overloading is a net positive and would like to see support for overloading existing operators. It seems to me that bad operator overloading implementations generally do not get much traction, with libraries doing this poorly generally being avoided. I very rarely find myself needing to overload anything more than an equality operator on most things in languages with the feature, and I think most devs have the common sense to not needlessly throw it around. I find I end up using libraries that do it well often on the flip side, but those are largely when dealing with numeric or vector types in other languages, and they're a huge benefit to code readability. It seems to me that most code authors have learned the lesson to use operator overloading carefully, which seems to have us to the point where comparison operators are the only ones most override unless you are a numeric type, which led me to the suggestion I made earlier.