C++ UFCS update

[Jonathan M Davis via Digitalmars-d]

On Sunday, 21 February 2016 at 00:52:13 UTC, bitwise wrote:
> On Saturday, 13 February 2016 at 10:27:59 UTC, Daniel N wrote:
>> "Abstract
>> This is the proposed wording for a unified call syntax based 
>> on the idea that f(x,y) can invoke a member function, x.f(y), 
>> if there are no f(x,y). The inverse transformation, from 
>> x.f(y) to f(x,y) is not proposed."
>>
>> They were considering 6 alternatives and chose the worst...
>> https://isocpp.org/files/papers/P0251R0.pdf
>
> Am I crazy, or is this paper proposing the exact opposite of 
> what would be needed to do chaning of ranges or extension 
> methods?
>
> I don't get how it would be useful at all to type f(x, y) and 
> have the compiler call x.f(y) for me. Why would I ever not want 
> to just use member invocation syntax?

Because UFCS is not about chaining function calls. It's about 
being able to call a function without worrying about whether it's 
a free function or a member function. Without some form of UFCS, 
it really doesn't work well for generic code to be able to call a 
function when some types define the function and others work with 
a free function with the same name, because the syntax to call 
them is different, meaning that the same code won't work with 
both types. Regardless of whether UFCS is foo(x, y) or x.foo(y), 
it allows for a _universal_ way to call a function (hence the 
name Universal Function Call Syntax). That's the whole point.

Much as many folks love how D's version of UFCS makes it really 
easy to chain function calls, it's really not the main goal of 
UFCS. It's just a nice side effect of how we've done it. C++ will 
still get all of the benefits for generic code the way that 
they're doing it. So, they'll get the intended benefit of UFCS. 
They just won't get the side benefits that many folks like about 
the syntax that D chose.

- Jonathan M Davis