[scoutt]

The difference is that you know (or can know, or predict) the outcome. In C++ a=b+c could be a simple addition or an operation that takes an hour, allocates 1GB of RAM, opens a socket and requests a JSON document from a server in China. You can't know wihtout looking at the code.

[mh7]

You don't know what the function called "add" does either.

There's no reason for the name "+" to be anymore special than "add" - especially in any language supporting unicode identifiers which allows even more crazy names.

[scoutt]

But with "add" I'm explicitly calling a function.

> There's no reason for the name "+" to be anymore special than "add"

This is debatable. I want "+" to do just an addition.

Also a function "add", depending on the context, can mean different things.

[stkdump]

See, framing it as a personal preference makes much more sense. Of course disallowing nontrivial work in operators will also mean you can't concatenate strings in them, so you will have few languages to choose from.

[scoutt]

Sorry. I don't know if you are saying that you won't be able to concatenate strings without operators, or if you choose a language just because it allows you to use a "a = b + c" form with strings.

For the first case, of course you can create something like:

    str1.append(str2);

For the second... I don't know what to say.

> framing it as a personal preference

But follow my logic for a moment: if "str3 = str1 + str2" concatenates a string, what "str3 = str1 - str2" should do?

(Yes I know there is no minus operator for std::string)

And "str3 = str1 * str2"?

And "str3 = str1 % str2"?

[stkdump]

I never said, that it is impossible to work without operator overloading (actually the opposite). Just that it is a very common feature in most programming languages, and I don't understand why an experienced developer would be confused by it. Even in maths expressions (where the operators come from), you have this behavior. If you multiply two matrices, it does something completely different. The result could be huge and thus in computing world require huge memory allocation. Also you can multiply matrices, but you can't divide them. The primary school level math you seem to be limiting the world to is not practical.

[stkdump]

You can predict the outcome very well. It is a call to an operator, which can be trivial for simple types. But of course if you concatenate two 500MB strings using +, you will have a 1GB allocation. I don't see how that is a problem or even a surprise. Of course you could do something in that operator that nobody would expect to happen inside it. But the same is true if you give a function a bad name. For all intents and purposes, an operator is just a function with a particularly short name and (default) style of how it is called.

[scoutt]

> You can predict the outcome very well

Not always. BTW, I don't know if you noticed it, but I was exagerating to make a point.

> Of course you could do something in that operator that nobody would expect to happen inside it

To me, this is the problem. For example, I do embedded. I have to know with a certain precision what is going on in my program.

It's a very different thing to call a bad-named or badly-done function. It's an unlucky case... I guess?...

But if I use an operator, there might be hidden code there I have to see.

Yes, I know you can use "=" to copy a struct. But also "a = b + c" might be doing something slow, like re-allocating internal pointers and making copies, allocating new objects, etc. I have to read the code to see what it will do. Believe me, I have done it with inherited embedded C++ projects.

[stkdump]

I don't do embedded (anymore), so please consider that your use-case and concern is very specific.

But even in C++ you can't redefine what + means for types, where it already has a builtin meaning. The only thing you can do is define what it does for custom types. That means when you see the + operator applied to some class or struct type, you should already be aware that this is nothing built-in and equivalent to a function call. If you are not, you are just not fluent in your tooling. That is completely different problem. It is something learnable, not a fundamental problem of the tooling.