> operator overloading is the spawn of Satan

I used to agree with you, because of the abuse of operator overloading like iostreams and making DSLs with it. D does support it, but in a way that discourages non-arithmetic uses (such as it won't allow < <= >= > to be overloaded separately).

Operator overloading allows for things like complex numbers, arbitrary precision numeric types, etc., to be done with a library module.

> Operator overloading allows for things like complex numbers, arbitrary precision numeric types, etc., to be done with a library module.

Why is this desirable vs. implementing those types in the language itself?

I think we've gone down a weird path where implementing things "in userspace" is seen as an inherent good -- why?

> Why is this desirable vs. implementing those types in the language itself?

That's a very good question.

1. It's simpler. In D, we transitioned from a builtin complex type to a library type. It was a happy experience. The simpler the compiler, the easier it is to deal with.

2. Most any programmer can create a library type. Relatively few can modify a compiler to add a new type.

3. It takes the pressure off the compiler team to develop more arithmetic types.

4. Users can add arithmetic types without needing anybody's consent, and can do it right now.

5. It tests and verifies the metaprogramming abilities of the language.

Elaborating on 3/4: the domain experts don't need to be compiler experts too.

There are always going to be more numeric-like types (int, float, complex, bigint, rational, symbolic-comp types etc.). Numeric vectors that act like numbers are useful (see: numpy), and trying to stick those all into the language is far harder than allowing extensibility.

This is probably the best talk ever on the general topic: https://m.youtube.com/watch?v=_ahvzDzKdB0 [Growing a language by Guy Steele], seriously give it a look if you have the time and do put up with the seemingly strange start.

But at around the end it asks this (paraphrasing): Should a language have complex numbers implemented natively? Should it have numbers module n implemented natively? What about intervals, or rational numbers?

I also dislike the ridiculous overloading of cryptic symbols, but neither extreme is good. Not allowing overloading will give you BigDecimal.of(3).add(BigDecimal.ONE).divide… , while allowing it unrestricted will give you things like msg #!! something. But perhaps a sane middle ground is to allow only basic operators (+,-,*,/) to be overloadable.

The author definitely understands that. The point is: when you don't have operator overloading you get stuff like that which does demonstrably confuse many people

In languages with operator overloading this just isn't a concern at all because == does the obvious thing

> In languages with operator overloading this just isn't a concern at all because == does the obvious thing

And what is the obvious thing? It varies wildly among languages, even within C++ itself.

The obvious thing is to check if the contents are equal. I don't know what cursed C++ you're looking at if you're finding a ton of string implementations not doing exactly that...

== should do the obvious thing. But with operator overloading, it's not clear that it does, unless you need to read the implementation of == very carefully.

How is that any different to some opaque method call? By the same logic `a.equals(b)` might be doing something funky under the hood

True. But people think about it a bit differently. People don't always expect == to be a function call.

Sure, but I think '== might be a function call' is a lot less confusing than '== sometimes compares for equal value and sometimes doesn't'

I don't get the problem with operator overloading. Yes, it can be implemented badly, but so can the equals() override. You can't even call a.equals(b) safely in many programming languages because either a or b could be null. I've run into so many null pointer exceptions in Java because someone wrote a.equals(b) when they clearly meant a!=null && a.equals(b).

Every time I have to write `BigDecimal sum = one.add(two).add(three).minus(four)` I cry a little. This is effectively no different from operator overloading and it's what special number implementations in all languages without operator overloading seem to end up doing out of necessity.

Usually you do want to compare by value, so it should get the obvious syntax. When you want to compare by reference, you should write if(&a == &b) or ReferenceEquals(a, b) or something.

Without operator overloading, it is basically impossible to adapt a language for numerical computing/data science applications. Yeah, operator overloading is a powerful tool that's easy to abuse; no, it's not optional if you want the language to succeed at all in a whole bunch of applications.

Mathematica works just fine without user-defined operator overloading.

> Also: operator overloading is the spawn of Satan.

It's necessary for "powerful" generic programming. In fact, the entire reason user-defined data types can be easily used in C++ libraries like CGAL, Eigen, fmt, Kokkos, ranges-v3, etc, is because of operator overloading.

> Also: operator overloading is the spawn of Satan.

It is. And I'm glad Zig has none of that. `==` only works for primitives and you will never be confused.

Not sure that's a good idea. The concept of some types being special should not be something exposed to the user.