3 ms·

One of the silly things about member functions is the effect that they have on argument ordering when ordering is not supposed to matter. For example, consider

One of the silly things about member functions is the effect that they have on argument ordering when ordering is not supposed to matter. For example, consider "operator +", which can have in-object or function implementations. The ridiculous thing is that, for any two types in an expression like "+", you can't tell from observation if it will compile! Is it only available as a member function? If so, then any primitive left-hand argument in this supposed-to-be-commutative expression must be swapped to the right side, or wrapped in a pointless object. The same problem can exist for non-operator functions. At least now with "auto" and other implicit typing (and even tuples and std::get<needed_type>), there is a chance to write single functions that work around messes such as these.

kibwen 11y ago
> One of the silly things about member functions is the > effect that they have on argument ordering when ordering > is not supposed to matter. This isn't a problem with member functions, free functions have this problem as well. And not just in C++, commutativity just isn't a first-class concept in any programming language that I've ever seen.
- makecheck 11y ago
  My main point is that there is no way for something like "2 + object" to do the right thing when member-function syntax is expected, whereas there is at least a way for a free function to do so; and the language could have avoided this problem. I believe this is also the entire reason that recent C++ standards introduced free-function forms of things like begin(thing)/end(thing)/etc. because it was just too hard for something like a template to operate on a value when it couldn't tell whether or not object syntax would work.