C++: calling non-member functions with the same syntax of member ones

Question

One thing I'd like to do in C++ is to call non-member functions with the same syntax you call member functions:

class A { };
void f( A & this ) { /* ... */ }
// ...
A a;
a.f(); // this is the same as f(a);

Of course this could only work as long as

• f is not virtual (since it cannot appear in A's virtual table.

• f doesn't need to access A's non-public members.

• f doesn't conflict with a function declared in A (A::f).

I'd like such a syntax because in my opinion it would be quite comfortable and would push good habits:

1. calling str.strip() on a std::string (where strip is a function defined by the user) would sound a lot better than calling strip( str );.

2. most of the times (always?) classes provide some member functions which don't require to be member (ie: are not virtual and don't use non-public members). This breaks encapsulation, but is the most practical thing to do (due to point 1).

My question here is: what do you think of such feature? Do you think it would be something nice, or something that would introduce more issues than the ones it aims to solve? Could it make sense to propose such a feature to the next standard (the one after C++0x)?

---

Of course this is just a brief description of this idea; it is not complete; we'd probably need to explicitly mark a function with a special keyword to let it work like this and many other stuff.

Answer 1

re your #2: Actually, making functions non-members often increases encapsulation, as Scott Meyers observed more than a decade ago.

Anyway, what you describe sounds much like C#'s extension methods to me. They are good to soothe the minds of those that are frightened when they see totally free functions. :) Once you've braved the STL (which, BTW, is not the standard library, but only that part of it which comes from the original STL) where almost all functions are so free that they aren't even real functions, but function templates, you will no longer need those.

In short: Don't try to bend a language to adapt to your mindset. Instead enhance your mindset to embrace the language's philosophy. You will emerge a bit taller from doing so.

Answer 2

Trying to answer your points:

1. This is just a matter of style. To you it sounds better, to someone else it sounds worse. Some languages (of Lisp heritage) define all calls as (<func name> <arguments>), is it inherently better or worse than <func name>(<arguments>)? Maybe and maybe not. Matter of style. I'm sure no one is going to consider changing the C++ standard on such considerations.
2. This is what static members are for in C++ - are you familiar with this construct? Besides, as the C++ standard library (the STL portions thereof) demonstrates, it's possible to combine objects with non-member functions that act on them in an elegant way.

Answer 3

I believe that as part of Concepts (which were dropped from C++0x), there was something like this, but going in the opposite direction, so that nonmember syntax could be used to call member functions. In other words, given a std::vector<int> vec, this

begin(vec)

would be equivalent to calling the member function explicitly:

vec.begin();

I think that is a better approach, in that it is biased so that it prefers nonmember functions, which are the most "public" part of the interface. To some extent, member functions are an implementation detail which is likely to change more often than the typically higher-level nonmember functions that use the class.

So something like this would allow us to use the general non-member syntax for everything, and while it would implicitly fall back to calling a member function if no matching non-member function is found, it would always prefer the most public, the most encapsulated function available, which is the non-member one.

Of course, both ways can silently break code, but allowing nonmember syntax for calling member functions will at least maintain encapsulation: by adding a new function, I can convert a member function call, which has access to the private members of the class, into a non-member which does not have access to private members.

But if it was done the other way around, allowing member syntax for calling non-member functions, then I could, by adding a new function to the class, silently convert an unknown number of non-member function calls into member function calls. In other words, a lot of code which previously called a function that had no access to private members, are silently changed into calls to a function that does access private members. I think that's the more dangerous way to go.

Answer 4

If you want to add methods to a class, just inherit from that call and add the members to your derived class.

If you're asking how I like your syntax, I don't. Why make it look like a method is part of a class when it isn't. Especially when it's pretty straight forward to make it part of a class.

Answer 5

I think it's an excellent idea because of ADL and the operator overloading mess- make operators pseudo-members, ditch ADL. Extension methods like this wouldn't change encapsulation because they're still an exterior function, they just have the syntax of an interior function.

There are some functions that do well to be free, and some functions that do well to be members- even if they're free from an encapsulation point of view.

Answer 6

To me it is a value to clearly be able to see whether I am making a call to a member or nonmember function.

But even if I preferred your style, what if after writing such a call a.f(...) into my code, a function f() with a compatible signature is introduced into class A? Should my code silently break upon the next recompile, calling into a totally different function than I originally intended? Should the design committee attempt to extend the (already very complex) name lookup rules to accommodate such special cases?... And what if I will have already left the company in the meantime, and it is up to my poor successor to try and decide what my original intent could be?