[PATCH] Changing lambda function pointer conversion operator to constexpr

[Richard Smith]

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:


https://groups.google.com/a/isocpp.org/forum/?fromgroups#!forum/std-proposals

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
details).

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>