As he mentions in that paper, this isn't likely to be a common issue, so I'm with the general consensus that it seems unfortunate that the feature wasn't adopted.
According to the classic C++ article, "What's in a class?" by Herb Sutter (http://www.gotw.ca/publications/mill02.htm) -
The Interface Principle suggests -
For a class X, all functions, including free functions, that both (a) "mention" X, and (b) are "supplied with" X are logically part of X, because they form part of the interface of X.
So yes, f(x) is part of x's interface in C++, and has been considered to be so for a long time.
A little awkward to read in response to my comment.
An educated disagreement to what? I guess you are disagreeing with their argument? I agree with your comment.
Or maybe it's a disagreement with what I think their argument is? This is why I am asking. :)
I think the concern is that a class "owns" its methods either directly or through inheritance. Therefor, the interface is expressed by this namespace and it can't be "invaded" or modified. From that perspective, having f(x,y) being callable as x.f(y) would be a violation of your interface.
But... the dot syntax does not make an interface, and neither does it make "object oriented programming". It implies that "f" is a specialized function for somehow applying "y" to "x".
If you have a generic "f" that can be compiled to a specialized "f" for your type... you are just adding composability to your language. That's a good thing! Calling "f" as x.f(y) in this case makes a lot of sense. It's just another specialized function for applying "y" to "x".