"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

On Saturday, 13 February 2016 at 10:27:59 UTC, Daniel N wrote:
> They were considering 6 alternatives and chose the worst...
> https://isocpp.org/files/papers/P0251R0.pdf

I'm not so sure this is the worst, given the C++ history. Think about this for a minute: "f(x,y) can invoke a member function, x.f(y), if there are no f(x,y)"

That means you can override member functions with local non-member functions, that it will encourage programmers to write `f(x, y)` and thus be more compatible with older compilers via freestanding shims, and just plain be more convincing for them to actually use non-friend, non-member functions which is the key encapsulation goal of UFCS.

It might not be an ideal decision, but I do think it is an OK one for C++.

On 2/13/2016 2:27 AM, 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

Wasn't it us who chose the term UFCS?

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

It makes a lot of sense in C++ actually. It allow to unify begin/end for instance.

On Monday, 15 February 2016 at 06:12:30 UTC, Walter Bright wrote:
> On 2/13/2016 2:27 AM, 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
>
> Wasn't it us who chose the term UFCS?

These aren't the acronyms you are looking for.

Personally, I find this proposal for C++ to be laughable. It's like hitch hiking from New York to California, and only getting as far as Texas and calling it good.

The great thing about our UFCS is the left-to-right chaining of algorithms.

x.map!(...).filter!(...).reduce!(...)

It beats the Hell out of...

reduce!(...)(filter!(...)(map!(...)(x)))

This proposal will encourage non member functions, which is good, but will never reach the "aha" moment D had which gave us UFCS chaining.

On Tuesday, 16 February 2016 at 07:59:49 UTC, w0rp wrote:
> Personally, I find this proposal for C++ to be laughable. It's like hitch hiking from New York to California, and only getting as far as Texas and calling it good.
>
> The great thing about our UFCS is the left-to-right chaining of algorithms.
>
> x.map!(...).filter!(...).reduce!(...)
>
> It beats the Hell out of...
>
> reduce!(...)(filter!(...)(map!(...)(x)))
>
> This proposal will encourage non member functions, which is good, but will never reach the "aha" moment D had which gave us UFCS chaining.

Ugh, that syntax is abusing the implied semantics of dot-notation; member-access. Better to have a pipeline operator.

Such syntax abuse is common in other languages too, so I don't get the "aha". It is more a case of "ugh, repeated mistake"...

Explicit extension methods is a much better alternative.

On 02/14/2016 10:12 PM, Walter Bright wrote:

> Wasn't it us who chose the term UFCS?

Can't be. Other languages take features from C++ but never admit it. ;)

Ali

On Tuesday, 16 February 2016 at 08:24:50 UTC, Ali Çehreli wrote:
> On 02/14/2016 10:12 PM, Walter Bright wrote:
>
>> Wasn't it us who chose the term UFCS?
>
> Can't be. Other languages take features from C++ but never admit it. ;)

I think it would be a good idea to drop this microscopic search for novelty. It is borderline pathetic...

I don't think Stroustrup has said that C++ has introduced novel features. What C++ has done is to integrate many known features with few restrictions on how to use them. D has done much of the same, but with more restrictions.

Other languages have provided various OO syntaxes and extension methods etc since the 70s or 80s, and it has probably been discussed for C++ before it was implemented in D.

UFCS/UCS is more a sign of starting with a non-OO language and adding OO-methods at a later stage. Pure OO languages implement the global scope as an object and "free functions" are just members of an outer scope.

On Tuesday, 16 February 2016 at 07:59:49 UTC, w0rp wrote:
> Personally, I find this proposal for C++ to be laughable. It's like hitch hiking from New York to California, and only getting as far as Texas and calling it good.
>
> The great thing about our UFCS is the left-to-right chaining of algorithms.
>
> x.map!(...).filter!(...).reduce!(...)
>
> It beats the Hell out of...
>
> reduce!(...)(filter!(...)(map!(...)(x)))
>
> This proposal will encourage non member functions, which is good, but will never reach the "aha" moment D had which gave us UFCS chaining.

I agree completely. Form my point of view, UFCS is D's biggest advantage over C++ (beating CTFE and saner templates). It was the thing that I hoped for the most in C++17. Alas, we'll be forced to write onion code. This sucks.

By the way, your example in C++ would be even worse:

auto sum_of_filtered = x
    .map([&](auto&& val){ foo(val); })
    .filter([](auto&& val){ return is_bar(val); })
    .reduce(std::plus<>{});

vs

auto sum_of_filtered =
reduce(filter(map(x, [&](auto&& val){ foo(val); }) ,[](auto&& val){ return is_bar(val); }), std::plus<>{});

Try adding an additional pass there. Where do you put the comma and second/third argument?

I have no idea how to indent that properly and creating a myriad of named temporary variables for no valid reason makes me hurt inside.