Hi All,
    Since some of you had expressed interest in constexpr lambdas
(either privately to me or on the list or at Urbana) - and since a
couple of our constexpr godfathers (Gabriel Dos Reis & Richard Smith)
seemed encouragingly un-averse to the general idea when i pinged them
months ago - I went ahead and implemented a quick prototype
(https://github.com/faisalv/clang/tree/constexpr-lambdas (*)) of what
constexpr lambdas might look like in C++, hoping to inform and
facilitate future EWG discussion.

The easiest way to think about constexpr lamdbas might be to ask
yourself if the equivalent non-lambda code using a literal class with
a constexpr member call-operator would be constexpr. Captures to
references can't escape their scope (at least in this branch ;).
Captures by value obviously can.

Note: Per my interpretation of preliminary thoughts from Gabby and
Richard, I made the constexpr annotation optional - that is
constexpr-ness of a lambda's call operator is inferred: if the call
operator could be constexpr it is assumed to be so annotated. If you
prefer to explicitly annotate it, you can.  (see comments below as to
where you would add the annotations)

Consider this highly contrived (braindead) fragment of code below to
get a sense of what's possible with the patch:

constexpr auto getFactorializer = [] {
  unsigned int optimization[6] = {};

  auto for_each = [](auto *b, auto *e, auto pred) {
    auto *it = b;
    while (it != e) pred(it++ - b);
  };

  for_each(optimization, optimization + 6, [&](int n) {
    if (!n) optimization[n] = 1;
    else
      optimization[n] = n * optimization[n-1];
  });

  auto FacImpl = [=](auto fac, unsigned n) {
    if (n <= 5) return optimization[n];
    return n * fac(fac, n - 1);
  };
  auto Fact = [=](int n) {
    return FacImpl(FacImpl, n);
  };
  return Fact;
};

constexpr auto Factorial = getFactorializer();

static_assert(Factorial(5) == 120, "");
static_assert(Factorial(10) == 3628800, "");


To see further examples of test-case code that seems to work:
https://github.com/faisalv/clang/blob/constexpr-lambdas/test/CXX/clambdas/cxx1z-constexpr-lambdas.cpp

Some technicalities:
  - the conversion operator to fptr for a non-capturing lambda is
always constexpr
  - the closure type behaves as a literal type as long as all of its
capture 'data members' are literals (this can include other closure
objects)
  - the evaluation of a lambda expression is a
core-constant-expression if all the initializations of the captures
are core-constant-expressions
  - the constexprness of the call operator is deduced if not
explicitly specified

I would certainly appreciate any useful feedback - especially if
anyone has the time to download the patch and play with it and report
any bugs (perceived or real) to me.

And unless there is overwhelming well reasoned majority opposition to
this idea, I hope to help write a paper on this (I might reach out to
some of you for help - or if you're motivated please reach out to me),
and perhaps we can submit something for the lenexa mailing?

Thanks!
Faisal Vali

(*)The llvm revision to use is contained within the Readme file.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_52_1295557628.1427401015156
Content-Type: multipart/alternative;
 boundary="----=_Part_53_1100356863.1427401015156"

------=_Part_53_1100356863.1427401015156
Content-Type: text/plain; charset=UTF-8

This is incredibly awesome. I've been waiting for this for so long.
I will play with it at soon as I get the time and let me know my thoughts.
I think I can provide several use cases for this feature, some of which
could definitely motivate a paper.

I'm also willing to help write a standard paper, but I must wait for the
summer when I have more time on my hands.

Thank you Faisal,
Louis


On Thursday, 26 March 2015 16:01:24 UTC-4, faisalv wrote:
>
> Hi All,
>     Since some of you had expressed interest in constexpr lambdas
> (either privately to me or on the list or at Urbana) - and since a
> couple of our constexpr godfathers (Gabriel Dos Reis & Richard Smith)
> seemed encouragingly un-averse to the general idea when i pinged them
> months ago - I went ahead and implemented a quick prototype
> (https://github.com/faisalv/clang/tree/constexpr-lambdas (*)) of what
> constexpr lambdas might look like in C++, hoping to inform and
> facilitate future EWG discussion.
>
> The easiest way to think about constexpr lamdbas might be to ask
> yourself if the equivalent non-lambda code using a literal class with
> a constexpr member call-operator would be constexpr. Captures to
> references can't escape their scope (at least in this branch ;).
> Captures by value obviously can.
>
> Note: Per my interpretation of preliminary thoughts from Gabby and
> Richard, I made the constexpr annotation optional - that is
> constexpr-ness of a lambda's call operator is inferred: if the call
> operator could be constexpr it is assumed to be so annotated. If you
> prefer to explicitly annotate it, you can.  (see comments below as to
> where you would add the annotations)
>
> Consider this highly contrived (braindead) fragment of code below to
> get a sense of what's possible with the patch:
>
> constexpr auto getFactorializer = [] {
>   unsigned int optimization[6] = {};
>
>   auto for_each = [](auto *b, auto *e, auto pred) {
>     auto *it = b;
>     while (it != e) pred(it++ - b);
>   };
>
>   for_each(optimization, optimization + 6, [&](int n) {
>     if (!n) optimization[n] = 1;
>     else
>       optimization[n] = n * optimization[n-1];
>   });
>
>   auto FacImpl = [=](auto fac, unsigned n) {
>     if (n <= 5) return optimization[n];
>     return n * fac(fac, n - 1);
>   };
>   auto Fact = [=](int n) {
>     return FacImpl(FacImpl, n);
>   };
>   return Fact;
> };
>
> constexpr auto Factorial = getFactorializer();
>
> static_assert(Factorial(5) == 120, "");
> static_assert(Factorial(10) == 3628800, "");
>
>
> To see further examples of test-case code that seems to work:
>
> https://github.com/faisalv/clang/blob/constexpr-lambdas/test/CXX/clambdas/cxx1z-constexpr-lambdas.cpp
>
> Some technicalities:
>   - the conversion operator to fptr for a non-capturing lambda is
> always constexpr
>   - the closure type behaves as a literal type as long as all of its
> capture 'data members' are literals (this can include other closure
> objects)
>   - the evaluation of a lambda expression is a
> core-constant-expression if all the initializations of the captures
> are core-constant-expressions
>   - the constexprness of the call operator is deduced if not
> explicitly specified
>
> I would certainly appreciate any useful feedback - especially if
> anyone has the time to download the patch and play with it and report
> any bugs (perceived or real) to me.
>
> And unless there is overwhelming well reasoned majority opposition to
> this idea, I hope to help write a paper on this (I might reach out to
> some of you for help - or if you're motivated please reach out to me),
> and perhaps we can submit something for the lenexa mailing?
>
> Thanks!
> Faisal Vali
>
> (*)The llvm revision to use is contained within the Readme file.
>

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_53_1100356863.1427401015156
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>This is incredibly awesome. I've been waiting for thi=
s for so long.&nbsp;</div><div>I will play with it at soon as I get the tim=
e and let me know my thoughts.&nbsp;</div><div>I think I can provide severa=
l use cases for this feature, some of which&nbsp;</div><div>could definitel=
y motivate a paper.</div><div><br></div><div>I'm also willing to help write=
 a standard paper, but I must wait for the&nbsp;</div><div>summer when I ha=
ve more time on my hands.</div><div><br></div><div>Thank you Faisal,</div><=
div>Louis</div><div><br></div><br>On Thursday, 26 March 2015 16:01:24 UTC-4=
, faisalv  wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Hi All,
<br>&nbsp; &nbsp; Since some of you had expressed interest in constexpr lam=
bdas
<br>(either privately to me or on the list or at Urbana) - and since a
<br>couple of our constexpr godfathers (Gabriel Dos Reis &amp; Richard Smit=
h)
<br>seemed encouragingly un-averse to the general idea when i pinged them
<br>months ago - I went ahead and implemented a quick prototype
<br>(<a href=3D"https://github.com/faisalv/clang/tree/constexpr-lambdas" ta=
rget=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'https://www.go=
ogle.com/url?q\75https%3A%2F%2Fgithub.com%2Ffaisalv%2Fclang%2Ftree%2Fconste=
xpr-lambdas\46sa\75D\46sntz\0751\46usg\75AFQjCNHqwZMgEdpAqwf0kD395poieEPm3A=
';return true;" onclick=3D"this.href=3D'https://www.google.com/url?q\75http=
s%3A%2F%2Fgithub.com%2Ffaisalv%2Fclang%2Ftree%2Fconstexpr-lambdas\46sa\75D\=
46sntz\0751\46usg\75AFQjCNHqwZMgEdpAqwf0kD395poieEPm3A';return true;">https=
://github.com/faisalv/<wbr>clang/tree/constexpr-lambdas</a> (*)) of what
<br>constexpr lambdas might look like in C++, hoping to inform and
<br>facilitate future EWG discussion.
<br>
<br>The easiest way to think about constexpr lamdbas might be to ask
<br>yourself if the equivalent non-lambda code using a literal class with
<br>a constexpr member call-operator would be constexpr. Captures to
<br>references can't escape their scope (at least in this branch ;).
<br>Captures by value obviously can.
<br>
<br>Note: Per my interpretation of preliminary thoughts from Gabby and
<br>Richard, I made the constexpr annotation optional - that is
<br>constexpr-ness of a lambda's call operator is inferred: if the call
<br>operator could be constexpr it is assumed to be so annotated. If you
<br>prefer to explicitly annotate it, you can. &nbsp;(see comments below as=
 to
<br>where you would add the annotations)
<br>
<br>Consider this highly contrived (braindead) fragment of code below to
<br>get a sense of what's possible with the patch:
<br>
<br>constexpr auto getFactorializer =3D [] {
<br>&nbsp; unsigned int optimization[6] =3D {};
<br>
<br>&nbsp; auto for_each =3D [](auto *b, auto *e, auto pred) {
<br>&nbsp; &nbsp; auto *it =3D b;
<br>&nbsp; &nbsp; while (it !=3D e) pred(it++ - b);
<br>&nbsp; };
<br>
<br>&nbsp; for_each(optimization, optimization + 6, [&amp;](int n) {
<br>&nbsp; &nbsp; if (!n) optimization[n] =3D 1;
<br>&nbsp; &nbsp; else
<br>&nbsp; &nbsp; &nbsp; optimization[n] =3D n * optimization[n-1];
<br>&nbsp; });
<br>
<br>&nbsp; auto FacImpl =3D [=3D](auto fac, unsigned n) {
<br>&nbsp; &nbsp; if (n &lt;=3D 5) return optimization[n];
<br>&nbsp; &nbsp; return n * fac(fac, n - 1);
<br>&nbsp; };
<br>&nbsp; auto Fact =3D [=3D](int n) {
<br>&nbsp; &nbsp; return FacImpl(FacImpl, n);
<br>&nbsp; };
<br>&nbsp; return Fact;
<br>};
<br>
<br>constexpr auto Factorial =3D getFactorializer();
<br>
<br>static_assert(Factorial(5) =3D=3D 120, "");
<br>static_assert(Factorial(10) =3D=3D 3628800, "");
<br>
<br>
<br>To see further examples of test-case code that seems to work:
<br><a href=3D"https://github.com/faisalv/clang/blob/constexpr-lambdas/test=
/CXX/clambdas/cxx1z-constexpr-lambdas.cpp" target=3D"_blank" rel=3D"nofollo=
w" onmousedown=3D"this.href=3D'https://www.google.com/url?q\75https%3A%2F%2=
Fgithub.com%2Ffaisalv%2Fclang%2Fblob%2Fconstexpr-lambdas%2Ftest%2FCXX%2Fcla=
mbdas%2Fcxx1z-constexpr-lambdas.cpp\46sa\75D\46sntz\0751\46usg\75AFQjCNG9gr=
rKi6w_7TdqC6m0RvB7A-hs3A';return true;" onclick=3D"this.href=3D'https://www=
..google.com/url?q\75https%3A%2F%2Fgithub.com%2Ffaisalv%2Fclang%2Fblob%2Fcon=
stexpr-lambdas%2Ftest%2FCXX%2Fclambdas%2Fcxx1z-constexpr-lambdas.cpp\46sa\7=
5D\46sntz\0751\46usg\75AFQjCNG9grrKi6w_7TdqC6m0RvB7A-hs3A';return true;">ht=
tps://github.com/faisalv/<wbr>clang/blob/constexpr-lambdas/<wbr>test/CXX/cl=
ambdas/cxx1z-<wbr>constexpr-lambdas.cpp</a>
<br>
<br>Some technicalities:
<br>&nbsp; - the conversion operator to fptr for a non-capturing lambda is
<br>always constexpr
<br>&nbsp; - the closure type behaves as a literal type as long as all of i=
ts
<br>capture 'data members' are literals (this can include other closure
<br>objects)
<br>&nbsp; - the evaluation of a lambda expression is a
<br>core-constant-expression if all the initializations of the captures
<br>are core-constant-expressions
<br>&nbsp; - the constexprness of the call operator is deduced if not
<br>explicitly specified
<br>
<br>I would certainly appreciate any useful feedback - especially if
<br>anyone has the time to download the patch and play with it and report
<br>any bugs (perceived or real) to me.
<br>
<br>And unless there is overwhelming well reasoned majority opposition to
<br>this idea, I hope to help write a paper on this (I might reach out to
<br>some of you for help - or if you're motivated please reach out to me),
<br>and perhaps we can submit something for the lenexa mailing?
<br>
<br>Thanks!
<br>Faisal Vali
<br>
<br>(*)The llvm revision to use is contained within the Readme file.
<br></blockquote></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_53_1100356863.1427401015156--
------=_Part_52_1295557628.1427401015156--

.

> I'm also willing to help write a standard paper, but I must wait for the
> summer when I have more time on my hands.

As another potential (ab)user of this, count me in too

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 26 March 2015 at 22:31, Joel FALCOU <joel.falcou@gmail.com> wrote:
>> I'm also willing to help write a standard paper, but I must wait for the
>> summer when I have more time on my hands.
>
> As another potential (ab)user of this, count me in too


It's on my todo-list to write a short paper about it for Urbana. I thought
Richard had already written a simple proof-of-concept implementation of it.

As a background, Finland suggested allowing constexpr lambdas for C++14,
but the NB comment was rejected as "too late to get in". I very much plan to
resurrect the idea.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

--047d7b471e3ae708c4051237eb0b
Content-Type: text/plain; charset=UTF-8

On Thu, Mar 26, 2015 at 2:31 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:

> On 26 March 2015 at 22:31, Joel FALCOU <joel.falcou@gmail.com> wrote:
> >> I'm also willing to help write a standard paper, but I must wait for the
> >> summer when I have more time on my hands.
> >
> > As another potential (ab)user of this, count me in too
>
>
> It's on my todo-list to write a short paper about it for Urbana. I thought
> Richard had already written a simple proof-of-concept implementation of it.
>

Faisal's implementation is substantially more complete than my own -- my
implementation had extremely limited support for captures.


> As a background, Finland suggested allowing constexpr lambdas for C++14,
> but the NB comment was rejected as "too late to get in". I very much plan
> to
> resurrect the idea.
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--047d7b471e3ae708c4051237eb0b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, Mar 26, 2015 at 2:31 PM, Ville Voutilainen <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilaine=
n@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span c=
lass=3D"">On 26 March 2015 at 22:31, Joel FALCOU &lt;<a href=3D"mailto:joel=
..falcou@gmail.com">joel.falcou@gmail.com</a>&gt; wrote:<br>
&gt;&gt; I&#39;m also willing to help write a standard paper, but I must wa=
it for the<br>
&gt;&gt; summer when I have more time on my hands.<br>
&gt;<br>
&gt; As another potential (ab)user of this, count me in too<br>
<br>
<br>
</span>It&#39;s on my todo-list to write a short paper about it for Urbana.=
 I thought<br>
Richard had already written a simple proof-of-concept implementation of it.=
<br></blockquote><div><br></div><div>Faisal&#39;s implementation is substan=
tially more complete than my own -- my implementation had extremely limited=
 support for captures.</div><div>=C2=A0</div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
>
As a background, Finland suggested allowing constexpr lambdas for C++14,<br=
>
but the NB comment was rejected as &quot;too late to get in&quot;. I very m=
uch plan to<br>
resurrect the idea.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
--<br>
<br>
---<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-propo=
sals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--047d7b471e3ae708c4051237eb0b--

.

------=_Part_1542_1323951756.1427485486017
Content-Type: multipart/alternative;
 boundary="----=_Part_1543_1579096525.1427485486017"

------=_Part_1543_1579096525.1427485486017
Content-Type: text/plain; charset=UTF-8

On Thursday, March 26, 2015 at 2:44:35 PM UTC-7, Richard Smith wrote:
>
> On Thu, Mar 26, 2015 at 2:31 PM, Ville Voutilainen <ville.vo...@gmail.com
> <javascript:>> wrote:
>
>> On 26 March 2015 at 22:31, Joel FALCOU <joel....@gmail.com <javascript:>>
>> wrote:
>
> As a background, Finland suggested allowing constexpr lambdas for C++14,
>> but the NB comment was rejected as "too late to get in". I very much plan
>> to
>> resurrect the idea.
>>
>
>
I have a few questions about this:


1. Will this change end the current prohibition against putting lambdas in
template parameters, decltypes, and sizeofs (unevaluated contexts for
latter two)?  I ask because it seems as though you could force the issue
indirectly:

template <typename T, T I>
T Passthrough()
{
    return I;
}

constexpr auto g_meow = []{ return 2; }();

int main()
{
    // returns 6 on most platforms
    return Passthrough<decltype(g_meow), g_meow>() + sizeof(g_meow);
}

Would putting a lambda *directly* in a template parameter or unevaluated
context be legal, or would such indirection as above be necessary?


2. What is the syntax for explicitly stating the constexpr status of the
call operator?  Putting it after the parentheses of the parameter list?

[](int x, int y) constexpr { return x + y; }

Assuming yes, what if the parameter list is omitted?  Is this legal?

[&] constexpr { return capturedX + capturedY; }


3. How would this interact with proposals for functions that overload on
the constexprness of their parameters?  This would seem to make things
unpredictable, since if you passed a lambda or lambda-derived value to such
a function, which one gets called would not be obvious.

I suppose that this isn't much of a problem, though; constexprness
overloading is supposed to be used only for optimization, not behavioral
differences.  Functions *should* do the same thing with constexpr
parameters as they do with non-constexpr parameters...


Melissa

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_1543_1579096525.1427485486017
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thursday, March 26, 2015 at 2:44:35 PM UTC-7, Richard S=
mith wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><d=
iv><div class=3D"gmail_quote">On Thu, Mar 26, 2015 at 2:31 PM, Ville Voutil=
ainen <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-o=
bfuscated-mailto=3D"klX1p30op4cJ" rel=3D"nofollow" onmousedown=3D"this.href=
=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript:';return =
true;">ville.vo...@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex"><span>On 26 March 2015 at 22:31, Joel FALCOU &lt;<a href=3D"javas=
cript:" target=3D"_blank" gdf-obfuscated-mailto=3D"klX1p30op4cJ" rel=3D"nof=
ollow" onmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"th=
is.href=3D'javascript:';return true;">joel....@gmail.com</a>&gt; wrote:</sp=
an></blockquote><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex">
As a background, Finland suggested allowing constexpr lambdas for C++14,<br=
>
but the NB comment was rejected as "too late to get in". I very much plan t=
o<br>
resurrect the idea.<br></blockquote></div><br></div></div></blockquote><div=
><br>I have a few questions about this:<br><br><br>1. Will this change end =
the current prohibition against putting lambdas in template parameters, <sp=
an style=3D"font-family: courier new,monospace;">decltype</span>s, and <spa=
n style=3D"font-family: courier new,monospace;">sizeof</span>s (unevaluated=
 contexts for latter two)?&nbsp; I ask because it seems as though you could=
 force the issue indirectly:<br><br><div class=3D"prettyprint" style=3D"bac=
kground-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border=
-style: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"pr=
ettyprint"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=
=3D"styled-by-prettify">template</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">&lt;</span><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">typename</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> T</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> T I</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"><br>T </span><span sty=
le=3D"color: #606;" class=3D"styled-by-prettify">Passthrough</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">()</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"><br>&nbsp; &nbsp; </span><span style=3D"color: #=
008;" class=3D"styled-by-prettify">return</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> I</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">}</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<br><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">co=
nstexpr</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span style=3D"color: #008;" class=3D"styled-by-prettify">auto</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> g_meow </span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">[]{</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">return</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> </span><span style=3D"color: #066;" class=3D"styled-by=
-prettify">2</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">}();</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"><br><br></span><span s=
tyle=3D"color: #008;" class=3D"styled-by-prettify">int</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> main</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">()</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"><br>&nbsp; &nbsp; </span><span style=3D"color: #800;" class=
=3D"styled-by-prettify">// returns 6 on most platforms</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; </span><span =
style=3D"color: #008;" class=3D"styled-by-prettify">return</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"colo=
r: #606;" class=3D"styled-by-prettify">Passthrough</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #0=
08;" class=3D"styled-by-prettify">decltype</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">g_meow</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">),</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> g_meow</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">&gt;()</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">+</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span=
 style=3D"color: #008;" class=3D"styled-by-prettify">sizeof</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify">g_meow</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">);</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">}</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br></span></div></code></div><br>Would putting a lambda <i>=
directly</i> in a template parameter or unevaluated context be legal, or wo=
uld such indirection as above be necessary?<br><br><br>2. What is the synta=
x for explicitly stating the <span style=3D"font-family: courier new,monosp=
ace;">constexpr</span> status of the call operator?&nbsp; Putting it after =
the parentheses of the parameter list?<br><br><div class=3D"prettyprint" st=
yle=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 18=
7); border-style: solid; border-width: 1px; word-wrap: break-word;"><code c=
lass=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">[](</span><span style=3D"color: #008;" cl=
ass=3D"styled-by-prettify">int</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> x</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">int</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> y</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">constexpr</span><span style=3D"color:=
 #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-=
prettify">return</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> x </span><span style=3D"color: #660;" class=3D"styled-by-prettify">+=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> y</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">}</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"><br></span></div></code></div><br>Assuming ye=
s, what if the parameter list is omitted?&nbsp; Is this legal?<br><br><div =
class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border=
-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-wr=
ap: break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint">=
<span style=3D"color: #660;" class=3D"styled-by-prettify">[&amp;]</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">constexpr</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"=
styled-by-prettify">return</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> capturedX </span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">+</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> capturedY</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"><br></span></div></=
code></div><br><br>3. How would this interact with proposals for functions =
that overload on the <span style=3D"font-family: courier new,monospace;">co=
nstexpr</span>ness of their parameters?&nbsp; This would seem to make thing=
s unpredictable, since if you passed a lambda or lambda-derived value to su=
ch a function, which one gets called would not be obvious.<br><br>I suppose=
 that this isn't much of a problem, though; <span style=3D"font-family: cou=
rier new,monospace;">constexpr</span>ness overloading is supposed to be use=
d only for optimization, not behavioral differences.&nbsp; Functions <i>sho=
uld</i> do the same thing with <span style=3D"font-family: courier new,mono=
space;">constexpr</span> parameters as they do with non-<span style=3D"font=
-family: courier new,monospace;">constexpr</span> parameters...<br><br><br>=
Melissa<br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_1543_1579096525.1427485486017--
------=_Part_1542_1323951756.1427485486017--

.

------=_Part_1629_1255887058.1427486127199
Content-Type: multipart/alternative;
 boundary="----=_Part_1630_77017443.1427486127199"

------=_Part_1630_77017443.1427486127199
Content-Type: text/plain; charset=UTF-8

On Friday, March 27, 2015 at 12:44:46 PM UTC-7, Myriachan wrote:
>
> On Thursday, March 26, 2015 at 2:44:35 PM UTC-7, Richard Smith wrote:
>>
>> On Thu, Mar 26, 2015 at 2:31 PM, Ville Voutilainen <ville.vo...@gmail.com
>> > wrote:
>>
>>> On 26 March 2015 at 22:31, Joel FALCOU <joel....@gmail.com> wrote:
>>
>> As a background, Finland suggested allowing constexpr lambdas for C++14,
>>> but the NB comment was rejected as "too late to get in". I very much
>>> plan to
>>> resurrect the idea.
>>>
>>
>>
> I have a few questions about this:
>
>
> 1. Will this change end the current prohibition against putting lambdas in
> template parameters, decltypes, and sizeofs (unevaluated contexts for
> latter two)?  I ask because it seems as though you could force the issue
> indirectly:
> Melissa
>

I just realized that my question here is partly somewhat silly.  We can
already indirectly do decltype and sizeof on lambdas, duh >.<  Also, the
prohibition on lambdas in unevaluated contexts is orthogonal to whether
they are constant expressions; not being a constant expression I don't
think was the reason this was prohibited anyway.  Sorry about that.

However, I still wonder whether it's intended to be legal under the
proposal to call a lambda in a template parameter, since now they would
qualify.

Melissa

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_1630_77017443.1427486127199
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Friday, March 27, 2015 at 12:44:46 PM UTC-7, Myriachan =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">On Thur=
sday, March 26, 2015 at 2:44:35 PM UTC-7, Richard Smith wrote:<blockquote c=
lass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote"=
>On Thu, Mar 26, 2015 at 2:31 PM, Ville Voutilainen <span dir=3D"ltr">&lt;<=
a rel=3D"nofollow">ville.vo...@gmail.com</a>&gt;</span> wrote:<br><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex"><span>On 26 March 2015 at 22:31, Joel FALCOU &lt;<a r=
el=3D"nofollow">joel....@gmail.com</a>&gt; wrote:</span></blockquote><block=
quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc=
 solid;padding-left:1ex">
As a background, Finland suggested allowing constexpr lambdas for C++14,<br=
>
but the NB comment was rejected as "too late to get in". I very much plan t=
o<br>
resurrect the idea.<br></blockquote></div><br></div></div></blockquote><div=
><br>I have a few questions about this:<br><br><br>1. Will this change end =
the current prohibition against putting lambdas in template parameters, <sp=
an style=3D"font-family:courier new,monospace">decltype</span>s, and <span =
style=3D"font-family:courier new,monospace">sizeof</span>s (unevaluated con=
texts for latter two)?&nbsp; I ask because it seems as though you could for=
ce the issue indirectly:<br>Melissa<br></div></div></blockquote><div><br>I =
just realized that my question here is partly somewhat silly.&nbsp; We can =
already indirectly do decltype and sizeof on lambdas, duh &gt;.&lt;&nbsp; A=
lso, the prohibition on lambdas in unevaluated contexts is orthogonal to wh=
ether they are constant expressions; not being a constant expression I don'=
t think was the reason this was prohibited anyway.&nbsp; Sorry about that.<=
br><br>However, I still wonder whether it's intended to be legal under the =
proposal to call a lambda in a template parameter, since now they would qua=
lify.<br><br>Melissa<br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_1630_77017443.1427486127199--
------=_Part_1629_1255887058.1427486127199--

.

On Fri, Mar 27, 2015 at 2:55 PM, Myriachan <myriachan@gmail.com> wrote:
> On Friday, March 27, 2015 at 12:44:46 PM UTC-7, Myriachan wrote:
>>
>> On Thursday, March 26, 2015 at 2:44:35 PM UTC-7, Richard Smith wrote:
>>>
>>> On Thu, Mar 26, 2015 at 2:31 PM, Ville Voutilainen
>>> <ville.vo...@gmail.com> wrote:
>>>>
>>>> On 26 March 2015 at 22:31, Joel FALCOU <joel....@gmail.com> wrote:
>>>>
>>>> As a background, Finland suggested allowing constexpr lambdas for C++14,
>>>> but the NB comment was rejected as "too late to get in". I very much
>>>> plan to
>>>> resurrect the idea.
>>>
>>>
>>
>> I have a few questions about this:
>>
>>
>> 1. Will this change end the current prohibition against putting lambdas in
>> template parameters, decltypes, and sizeofs (unevaluated contexts for latter
>> two)?  I ask because it seems as though you could force the issue
>> indirectly:
>> Melissa
>
>
> I just realized that my question here is partly somewhat silly.  We can
> already indirectly do decltype and sizeof on lambdas, duh >.<  Also, the
> prohibition on lambdas in unevaluated contexts is orthogonal to whether they
> are constant expressions; not being a constant expression I don't think was
> the reason this was prohibited anyway.  Sorry about that.
>
> However, I still wonder whether it's intended to be legal under the proposal
> to call a lambda in a template parameter, since now they would qualify.
>

Yes - I would expect that to work - since I don't believe default
template arguments are unevaluated operands (unlike operands of
sizeof, decltype, typeid(?), noexcept). [I just tweaked my patch to
make sure it works - clang-trunk seems to evaluate template arguments
in an unevaluated context]

Keep in mind that evaluation of a lambda-expression (that constructs a
closure object) is different from the evaluation of an id-expression
(that refers to a closure object).  The lambda-expression is not the
'thing', the closure object is the 'thing'.

Just because lambda-expressions are forbidden in certain operands does
not mean that id-expressions that refer to a closure object are
forbidden in those operands. If you find this unintuitive or strange,
I would agree, wishing that there was symmetry there.

Hope that helps.


> Melissa
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

While I was fixing a bug in the constexpr-lambda branch - it occurred
to me that true compile time closures -- i.e.constexpr lambdas that
capture variables by reference, capture their relevant data-frames on
the call stack, but only if executed at compile time) --  are
relatively straightforward to implement (unless I'm missing something
fundamental) given the framework that Richard Smith laid down for
constexpr in clang.

So I went ahead and prototyped a quick implementation in clang:
https://github.com/faisalv/clang/tree/constexpr-lambdas-ref-closures.

Of course, there is a significant compile-time penalty (but this could
also be optimized further) - but no run time cost.

It makes the following (those of  you who program using dynamic
languages might be quite familiar with the pattern) well-defined  -
BUT only at compile time, at run-time, things remain horribly
undefined :

constexpr auto make_obj(int data) {
   auto addL = [&] { return ++data; };
   auto subL = [&] { return --data; };
   struct {
     decltype(addL) add;
     decltype(subL) sub;
   } ret = {addL, subL};
  return ret;
}

constexpr auto Obj1 = make_obj(10);
static_assert(Obj1.add() == 11, "");
static_assert(Obj1.add() == 12, "");
static_assert(Ob1.sub() == 11, "");

auto RuntimeObj2 = Obj1.add(); // This will reliably cause your
program to crash (but only if executed ;)

You can see further examples here:
https://github.com/faisalv/clang/blob/constexpr-lambdas-ref-closures/test/CXX/clambdas/saved-frames.cpp

Does anyone see any merit in proposing something like this?  My
initial thought is that it introduces an asymmetry between compile
time and run time computation that by itself makes this quite
unattractive.  I suspect there might be other issues too - such as
breaking compiler optimizations that might rely on the execution of a
constexpr function to maintain a certain invariance (are there any
such optimizations that occur during translation?)

Thoughts?

Thanks!
Faisal Vali

P.S. I'm sending this out (coincidentally) on April 1st - since the
idea might seem appropriate for the date  - but the question is an
earnest one ;)





