A sixth alternative UFCS approach

[eyalroz]

I was just reading the UFCS design notes.

I noticed that one approach to UFCS, which is the one I (think I) like best, seems to be missing. It's another way to "slice the Gordian knot": Instead of choosing one kind of function and disallowing the other, Make member functions and nonmember functions be one and the same thing. That is, if you have class ns::A and you define (a non-virtual) ns::f(A&, B), it's as though you've defined ns::A::f(B) & - and vice-versa, if you've defined the former, you've defined the latter.

(This also opens up the possibility of virtual non-member functions and maybe also multiple dispatch, which would completely remove the distinction between member functions and independent ones.)

Has this been discussed in any of the times UFCS has been brought up? Or - was this considered too far from what C++ is?

[hsutter]

Thanks! I've thought of unifying all functions, but in this case going that far wouldn't meet the benefit:cost bar.

I would ask: What problem is that additional unification solving? (i.e., what important use cases aren't enabled by the UFCS as currently implemented, or what % of existing bugs/guidance literature would be eliminated by this change)

Note that virtual functions not only are members, but they also have access (privates) and layout (vtable) implications. Adding another virtual function requires adding a vtable slot and recompiling the world (or at least as much of the world as can transitively be sensitive to the layout of that class). As long as virtual functions are limited to declaration inside a class, they are under the control of the class author.

Just some thoughts.

[eyalroz]

wouldn't meet the benefit:cost bar.

Yes, probably, but it rounds out the discussion and the space of options with one that I believe is important to think about. Which is why I'm suggesting adding it to the wiki page, not (necessarily) to cpp2.

What problem is that additional unification solving? (i.e., what important use cases

The problem is not in a specific use case. Or rather, it's the same use case as UFCS in general, but with an approach that is more decisive - like your existing "cutting the Gordian knot" approach. But it improves on that one: It has the benefits of avoiding ambiguity and avoiding implementation contrivances, but without the detriment of preventing one of two extremely common idioms in the language.

If taken to the extreme, to also cover vtables, it offers an interesting change in the innards of the language and the ABI: vtables constructed at link time from the contributions of functions in different compiled objects, and maybe even multiple dispatch. Again - interesting to discuss/mention, not necessarily to adopt. About the issue of protected/private member access - that can be taken care of just as it is today: Functions defined using the method syntax are friend'ed, functions which are defined outside the class are not automatically friended and only an in-class friend'ing can grant them access - maintaining class author control.