[lmm]

Nah. The problem is that , doesn't look like a function, isn't treated as a function by most of your tooling, and so it's very surprising if it behaves like one (plus it's not at all clear what you'd expect a function called , to do in most cases). Polymorphic functions are fine when they have sensible names and are understood as functions by the reader and tooling (of course it helps if your language is actually parseable by those tools, which C++ isn't).

[robalni]

I don't think the main problem in this article is that "," doesn't look like a function because we are told that it is overloaded so we know it's a function.

The problem is that the behavior of the code silently changes when a function is moved and this is because of the overloading feature in C++. You can get those types of problems in other cases too when you overload functions that have a good name, but maybe it's less likely since I guess the comma operator is already defined for all different types but named functions have to be defined by the programmer.

[lmm]

> I don't think the main problem in this article is that "," doesn't look like a function because we are told that it is overloaded so we know it's a function.

Well it's a function in one of the code snippets and not in the other. That it can be both is definitely part of the problem.

> You can get those types of problems in other cases too when you overload functions that have a good name, but maybe it's less likely since I guess the comma operator is already defined for all different types but named functions have to be defined by the programmer.

The problem is that it's not just overloaded but overridden. Subtyping is problematic at the best of times, but the subtyping relationship of C++ lvalues and rvalues is particularly insidious since it is completely invisible in the code.