[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.