The confusion created by operator overloading is easily solved by tooling. The compiler always knows what a given operator resolves to, and environments like Visual Studio Code with the right plugins can handily highlight what you are actually calling.

Also I think that like everything in C++ it's a matter of not abusing a given feature. It's still useful to have the ability to overload operators because it makes the intent behind certain operations much clearer. There's nothing worse than not being able to address an ArrayList in Java with the subscript operator.

Nowadays I don't use operator overloading in C++ a lot, it's mostly `=`, `==`, `<=>`, `bool`, `*`, `->`.

I fail to understand how that’s more explicit to be perfectly honest. If it’s hard to resolve where overloads are coming from then that’s a problem but otherwise it just seems more verbose for no benefit. Addition and multiplication are the operations in use here, why shouldn’t we use their operators to represent them?

In situations where the output's shape changes based on the operation this can be helpful.

    auto accumulate = ...;
    auto a = ...
    auto b = ...
    auto result = a*b;
    for (int row = 0; row < a.rows) {
        accumulate += result[row]
    }

This expression might be entirely valid when a and b are both 2x2 but then becomes incorrect when there's a different shape in b.

Do you mean type instead of shape? I also don't know what you mean by incorrect. C will also create casts when using two different number types in a math operation.

For matrix and quaternions multiplication does not output the same type as the input.

For example:

    int a = 1;
    
    a + a = 2; (int)
    a * 2 = 2; (int)


    auto ma = matrix<2, 4>();
    auto mb = matrix<4, 1>();
 
    ma * a  is matrix<2, 4>
    ma * ma is not possible
    ma * mb is matrix<2, 1>

Compilers used to be very bad at telling you what was going on here if you, for example, changed `<2, 4>` to `<3, 4>` or something. g++ now handles it pretty well: https://hastebin.com/idemopikag

Your original comment was about something being incorrect, now you are talking about error messages, but I don't think either has to do with operator overloading.

There is more than one definition of a matrix or vector product and whichever one is most obvious can be contextual.

I like operator overloading, but it is susceptible to argument dependent lookup while member methods are not. The syntax is literally more explicit about what logic is being called.

You'll find a lot of SIMD code using the multiple calls approach as for far too long C++ compilers did daft things like transfer the SIMD registers back to the stack or refuse to inline when the expression got slightly interesting.

That's still better than matrix_add(c, matrix_mul(b, a)) though - you can't do A.mul(B).add(C) in C