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?
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.
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.
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.
So the simple answer is YES.
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.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With