#include <functional>
#include <iostream>
int main()
{
std::function<double(double)> l1 = [](double x) { return x*x; };
std::function<double(double)> l2 = [](double x) { return 1.0 / x; };
bool b = false;
auto f = b ? l2 : l1;
std::cout << f(2.0) << '\n'; // 4
b = true;
auto f2 = b ? l2 : l1;
std::cout << f2(2.0) << '\n'; // .5
}
#include <functional>
#include <iostream>
int main()
{
std::function<double(double)> fCanonical;
decltype(fCanonical) l1 = [](double x) { return x*x; };
decltype(fCanonical) l2 = [](double x) { return 1.0 / x; };
bool b = false;
auto f = b ? l2 : l1;
std::cout << f(2.0) << '\n'; // 4
b = true;
auto f2 = b ? l2 : l1;
std::cout << f2(2.0) << '\n'; // .5
}
auto l1 = [](int x) {return 1;};
auto l2 = [](int x) {return 1;};
static_assert( std::is_same<decltype(l1), decltype(l2)>::value, "l1 has a different type than l2");
Of course, that's the answer. But I do think it's a sad thing to force lambdas to have their own unique type even if they have no captures and the signature is known at compile time. But I suppose it's impossible within C++.It shouldn't compile as each lambda has a unique type even when the signatures are the same (even guaranteed to be unique).
The solution is to use std::function
Yes, I agree, or at least make the behaviour selectable either way. Meta programming with a rich type system is a very important part of C++ and unique lambda types aren't very useful in that respect.Of course, that's the answer. But I do think it's a sad thing to force lambdas to have their own unique type even if they have no captures and the signature is known at compile time. But I suppose it's impossible within C++.It shouldn't compile as each lambda has a unique type even when the signatures are the same (even guaranteed to be unique).
The solution is to use std::function
Is that a feature or a bug?Of course, that's the answer. But I do think it's a sad thing to force lambdas to have their own unique type even if they have no captures and the signature is known at compile time. But I suppose it's impossible within C++.It shouldn't compile as each lambda has a unique type even when the signatures are the same (even guaranteed to be unique).
The solution is to use std::function
It's a choice made in the C++ standard, it's what the C++ version of lambdas are defined to be.Is that a feature or a bug?Of course, that's the answer. But I do think it's a sad thing to force lambdas to have their own unique type even if they have no captures and the signature is known at compile time. But I suppose it's impossible within C++.It shouldn't compile as each lambda has a unique type even when the signatures are the same (even guaranteed to be unique).
The solution is to use std::function
Maybe lambdas were not built for this more heavyweight work.
PARSE ERRORSome people, like autos, some don't.
Yes.Yes indeed, for configuring 1-liners, and not to replace templates or functions
I'll get @tags onto this.PARSE ERRORSome people, like autos, some don't.
In a function declaration that uses the trailing return type syntax, the keyword auto does not perform automatic type detection. It only serves as a part of the syntax.Lambda functions have this annoying feature that this does not work:
auto l1 = [](double x) { return x*x; };
auto l2 = [](double x) { return 1.0 / x; };
auto l = use_l2 ? l2 : l1;
At least in VS 2015. Why can't two lambdas of the same signature be treated as instances of the same type???