On Tue, Mar 10, 2015 at 4:31 PM, Louis Dionne
Also, there are several caveats. First, because we're using lambdas, it means that the function's result can't be used in a constant expression. This is IMO a stupid limitation of the language and one that should be lifted. If someone is willing to team up with me for writing a proposal, I would be interested.
I, too, really want this both for hana and for much more general uses. IMO, it's a really unfortunate limitation. I investigated this not too long ago to see just what the difficulties would be here if one were to try and get constexpr lambdas, and there is some hairiness that wasn't immediately apparent to me at the time: If you expect the results to be usable in all places that a constexpr could be used, such as in argument to a template or anywhere in a function's declaration other than a function's default argument, which is pretty important in the world of metaprogramming, then standardization of constexpr lambdas is not quite as easy as it may initially seem. For a related issue, see: https://isocpp.org/files/papers/n4019.html#1607 In short, the standard currently bans the situations mentioned here due to implementation complexity. The resolution of this in C++14 explicitly made it clear that lambdas should never appear in a signature, which was actually the original intent, though was not properly specified in C++11. I contacted Daniel Krügler about this and he said there was consensus that the issue could/should be addressed in a future standard, though that is still something that needs to be addressed. Assuming these restrictions are lifted or relaxed, SFINAE would then also need to be addressed, as lambdas would be able to appear in template declarations. My assumption there is that SFINAE just wouldn't apply to the body of the lambda (I.E. it would cause a hard error during substitution rather than just substitution failure). -- -Matt Calabrese