Re: [boost] [mpl] multiset

Subject: Re: [boost] [mpl] multiset
From: Matt Calabrese (rivorus_at_[hidden])
Date: 2015-03-10 20:25:56

On Tue, Mar 10, 2015 at 4:31 PM, Louis Dionne <ldionne.2_at_[hidden]> wrote:
>
> 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