On 2/21/2016 2:16 AM, Jonathan M Davis wrote:
As for a pipe operator, I expect that it wouldn't really help any. It would be a
lot like . vs -> in that it's an unnecessary complication, but it would actually
probably be worse. If | meant that a function call could be either a member
function or a free function, you'd still have no more clue about which functions
were member functions than you do now, and there would be plenty of incentive to
just not bother using . in order to be consistent. Certainly, . would become
unnecessary.
I'm not thrilled about overloading | with a non-arithmetic purpose. I hated
iostreams' use of << from the beginning.
It's the fact that there is a way to call a function without caring
whether it's a member function or a free function which causes the confusion.
The syntax itself doesn't really matter. But ultimately, regardless of the
syntax, it's a big win, because it allows us to do stuff like have find be a
free function and then have a range which can implement find more efficiently
overload it as a member function, and the calling code doesn't need to care. So,
UFCS is almost always worth the confusion about whether you're calling a member
function or not, and the confusion is just inherent to UFCS regardless of the
syntax. So, I really don't see how another syntax would help any.
Big reasons for allowing f(x) and x.f() equivalence are:
1. Head off the temptation to fill up a class declaration with every conceivable
member function:
http://www.drdobbs.com/cpp/how-non-member-functions-improve-encapsu/184401197
2. Allow users to 'extend' a class without having to modify the original.
3. And, of course, to chain calls together.
