C++ provides two calling syntaxes, x.f(y) and f(x,y). This has bothered me for a long time. I discussed the problem in the context of multimethods in D&E in 1994, referring back to a proposal by Doug Lea from 1991, and again in 2007. Each of the syntaxes has its virtues, but they force design decisions on people, especially library designers. When you write a library, which syntax do you use for operations on objects passed to you by your users? The STL insists on the traditional functional syntax, f(x,y), whereas many OO libraries insist on the dot notation, x.f(y). In turn, libraries force these decisions on their users.



Interestingly, I solved the problems for operators: x+y doesn’t care whether you provide operator+(T,T) or T::operator+(T). The problem is getting more noticeable as we get more generic libraries. Note begin(c) and c.begin() for range-for loops and in general code. Why do we/someone have to write both? If c.begin() exists, begin(c) should find it, just as x+y finds the right implementation. Such call-syntax adapters are pure overhead and different people’s adapters can clash.



In early 2014, Herb Sutter and I each independently decided to propose a unified syntax. Herb suggested unification based on allowing x.f(y) to find a non-member function, giving preference to the x.f(y) syntax, whereas my ideal was that x.f(y) and f(x,y) should mean exactly the same. After a quick discussion, we joined forces. Based on real input from code and users, I reluctantly agreed that for compatibility reasons, x.f(y) and f(x,y) could not mean exactly the same. The only feasible way forward was to do a traditional lookup based on the syntax used, and then try the other syntax if the first one failed. Stability – backwards compatibility – is an important feature, overruling my desire for perfection.



To my surprise, many people came out strongly against x.f(y) finding f(x,y) – even if member functions were preferred over free-standing functions by the lookup rules. I received email accusing me of “selling out to the OO crowd” and people whose experience and opinion I respect insisted that x.f(y) finding f(x,y) would seriously compromise their ability to design stable interfaces. I think those fears are greatly exaggerated, but I could be wrong. Also, I prefer the dot syntax in some cases; for example, I find x.f(y).g(z) more readable than g(f(x,y),z). However, there was no chance of acceptance of a proposal that included x.f(y) finding f(x,y). Maybe modules will eventually help here. Furthermore, David Vandevoorde pointed out that because of the two-phase lookup rules having x.f(y) find f(x,y) would complicate the task for compiler writers and possibly be expensive in compile time.



So, we are left with a simple proposal to allow f(x,y) to find x.f(y) where f(x,y) wouldn’t work today. This solves the problem for library writers and their users along the lines of the STL:

Library designers don’t have to force users to use one preferred syntax or to duplicate the implementation to handle both.

It allows us to write simple concepts for new libraries.

We no longer have to write call-syntax adapters.

We can in many cases add functionality to an abstraction without modifying a class

We no longer have to bother the users with the distinction between member functions and helper functions.

The proposal was approved by the Evolution Working Group. Faisal Vali did an experimental implementation in Clang. Now we just have to hope that we can agree on exact wording in time for C++17. I consider it a small proposal that will significantly simplify the way we design and use libraries.