[PATCH] Changing lambda function pointer conversion operator to constexpr

Richard Smith richard at metafoo.co.uk
Thu Jun 5 13:03:24 PDT 2014

On Tue, Jun 3, 2014 at 10:14 AM, Andy Gibbs <andyg1001 at hotmail.co.uk> wrote:

> Hi,
> Attached is a patch which I would like to put forward to relax the
> constexpr restriction on the lambda function pointer conversion operator.
> Currently, it is not possible to cast a non-capturing lambda to its
> function pointer form at compile time.  This means the following code will
> not work:
> struct Table {
>  // ...
>  int (*fn)();
>  // ...
> };
> constexpr Table table[] = {
>  // ...
>  { .fn = []{ return 123; } },
>  // ...
> };
> I have tried to find a clear rationale as to why this should not work, but
> without real success.

IIRC, the intent was to avoid lambda-expressions from appearing in contexts
where we might need to mangle their contents into the surrounding
expression. I don't think this rule is necessary for that any more, now
that core issue 1607 has been resolved.

The closest I have come to is that lambda expressions *themselves* may not
> be constexpr.  However, this doesn't mean that the conversion operator
> itself should be so restricted, IMHO, and certainly the use-case above is
> clearer using lambdas than the alternative of static global functions.
> The attached patch therefore lifts this restriction so that the conversion
> operator itself is constexpr (a one-line change in SemaLambda.cpp but also
> requiring LambaExpr be supported in TemporaryExprEvaluator in
> ExprConstant.cpp).
> Note that this patch *does not* permit calling a lambda expression through
> its function pointer in a constexpr evaluation context -- this restriction
> remains as before.
> I think this is a reasonable and valid change.

This is a non-conforming extension. Even if it were conforming, you'd need
to demonstrate how this extension satisfies the rules listed here:
http://clang.llvm.org/get_involved.html (and in particular the fourth one).

If you want to make a change to C++, the place to start is the C++
committee, not here. Perhaps post your idea here:


Alternatively, if you think this is a minor bug in the C++ specification,
you could report it as a core issue (see the top of
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html for contact

Please could someone look at this for me and let me know if it is worth
> committing and if the approach is right!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140605/7008ac69/attachment.html>

More information about the cfe-commits mailing list