Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

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

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?

like image 623
Max Langhof Avatar asked Sep 17 '18 14:09

Max Langhof


People also ask

What is an important rule about a function with default parameters?

Rule 1: creating functions.When programmers give a parameter a default value, they must give default values to all the parameters to right of it in the parameter list.

What is function with default parameter explain with example?

A default argument is a value provided in a function declaration that is automatically assigned by the compiler if the calling function doesn't provide a value for the argument. In case any value is passed, the default value is overridden.

What is Sfinae used for?

One of the primary uses of SFINAE can be found through enable_if expressions. enable_if is a set of tools, available in the Standard Library since C++11, that internally use SFINAE. They allow to include or exclude overloads from possible function templates or class template specialization.

Will concepts replace Sfinae?

So the simple answer is YES.


2 Answers

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.

like image 36
Yakk - Adam Nevraumont Avatar answered Oct 07 '22 08:10

Yakk - Adam Nevraumont


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.

like image 129
StoryTeller - Unslander Monica Avatar answered Oct 07 '22 08:10

StoryTeller - Unslander Monica