On Thu, Mar 26, 2015 at 3:16 PM, Louis Dionne <ldionne.2@gmail.com> wrote:
> This is incredibly awesome. I've been waiting for this for so long.
> I will play with it at soon as I get the time and let me know my thoughts.
> I think I can provide several use cases for this feature, some of which
> could definitely motivate a paper.
>
> I'm also willing to help write a standard paper, but I must wait for the
> summer when I have more time on my hands.
>
> Thank you Faisal,
> Louis
>
>
> On Thursday, 26 March 2015 16:01:24 UTC-4, faisalv wrote:
>>
>> Hi All,
>>     Since some of you had expressed interest in constexpr lambdas
>> (either privately to me or on the list or at Urbana) - and since a
>> couple of our constexpr godfathers (Gabriel Dos Reis & Richard Smith)
>> seemed encouragingly un-averse to the general idea when i pinged them
>> months ago - I went ahead and implemented a quick prototype
>> (https://github.com/faisalv/clang/tree/constexpr-lambdas (*)) of what
>> constexpr lambdas might look like in C++, hoping to inform and
>> facilitate future EWG discussion.
>>
>> The easiest way to think about constexpr lamdbas might be to ask
>> yourself if the equivalent non-lambda code using a literal class with
>> a constexpr member call-operator would be constexpr. Captures to
>> references can't escape their scope (at least in this branch ;).
>> Captures by value obviously can.
>>
>> Note: Per my interpretation of preliminary thoughts from Gabby and
>> Richard, I made the constexpr annotation optional - that is
>> constexpr-ness of a lambda's call operator is inferred: if the call
>> operator could be constexpr it is assumed to be so annotated. If you
>> prefer to explicitly annotate it, you can.  (see comments below as to
>> where you would add the annotations)
>>
>> Consider this highly contrived (braindead) fragment of code below to
>> get a sense of what's possible with the patch:
>>
>> constexpr auto getFactorializer = [] {
>>   unsigned int optimization[6] = {};
>>
>>   auto for_each = [](auto *b, auto *e, auto pred) {
>>     auto *it = b;
>>     while (it != e) pred(it++ - b);
>>   };
>>
>>   for_each(optimization, optimization + 6, [&](int n) {
>>     if (!n) optimization[n] = 1;
>>     else
>>       optimization[n] = n * optimization[n-1];
>>   });
>>
>>   auto FacImpl = [=](auto fac, unsigned n) {
>>     if (n <= 5) return optimization[n];
>>     return n * fac(fac, n - 1);
>>   };
>>   auto Fact = [=](int n) {
>>     return FacImpl(FacImpl, n);
>>   };
>>   return Fact;
>> };
>>
>> constexpr auto Factorial = getFactorializer();
>>
>> static_assert(Factorial(5) == 120, "");
>> static_assert(Factorial(10) == 3628800, "");
>>
>>
>> To see further examples of test-case code that seems to work:
>>
>> https://github.com/faisalv/clang/blob/constexpr-lambdas/test/CXX/clambdas/cxx1z-constexpr-lambdas.cpp
>>
>> Some technicalities:
>>   - the conversion operator to fptr for a non-capturing lambda is
>> always constexpr
>>   - the closure type behaves as a literal type as long as all of its
>> capture 'data members' are literals (this can include other closure
>> objects)
>>   - the evaluation of a lambda expression is a
>> core-constant-expression if all the initializations of the captures
>> are core-constant-expressions
>>   - the constexprness of the call operator is deduced if not
>> explicitly specified
>>
>> I would certainly appreciate any useful feedback - especially if
>> anyone has the time to download the patch and play with it and report
>> any bugs (perceived or real) to me.
>>
>> And unless there is overwhelming well reasoned majority opposition to
>> this idea, I hope to help write a paper on this (I might reach out to
>> some of you for help - or if you're motivated please reach out to me),
>> and perhaps we can submit something for the lenexa mailing?
>>
>> Thanks!
>> Faisal Vali
>>
>> (*)The llvm revision to use is contained within the Readme file.
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_4494_1074399931.1428371573000
Content-Type: multipart/alternative;
 boundary="----=_Part_4495_1397136341.1428371573000"

------=_Part_4495_1397136341.1428371573000
Content-Type: text/plain; charset=UTF-8

On Wednesday, April 1, 2015 at 5:01:40 AM UTC-7, faisalv wrote:
>
> constexpr auto make_obj(int data) {
>    auto addL = [&] { return ++data; };
>    auto subL = [&] { return --data; };
>    struct {
>      decltype(addL) add;
>      decltype(subL) sub;
>    } ret = {addL, subL};
>   return ret;
> }
>
> constexpr auto Obj1 = make_obj(10);
> static_assert(Obj1.add() == 11, "");
> static_assert(Obj1.add() == 12, "");
> static_assert(Ob1.sub() == 11, "");
>
> auto RuntimeObj2 = Obj1.add(); // This will reliably cause your
> program to crash (but only if executed ;)
>
> Does anyone see any merit in proposing something like this?  My
> initial thought is that it introduces an asymmetry between compile
> time and run time computation that by itself makes this quite
> unattractive.
>

Why would that code be defined at compile time?  Access to an object whose
lifetime has ended ought to make that access not a constant-expression,
therefore making the static_assert ill-formed.

Melissa

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_4495_1397136341.1428371573000
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wednesday, April 1, 2015 at 5:01:40 AM UTC-7, faisalv w=
rote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;">constexpr auto make_obj(i=
nt data) {
<br>&nbsp; &nbsp;auto addL =3D [&amp;] { return ++data; };
<br>&nbsp; &nbsp;auto subL =3D [&amp;] { return --data; };
<br>&nbsp; &nbsp;struct {
<br>&nbsp; &nbsp; &nbsp;decltype(addL) add;
<br>&nbsp; &nbsp; &nbsp;decltype(subL) sub;
<br>&nbsp; &nbsp;} ret =3D {addL, subL};
<br>&nbsp; return ret;
<br>}
<br>
<br>constexpr auto Obj1 =3D make_obj(10);
<br>static_assert(Obj1.add() =3D=3D 11, "");
<br>static_assert(Obj1.add() =3D=3D 12, "");
<br>static_assert(Ob1.sub() =3D=3D 11, "");
<br>
<br>auto RuntimeObj2 =3D Obj1.add(); // This will reliably cause your
<br>program to crash (but only if executed ;)
<br>
<br>Does anyone see any merit in proposing something like this? &nbsp;My
<br>initial thought is that it introduces an asymmetry between compile
<br>time and run time computation that by itself makes this quite
<br>unattractive.<br></blockquote><div><br>Why would that code be defined a=
t compile time?&nbsp; Access to an object whose lifetime has ended ought to=
 make that access not a constant-expression, therefore making the static_as=
sert ill-formed.<br><br>Melissa<br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_4495_1397136341.1428371573000--
------=_Part_4494_1074399931.1428371573000--

.

[dropping c++-std-ext - FYI: EWG leadership has asked we not
cross-post to both groups in the future given the difference in
access]

On Mon, Apr 6, 2015 at 8:52 PM, Myriachan <myriachan@gmail.com> wrote:
> On Wednesday, April 1, 2015 at 5:01:40 AM UTC-7, faisalv wrote:
>>
>> constexpr auto make_obj(int data) {
>>    auto addL = [&] { return ++data; };
>>    auto subL = [&] { return --data; };
>>    struct {
>>      decltype(addL) add;
>>      decltype(subL) sub;
>>    } ret = {addL, subL};
>>   return ret;
>> }
>>
>> constexpr auto Obj1 = make_obj(10);
>> static_assert(Obj1.add() == 11, "");
>> static_assert(Obj1.add() == 12, "");
>> static_assert(Ob1.sub() == 11, "");
>>
>> auto RuntimeObj2 = Obj1.add(); // This will reliably cause your
>> program to crash (but only if executed ;)
>>
>> Does anyone see any merit in proposing something like this?  My
>> initial thought is that it introduces an asymmetry between compile
>> time and run time computation that by itself makes this quite
>> unattractive.
>
>
> Why would that code be defined at compile time?  Access to an object whose
> lifetime has ended ought to make that access not a constant-expression,
> therefore making the static_assert ill-formed.
>

Yes - it wouldn't make that access a 'constant expression' (in C++14).

But perhaps a different way to think about this is the following:
  - In C++ we have an abstract-machine (memory model, object model,
order of evaluations (including object creation, destruction,
side-effects) etc) and all executions/evaluations have to follow its
observable behavior.
  - If we want this abstract-machine to compute a vaue at
compile-time, the essential restriction should only be that the
complete input must be *determined* at compile-time (that is I/O can
not be interactive, although you could read from and write to files at
compile time etc.), whereas at run-time there is no such restriction.
  - Asides from that, there appears to be no theoretical restriction
to place on executions of the abstract machine at compile-time (for
e.g. we prohibit function local statics, exceptions, goto, using
volatile objects - but these are restrictions we placed because the
committee felt the language would be better that way - not because
there were inherent implementation concerns)
  - So just like at run-time where a function local static outlives
the execution that creates it, similarly at compile-time, the compiler
can extend the life-time of an object (created at compile-time) beyond
its scope and declared storage-duration.  It can do this obviously
without incurring a *run-time* penalty - you do pay for this extension
of the life-time of reference captures by generally slowing your
compiler down when executing compile-time code (at least based on one
obvious implementation strategy).  We could potentially also do this
at run-time, but that could incur a run-time cost even for code that
doesn't use these captures (which goes against the C++ philosophy of
'u shouldn't pay for what you don't use') - but if there is a way to
do this at run-time that does not penalize code (within the same
program) that doesn't use it - and incurs reasonable cost on code that
does  - then that makes the idea more palatable for discussion.

