SFINAE on functions with default parameters - free function vs operator()

Question

I was playing around with this answer to investigate how it handles functions with default parameters. To my surprise, the results are different for free functions and operator():

template <typename F>
auto func(F f) -> decltype(f(42))
{
    int a = 51;
    return f(51);
}

template <typename F>
auto func(F f) -> decltype(f(42, 42))
{
    int a = 0;
    int b = 10;
    return f(a, b);
}

int defaultFree(int a, int b = 0)
{
    return a;
}

auto defaultLambda = [](int a, int b = 0)
{
    return a;
};

int foo()
{
    return func(defaultFree);  
    //return func(defaultLambda);
}

Godbolt link

The func(defaultFree) version above compiles while both func templates are available. As expected, it picks the second one because default parameters are not considered part of the function signature. Indeed, removing the second func template causes a compilation error.

However, func(defaultLambda) does not compile due to ambiguity: Both func templates match. Removing either one makes this version compile.

(The same happens if you manually write a struct with a similar operator(), of course. Latest gcc, clang and MSVC all agree on it, too.)

What is the reason that the default parameter is considered inside the unevaluated SFINAE context for operator() but not for the free function?

Elasticize

Answer 1

When you pass the free function as an argument, it undergoes the function-to-pointer conversion. When that happens, the default argument (which is not a part of the function's type) is gone. It's now a pointer to a function taking two parameters, and as such only one SFINAE check can pass for it.

The lambda's type doesn't undergo such an adjustment. The unevaluated expression must involve overload resolution for operator(), and that finds the declaration with the default argument, which allows it be used in a call with a single argument.

When the capturesless lambda is forced to undergo a conversion to a function pointer (for instance func(+defaultLambda);, courtesy of @YSC), the ambiguity is gone, for the same reason.

Kitchenware

+1. I'd always assumed that (for example) void f(int a = 0) { ... } was essentially the same as void f(int a) { ... } plus void f() { f(0); }, but whoa, apparently not! – Gregoriogregorius

Answer 2

A function name is not the name of a C++ object.

Instead, when you use a function name, a bunch of conversions occur. Overload resolution is done based on the calling or (implicit or explicit) casting context, and a pointer is produced.

Default arguments on a function are part of overload resolution. They are never passed as part of a function pointer type.

You can create a simple wrapper that turns a function name into a function object:

#define RETURNS(...) \
  noexcept(noexcept(__VA_ARGS__)) \
  -> decltype(__VA_ARGS__) \
  { return __VA_ARGS__; }

#define OVERLOADS_OF(...) \
  [](auto&&...args) \
  RETURNS( __VA_ARGS__( decltype(args)(args)... ) )

with this, you can modify your code:

return func(OVERLOADS_OF(defaultFree));

and get the default arguments to be considered by func and SFINAE to result in ambiguity.

Now, OVERLOADS_OF(defaultFree) is a function object which SFINAE tests if its arguments can be passed to a callable called defaultFree. This permits 1 argument to be passed.

Function objects are not functions. A lambda is a function object, as is the return type of OVERLOADS_OF. Function objects can be passed in and their overloaded operator() considered; they can remember their default parameters, do SFINAE, etc.

So when you pass the lambda, both possibilities are legal. When you pass a function, it becomes a function pointer to the no-default-argument call to the function, and that unambiguously does not accept 1 parameter.

---

To fix your problem you should make one overload look better than the other.

One approach is to use ...:

namespace impl {
  template <typename F>
  auto func(F f,...) -> decltype(f(42))
  {
    int a = 51;
    return f(51);
  }

  template <typename F>
  auto func(F f, int) -> decltype(f(42, 42))
  {
    int a = 0;
    int b = 10;
    return f(a, b);
  }
}
template <typename F>
auto func(F f) -> decltype( impl::func(f, 0) )
{
  return impl::func(f, 0);
}

the trick is that int is preferred over ... when you pass 0.

You could also be more explicit, and generate traits like "can be called with 1 argument", "can be called with 2 arguments", then state that the 1 arg case is only enabled when you can be called with 1 but not 2 arguments.

There are also tag dispatching based overload resolution ordering techniques.

Corrasion