<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Jun 3, 2014 at 10:14 AM, Andy Gibbs <span dir="ltr"><<a href="mailto:andyg1001@hotmail.co.uk" target="_blank">andyg1001@hotmail.co.uk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi,<br>
<br>
Attached is a patch which I would like to put forward to relax the constexpr restriction on the lambda function pointer conversion operator.<br>
<br>
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:<br>
<br>
struct Table {<br>
 // ...<br>
 int (*fn)();<br>
 // ...<br>
};<br>
<br>
constexpr Table table[] = {<br>
 // ...<br>
 { .fn = []{ return 123; } },<br>
 // ...<br>
};<br>
<br>
I have tried to find a clear rationale as to why this should not work, but without real success.</blockquote><div><br></div><div>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.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">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.<br>

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

<br>
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.<br>
<br>
I think this is a reasonable and valid change.</blockquote><div><br></div><div>This is a non-conforming extension. Even if it were conforming, you'd need to demonstrate how this extension satisfies the rules listed here: <a href="http://clang.llvm.org/get_involved.html">http://clang.llvm.org/get_involved.html</a> (and in particular the fourth one).</div>
<div><br></div><div>If you want to make a change to C++, the place to start is the C++ committee, not here. Perhaps post your idea here:</div><div><br></div><div>  <a href="https://groups.google.com/a/isocpp.org/forum/?fromgroups#!forum/std-proposals">https://groups.google.com/a/isocpp.org/forum/?fromgroups#!forum/std-proposals</a></div>
<div><br></div><div>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 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html">http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html</a> for contact details).</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Please could someone look at this for me and let me know if it is worth committing and if the approach is right!</blockquote>
</div></div></div>