> Fight me.

OK.

Operator overloading is a useful feature that saves a bunch of time and makes code way more readable.

You can quibble whether operator<<() is a good idea on streams and perhaps C++ takes the concept too far with operator,() but the basic idea makes a lot of sense.

string("hello ") + string("world"); complexNumber2 * complexNumber2; for (int i : std::views::iota(0, 6) | std::views::filter(even) | std::views::transform(square)) someSmartPtr->methodOnWrapperClass();

All the things you wrote could be about as easily written & much more easily read without operator overloading. Operator overloading only allows programmers to feel "smart" for doing a "clever" thing, to the detriment of future readers.

    string("hello ").append("world");

    complexNumber2.mult(complexNumber2);

    // wtf is even going on with this one in your example? have these people never heard of method chaining?
    for(int i : std::views::iota(0,6).filter(even).transform(square))
        (*smartPtr)->methodOnWrapperClass();

That's all about the same verbosity, it's much more clear to the reader even if they're unfamiliar with your codebase, and dropping operator overloading eliminates the "clever" option to do stupid crap like divide file path objects together.

Would you advocate getting rid of operators altogether?

    3.times(2).plus(7)

Some things just lend themselves to being expressed in terms of simple operators.

    (*smartPtr)->methodOnWrapperClass();

That is still using the overloaded SmartPtr<>::operator*() method.

I understand the viewpoint that operator overload is syntactic sugar for things that can easily be done another way, I just disagree that costs outweigh the benefits.

> Would you advocate getting rid of operators altogether?

Of course not. It makes sense for built-in types, as everyone reading the code can be assumed to know them.

> That is still using the overloaded SmartPtr<>::operator*() method.

Good catch ;)

> I just disagree that costs outweigh the benefits.

Yah, I think that's the disagreement. My feeling is there's a teeny, tiny handful of appropriate places for it (almost entirely math) and it opens up a pandora's box of terrible decisions that programmers clearly find irresistible.

Are you suggesting

  3.times(2).plus(7)

as a good thing or a bad thing? I see a.equals(b) occasionally from the first argument is magic crowd but 3.times is novel here. I'm really unsure what the order of operations is for that expression.

C++ doesn't have extension methods, so you wouldn't be able to add custom algos to the set of chainable algos.

Overloading operator| is a crude way to get the equivalent of extension methods without having to change the language.

The majority of time in professional codebases is not spent on typing but reading and understanding code.

"saves a bunch of time and makes code way more readable"

Not when everybody defines their own operators.

Note - we are discussing operator overloading, not operators as features in syntax. Operators at the syntax level make life a lot easier. But then everybody uses the exactly same operator semantics, not some weird per-project abstraction.

The lines of code you wrote as an example are not saving anyones time, except when writing it if you are a slow typist and lack a proper IDE support for C++. If typing speed is an issue, get a better IDE, don't write terser code.

Hiding the actual logic in extra boilerplate doesn't make it easier to read.

The lines of code in the example save reader's time as they focus attention on the actual business logic.

Yes, this assumes that operator overloading follows some convention, but you need to follow conventions regardless to make readable code.

by this reasoning should we get rid of templates/generics as well?

YES

Making things explicit isn't necessarily boilerplate.

Code is read more often than written. Writing code that can be understood at a glance (by using common, well understood operators) optimizes for readability.

I think your argument is basically "people should not aggressively violate the implicit bonds of interfaces", which is true. But that goes for all interfaces, not just and not in particular those around operators.

We just have cases where it's common with operators because those are one of the few cases where we have lots of things that meet the interface and interact directly as opposed to hierarchically. The same kind of issue comes up with co/contravariant types and containers sometimes, but that's less often visible to end developers.

