[kibwen]

Overloadable operators are not an instance of hidden control flow. Overloadable operators represent a user-defined function call, and thus can't influence control flow any more than a regular function. And if regular functions can't do anything weird to control flow (e.g. if your language already lacks exceptions (or even weirder things like Ruby-style procs)), then overloadable operators can't either.

> It locks you into a single implementation when you may want to do something different based on the context.

If you want differing behavior in a certain context, and if you don't want to use a different method to make the differing behavior explicit (e.g. the `wrapping_add` methods that Rust provides on numeric types), then you can use a different type for that context, e.g. the `std::num::Wrapping` type that Rust provides.

[smj-edison]

> Overloadable operators are not an instance of hidden control flow.

In general perhaps not, but in Zig it definitely does. Zig considers calling a function to change control flow, because it's no longer just an operator but something that can cause side effects, includinh mutating in place. Perhaps control flow isn't the right term, maybe non-trivial would be better?

With regard to wrappers, I personally find them ugly since 1. They bring in indirection, and I have a personal vendetta against unnecessary indirection, 2. Wrapping doesn't compose well and is a pain to shephard between representations, 3. It's harder to make a function generic across different representations, and 4. Wrappers often don't re-export everything available to their underlying value.

[kibwen]

> Perhaps control flow isn't the right term, maybe non-trivial would be better?

Indeed, there are plenty of valid reasons to be wary of operator overloading, such as the risk that someone might insert a network call into your vector addition. There's some precedence from C++ in calling an operator invocation "trivial" when it hasn't been user-defined, in general I might go further and say that a good overloaded operator is "well-behaved" when it not only has a non-surprising implementation (e.g. no side-effects) but also its function is congruent with the specific chosen operator (so no overloading bitshift for iostreams).

[charlieflowers]

I’m not advocating this, but it is worth observing that it is yet another problem one could attempt to address with dependency injection, similar to io and allocators.