It's because defining "customization points" as operators make it easier to write templates, essentially. See "C++ doesn’t know how to do customization points that aren’t operators": https://quuxplusone.github.io/blog/2018/08/23/customization-...

This is one of the downsides of not having typeclasses that is often forgotten about.

Wouldn’t uniform call syntax (like in D) solve most of the issues outlined above? I.e. it always boils down to “primitive types can’t have methods”; but uniform call syntax would let us call any function like a method on its first argument...

Or just allow methods to be defined on primitive types, like Rust.

Uniform call syntax is a superset of that, since you can’t have virtual methods on primitive types.

That's why I cannot wait for concepts

Often the reason is not wanting to introduce new keywords for backwards compatibility reasons. And when keywords are introduced, often they have to be awkward (like `co_await`) to minimize conflicts with existing code. Context-sensitive keywords are one solution but can make parsing even more complicated in places where arbitrary lookahead might be needed.

That’s also why the sizeof... operator was chosen. It’s an abuse of notation, because it returns a count of elements rather than the sum of sizeof applied to each, but ... and sizeof were already reserved.

C++ land is actually quite conservative.

You should try Lisp, ML, Haskell Julia lands regarding that matter.

Developers with math background on languages with symbols as identifiers can get quite creative.

At least with Haskell (I can't speak for the others), you don't redefine existing operators, you add new ones. Which is less confusing in some ways

Is it really less confusing that + for numbers has another meaning that + for a newtype that implements Num?

I think so, since you can also count on that type to implement the other required methods of Num.

Right, the fact that functions and operators must be part of a typeclass to be overloaded makes a huge difference. Sure, you can define your Num instance however you want—but that doesn't change the fact that by providing a Num instance you're asserting that the type is "number-like". The typeclass also enforces certain restrictions, such as the fact that the arguments and return value of (+) must all be the same type, which helps curtail the more egregious abuses like the repurposing of the C++ bit-shift operator for stream I/O. And since the set of possible operators is so much larger (almost any sequence of Unicode symbols) there isn't a great deal of pressure to abuse the existing notation. In C++ you can only override the limited set of built-in operators, even if the concept you're trying to express isn't closely related to any of them.

It helps that Haskell operators are namespaced just like functions, so you can choose which operators to bring into scope from other modules.

There is no way to enforce that + actually implements the concept of adding two values.

With dependent types you can. I'm not aware of whether that proof is possible in Haskell, however.

Besides, that's not what I was saying. What I was saying it that + in Haskell means more than an overloaded operator. It means the type has access to additional methods. This gives you more information.

In that case you get the same information on any usable C++ IDE.

It's weird how opposite the core language and the std library of C++ are, and even more so in the recent revisions! The core language seems to go for being as code-golfy as possible, while the std library goes for super-verbose without any convenient shortcuts

The core language adds ascii character notations optimized for brevity.

The library instead makes things that should require 1 argument take 2 or 3 arguments (which ranges will hopefully fix), makes value to string conversions as verbose as possible, etc...

The core language is much harder to work with than the library, thus the difference.

The library can be posted as code and thus we can test it thoroughly, and discuss it based on a real implementation.

Contrast that to the language. It isn't code, it is standardize. It is written by and for lawyers in the negative sense of the word lawyers. Anything you do in the core language is hard because there are too many ways to accidentally (or intentionally) slip something evil past everybody.

C++ takes backward compatibility seriously. If I didn't have a 20 year old code base of working code to deal with I'd be working in Rust, D, Go, Java, C#, or whatever the language of the day is. (Note that because of the amount of users and time C++ often has better optimization, but if that fraction of a percent better matters you can invest in optimizer work for your chosen language and solve the problem)

That's pretty idiomatic in Python and often is fine. But surely can be abused. Pathlib let's you use / to append paths. You're not dividing anything but it's still quite intuitive.

And python sets let you subtract to get a difference, similar to your clever trick. I think it helps when these things are core to the language and broadly known. Otherwise you're scratching your head at what - will do.