I tend to agree with this. I like operator overloading for mathematical constructs (like complex numbers or even just for conversions of literal types, Imagine, for example, you have a gram type and a second type, if you said 1g / 1s you'd get 1gps, that seems reasonable)

I don't like it in the example given

    for (int i : std::views::iota(0, 6)
               | std::views::filter(even)
               | std::views::transform(square))

What benefit does this have over the Javay/Rusty version that looks like this

    for (int i : std::views::iota(0, 6)
               .filter(even)
               .transform(square))

?

No deducing what `|` means, you are applying the filter then transform function against the view.

People don't use the same operator semantics. Is + commutative? Does it raise exceptions or sometimes return sentinels? What type conversions might == do?

And how exactly do you propose library authors should work with user-defined types? Operator overloading is what allows algorithms to be efficiently generalized across types.

The code isn't readable (you can't even reliably tell at a glance what the operator does) and it takes negligibly longer to write "add()" rather than "+" in your program (yes, 'add()' is more keystrokes and thus takes longer to type, but most of your program isn't addition instructions).

I think what people should advocate is full DSL capabilities with some unambiguous gate syntax so people know precisely that `foo * bar` is not using the host language syntax. Overloading operators is ambiguous and vastly incomplete (everyone is holding up matrix math as the shining example for the utility of operator overloading and you can't even express dot product notation in C++!)--it's a hack at best.

> The code isn't readable (you can't even reliably tell at a glance what the operator does) and it takes negligibly longer to write "add()" rather than "+" in your program (yes, 'add()' is more keystrokes and thus takes longer to type, but most of your program isn't addition instructions).

Except now you replaced + with a name that tells you just as much/little as + does. So you made your program verbose for the sake of verbosity.

No, you’ve made your program “verbose” (by a handful of characters) for the sake of clarity—there is no longer ambiguity about what code runs (of course, this assumes you aren’t similarly overloading named functions, which should also be disallowed).

Given that your example uses neither namespacing nor explicit typing you seem to preach do as I say, not as I do.

I don't know what example you're talking about. I haven't given an example in this thread. I think you may have me confused with another commenter.

so that throwaway suggesting that add is barely longer than + wasn't you?

That was me, but I didn’t provide example code that would require namespaces. I don’t understand his your earlier comment makes sense in the context of this thread.

Operator overloading is like spicy peppers. A little bit can make the program better, but it's very easy to use too much.

Unfortunately, like spicy peppers, everyone's definition of "too much" is different. Some people are eating ghost chili peppers just fine while others are struggling with ketchup.

Which is why we've banned spicy food: it's just too risky to be used safely.

How far are you prepared to take this stance, exactly? C has operators that are generic over both integral and floating point types. Was that a mistake? Did OCaml do it better?

For my part, I've been persuaded that generic operators like that are a net win for math-heavy code, especially vector and matrix math. Sure, C++ goes too far, but there are middle grounds that don't.

Having operators defined for value types within the langauge spec is different thing than defining operator overloading for arbitrary struct and class types.

For numeric value types mathematical operators are the only sane option.

For arbitrary classes - not so much.

A sane language in the slot of C++ in the language ecosystem would not have operator overloading. It would have matrix types defined in the language spec with mathematical operators operating on them.

One part of the philosophy of the language maintainers is that they're somewhat humble about their designs in the standard library, and very much against breaking changes.

Some folks prefer absl's flat_hash_map over std::unordered_map for a hash table, and it's not great that you need to choose or risk having both in a codebase, but it _is_ nice that you can have your preferred hash table and use operator[] whichever you decide.

Python also has operator overloading, and people seem to like that numpy can exist using it. And container types. Weirdly doesn't cause much consternation compared to C++ (maybe because the criticisms of the latter come from C programmers?)

I've occasionally missed overloading in JS/TS though.

> It would have matrix types defined in the language spec with mathematical operators operating on them.

This is unfortunately impossible (IMO). The problem is matrixes have multiple operations that don't translate nicely like complex numbers do. If you want to be consistent, you have to pick and choose What A * B means, under which contexts, and when is that illegal (or what should happen on an error).

For complex numbers, there's only one definition of A * B that matters and no failure cases.

I fear there's not clean way to do matrix operations that won't make some community really irritated for choosing "wrong". (Physics, engineering, science, etc.)

C's integer promotion and conversion rules are definitely terrible. Implicit conversions bad.

Speaking of OCaml, I like the local namespace import:

MyVecModule(v1 * v2 + v3)

Easy to read and explicit enough to know which functions is used.

https://dev.realworldocaml.org/files-modules-and-programs.ht...

> Fight me.

Lunch, behind the cafeteria. Closed fists allowed, nothing below the belt.

"Don't bring your fists to a C++ spec fight."

I personally love glm[1] and the way you can just

    vec3 foo{1, 2, 3};
    vec3 bar{2, 0, -2};
    auto baz = foo + bar; // {3, 2, 1}

[1]: https://github.com/g-truc/glmhttps://github.com/g-truc/glm

Corrected link:

https://github.com/g-truc/glm

Counter example: Any Tensor library ever

You could argue that there is just one type (tensor) with some invalid operations between its values (e.g., when dimensions mismatch). Just like integer division by zero.

What's wrong with being able to add my Complex or Dual numbers together?

Whatever you save in avoiding having to write "sum = add(l, r)" is not worth allowing programmers to bitshift file handles[1], divide file path objects[2], or subscript objects to launch a process[3].

[1] https://en.cppreference.com/w/cpp/io/cout

[2] https://docs.python.org/3/library/pathlib.html

[3] https://pypi.org/project/plumbum/

C++ "bitshifts" (yes, but it's just a symbol in this context) make no real difference to me. It was type safe when it wasn't easy to be back in the day, everyone knows exactly how they work - it's never shot me in the foot (whereas the real meat of the design has, independently of how the composition is expressed syntactically).

The others are more sus but you can make a bad API out of anything.

Rewriting (say) a load of calculations as a tree of sum pow exp etc. is just a huge burden - a codebase I work on has a formula that takes up about 6 lines for example, outputted by mathematica: total pain to to translate to function calls.

> The others are more sus but you can make a bad API out of anything.

Yahhhh but there's something about operator overloading that is like catnip to clever programmers. Ah ha, file paths have slashes, and the divide operator is a slash! Clearly I should use the divide operator to append paths segments together! I'm so clever! Ah ha, << looks kinda like an arrow I guess, so we can use it to, uh, pass data between objects, I guess. I'm so clever...?

It's irresistible. We have abused it and we must give it up for the good of all.

Just because some library writers abuse language features, that doesn't mean everyone else who uses those features correctly should be punished.

[2] pathlib

I quite like that one but I'd be willing to give it up for the hobgoblin of my little mind.

Why not do num1.add(num2)? Or str1.append(str2)?

Like with many things in C++, its another grenade, but when used appropriately is pretty great

“Fried shrimp should be removed from the all you can eat chinese buffay because i cant help myself from eating at least 20 of them in a single sitting and now i have stomach cramp”

The very first Hello World program anyone learning C++ will write uses the godawful iostream bitshifting operators! Not even the language's authors could help themselves eating 20 fried shrimp on the first day the buffet was open!

Agreed the gluttons

If we were set on banning all of the features C++ abused from new languages, we would probably end up writing just empty brackets.

And even then, some Python fan will come in and this is what you will end up with.

https://en.wikipedia.org/wiki/Whitespace_(programming_langua...

This!

The iostream bitshift overload was one of the first features of C++ that I learned to despise. I'm very happy that there's an alternative in the new version.

Sigh. Do you really think that "(vec1.mul(vec2)).plus(vec3.mul(vec4))" is better than "vec1 * vec2 + vec3 * vec4"? Thanks, but no thanks.

Try this on:

    plus(
        mul(vec1, vec2),
        mul(vec3, vec4))

Yeah it's a tiny bit clumsier, and prefix notation takes some getting used to. But on the plus side we avoid all the too-clever travesties programmers have inflicted on us with bad operator overloading decisions! On the whole I think it's easily worth the trade.

Again, no thanks. I want mathematical notation and I simply won't use any language without operator overloading. Free functions for common mathematical operations are an abomination.

Then you should probably use a language that lets you write DSLs for any given domain, rather than abusing operator overloading which just happens to work for a few subdomains of mathematics (e.g., you can't use mathematical conventions for dot product multiplication in C++). Anyway, I've never seen any bugs because someone misunderstood what a `mul()` function does, but I've definitely seen bugs because they didn't know that an operator was overloaded (spooky action at a distance vibes).

Assuming mul does actually a multiplication.

It doesn’t matter, you can look it up easily because without overloading, you know exactly which implementation will run.

Ah, just like I do when I press F12 over an operator.

You come across as a bit facetious here.

Of course, the compiler or an advanced IDE can know what your code means. If all your identifiers were random permutations of l and I: lIllI1lI, your IDE would not mind either, but the code would be horrific, don't you agree? The point of the OP is that overloaded operators (and functions) make it harder to reason about the code for a human that reads it. At least for some people. At the end, everything is "just" syntactic sugar, but it makes a significant difference.

Exactly. If you don't care that the code is unreadable and you can rely on every human viewing the code through an IDE with symbol resolution (and not say, online code review platforms) and remembering to use said symbol resolution to check every operator, then operator overloading is great!

Actually, I'm quite happy what C++ has to offer :)

Yes, the * operator can be ambiguous in the context of classic vector math (although that is just a matter of documentation), but not so much with SIMD vectors, audio vectors, etc.

Again:

a) vec4 = (vec1 - vec2) * 0.5 + vec3 * 0.3;

or

b) vec4 = plus(mul(minus(vec1, vec2), 0.5), mul(vec3, 0.3));

Which one is more readable? That's pretty much the perfect use case for operator overloading.

Regarding the * operator, I think glm got it right: * is element-wise multiplication, making it consistent with the +,-,/ operators; dot-product and cross-product are done with dedicated free functions (glm::dot and glm::cross).

That's what numpy does too.

One never writes such expression in a serious code. Even with move semantic and lazy evaluation proxies it is hard to avoid unnecessary copies. Explicit temporaries make code mode readable and performant:

auto t = minus(vec1, vec2); mul_by(t, 0.5/0.3); add(t, vec3); mul_by(t, 0.3); v4 = std::move(t);

I think there may be a misunderstanding here regarding the use case. If the vectors are large and allocated on the heap/on an accelerator, then yes, writing out explicit temporaries may be faster. Of course, this does not preclude operator overloading at all: You could write the same code as auto t = vec1 - vec2; t *= 0.5/0.3; t += vec3; t *= 0.3;

However, if the operands are small (e.g. 2/3/4 element vectors are very common), then "unnecessary copies" or move semantics don't come into play at all. These are value types and the compiler would boil them down to the same assembly as the code you post above. Many modern C++ codebases in scientific computing, rendering, or the game industry make use of vector classes with operator overloading, with no performance drawbacks whatsoever; however, code is much more readable, as it matches actual mathematical notation.

Thank you for putting this so eloquently!

> Many modern C++ codebases in scientific computing, rendering, or the game industry make use of vector classes with operator overloading, with no performance drawbacks whatsoever

I guess these people are all not writing "serious code" :-p

> One never writes such expression in a serious code.

Oh please, because you know exactly which kind of code I write? I'm pretty sure that with glm::vec3 the compiler can optimize this just fine. Also, "vec" could really be anything, it is just a placeholder.

That being said, if you need to break up your statements, you can do so with operators:

    auto t = vec1 - vec2;
    t *= 0.5/0.3;
    t += vec3;
    t *= 0.3;

Personally, I find this much more readable. But hey, apparently there are people who really prefer free functions. I accept that.

TIL Box2D must not be serious code because it doesn't use copious amounts of explicit temporaries[0].

And just for the record, I'm very glad Erin Catto decided to use operator overloading in his code. It made it much easier for me to read and understand what the code was doing as opposed to it being overly verbose and noisy.

[0]: https://github.com/erincatto/box2d/blob/main/src/collision/b...

If editors were to implement it, you could navigate to the corresponding overload implementation or even provide some hint text. Just like they do for other functions.

In Visual Studio it is already there.

Yeah, we would need editors and code review tools to not only follow overloads to their functions but also highlight that the operator is overloaded in the first place. Of course, this is quite a lot more work than just not overloading things in the first place (particularly since the benefit of operator overloading is negligible).

Dealing with money is important, even if it's only a small part of mathematics. I'll focus on that.

Python's 'decimal' module uses overloaded operators so you can do things like:

  from decimal import Decimal as D

  tax_rate = D('0.0765')

  subtotal = 0
  for item in purchase:
     subtotal += item.price * item.count # assume price is a Decimal
  
  taxes = (subtotal * tax_rate).quantize(D('0.00'))
  total = subtotal + taxes

Plus, there's support for different rounding modes and precision. In Python's case, something like "a / b" will look to a thread-specific context which specifies the appropriate settings:

  >>> import decimal
  >>> from decimal import localcontext, Decimal as D
  >>> D(1) / D(8)
  Decimal('0.125')
  >>> with localcontext(prec=2):
  ...   D(1) / D(8)
  ...
  Decimal('0.12')
  >>> with localcontext(prec=2, rounding=decimal.ROUND_CEILING):
  ...   D(1) / D(8)
  ...
  Decimal('0.13')

Laws can specify which settings to use, for examples, https://www.law.cornell.edu/cfr/text/40/1065.20 includes "Use the following rounding convention, which is consistent with ASTM E29 and NIST SP 811",

  (1) If the first (left-most) digit to be removed is less than five, remove all the appropriate digits without changing the digits that remain. For example, 3.141593 rounded to the second decimal place is 3.14.

  (2) If the first digit to be removed is greater than five, remove all the appropriate digits and increase the lowest-value remaining digit by one. For example, 3.141593 rounded to the fourth decimal place is 3.1416.

   ... (I've left out some lines)

and from https://www.law.cornell.edu/cfr/text/7/1005.83 :

  (3) Divide the result in paragraph (a)(2) of this section by 5.5, and round
  down to three decimal places to compute the fuel cost adjustment factor;

  (4) Add the result in paragraph (a)(3) of this section to $1.91;

  (5) Divide the result in paragraph (a)(4) of this section by 480;

  (6) Round the result in paragraph (a)(5) of this section down to five decimal
  places to compute the mileage rate. 

There's probably laws which require multiple and different rounding modes in the calculation.

This means simply doing all of the calculations in scaled bigints or as fractions won't really work.

Now of course, you could indeed handle all of this with prefix functions and with explicit context in the function call, but it's going to be more verbose, and obscure the calculation you want to do. I mean, it's not seriously worse. Compare:

  with localcontext(prec=3, rounding=decimal.ROUND_DOWN):
    line3 = line2 / D("5.5")
  line4 = line3 + D("1.91")
  line5 = line4 / 480
  line6 = line5.quantize(D('.00001'), rounding=decimal.ROUND_DOWN)

vs. some function-based API with overloaded parameter types:

  line3 = decimal_div(line2, D("5.5"), prec=3, rounding=decimal.ROUND_DOWN)
  line4 = decimal_add(line3, D("1.91"))
  line5 = decimal_div(line4, 480)
  line6 = decimal_quantize(line5, D('.00001'), rounding=decimal.ROUND_DOWN)

But it is worse. I also originally made a typo in the function-based API for line5 where I used "decimal_add" instead of "decimal_div" - the symbols "/" and "+" stand out more, and are less likely to be copy&pasted/auto-completed incorrectly.

If overloaded parameters - "spooky action at a distance vibes" - also aren't allowed, then this becomes more rather more complicated.

plus(x, y) IS mathematical notation. It's RPN without symbol shortcuts. Mathematica has used this for decades.

It's Polish Notation actually.

Thanks, corrected in place.

sure, I was a bit sloppy there, but I think you know what I meant. Polish notation is just not how most people write arithmetic expressions :)

mul(x, y)

can be overloaded! x and y could be any cobination of matrix, vector, or integer, float.

You're mixing up overloading (which is semantics) with syntax.

We all know that functions can be overloaded. The emphasis is on operator overloading. So yes, it is about syntax.

Why have operators at all? If that notation is good enough, then you might as well use it for the built-in types too. We're halfway to designing a Lisp!

How can you be sure that plus() and mul() actually do what they say?

They're functions. Whatever they do, my code will go execute some code from whatever library implements them, which is what a function does. I just want to be able to rely on [] being an array subscript when I read some unfamiliar code. Is that too much to ask?

Just like the function that happens to be named [].

Can IDE's detect this and offer "go to implementation" on an overloaded operator these days? Because besides from the surprise-element in the fact that there even is code to debug hiding somewhere, not being able to quickly navigate to it is much worse in my opinion. And with infix operators where you can't even be sure which operand the implementation belongs to, figuring it out can be a bit of a detective task.

Visual Studio does show a popup, go to implementation, and if the implementation happens to be visible on the same screen, also highlights it.

If you’re using it right then [] is still an array subscript, just with a custom implementation for getting array elements

You read the code. And unlike operator overloading, you know at a glance exactly which implementation to look at. There is no spooky action at a distance.

How, the functions might support dynamic dispatch or be overloaded based on types.

There's nothing that prevents me from implementing all of

    plus(Int, Int)
    plus(Int, Vec)
    plus(Int, Mat)
    plus(Vec, Vec)
    plus(Vec, Mat)
    plus(Mat, Mat)

and to know which `plus` is being dispatched, you need to know the types of both arguments, exactly the same as if `plus` is named `__add__` in python or `operator+` in C++.

Yes, overloading is bad (operator overloading is a kind of overloading).

How do you do math without overloading? I have ints, floats, bignums, vectors, matrices, complex numbers, and potentially fractions.

You want every operation to have a distinctly named version for each other numeric type?

Maybe you can reduce some of those, but you can't really have interfaces without some overloading.

Exactly the same thing with functions that happen to use funny characters.

Nah, there’s no spooky action at a distance when you don’t overload. You know concretely what code is running.

Have you ever heard of linkers?

Have you ever heard of potatoes? Neither of them help you tell at a glance which code is being dispatched to.

I think in this context what's important is if these functions are overloaded or not…

Which in any case also means the only way to be sure is to track down the implementation, the actual character set hardly makes a difference.

I agree. Function overloading is just as bad as operator overloading.

You still need to validate if the implementation matches the name, no matter what.

Sorry but please don't take Eigen (https://eigen.tuxfamily.org) away from me. Can't speak for others, but the scientific code I work on would become unreadable like that.

The site seems to be down

https://downforeveryoneorjustme.com/eigen.tuxfamily.org?prot...

Function overloading's not that much better.

Even better:

    (plus 
      (mul vec1 vec2)
      (mul vec3 vec4))

Lisp is love.

Love is cruel; you could fall for a goat (a Russian proverb)

I rather type,

    (+
       (* vec1 vec2)
       (* vec3 vec4))

Lisp is love indeed.

That't literally the only place where operator overloading makes any sense.

In other places they monkey patch c++ defincies as a language.

And they are confusing and error prone.

Nobody is pretending we will get rid of any c++ syntax ever. So the discussion is about a hypothetical language syntax that fits C++ slot.

In that world C++ would have N x M matrices as native value types in the language (as fortran does) and those operators would be defined in the language spec for matrix types just as they are defined for standard number types at the moment.

And it would not have any operator overloading.

> That't literally the only place where operator overloading makes any sense.

That may be true for C++ (I'll take your word for it), but not for all programming languages in general. For example, in C# it's fairly common to overload == and != to implement value equality for reference types (classes).

Of course, you should really only do this for immutable classes that are mostly just records of plain old data. And C# 9 introduced record classes, which is a more convenient way of defining such classes. But record classes still overload these operators themselves, so you don't have to do it manually.

Honestly that sort of thing always confused me when I worked in Java, C#, etc. I could never tell at a glance whether the operator was doing an identity comparison or a value comparison, and I definitely contributed a few bugs from this misunderstanding. In Go which lacks operator overloading, we either `ptr1 == ptr2` or we do some `ptr1.Equals(ptr2)` for value comparisons and `ptr1 == ptr2` for pointer comparisons--in either case, there is no ambiguity and IME fewer bugs.

Java's the same regarding == and .equals( ) and when it's Java code written by devs who also work in other languages, it definitely still results in bugs, sometimes that go undiscovered for remarkably long times (particularly if == happens to return the right result in most cases). Meaning/needing to compare references for string (and similar) types is exceedingly uncommon, yet uses the more "natural" syntax for testing equality. FWIW I can't remember working with a codebase where unexpected behavior due to operator overloading was a serious problem.

That's more of a problem with languages that confuse value types and references.

Making such assumptions about what is correct or proper use is why c++ is so successful, it doesnt make assumptions it leaves it up to the project / community using it. Go ahead make a language that dictates alot and makes srict assumptions it will be depricated or forced to open up before the end of the decade. Notr this is why i think python and lisp is so populare meta programing is very powerful and expressive.

That's a good observation about C++ not making assumptions, it strikes me as true. C++ apparently doesn't even make assumptions about what the C++ filename extension is. .h, .hh, .hpp, .hxx, .C, .cc, .cpp, .cxx, .ixx, cppm

The fact C++ has so many ways of defining things is not the reason it's so popular. The reason is the enormous industry investment on the language tooling and ecosystem. IMO the language itself is the worst part of the ecosystem, but the other parts create a totality that is the best development language ecosystem in industry for my niche (graphics and geometry) including libraries, copmpilers, debugger & profiling etc.

Any language with the level of industrial support C++ has had would have grown to prominence. C++ came abut a judicious time in history when "object orientation" was becoming the latest buzzword. And now we have ended up with gazillions of lines of C++ code.

It's a tragedy of our trade that two mongrels - C++ and Javascript - became to be among the most prominent in our trade.

But the reason C++ fits in so many industries from embedded system to high level gui libraries is its flexibility we see the end of OOP trend but C++ does bot lock its users into one paradigm or another so it will continue to be industry standard. Even if the industry is moving towards other paradigms of programing.

I recently wrote a program to generate tilings. It used exact coordinates internally represented by algebraic numbers with integer coefficients. If I couldn't have overloaded the arithmetic operators then using the algebraic numbers would have been a massive pain in the arse. Overloading is legitimately useful.

What about the assignment operator?

> That't literally the only place where operator overloading makes any sense.

So, no overloading for decimal types? Nor fraction types?

I may be the oddball here, but I've used operator overloading on those types more than I have for vectors and arrays.

Fortran now has operator overloading, though.

Vectors and perhaps matrices are about the only valid use case I have ever come across, so I agree with GP that it's not worth it. And that's speaking as someone who once implemented a path class with a subtraction operator that would return the relative path between two absolute ones. I thought I was very clever. I feel sorry for the developers who had to figure out what that was about after I left..

Ah, matrices! Does * mean dot product, cross product, or the usually less useful matrix multiplication? Ooh, or maybe you should you use . for dot! How clever that would be!

> And that's speaking as someone who once implemented a path class with a subtraction operator that would return the relative path between two absolute ones. I thought I was very clever.

Haha! It's ok. The temptation to be clever with operators is too strong, few can resist before getting burned (or more usually, burning others!) at least once.

> Ah, matrices! Does * mean dot product, cross product, or the usually less useful matrix multiplication? Ooh, or maybe you should you use . for dot! How clever that would be!

Why the snark? The fact that you're free to make a bad choice does not imply that having a free choice must be bad. Obviously neither dot nor cross product should be *. It should be the Hadamard product or matrix multiplication. You can choose one convention for your code and be perfectly happy for it.

As a follow-up question: How do you feel about languages like Fortran and Matlab then? Is it actually a good thing that mathematics convenience features are relegated to a few math-oriented languages and kept away from all the others? (Or are the linear algebra types in these languages offensive as well?)

Maybe C++26 will let us write operator·() and operator×().

In C++34 we'll finally have a way of overloading the empty string operator, so that we can, at last, write AB for the product of matrices A and B. As God intended.

Stroustrup, B. (1998, April 1) Generalizing Overloading for C++2000. AT&T Labs. https://www.stroustrup.com/whitespace98.pdf

The benefits from operator overloading are "I can show this to a mathematician and it looks like what they're used to". The downsides lurk in the corners of whether it's actually doing what you think.

I'll pass.

As someone who has written math libraries over and over again for the last 25 years (I wish I was joking, but it turns out it is something I'm good at [1]), I find that operator overloading works only for the simple cases but that for performance and clarify, function names work best.

Function names let you clarify that it is an outside product or inside product (e.g. there are often different types of adds, multiplies, divides), and I can not stand when someone maps cross product onto ^ (because you can both exponent and cross product some vectors, like quaternions, so why use exponent operator for cross?) or dot product onto something else that doesn't make any sense. Also operator overloading often doesn't make clear memory management, rather it relies on making new objects constantly, whereas with explicit functions, you can pass in an additional parameter that will take the result. Lastly, explicit functions allow you to pass additional information like how to handle various conditions, like non-invertible, divide by zeros, etc.

I find word based function more verbose but significant less error prone and also they are more performant (because of the full control over new object creation.) Operator overloading is only good for very simple code and even then people always push it too far so that I cannot understand it.

[1] 1997: https://github.com/bhouston/BezierCurveDemo1997/blob/master/..., 2001: C# math library: https://github.com/bhouston/ExoEngine3D/tree/master/Librarie..., 2013: a bunch of the core Three.js math library, 2023: https://github.com/bhouston/threeify/tree/master/packages/ma...

> rather it relies on making new objects constantly, whereas with explicit functions, you can pass in an additional parameter that will take the result.

We have move semantics since C++11.

And expression templates even before that.

It's not the same if you need to allocate memory for the result. If you could pass the result in by reference, then you could (re)use a buffer which has already been allocated. The difference is massive in things like matrix calculations or image processing where you have an inner loop or a real-time stream repeating similar calculations.

Or you are working with a language like JavaScript where math primitives are GC objects and thus quite costly. In those languages if you do not reduce object creation via reuse in this way, it can be very slow.

Perhaps you're arguing that you ought to be able to name new operators (like Haskell) so that you can create a new operator for inner product instead of having to use '^' (typically used for exp or xor).

Alternatively, the main reason to use operators here is infix notation, so perhaps Haskell-like backticks.

I think languages like Julia make a strong case the other way. you can literally write algorithms that match the pseudocode in a paper. You have to be ok with unicode in your source file, but for numeric stuff, I think its a nice feature

What if you could type the asterisk to multiply vectors, but then your editor of choice would replace it with the symbol that actually means vector multiplication?

Perhaps that idea falls apart once you realize you would need hundreds of symbols for just addition…

But what if those symbols were (automatically) imported and named at the beginning?

Perhaps it would be annoyingly inconsistent how in various files different symbols are used for the same operation…

> then your editor of choice would replace it

I realize this is a minority opinion, but I don't want my editor to replace anything unless I've deliberately told it to.

It could annotate the view without changing the source.

For example my editor annotates auto with inferred types and function parameters with parameter names.

The idea is, operator overloading is a convenience feature. Why not have that convenience as an option in an editor, without influencing the language? If you want scalar multiplication to look the same as vector multiplication, set it in your editor. If you want to insert scalar multiplication with the same key you insert vector multiplication, set it in the editor (to figure out which you mean, based on context, when you press that key).

Just to be clear, I'm not being a smartass, just considering this as an option and wondering if the HN crowd has some thoughts on this.

Sure, there is a place for operator overloading.

That said, in my experience over the decades, operator overloading has been one of the primary causes of bugs that are very hard to pin down, so I have come to hate it. It hides far too much.

The cost/benefit ratio of operator overloading is generally unfavorable in practice, in my experience. Which is not to say it shouldn't be used when it actually clarifies things! But those situations tend to be fairly niche.

Interestingly, where I work right now, using operator overloading is specifically prohibited. So I'm confident that my dislike of the practice is not just a personal quirk.

Yes (I’m a numerical analysis researcher and wrote a handful of ubiquitous mathematical packages)! The implementation of even primitive types can vary considerably! It’s way too much to hide. Nevertheless, I understand I’m biased. :)

In engineering practice, we often start using math without first consulting numerical analysts. It takes a long time to identify and fix the inevitable issues, which eventually becomes a lesson we have to teach students and practicing engineers because there's so much history of doing it the wrong way.

As an example, early device models for circuit simulation were not designed to be numerically differentiable, leading to serious numerical artifacts and performance issues. Now we have courses dedicated to designing such models, and numerical analysis is used and emphasized throughout.

Is there anything today that you look at and think "yeah, they're gonna need to fix that at some point"?

No but I think

    sum({ mul(vec1, vec2), mul(vec3, vec4) })

definitely is.

In a certain pedantic, functional way, yes. For fast visual parsing, no.

Overloading is orthogonal to the issue you're striking at: infix operators versus postfix function calls. Functions can be overloaded just like operators.

I'd prefer MultiplyVecs(v1, v2) + MultiplyVecs(v3, v4) myself. Makes it easy to jump to the function definition and see exactly what's going on.

I wish that Java had it, so that adding and multiplying BigDecimals would not look as ugly as it does

Not every day you get your wish.

https://github.com/manifold-systems/manifold/tree/master/man...

Operator overloading is critical for building ergonomic frameworks.

The modern web is built on overloading the . operator (e.g. ORMs like Rails and Django). We will never see a Tier-1 ORM in Golang simply because it lacks it.

Gamedev, AI also benefits heavily from it.

> Operator overloading is critical for building ergonomic frameworks. The modern web is built on overloading the . operator (e.g. ORMs like Rails and Django). We will never see a Tier-1 ORM in Golang simply because it lacks it.

Not true. It can be replaced with codegen.

See Ent (spun out of Facebook I believe)

https://entgo.io/docs/getting-started

As I said, there won't be a Tier-1 ORM in Go. Ent or Gorm are tier-2 at best.

Any advantages of Go (and there are many) are outweighed by the fact that you have to write and read 2x more code to be equally productive as Rails or Django.

You should actually try Ent, it's about as good as commercial ORMs like Prisma.

> We will never see a Tier-1 ORM in Golang

That sounds like a good thing, having dealt with Hibernate in production. As a backend developer, I'm pretty happy with C++17 (and beyond), Go and Rust. All of them can be used in fairly explicit ways, which means debugging a problem is easy, and performance issues are right there on the page if any. I want less magic, not more.

> I want less magic, not more.

Magic is magic until it becomes understood, then it is science.

While I don't want junior programmers wielding the dark magic of operator overloading, I trust that the engineers behind Django are using it reasonably.

C#?

I disagree, it’s heavily abused but very useful for types where it’s obvious what the operation is (inherently mathematical types like vectors and matrices). I wrote a macro library for C that vector/matrix math in prefix notation with _Generic overloads and it’s still too clumsy to get used to.

> where it’s obvious what the operation is (inherently mathematical types like vectors and matrices)

Considering there are like 3 different types of matrix multiplication operations, I don't think it's obvious at all. Feels like you should either use a language with complete support for implementing custom DSLs (that can express the whole domain naturally) or eschew ambiguous operator overloading altogether (gaining consistency and quality at the expense of a few keystrokes).

I think we all know what someone means when they say “matrix multiplication”. Asserting that * could mean, say, the Hadamard product or the tensor product is a reach. In practice I have never seen it mean anything else for matrices.

DSLs just push the complexity away from the language into someone else’s problem in a way that has much higher sum complexity. You’re making authors of numerical libraries second-class citizens by doing so. For some languages that’s probably not a bad choice (Go is one example where I don’t feel the language is targeted at such use cases).

Also, the lack of a standard interface for things like addition, multiplication, etc. means that mathematical code becomes less composable between different libraries. Unless everyone standardizes on the same DSL, but I find this an unlikely proposition, given that DSLs are far more opinionated than mere operator overloads.

Cage fight, or arguing about the feature?

You want different addition functions for floats vs ints vs unsigned ints?

I'll byte: complex numbers and matrix support is bad in languages without operator overloading. Why should only the primitive types of the language be privileged to proper math notation?

BS. I thought that Java already demonstrated to the world how dumb it is to disallow operator overloading altogether.

Allowing ANY operator to be overloaded was dumb, like C++ did, where you could do batshit crazy stuff like overloading unary & (addressof) or the comma operator (!), or stuff like the assignment operator (that actually opens a parenthesis about how copy/move semantics in C++ are a total hack that completely goes OT compared to this).

Sensible operator overloading makes a lot of sense, especially when combined with traits that clearly define what operations are supported and disallow arbitrary code to define new operators on existing types. Rust does precisely that, and IMHO it works great and provides a much nicer experience than Java's verbose mess of method chaining.

It is a very natural feature. Especially when you are writing mathematical code e.g. implementing different types of numbers, e.g. automatic differentiation, interval arithmeic, big ints, etc.

Overloading gives user defined types the expressiveness of internal types. Like all features, of they are used badly (e.g when + is overloaded to an operation which can hardly be interpreted as addition) it makes things worse. But you can write bad code in any language, using any methodology.

It is a very natural feature, but it makes discovering what you can and can't do with a library really hard. Learning what is and isn't legal with math libraries that use a lot of them can be really tricky. For example, numpy code is really easy to read, which is fantastic, but figuring out how you're intended to do things from the documentation alone is quite difficult.

In my experience numpy has also been on of the worst numerics libraries to deal with. The main reason is that Python seems designed to be hostile to numerics. Loose typing, assumptive conversions, specific numeric types hard to access, tedious array notations, etc. all are bad preconditions for a language which sadly seems to have become the prototyping standard in that area.

The moment you have a language actually designed for numerics all these things vanish. One of Julias core design aspects is multiple dispatch, including operator overloading and it works extremely well there.

I also don't see the point for discoverability at all. The documentation will list the overloads and the non-overloaded calls are exactly as discoverable as the others.

Exhibit a: Haskell.

Consider the humble + operator. In most compiled languages -- even those that don't support operator overloading -- it is in fact overloaded. int + int. long + long. float + float. double + double. pointer + int. Would every language be better with it?

Built in operators don't always map 1-1 to CPU instructions so don't appeal to that authority. There are still plenty of CPUs -- old and new -- without multiplication, division, or floating point support.

Agree. It looks fun when I am writing the code and re-inventing abstract algebra and category theory types for classifying cat pictures. However then at some point I have to read someone else's code, even my own code weeks later and then I start cursing operator overloading.

In C++, with its templates, there are only a couple alternatives:

1. Operator overloading

2. Operator desugaring (e.g. __subscript__(), which substitutes the intrinsic function for basic types, but can also be defined for user defined types)

3. Writing templates with weird adaptors for primitive types.

Given that its design goal was to embed C, there were already operators that worked with various and mixed types. Adding (+.), etc., would have been unacceptable to the users. So, I think in general, for this language, it was good but, unfortunately, iostream made people think you should overload the behavioral expectation, too.

The alternative GP is advocating for is "none of the above." Meaning "operators are only defined for primitive types" which is perfectly fine when working with C.

If you wanted to use an abstraction over non primitive types for such things you would use a normal function.

But then you make built-in types special. One of the tenets of C++ is that user defined types have as much power as built-in types.

Built in types are special. The compiler needs to define operator precedence and certain semantics (commutativity, associativity, overflow, etc) that cannot be expressed in the type system or enforced by the interface.

The fact that it makes syntax "nicer" for user defined types is at best subjective and at worst an anti-pattern because it leads to bad compiled code and confused programmers. Function calls are unambiguous and follow the same rules as other function calls, while operator overloading does not.

Its design goal was to repeat the author's experience having to downgrade himself from Simula to BCPL, he wasn't keen in repeating the same experience with C, when he went out to write distributed computing applications at Bell Labs.

Bjarne has given a couple of interviews on the matter.

How about infix function with a prefix? That is to say #+ would be an overloadable infix function, + would be a non overloadable operator.

> Fight me.

OK, come to my glass labyrinth where you don't know which of a dozen images of me are the real instance.

You will soon appreciate obfuscation techniques.

I've never understood why people complain a lot about `std::cout << "string"`, if the problem is that this operator is used for bit shifting, simply stop thinking that way (genius I know), do you think of addition when you see `string + "concatenate"`? Operator overloading is awesome, and like everything in programming, if used correctly; constructing paths with / is sweet, and I find << with streams visually appealing and expressive, it's feeding data to the stdout/file/etc, same for `std::cin >> var`, data goes from the stdin to the variable.

Aside from the syntax (I find it ugly, you find it visually appealing - it's subjective), iostreams are inefficient, awkward to customise, not thread safe (allows interleaving), and mix format and data (that one is also subjective).

I love me some operator overloading. I love / for filesystem separators, I love | for piping things. I don't like << and >> so much but that's just because of too many years of writing them everywhere.

> do you think of addition when you see `string + "concatenate"`

Yes. And it tortures me every time.

I religiously avoid string concatenation in Python for this very reason. It's not that "+" necessarily means addition; it's that it always means a commutative operation (to somebody who has learned some algebra). String concatenation is notoriously non-commutative, thus it is extremely disturbing to write it using a visibly commutative operator. Any other operator except "+" would be better. For example, a space, or a product, or a hyphen. Whatever. But please, not a commutative operator. It breaks my brain parser.

This is a really good point. It bothers me too, but I hadn't really articulated why.

It's also one of the biggest sources of bugs when dealing with loose types around strings and numbers.

When it comes to languages that let you mix strings and numbers, Lua has it right. + always adds, and accepts numbers and strings that can cleanly convert to numbers. .. always concatenates, and accepts numbers and strings.

Nah. I'll just step away and let you fall on a sword. I am not religious about languages, paradigms, etc. etc.

Not having operator overloading is anti-human. To think so highly of yourself that there is no other thing that can properly be the subject of the field operators (or other basic operators) is the height of hubris. The compiler typically must handle the operators on certain types due to the compilation target's semantics, but in reality, there's nothing special about these 'built-ins'.

Operators like +, -, /, *, etc have meanings independent of integers and floats and to not allow these meanings to be expressed is sad.

I've heard many programmers express this sentiment and what they actually are attempting to argue is that having overloads of these operators that do not respect the corresponding group, ring, or field laws is confusing. This I agree with. Operators should mainly follow the proper abstract semantics.

The big problem is lack of consistency:

Most programming languages use infix notation for mathematical operations but polish notation for function calls. This creates an inconsistency. In languages, like LISP, that entirely use polish notation the inconsistency does not exist.

One could argue that if a programming language has this inconsistency, then one should at least try to be consistent with one's notation, i.e. for mathematical operations use infix notation (operator overloading).

Operator overloading has been a feature of many languages dating back to the very concept of using operator notation in programming. I know of no language that has the * operator dedicated solely to a single type. Typically you have at least signed and unsigned overload, as well as various bit sizes (including larger than the machine word size), and floating point representations. Extending that to vectorial operations, arbitrary precision, and others only seem to make sense and to be going with the flow...

I'm on your side, but only after many years of being on the other side. I used to think they were "graceful" and "minimalist", and refused to acknowledge they can be the source of many surprises.

The Google C++ style guide has a very nice overview. There are only two pros listed, and large number of cons. And this document is old by Internet (dog) years -- at least 10 years.

Ref: https://google.github.io/styleguide/cppguide.html#Operator_O...

If you do a lot of math code (linear algebra), operator overloading helps a lots to maintain readability.

Operator overloading is one of the cornerstones of generic programming in C++. And perhaps it is a failure of imagination on my part, but it’s difficult to think of a more elegant approach.

> Operator overloading is an anti-feature and every language with it, would be better without it. Fight me.

In Scala, infix operators and methods are the same thing.

  a + b

  a.+(b)

Or

  a.map(b)

  a map b

It's never been clear to me why there should be special "operator" things.