What if the lambda expression of C++11 supports default arguments?

Question

I think the following code is very handy and no harmful:

auto fn = [](bool b = false) -> int // NOT legal in C++11
{
    return b ? 1 : 0;
}; 

Why does C++11 explicitly prohibit default arguments of the lambda expression?

I just wonder the rationales and considerations behind.

I want to know "WHY" rather than "WHAT" the C++11 standard says.

Answer 1

There is no real reason that lambdas can't have default arguments. However, there are two main ways to use lambdas, and only one of them would allow default arguments without changing the type system.

1. You can call the lambda directly, or through a template. Default parameters would work fine in this case.

2. You can call the lambda through std::function. Default parameters would not work without changing the type system.

My guess is that new functions that people write in C++11 will usually take std::function parameters because this way, the function won't have to be a template, or it won't have to be instantiated for every single lambda and functor that gets passed to it.

Why can't a std::function (or function pointer) take defaults?

It's not obvious what the type of such a function would be.

• If it's std::function<int(bool)>, then how do you call it with the defaults? (You can't.)

• If it's std::function<int(bool=false)>, then what types is it compatible with, and how does conversion work? Can you convert it to std::function<int()>? What about std::function<int(bool=true)>?

• If it's something new like std::function<int(bool=default)>, then what types is it compatible with, and how does conversion work?

Basically, this isn't just a switch you can flip in the standard and make function pointers / std::function handle default arguments. Default arguments in normal functions are handled using information from the function's declaration, which is not available at the call site for a lambda or function pointer. So you would have to encode information about the defaults into the function type, and then work out all of the non-obvious rules for conversion and compatibility.

So you would have to come up with a compelling case for why such a feature would be added, and convince the committee.

So, why can't lambdas take defaults?

I haven't answered this question. But I don't think it would be a very useful feature to add. I would delete this answer if I could, but it's been accepted. I would downvote it if I could, but it's mine. C'est la vie.

Answer 2

I agree that there is no real "technical" restriction per se to allowing default arguments in lambdas to work in some cases. It wouldn't mangle your pointers and auto, because the type of a function is not affected by default arguments. But that's also why this wouldn't be terribly practical.

Why?

Because default arguments, while part of a function signature, are not part of a function type:

[C++11: 1.3.17]:
signature
<function> name, parameter type list (8.3.5), and enclosing namespace (if any)
[ Note: Signatures are used as a basis for name mangling and linking. —end note ]

[C++11: 8.3.5/6]: [..] The return type, the parameter-type-list, the ref-qualifier, and the cv-qualifier-seq, but not the default arguments (8.3.6) or the exception specification (15.4), are part of the function type. [ Note: Function types are checked during the assignments and initializations of pointers to functions, references to functions, and pointers to member functions. —end note ]

They are essentially a piece of syntactic sugar that are "activated" by the compiler being able to see the declaration of the function you use, and injected at the point of the function call:

#include <iostream>

void foo(int x = 5)
{
   std::cout << x << '\n';
}

int main()
{
   foo();
}

• Output: 5

The default argument is "visible".

However, when you "hide" your function behind a pointer:

int main()
{
    void (*bar)(int) = &foo;
    bar();
}

• Error: too few arguments to function

The type of bar is correct, and the compiler knows that foo has a default, but there's simply no direct syntax that exists to inform the compiler at the point of calling bar that bar is also foo. Sure, in this trivial scenario it could figure it out by observing the assignment, but that's hardly justification for the wider argument.

For the same reason, default arguments stated only in a definition not visible at the call site are next to useless:

// a.h
void foo(int);

// a.cpp
#include "a.h"
#include <iostream>

void foo(int x = 5)
{
   std::cout << x << '\n';
}

// main.cpp
#include "a.h"

int main()
{
    foo();
}

• Error in main.cpp: too few arguments to function

I imagine that this is the reason for:

[C++11: 8.3.6/4]: [..] Declarations in different scopes have completely distinct sets of default arguments. [..]

We are allowed to "pile up" default arguments for class non-template member function definitions ([C++11 8.3.6/6]); the example indicates that this default will still only apply in the same TU, which follows the behaviour we've seen above in my second code snippet.

So, if default arguments are not part of the function type, and must be unambiguously visible to the call site, then there are only a handful of trivially contrived corner-cases in which they would be useful for lambdas, which is when they are called in the same scope that they are created so the compiler can tractibly figure out how to "fill in" the default argument for the call to the lambda and, well, what is the point of that? Not a lot, I tell thee.

Answer 3

As the comments to the question suggest, there's probably no technical reason for there to be no default arguments. But the flip question is "Is there a practical reason for default arguments?" I would think the answer to this is "no", and here's why.

In order to call a lambda, one thing you can do is call it right away

[] { printf("foo"); }();

I'm sure this has limited uses, if any, so let's move on. The only other way to call a lambda is to bind it to a variable first, and there's a few options here.

1. Use auto. So we get auto foo = [] { printf("foo"); }; foo();
2. Bind it to a function pointer: void (*foo)() = [] { printf("foo"); }; foo(). Of course, this only works if the lambda doesn't capture.
3. Do the equivalent of either 1 or 2 by passing the lambda to a function or function template.

Now let's go through the usefulness of default arguments in each case

1. We're calling the lambda directly in this case, so the code is probably tight-knit enough that we won't be calling the lambda with various numbers of arguments. If we are, the lambda could (should?) probably be refactored into a more general component. I don't see any practical benefit here.
2. (see 1)
3. We pass the lambda off to another function. I don't see the practical benefit to a default argument here, either. Think back to good old functors (which can have default arguments) - I can't say I know of too many functions which count on default arguments being present even for these. Since lambdas are effectively just functors, there's no reason for this observation to change suddenly.

I think these points are enough to say the default arguments to a lambda really aren't that useful. Also, I see some people are talking about issues with the type of a lambda if it had default arguments, but this is a non-issue IMO. You can always write up your own functor that does the same thing, and which does have the default argument. Also, about degrading to a function pointer, there's not much to say either. Take a normal function

void func(int i = 0)
{
}

and take it's address. What do you get? A void (*)(int). There's no reason a lambda would follow different rules.

Answer 4

I've read some of these responses, and everyone (from what I read tl;dr) was referring to restrictions in the type system. This really doesn't have anything to do with that. Although a function's type includes all parameters, default or not, a functor with default arguments can be thought of as a fuzzy function, who's type doesn't come into being until you look at it.

As a lambda is syntactic sugar to simplify a functor's use, with some cool type deduction thrown in. It is, when boiled down and converted by the compiler, a functor when it has captures (a function if it does not). So there is really no reason why you can't have it in a lambda. Observe:

#include<functional>
#include<iostream>

int main()
{
    // my lambda as written as a functor.  Not pretty eh?  But it works. o.O
    struct {
    void operator()(char const* x = "default") {
         std::cout << x << std::endl;
    } } fn;

    fn("Hi");
    fn();
    std::function<void(char const*)> fn_copy_1 = fn;
    std::function<void()>            fn_copy_0 = fn;
    fn_copy_1("there");
    fn_copy_0();
    return 0;
}

Results (running example here):

Hi
default
there
default

All without any changes to the type system.

So, why is there such a restriction? My guess, nobody thought it would be useful and it would be less stuff to test if it wasn't implemented. Things are added to the language by the users calling out that they need feature X. If no one asks for it and there isn't enough value associated with it, then it's not added. This is not to say it can't be added in the future, but only if there is call for it.