D initially wasn't going to do operator overloading, mainly because C++ iostreams was a disaster (in my not-so-humble opinion) as well as the awfulness of overloading operators to create a DSL.

But I wound up being convinced that on balance it was a good thing. But I was able to inculcate a culture that operator overloading should be restricted to the creation of user arithmetic types.

Not allowing the overloading of unary *, &, and dot also help discourage non-arithmetic overloading.

Well, there is always the limited form of arithmetic overloading which Ken Thompson added to his compiler:

https://marc.info/?l=9fans&m=111559034637840&w=2

C# has had extensive operator overloading from day 1, and the only instance of (mild) abuse that I can think of is the use of implicit conversions from strings in XLINQ. It really is mostly down to culture, I think.

What about something like R's custom infix operators? R has %*% for matrix multiplication (and a few other built-in ones), but you can define your own %op%. It lets users know that potentially "here be dragons".

That has come up a few times. Frankly, %*% looks even worse. Using Unicode sounds like a good idea, until one discovers that the source code is not parseable without semantic analysis.

How is w=add(u, v) more explicit than w=u+v?

Because operators "should not be function calls"?

That would make zig unusable on soft float/soft div architectures, or would have to get rid of / for division and operators for floats.

But I would also assume add() is inlined and not be a function call in a sane language/compiler, so the explicitness even falls apart from the start.

if we can do 1 + 1, we should be able to do vec2 + vec2, same with mat4 * mat4

Odin proved it that it can be made efficiently while keeping sanity

The thing about operator overloading is that it was abused during one of the worst era of C++.

And vec2 + vec2 can probably be unambiguously translated to assembly code while mat4 * mat4 is an other story. In most cases it should be a function call, and not a trivial one, with SIMD it can be relatively fast but still several orders of magnitude slower than 1 + 1. (we're talking about more than 500 scalar-equivalent operations)

And unfortunately, from my experience, if you let people (especially new coders) use this kind of powerful syntactic sugar they tend to ignore the performance characteristics because it look so simple and basic, like if the CPU had a special instruction to multiply two 4x4 matrices.

I prefer when the function call is explicit, it is a bit more cumbersome to write, but there is less hidden complexity.

> I prefer when the function call is explicit, it is a bit more cumbersome to write, but there is less hidden complexity.

you hide and obfuscate basic operations with functions, that's worse, specially when you have to chain arithmetic operations, with functions it becomes ugly and unreadable

Matrix multiplication or even worse, matrix inversion, is NOT a basic operation.

This is exactly the point.

> Matrix multiplication or even worse, matrix inversion, is NOT a basic operation.

Neither is dividing floats, especially not on a softfloat & softdiv architecture. And yet, Zig is perfectly OK with you using division between 2 floats. Why does it get to insert expensive function calls behind operators but I can't?

Zig also lets you do remainder division for floats, which is also not a "basic operation." It's slower even then taking the sqrt of a float! Zig then also has specialized operators like saturating addition, which also isn't a "basic operation"

And then Zig also has `*` for array multiplication and `++` for array concatenation. Those are compile-time only, but still deviates from "basic operations only" territory surely. And also Zig overloads `||` to allow for the merging of enums (sorry, "error sets"), rather than only being a boolean OR.

Integer division isn't a simple one either though…

Matrix multiplication are “basic operations” in the sense that you use them as the basic block of your algorithms, and in code using such blocks you really appreciate having a simple operator for those instead of littering your formula with functions calls (which is basically writing your formulas in Polish notation, not the most legible way to write formulas …)

Matrix multiplication is a niche in the programming world.

The programming world is made of niches. That's why arithmetic operator overloading is nice, the language doesn't need to know which niche I'm in to satisfy my needs.

I somewhat agree with you, I argue that mat*mat should be an element wise operation and use a different operator for matrix operations (like numpy does it).

Show me an example and I am pretty sure that I can rewrite it in a way that is neither ugly nor unreadable.

> if we can do 1 + 1, we should be able to do vec2 + vec2, same with mat4 * mat4

why? operator overloading doesn't help you solve any problems. you can have the readability with methods which are named appropriately.

operator overloading seems so powerful and useful until you realize one day that it only changes the appearance of things, and makes no difference whatsoever to anything you are actually doing.

Here's a sweet example of proper use of operator overloading:

https://dlang.org/phobos/std_checkedint.html

where operator overloading is used to create variations on integer types, like specifying the behavior when overflow happens.

Besides, `a + b / (c * d)` is far more readable than `add(a, div(b, mul(c, d)));

I think haskell does this right. You can make function infix by turning "add a b" into "a `add` b" and you can't overload existing operators but you can make your own and do "a _+ b" or whatever and everybody will know it isn't the standard + but it's still readable.

> you can't overload existing operators

You can though, just implement the relevant typeclass.

Not only that, but you can straight up shadow existing operators.

It makes a massive difference. I find most math related code unreadable without operator overloading, such code is very common in e.g. gamedev.

Just because people misuse operator overloading doesn't mean it should be removed from the language.

But we are using operator overloading already, + does work for the basic numeric types doesn't it? So why should the line be drawn at float or double (zig didn't have a complex type last I looked), why not vec?

readability is important. specifically, operator overloading is great because it makes code look more like math. when translating from math to code, this is highly useful.

i'm not asking for operator _overloading_, i am asking for having operators for my math types

Good point, you could have + * / restricted to basic types, but have #* #+ #mod_add as (overloadable) operators.

Then no operators should exist at all. After all, adding 2 ints and adding 2 floats are drastically different runtime characteristics - performance and errors are completely different! Anarchy! Chaos! And let's not forget about all those architectures where the division operator is, gasp, a function call!

Also function overloads should never be allowed, either. After all, that's not explicit and the only thing that ever matters is being obsessively explicit for the sake of being explicit. How can I possibly tell what `min(a, b)` is going to do if function overloads or templates or macros exist?!? UNREADABLE!

I think at this point it's pretty well established that operator overloading is a net-good, and languages that don't have it end up with far more bugs than languages that do. Or they come up with arbitrary nonsense rules on why some types are allowed to have it but not your types you dirty filthy casual. Looking at you, Java, where the Integer class is allowed to overload operators but BigInteger isn't. Which, then again, is something Scala and Kotlin immediately completely reversed.