Anyways, given the asymmetry in the behavior of this feature
(well-defined at compile-time, undefined at run-time for ref captures)
- I doubt it will ever see the light of day in any production
implementation, in the near future.

Interestingly, it may be worth mentioning here that constexpr simply
implies that a function *probably* has a flow that could be executable
at compile-time  (i.e. it does not require the function to be
referentially transparent or stateless) - and I wonder if in that one
word (constexpr) we've conflated notions of 'pure' with 'immutable'
with 'compile-time-execution' more so than they deserve to be
conflated.



> Melissa

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

Faisal Vali <faisalv@gmail.com> writes:

[...]

| Interestingly, it may be worth mentioning here that constexpr simply
| implies that a function *probably* has a flow that could be executable
| at compile-time  (i.e. it does not require the function to be
| referentially transparent or stateless) - and I wonder if in that one
| word (constexpr) we've conflated notions of 'pure' with 'immutable'
| with 'compile-time-execution' more so than they deserve to be
| conflated.

No. Since day 1, 'constexpr' has always meant "something that can be
executed or evaluated at compile-time, with the proper condition;
e.g. call with constexpr arguments."   Phase distinction was also an
explicit design criteria: the compiler has no clue of load-time or
runtime addresses, so there are to be a distinction between those
entities.  This means, a symbolic representation for most data at
compile time.  'constexpr' on objects has always meant constant known at
compile time.  The C++14 relaxation were exactly in those lines --
finally bringing in facilities that WG21 couldn't stomach the first time
around.

'pure' is a pure (no pun intended) side effect of those design
criteria.  Not a desire to conflat anything.

Even Lisp, which allows arbitrary code at compile-time, has phase distinction: http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec/Body/speope_eval-when.html

It was a deliberate design decision to keep the explicit control of
phases out of source codes.  Overall, based on extended practical
experience with both C++ and Lisp, I believe the C++ design is much
saner and simpler for the working programmer.  If people want a general
metaprogramming framework, it should be *designed*.

-- Gaby


--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.