C++ UFCS update

[Walter Bright via Digitalmars-d]

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.