> The code isn't readable (you can't even reliably tell at a glance what the operator does) and it takes negligibly longer to write "add()" rather than "+" in your program (yes, 'add()' is more keystrokes and thus takes longer to type, but most of your program isn't addition instructions).
Except now you replaced + with a name that tells you just as much/little as + does. So you made your program verbose for the sake of verbosity.
Re:C++23: The Next C++ Standard
by throwaway894345 on Wednesday July 12, 2023 @08:06AM
(#36693335)
No, you’ve made your program “verbose” (by a handful of characters) for the sake of clarity—there is no longer ambiguity about what code runs (of course, this assumes you aren’t similarly overloading named functions, which should also be disallowed).
Given that your example uses neither namespacing nor explicit typing you seem to preach do as I say, not as I do.
Re:C++23: The Next C++ Standard
by throwaway894345 on Wednesday July 12, 2023 @01:27PM
(#36698260)
I don't know what example you're talking about. I haven't given an example in this thread. I think you may have me confused with another commenter.
so that throwaway suggesting that add is barely longer than + wasn't you?
Re:C++23: The Next C++ Standard
by throwaway894345 on Thursday July 13, 2023 @06:24AM
(#36707076)
That was me, but I didn’t provide example code that would require namespaces. I don’t understand his your earlier comment makes sense in the context of this thread.
I think what people should advocate is full DSL capabilities with some unambiguous gate syntax so people know precisely that `foo * bar` is not using the host language syntax. Overloading operators is ambiguous and vastly incomplete (everyone is holding up matrix math as the shining example for the utility of operator overloading and you can't even express dot product notation in C++!)--it's a hack at best.