Potential design flaw with unified function calls?

[ramytarchichy]

I really liked the fprintf demo in the cppcon talk, but either I'm missing something (more likely) or it simply cannot work (sad).
In cpp1+cpp2 mode, let's assume we have this code:

struct S
{
    int a;
};

get: (s: S) -> int = s.a;

Now we can call both:

a := get(s)
b := s.get()

So far so good. But let's say that S is actually defined in some library's header file, and the author decides it would be a good idea to add a member callable, be it a member function, lambda, std::function, function pointer, or whatever, that is also called get.

In cpp1, that would be totally fine. In cpp2 however, it seems to me that it would break everything. Even if you add a rule saying that a member callable takes precedence over the one we defined in the first bit of code, that would still mean that b's assignment now calls a different function, without us changing any of our code, only because of a library update that would be a-OK in cpp1. Backwards-compatibility broken, silently, and unexpected behavior that will be very fun to debug, I'm sure.

But it gets worse: if we define get as a template instead:

get<T>: (t: T) -> int = ...;

part of the design goals as far as I understand is making cpp2 more toolable. But without concepts or something, Intellisense would probably show this as a member function of every single variable in your code.

Oh, and what about more basic stuff, like factorial? Cause this syntax looks kinda weird imo:

fact: (n: int) -> int = n ? (n * fact(n - 1)) : 1;

main: () -> int = {
    std::cout << 5.fact();  //do I really want Intellisense to recommend every function that takes an integer whenever I type an integer?
}

I don't know, maybe I'm missing something, but it seems like something to think about for sure.

[switch-blade-stuff]

My suggestion to solve these kind of issues would be to explicitly state that the function can be used as a member, for example like this:

struct S
{
    int a;
};

get: (s: S) -> int = s.a;
mem_get: (s: this S) -> int = s.a;

Where the get function is a pure static function, and cannot be used as a member, while mem_get can both be used as a static function and a member function. This way, if the user would want to create a template function for every possible type, they would do something like this get<T>: (t: this T), and get<T>: (t: T) would be treated as static-only function.

[hsutter]

Thanks for pointing out out. Maybe I should start writing up some "design notes" wiki pages; this would be one. For now let me try to summarize some of the thinking here, with the usual caveat of "it's an experiment! we'll learn" which applies to all of Cpp2.

Yes, these issues were raised and discussed in WG 21 when we looked at UFCS proposals.

Note this isn't new, we have some relevant experience already: Anytime you use fallback semantics for name lookup, such as preferring one scope over another, this leads to name hiding. This happens today when a derived name hides a base name, or a name in a nested class or namespace hides one in an outer namespace... so name hiding is not necessarily inherently scary, and in those cases I think the experience is that it's been working fine because of the principle that the more-specialized thing should be in control of its interface and therefore have the priority in saying what the name means for its type.

For UFCS, name hiding will happen if UFCS prefers one scope over another (e.g., if it prefers a member if available). This can be a feature rather than a bug, but I agree there are potential dangers in silent changes in behavior. But again, the same thing can already happen if a derived class adds a name (not just a function), or a nested namespace/class adds a name. I think the priority principle still applies -- the more-specialized thing should be in control of its interface, and for UFCS that is the type author of this object.

Here are five major alternative semantics we could choose for UFCS, in rough order of likelihood of unwanted silent changes in behavior:

A) Prefer nonmember function. Adding a new nonmember function could hide a member function, even one that is a better match, and silently change behavior. Probably really bad, because now we're changing what the type's own interface means in different contexts. The type author should have control over what their type means. This is the version that got the most resistance in WG 21 (and I now think rightly so).

B) Prefer member function. Adding a new member function could hide a nonmember function, even one that is a better match, and silently change behavior. This is much less bad than A, and preserves the principle that the type author should have control over what their type means. (In this alternative, the implementation could warn when a nonmember is a better match, but I suspect that would be noisy and people would want to turn it off.)

C) Overload and select the best match. Adding a new member or nonmember function could still silently change behavior (so this does not eliminate potential accidental surprises), but if it does it's because you're getting a better match which is at least something.

D) Declare the call ambiguous if either set is nonempty, and require explicit disambiguation (e.g., scope resolution). This seems to at least partly defeat the purpose of UFCS in many use cases though.

E) Slice the Gordian knot: Don't allow both nonmember and member functions in the language, pick one kind and force everything to be that. This can work but I feel it would go way beyond the charter of Cpp2 to be a cleaner C++, and limit to only changes that solve known problems in quantifiable ways while still being C++. It seems like it would be a fundamental underlying change to C++'s model and a foreign concept, so IMO it's on the table for Cpp2 but has to clear a high bar for being compellingly the right way to go because every change like this adds to risk of incompatibility.

Right now, I think B and C are likely the best choices, and for now I'm going with B to keep the type's author in control of their type's interface. But it's an experiment! We'll learn.

My suggestion to solve these kind of issues would be to explicitly state that the function can be used as a member

That sounds a bit like C# extension methods? I worry that means abandoning UFCS for any existing code. Also, I worry it means that when we write the function we have to know and specify in advance what functions can be used as members, when it should be enough to know that the function operates on the given types.

Thanks for the note!

[hsutter]

Added Design note: UFCS