C++ UFCS update

[Jonathan M Davis via Digitalmars-d]

On Friday, 19 February 2016 at 16:18:12 UTC, Dejan Lekic wrote:
> I *completely* agree with this. UFCS is OK in some places but 
> not everywhere like people do lately. What you said about 
> abusing the dot- notation is on the spot. It is not uncommon 
> nowadays to see D code that I have absolutely no idea what it 
> does, because of UFCS. I have to go through each piece 
> separated by dots to understand what it is...

Well, you could actually argue the exact same thing about 
function overloading and overriding, which is part of why Linus 
Torvalds prefers C to C++ - ostensibly, you can look at a chunk 
of C code and know exactly what it's doing without a lot of 
context, which is often not at all true in languages which have 
overloading and the like (especially when operator overloading 
gets added into the mix). Now, how big a deal that is is 
debatable, but it's something that some folks have complained 
about, whereas many folks would never want to have to deal with 
not having function overloading. With regards to UFCS, some folks 
think that it makes code way cleaner and easier to figure out 
what's going on, whereas others think that it's worse.

Personally, I'm enough used to dealing with functional languages, 
that not having UFCS doesn't bother me that much, though it's 
easier to have clean, long UFCS chains than it is to have clean, 
long normal function call chains, because the number of parens 
tend to drown things out.

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. 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.

- Jonathan M Davis