--001a113fb15c282a190531ecc03e
Content-Type: text/plain; charset=UTF-8

Unless this has been covered by a proposal that I have missed, there is no
way to do something like this:

auto f = [&f]{ f(); };

I believe the reason for this is that the type of f is not yet known within
the capture list.

Yet such a thing is expressible manually:

struct F
{
F &f;
F() : f(*this) {}
void operator()() { f(); }
} f;

Note that the full type F is not known, yet it is perfectly fine to use a
reference to it.

(I know that the code above is not optimal.)

A problem with the original (invalid) syntax and the manual (valid) syntax
is that both capture the original object by reference, which may become
invalid if the value is copied. What we really need is a way to refer to
'this' of the lambda's object. We cannot use just 'this' because that would
conflict with its normal use, as in a lambda defined in a member function.

Therefore we need a special way to refer to 'this' of the lambda's object.
I therefore propose:

1. Concept: *some* special syntax so that a lambda's body could refer to
'this' of the lambda's object.

2. Syntax: () is a reference to the lambda's object (the one currently
executing, which can be different from the one originally instantiated).

Example:

auto f = []{ ()(); };

auto g = [](int a){ ()(a); };

3. We could probably generalize the special syntax (not necessarily that of
#2) to be applicable to any function, such that the following

int f() { ()(); };

would be equivalent to

int f() { f(); };

Comments?

Cheers,
V.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg3WtXczNiR4q7023Q09Tf6N1d5XuO8jyHnPQuzf3Kzucw%40mail.gmail.com.

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

<div dir=3D"ltr">Unless this has been covered by a proposal that I have mis=
sed, there is no way to do something like this:<div><br></div><div>auto f =
=3D [&amp;f]{ f(); };</div><div><br></div><div>I believe the reason for thi=
s is that the type of f is not yet known within the capture list.</div><div=
><br></div><div>Yet such a thing is expressible manually:</div><div><br></d=
iv><div><div>struct F</div><div>{</div><div><span class=3D"" style=3D"white=
-space:pre"> </span>F &amp;f;</div><div><span class=3D"" style=3D"white-spa=
ce:pre"> </span>F() : f(*this) {}</div><div><span class=3D"" style=3D"white=
-space:pre"> </span>void operator()() { f(); }</div><div>} f;</div></div><d=
iv><br></div><div>Note that the full type F is not known, yet it is perfect=
ly fine to use a reference to it.<br></div><div><br></div><div>(I know that=
 the code above is not optimal.)<br></div><div><br></div><div>A problem wit=
h the original (invalid) syntax and the manual (valid) syntax is that both =
capture the original object by reference, which may become invalid if the v=
alue is copied. What we really need is a way to refer to &#39;this&#39; of =
the lambda&#39;s object. We cannot use just &#39;this&#39; because that wou=
ld conflict with its normal use, as in a lambda defined in a member functio=
n.</div><div><br></div><div>Therefore we need a special way to refer to &#3=
9;this&#39; of the lambda&#39;s object. I therefore propose:</div><div><br>=
</div><div>1. Concept: <i>some</i>=C2=A0special syntax so that a lambda&#39=
;s body could refer to &#39;this&#39; of the lambda&#39;s object.</div><div=
><br></div><div>2. Syntax: () is a reference to the lambda&#39;s object (th=
e one currently executing, which can be different from the one originally i=
nstantiated).</div><div><br></div><div>Example:</div><div><br></div><div>au=
to f =3D []{ ()(); };</div><div><br></div><div>auto g =3D [](int a){ ()(a);=
 };</div><div><br></div><div>3. We could probably generalize the special sy=
ntax (not necessarily that of #2) to be applicable to any function, such th=
at the following</div><div><br></div><div>int f() { ()(); };</div><div><br>=
</div><div>would be equivalent to=C2=A0</div><div><br></div><div>int f() { =
f(); };<br></div><div><br></div><div>Comments?<br></div><div><br></div><div=
>Cheers,</div><div>V.</div><div><br></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAA7YVg3WtXczNiR4q7023Q09Tf6N1d5XuO8j=
yHnPQuzf3Kzucw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg3WtXczNiR4=
q7023Q09Tf6N1d5XuO8jyHnPQuzf3Kzucw%40mail.gmail.com</a>.<br />

--001a113fb15c282a190531ecc03e--

.

--Apple-Mail=_5434B9C7-C547-4E0F-BF44-5E06D71C7E7A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2016=E2=80=9305=E2=80=9303, at 5:29 PM, Viacheslav Usov <via.usov@gmai=
l.com> wrote:
>=20
> Unless this has been covered by a proposal that I have missed, there is n=
o way to do something like this:
>=20
> auto f =3D [&f]{ f(); };

There was a library proposal for a function template implementing a fixed-p=
oint combinator (=E2=80=9Cthe Y combinator=E2=80=9D). It did not find much =
support, but the idea works without too much trouble:

    auto f =3D recursively( [&]( auto && recurse, int arg ) { return recurs=
e( arg ); } );

Any language extension should look at least as good.

> 2. Syntax: () is a reference to the lambda's object (the one currently ex=
ecuting, which can be different from the one originally instantiated).
>=20
> Example:
>=20
> auto f =3D []{ ()(); };

This syntax is lacking in exposition. At a glance, it doesn=E2=80=99t look =
like a function call.

--=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/5A7A2B8A-F91A-4996-91F2-1532312BD08D%40gmail.com=
..

--Apple-Mail=_5434B9C7-C547-4E0F-BF44-5E06D71C7E7A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><div class=3D""><b=
r class=3D""></div><div><blockquote type=3D"cite" class=3D""><div class=3D"=
">On 2016=E2=80=9305=E2=80=9303, at 5:29 PM, Viacheslav Usov &lt;<a href=3D=
"mailto:via.usov@gmail.com" class=3D"">via.usov@gmail.com</a>&gt; wrote:</d=
iv><br class=3D"Apple-interchange-newline"><div class=3D""><div dir=3D"ltr"=
 class=3D"">Unless this has been covered by a proposal that I have missed, =
there is no way to do something like this:<div class=3D""><br class=3D""></=
div><div class=3D"">auto f =3D [&amp;f]{ f(); };</div></div></div></blockqu=
ote><div><br class=3D""></div><div class=3D"">There was a library proposal =
for a function template implementing a fixed-point combinator (=E2=80=9Cthe=
 Y combinator=E2=80=9D). It did not find much support, but the idea works w=
ithout too much trouble:</div><div class=3D""><br class=3D""></div><div cla=
ss=3D""><font face=3D"Courier" class=3D"">&nbsp; &nbsp; auto f =3D recursiv=
ely( [&amp;]( auto &amp;&amp; recurse, int arg ) { return recurse( arg ); }=
 );</font></div><div class=3D""><br class=3D""></div><div class=3D"">Any la=
nguage extension should look at least as good.</div><div class=3D""><br cla=
ss=3D""></div><blockquote type=3D"cite" class=3D""><div dir=3D"ltr" class=
=3D""><div class=3D"">2. Syntax: () is a reference to the lambda's object (=
the one currently executing, which can be different from the one originally=
 instantiated).</div><div class=3D""><br class=3D""></div><div class=3D"">E=
xample:</div><div class=3D""><br class=3D""></div><div class=3D"">auto f =
=3D []{ ()(); };</div></div></blockquote><div><br class=3D""></div><div>Thi=
s syntax is lacking in exposition. At a glance, it doesn=E2=80=99t look lik=
e a function call.</div></div><br class=3D""></body></html>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/5A7A2B8A-F91A-4996-91F2-1532312BD08D%=
40gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/5A7A2B8A-F91A-4996-91F2-1532312BD08D%=
40gmail.com</a>.<br />

--Apple-Mail=_5434B9C7-C547-4E0F-BF44-5E06D71C7E7A--

.

--001a1139c222ec5dd50531eef950
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Being able to recursively call lambdas would be useful to me.

It would be good to see a language solution broad enough to encompass the
'overload' objects proposed by

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0051r0.pdf

in code:
```
auto o =3D overload(
  [](int i){ /* handle int*/ },
  [](std::vector<int>&){ /* handle vector of int through recursive call to
overload object to handle int*/});

std::vector<int> xs =3D {1,2,3,4,5,6};
o(xs);

```

I agree with David that the proposed `()` syntax is not explicit enough,
but have no nicer suggestions.

Best,

Jon

On 3 May 2016 at 12:58, David Krauss <potswa@gmail.com> wrote:

>
> On 2016=E2=80=9305=E2=80=9303, at 5:29 PM, Viacheslav Usov <via.usov@gmai=
l.com> wrote:
>
> Unless this has been covered by a proposal that I have missed, there is n=
o
> way to do something like this:
>
> auto f =3D [&f]{ f(); };
>
>
> There was a library proposal for a function template implementing a
> fixed-point combinator (=E2=80=9Cthe Y combinator=E2=80=9D). It did not f=
ind much support,
> but the idea works without too much trouble:
>
>     auto f =3D recursively( [&]( auto && recurse, int arg ) { return
> recurse( arg ); } );
>
> Any language extension should look at least as good.
>
> 2. Syntax: () is a reference to the lambda's object (the one currently
> executing, which can be different from the one originally instantiated).
>
> Example:
>
> auto f =3D []{ ()(); };
>
>
> This syntax is lacking in exposition. At a glance, it doesn=E2=80=99t loo=
k like a
> function call.
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/5A7A2B8A-F91=
A-4996-91F2-1532312BD08D%40gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/5A7A2B8A-F9=
1A-4996-91F2-1532312BD08D%40gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r>
> .
>

--=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAAbBDD_K_%2BDjgEbRB8s9yCt-YW5fA3%3D7H3m4-ZpQ7_i=
iq5rQxg%40mail.gmail.com.

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

<div dir=3D"ltr">Being able to recursively call lambdas would be useful to =
me.<div><br></div><div>It would be good to see a language solution broad en=
ough to encompass the &#39;overload&#39; objects proposed by</div><div><br>=
</div><div><a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/20=
15/p0051r0.pdf">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p00=
51r0.pdf</a><br></div><div><br></div><div>in code:</div><div>```</div><div>=
auto o =3D overload(</div><div>=C2=A0 [](int i){ /* handle int*/ },=C2=A0</=
div><div>=C2=A0 [](std::vector&lt;int&gt;&amp;){ /* handle vector of int th=
rough recursive call to overload object to handle int*/});</div><div><br></=
div><div>std::vector&lt;int&gt; xs =3D {1,2,3,4,5,6};</div><div>o(xs);</div=
><div><br></div><div>```</div><div><br></div><div>I agree with David that t=
he proposed `()` syntax is not explicit enough, but have no nicer suggestio=
ns.</div><div><br></div><div>Best,</div><div><br></div><div>Jon</div></div>=
<div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On 3 May 2016 at =
12:58, David Krauss <span dir=3D"ltr">&lt;<a href=3D"mailto:potswa@gmail.co=
m" target=3D"_blank">potswa@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"><div style=3D"word-wrap:break-word"><div><br></div><div>=
<span class=3D""><blockquote type=3D"cite"><div>On 2016=E2=80=9305=E2=80=93=
03, at 5:29 PM, Viacheslav Usov &lt;<a href=3D"mailto:via.usov@gmail.com" t=
arget=3D"_blank">via.usov@gmail.com</a>&gt; wrote:</div><br><div><div dir=
=3D"ltr">Unless this has been covered by a proposal that I have missed, the=
re is no way to do something like this:<div><br></div><div>auto f =3D [&amp=
;f]{ f(); };</div></div></div></blockquote><div><br></div></span><div>There=
 was a library proposal for a function template implementing a fixed-point =
combinator (=E2=80=9Cthe Y combinator=E2=80=9D). It did not find much suppo=
rt, but the idea works without too much trouble:</div><div><br></div><div><=
font face=3D"Courier">=C2=A0 =C2=A0 auto f =3D recursively( [&amp;]( auto &=
amp;&amp; recurse, int arg ) { return recurse( arg ); } );</font></div><div=
><br></div><div>Any language extension should look at least as good.</div><=
span class=3D""><div><br></div><blockquote type=3D"cite"><div dir=3D"ltr"><=
div>2. Syntax: () is a reference to the lambda&#39;s object (the one curren=
tly executing, which can be different from the one originally instantiated)=
..</div><div><br></div><div>Example:</div><div><br></div><div>auto f =3D []{=
 ()(); };</div></div></blockquote><div><br></div></span><div>This syntax is=
 lacking in exposition. At a glance, it doesn=E2=80=99t look like a functio=
n call.</div></div><br></div><span class=3D"">

<p></p>

-- <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" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/5A7A2B8A-F91A-4996-91F2-1532312BD08D%=
40gmail.com?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/5A7A2B8A-F91A-4=
996-91F2-1532312BD08D%40gmail.com</a>.<br>
</blockquote></div><br></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAAbBDD_K_%2BDjgEbRB8s9yCt-YW5fA3%3D7=
H3m4-ZpQ7_iiq5rQxg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAAbBDD_K_%2B=
DjgEbRB8s9yCt-YW5fA3%3D7H3m4-ZpQ7_iiq5rQxg%40mail.gmail.com</a>.<br />

--001a1139c222ec5dd50531eef950--

.

--001a11402cb850b0140531f23292
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tue, May 3, 2016 at 1:58 PM, David Krauss <potswa@gmail.com> wrote:

>
> On 2016=E2=80=9305=E2=80=9303, at 5:29 PM, Viacheslav Usov <via.usov@gmai=
l.com> wrote:
>
> Unless this has been covered by a proposal that I have missed, there is n=
o
> way to do something like this:
>
> auto f =3D [&f]{ f(); };
>
>
> There was a library proposal for a function template implementing a
> fixed-point combinator (=E2=80=9Cthe Y combinator=E2=80=9D). It did not f=
ind much support,
> but the idea works without too much trouble:
>
>     auto f =3D recursively( [&]( auto && recurse, int arg ) { return
> recurse( arg ); } );
>
> Any language extension should look at least as good.
>

We could do something like this:

[] this =3D f { f(); }

where 'this' would introduce a name for lambda's object; we could even say
that the =3D f part is optional and if omitted, then this is available in t=
he
object as the name (and if that clashes with the capture list, then the
expression is malformed). In the latter case one would have to write
this(x, y, z); I am not sure whether this is really good or bad.

Still, I thought () would actually *seem* like something very *functional* =
was
happening, so it is somewhat surprising to hear otherwise. Somehow I keep
thinking about *more* brevity, as in

[] (auto n) { return n ? .(n - 1) : 1; }

where the dot means 'this' as it frequently does in certain contexts.

Cheers,
V.

--=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAA7YVg0YS6U8wK1wft9JtVywA9Uyci8nwnMS9qFrzv5z_Jn=
dMw%40mail.gmail.com.

--001a11402cb850b0140531f23292
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=
ue, May 3, 2016 at 1:58 PM, David Krauss <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:potswa@gmail.com" target=3D"_blank">potswa@gmail.com</a>&gt;</span> w=
rote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div style=3D"word-wrap:break-word"=
><div><br></div><div><blockquote type=3D"cite"><div>On 2016=E2=80=9305=E2=
=80=9303, at 5:29 PM, Viacheslav Usov &lt;<a href=3D"mailto:via.usov@gmail.=
com" target=3D"_blank">via.usov@gmail.com</a>&gt; wrote:</div><br><div><div=
 dir=3D"ltr">Unless this has been covered by a proposal that I have missed,=
 there is no way to do something like this:<div><br></div><div>auto f =3D [=
&amp;f]{ f(); };</div></div></div></blockquote><div><br></div><div>There wa=
s a library proposal for a function template implementing a fixed-point com=
binator (=E2=80=9Cthe Y combinator=E2=80=9D). It did not find much support,=
 but the idea works without too much trouble:</div><div><br></div><div><fon=
t face=3D"Courier">=C2=A0 =C2=A0 auto f =3D recursively( [&amp;]( auto &amp=
;&amp; recurse, int arg ) { return recurse( arg ); } );</font></div><div><b=
r></div><div>Any language extension should look at least as good.</div></di=
v></div></blockquote><div><br></div><div>We could do something like this:</=
div><div><br></div><div>[] this =3D f { f(); }<br></div><div><br></div><div=
>where &#39;this&#39; would introduce a name for lambda&#39;s object; we co=
uld even say that the =3D f part is optional and if omitted, then this is a=
vailable in the object as the name (and if that clashes with the capture li=
st, then the expression is malformed). In the latter case one would have to=
 write this(x, y, z); I am not sure whether this is really good or bad.</di=
v><div><br></div><div>Still, I thought () would actually <i>seem</i>=C2=A0l=
ike something very <i>functional</i>=C2=A0was happening, so it is somewhat =
surprising to hear otherwise. Somehow I keep thinking about <i>more</i>=C2=
=A0brevity, as in</div><div><br></div><div>[] (auto n) { return n ? .(n - 1=
) : 1; }</div><div><br></div><div>where the dot means &#39;this&#39; as it =
frequently does in certain contexts.</div><div><br></div><div>Cheers,</div>=
<div>V.</div><div><br></div></div></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAA7YVg0YS6U8wK1wft9JtVywA9Uyci8nwnMS=
9qFrzv5z_JndMw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg0YS6U8wK1w=
ft9JtVywA9Uyci8nwnMS9qFrzv5z_JndMw%40mail.gmail.com</a>.<br />

--001a11402cb850b0140531f23292--

.

--14dae947391502137d0531f2e201
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 3 May 2016 at 12:58, David Krauss <potswa@gmail.com> wrote:

>
> On 2016=E2=80=9305=E2=80=9303, at 5:29 PM, Viacheslav Usov <via.usov@gmai=
l.com> wrote:
>
> Unless this has been covered by a proposal that I have missed, there is n=
o
> way to do something like this:
>
> auto f =3D [&f]{ f(); };
>
>
> There was a library proposal for a function template implementing a
> fixed-point combinator (=E2=80=9Cthe Y combinator=E2=80=9D). It did not f=
ind much support,
> but the idea works without too much trouble:
>
>     auto f =3D recursively( [&]( auto && recurse, int arg ) { return
> recurse( arg ); } );
>
> Any language extension should look at least as good.
>

i like this, not least because it's basically exactly how haskell handles
this: http://stackoverflow.com/a/7141256

--=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAHK%2B-Fsio9QvUgOf6ouH%3Dq0iCe0AeMGPuwpSvspjGsj=
Fxz9t0A%40mail.gmail.com.

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

<div dir=3D"ltr">On 3 May 2016 at 12:58, David Krauss <span dir=3D"ltr">&lt=
;<a href=3D"mailto:potswa@gmail.com" target=3D"_blank">potswa@gmail.com</a>=
&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote"=
><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border=
-left:1px solid rgb(204,204,204);padding-left:1ex"><div style=3D"word-wrap:=
break-word"><div><br></div><div><span class=3D""><blockquote type=3D"cite">=
<div>On 2016=E2=80=9305=E2=80=9303, at 5:29 PM, Viacheslav Usov &lt;<a href=
=3D"mailto:via.usov@gmail.com" target=3D"_blank">via.usov@gmail.com</a>&gt;=
 wrote:</div><br><div><div dir=3D"ltr">Unless this has been covered by a pr=
oposal that I have missed, there is no way to do something like this:<div><=
br></div><div>auto f =3D [&amp;f]{ f(); };</div></div></div></blockquote><d=
iv><br></div></span><div>There was a library proposal for a function templa=
te implementing a fixed-point combinator (=E2=80=9Cthe Y combinator=E2=80=
=9D). It did not find much support, but the idea works without too much tro=
uble:</div><div><br></div><div><font face=3D"Courier">=C2=A0 =C2=A0 auto f =
=3D recursively( [&amp;]( auto &amp;&amp; recurse, int arg ) { return recur=
se( arg ); } );</font></div><div><br></div><div>Any language extension shou=
ld look at least as good.</div></div></div></blockquote><div><br></div><div=
>i like this, not least because it&#39;s basically exactly how haskell hand=
les this: <a href=3D"http://stackoverflow.com/a/7141256">http://stackoverfl=
ow.com/a/7141256</a> <br></div></div></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAHK%2B-Fsio9QvUgOf6ouH%3Dq0iCe0AeMGP=
uwpSvspjGsjFxz9t0A%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHK%2B-Fsio9=
QvUgOf6ouH%3Dq0iCe0AeMGPuwpSvspjGsjFxz9t0A%40mail.gmail.com</a>.<br />

--14dae947391502137d0531f2e201--

.

--001a1140160c09c6b6053206b9ba
Content-Type: text/plain; charset=UTF-8

On Tue, May 3, 2016 at 5:59 PM, Viacheslav Usov <via.usov@gmail.com> wrote:

> In the latter case one would have to write this(x, y, z); I am not sure
whether this is really good or bad.

Thinking more about it, a syntax like

this(x, y, z)

is currently ill-formed in any context, because 'this' is not a function or
a function pointer. Consequently, this form can be specified to mean,
within the body of a lambda, a recursive call to the lambda's operator().
We can refer to this form as the "this-call". Example:

auto f = [](int n)
{
    if (n == 0)
        return 1;

    return n * this(n - 1);
};

Even if 'this' is captured from an outer scope, a "this-call" has the
meaning defined above. Any other use of 'this' is interpreted as one
involving the "ordinary" this pointer (which then must have been captured).

The above alone is sufficient to write recursive lambdas. One thing I am
not so sure about is the return type deduction. Would we need to make any
provisions beyond the generalized return type deduction of C++14?

Cheers,
V.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg3f5iB9wu2eZ7BAJ2fW9jziQwsRoma0sgb-wp9rPSXR4A%40mail.gmail.com.

--001a1140160c09c6b6053206b9ba
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=
ue, May 3, 2016 at 5:59 PM, Viacheslav Usov <span dir=3D"ltr">&lt;<a href=
=3D"mailto:via.usov@gmail.com" target=3D"_blank">via.usov@gmail.com</a>&gt;=
</span> wrote:</div><div class=3D"gmail_quote"><br></div><div class=3D"gmai=
l_quote">&gt; In the latter case one would have to write this(x, y, z); I a=
m not sure whether this is really good or bad.</div><div class=3D"gmail_quo=
te"><br></div><div class=3D"gmail_quote">Thinking more about it, a syntax l=
ike</div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">th=
is(x, y, z)</div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_q=
uote">is currently ill-formed in any context, because &#39;this&#39; is not=
 a function or a function pointer. Consequently, this form can be specified=
 to mean, within the body of a lambda, a recursive call to the lambda&#39;s=
 operator(). We can refer to this form as the &quot;this-call&quot;. Exampl=
e:</div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">aut=
o f =3D [](int n)</div><div class=3D"gmail_quote">{</div><div class=3D"gmai=
l_quote">=C2=A0 =C2=A0 if (n =3D=3D 0)</div><div class=3D"gmail_quote">=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 return 1;</div><div class=3D"gmail_quote"><br></di=
v><div class=3D"gmail_quote">=C2=A0 =C2=A0 return n * this(n - 1);</div><di=
v class=3D"gmail_quote">};</div><div class=3D"gmail_quote"><br></div><div c=
lass=3D"gmail_quote">Even if &#39;this&#39; is captured from an outer scope=
, a &quot;this-call&quot; has the meaning defined above. Any other use of &=
#39;this&#39; is interpreted as one involving the &quot;ordinary&quot; this=
 pointer (which then must have been captured).</div><div class=3D"gmail_quo=
te"><br></div><div class=3D"gmail_quote">The above alone is sufficient to w=
rite recursive lambdas. One thing I am not so sure about is the return type=
 deduction. Would we need to make any provisions beyond the generalized ret=
urn type deduction of C++14?<br></div><div class=3D"gmail_quote"><br></div>=
<div class=3D"gmail_quote">Cheers,</div><div class=3D"gmail_quote">V.</div>=
</div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAA7YVg3f5iB9wu2eZ7BAJ2fW9jziQwsRoma0=
sgb-wp9rPSXR4A%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg3f5iB9wu2e=
Z7BAJ2fW9jziQwsRoma0sgb-wp9rPSXR4A%40mail.gmail.com</a>.<br />

--001a1140160c09c6b6053206b9ba--

.

On quarta-feira, 4 de maio de 2016 18:28:59 PDT Viacheslav Usov wrote:
> Thinking more about it, a syntax like
>
> this(x, y, z)
>
> is currently ill-formed in any context, because 'this' is not a function or
> a function pointer. Consequently, this form can be specified to mean,
> within the body of a lambda, a recursive call to the lambda's operator().
> We can refer to this form as the "this-call".

What's decltype(this) ?

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/12200502.jnC8Wc1Rj7%40tjmaciei-mobl4.

.

--001a113eb08e391e680532075ddb
Content-Type: text/plain; charset=UTF-8

On Wed, May 4, 2016 at 7:10 PM, Thiago Macieira <thiago@macieira.org> wrote:

> What's decltype(this) ?

As said in the part of my message that you did not quote: "Any other use of
'this' is interpreted as one involving the "ordinary" this pointer (which
then must have been captured)."

Other there means other than the proposed this-call syntax.

Cheers,
V.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg1sqt6947jMnw%2BE3R4E83QC5nnf%2Bc_Zx0yr6AYXd1%3DAzQ%40mail.gmail.com.

--001a113eb08e391e680532075ddb
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 W=
ed, May 4, 2016 at 7:10 PM, Thiago Macieira <span dir=3D"ltr">&lt;<a href=
=3D"mailto:thiago@macieira.org" target=3D"_blank">thiago@macieira.org</a>&g=
t;</span> wrote:</div><div class=3D"gmail_quote"><br></div><div class=3D"gm=
ail_quote">&gt; What&#39;s decltype(this) ?</div><div class=3D"gmail_quote"=
><br></div><div class=3D"gmail_quote">As said in the part of my message tha=
t you did not quote: &quot;<span style=3D"font-size:12.8px">Any other use o=
f &#39;this&#39; is interpreted as one involving the &quot;ordinary&quot; t=
his pointer (which then must have been captured).&quot;</span></div><div cl=
ass=3D"gmail_quote"><span style=3D"font-size:12.8px"><br></span></div><div =
class=3D"gmail_quote"><span style=3D"font-size:12.8px">Other there means ot=
her than the proposed this-call syntax.</span></div><div class=3D"gmail_quo=
te"><span style=3D"font-size:12.8px"><br></span></div><div class=3D"gmail_q=
uote"><span style=3D"font-size:12.8px">Cheers,</span></div><div class=3D"gm=
ail_quote"><span style=3D"font-size:12.8px">V.</span></div></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAA7YVg1sqt6947jMnw%2BE3R4E83QC5nnf%2=
Bc_Zx0yr6AYXd1%3DAzQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg1sqt=
6947jMnw%2BE3R4E83QC5nnf%2Bc_Zx0yr6AYXd1%3DAzQ%40mail.gmail.com</a>.<br />

--001a113eb08e391e680532075ddb--

.

------=_Part_4522_1197723510.1462384382116
Content-Type: multipart/alternative;
 boundary="----=_Part_4523_770321414.1462384382116"

------=_Part_4523_770321414.1462384382116
Content-Type: text/plain; charset=UTF-8



On Wednesday, May 4, 2016 at 1:14:55 PM UTC-4, Viacheslav Usov wrote:
>
> On Wed, May 4, 2016 at 7:10 PM, Thiago Macieira <thi...@macieira.org
> <javascript:>> wrote:
>
> > What's decltype(this) ?
>
> As said in the part of my message that you did not quote: "Any other use
> of 'this' is interpreted as one involving the "ordinary" this pointer
> (which then must have been captured)."
>
> Other there means other than the proposed this-call syntax.
>

That makes for exceedingly bizarre syntax. You're saying that
`decltype(expr)` may resolve to something which is completely incompatible
with `expr(...)`.

That sounds like someone clearly grasping for syntax.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/d5b4534d-cef2-45c5-90b5-7ef06b5b468c%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Wednesday, May 4, 2016 at 1:14:55 PM UTC-4, Via=
cheslav Usov wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D=
"ltr"><div><div class=3D"gmail_quote">On Wed, May 4, 2016 at 7:10 PM, Thiag=
o Macieira <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" =
gdf-obfuscated-mailto=3D"2KAFO80qBgAJ" rel=3D"nofollow" onmousedown=3D"this=
..href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;jav=
ascript:&#39;;return true;">thi...@macieira.org</a>&gt;</span> wrote:</div>=
<div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">&gt; What&#=
39;s decltype(this) ?</div><div class=3D"gmail_quote"><br></div><div class=
=3D"gmail_quote">As said in the part of my message that you did not quote: =
&quot;<span style=3D"font-size:12.8px">Any other use of &#39;this&#39; is i=
nterpreted as one involving the &quot;ordinary&quot; this pointer (which th=
en must have been captured).&quot;</span></div><div class=3D"gmail_quote"><=
span style=3D"font-size:12.8px"><br></span></div><div class=3D"gmail_quote"=
><span style=3D"font-size:12.8px">Other there means other than the proposed=
 this-call syntax.</span></div></div></div></blockquote><div><br>That makes=
 for exceedingly bizarre syntax. You&#39;re saying that `decltype(expr)` ma=
y resolve to something which is completely incompatible with `expr(...)`.<b=
r><br>That sounds like someone clearly grasping for syntax.<br></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/d5b4534d-cef2-45c5-90b5-7ef06b5b468c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d5b4534d-cef2-45c5-90b5-7ef06b5b468c=
%40isocpp.org</a>.<br />

------=_Part_4523_770321414.1462384382116--
------=_Part_4522_1197723510.1462384382116--

.

--001a11402cb8e5a02e0532083d45
Content-Type: text/plain; charset=UTF-8

On Wed, May 4, 2016 at 7:53 PM, Nicol Bolas <jmckesson@gmail.com> wrote:

> That makes for exceedingly bizarre syntax. You're saying that
`decltype(expr)` may resolve to something which is completely incompatible
with `expr(...)`.

That is the normal case in C++. decltype(1) resolves to something which is
completely incompatible with 1(...).

> That sounds like someone clearly grasping for syntax.

Illogical.

Cheers,
V.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg064_g8MxQbD%3DV36Vv6uM%2BBywTxJFRXkTr%2Bkg4Gu_BUzA%40mail.gmail.com.

--001a11402cb8e5a02e0532083d45
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 W=
ed, May 4, 2016 at 7:53 PM, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</sp=
an> wrote:</div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_qu=
ote">&gt; That makes for exceedingly bizarre syntax. You&#39;re saying that=
 `decltype(expr)` may resolve to something which is completely incompatible=
 with `expr(...)`.</div><div class=3D"gmail_quote"><br></div><div class=3D"=
gmail_quote">That is the normal case in C++. decltype(1) resolves to someth=
ing which is completely incompatible with 1(...).</div><div class=3D"gmail_=
quote"><br></div><div class=3D"gmail_quote">&gt; That sounds like someone c=
learly grasping for syntax.</div><div class=3D"gmail_quote"><br></div><div =
class=3D"gmail_quote">Illogical.</div><div class=3D"gmail_quote"><br></div>=
<div class=3D"gmail_quote">Cheers,</div><div class=3D"gmail_quote">V.</div>=
</div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAA7YVg064_g8MxQbD%3DV36Vv6uM%2BBywTx=
JFRXkTr%2Bkg4Gu_BUzA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg064_=
g8MxQbD%3DV36Vv6uM%2BBywTxJFRXkTr%2Bkg4Gu_BUzA%40mail.gmail.com</a>.<br />

--001a11402cb8e5a02e0532083d45--

.

------=_Part_3721_1858528362.1462386617008
Content-Type: multipart/alternative;
 boundary="----=_Part_3722_633257916.1462386617009"

------=_Part_3722_633257916.1462386617009
Content-Type: text/plain; charset=UTF-8



On Wednesday, May 4, 2016 at 2:17:45 PM UTC-4, Viacheslav Usov wrote:
>
> On Wed, May 4, 2016 at 7:53 PM, Nicol Bolas <jmck...@gmail.com
> <javascript:>> wrote:
>
> > That makes for exceedingly bizarre syntax. You're saying that
> `decltype(expr)` may resolve to something which is completely incompatible
> with `expr(...)`.
>
> That is the normal case in C++. decltype(1) resolves to something which is
> completely incompatible with 1(...).
>

OK fine Mr. Pedant:

You're saying that `decltype(expr)` may resolve to something which is
> completely incompatible with `expr(...)`, but you still want `expr(...)` to
> be legal syntax.
>

Alternatively, `(this)()` should be no different from `this()`. Yet what
you propose would require this, because your `this()` syntax is not based
on an `this` being an expression. It's based on it being the keyword `this`.

No, if you want to have recursive lambdas, you're going to have to find a
better way to do it.

> That sounds like someone clearly grasping for syntax.
>
> Illogical.
>

.... it takes a special kind of logic to suggest that someone is being
illogical, while simultaneously proposing that it's perfectly sensible for
`this()` to behave in a way that is completely inconsistent with *every
other use* of `this`.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b03e9e4c-049d-4519-ad4e-a06d588680f6%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Wednesday, May 4, 2016 at 2:17:45 PM UTC-4, Via=
cheslav Usov wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D=
"ltr"><div><div class=3D"gmail_quote">On Wed, May 4, 2016 at 7:53 PM, Nicol=
 Bolas <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-=
obfuscated-mailto=3D"WLj49zouBgAJ" rel=3D"nofollow" onmousedown=3D"this.hre=
f=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascr=
ipt:&#39;;return true;">jmck...@gmail.com</a>&gt;</span> wrote:</div><div c=
lass=3D"gmail_quote"><br></div><div class=3D"gmail_quote">&gt; That makes f=
or exceedingly bizarre syntax. You&#39;re saying that `decltype(expr)` may =
resolve to something which is completely incompatible with `expr(...)`.</di=
v><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">That is t=
he normal case in C++. decltype(1) resolves to something which is completel=
y incompatible with 1(...).</div></div></div></blockquote><div><br>OK fine =
Mr. Pedant:<br><br><blockquote style=3D"margin: 0px 0px 0px 0.8ex; border-l=
eft: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class=3D"gmail_quote=
">You&#39;re saying that `decltype(expr)` may resolve to something which is=
 completely incompatible with `expr(...)`, but you still want `expr(...)` t=
o be legal syntax.<br></blockquote><br>Alternatively, `(this)()` should be =
no different from `this()`. Yet what you propose would require this, becaus=
e your `this()` syntax is not based on an `this` being an expression. It&#3=
9;s based on it being the keyword `this`.<br><br>No, if you want to have re=
cursive lambdas, you&#39;re going to have to find a better way to do it.<br=
><br></div><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">&gt; That sounds like someone clearly graspin=
g for syntax.</div><div class=3D"gmail_quote"><br></div><div class=3D"gmail=
_quote">Illogical.</div></div></div></blockquote><div><br>... it takes a sp=
ecial kind of logic to suggest that someone is being illogical, while simul=
taneously proposing that it&#39;s perfectly sensible for `this()` to behave=
 in a way that is completely inconsistent with <i>every other use</i> of `t=
his`.<br></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/b03e9e4c-049d-4519-ad4e-a06d588680f6%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b03e9e4c-049d-4519-ad4e-a06d588680f6=
%40isocpp.org</a>.<br />

------=_Part_3722_633257916.1462386617009--
------=_Part_3721_1858528362.1462386617008--

.

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

On Wed, May 4, 2016 at 8:30 PM, Nicol Bolas <jmckesson@gmail.com> wrote:

> Alternatively, `(this)()` should be no different from `this()`.

Why *should* it?

> Yet what you propose would require this, because your `this()` syntax is
not based on an `this` being an expression. It's based on it being the
keyword `this`.

Yes and yes.

> No, if you want to have recursive lambdas, you're going to have to find a
better way to do it.

I have mentioned a few other options. Yet, can you explain why this() is
bad without resorting to ad hoc assumptions?

> ... it takes a special kind of logic to suggest that someone is being
illogical, while simultaneously proposing that it's perfectly sensible for
`this()` to behave in a way that is completely inconsistent with *every
other use* of `this`.

One could say the exact same thing about [] when it was being introduced
for lambdas. The latter felt a little weird initially, and my proposal felt
a little weird initially even to myself. I did try to ensure that the
proposed syntax would in no way affect or be affected by *every other use* of
`this`. The proposal is self-consistent as far as I can tell.

Cheers,
V.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg3ebPar2ezMvd0p--U0WoSe18XbLT5D6rP-OOGx4JP-iw%40mail.gmail.com.

--047d7b3a8f4a12506c053209108d
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 W=
ed, May 4, 2016 at 8:30 PM, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</sp=
an> wrote:<br><div><br></div><div>&gt; Alternatively, `(this)()` should be =
no different from `this()`.</div><div><br></div><div>Why <i>should</i>=C2=
=A0it?</div><div><br></div><div>&gt; Yet what you propose would require thi=
s, because your `this()` syntax is not based on an `this` being an expressi=
on. It&#39;s based on it being the keyword `this`.</div><div><br></div><div=
>Yes and yes.</div><div><br></div><div>&gt; No, if you want to have recursi=
ve lambdas, you&#39;re going to have to find a better way to do it.</div><d=
iv><br></div><div>I have mentioned a few other options. Yet, can you explai=
n why this() is bad without resorting to ad hoc assumptions?</div><div><br>=
</div><div>&gt; ... it takes a special kind of logic to suggest that someon=
e is being illogical, while simultaneously proposing that it&#39;s perfectl=
y sensible for `this()` to behave in a way that is completely inconsistent =
with <i>every other use</i> of `this`.</div><div><br></div><div>One could s=
ay the exact same thing about [] when it was being introduced for lambdas. =
The latter felt a little weird initially, and my proposal felt a little wei=
rd initially even to myself. I did try to ensure that the proposed syntax w=
ould in no way affect or be affected by=C2=A0<i>every other use</i>=C2=A0of=
 `this`. The proposal is self-consistent as far as I can tell.</div><div><b=
r></div><div>Cheers,</div><div>V.</div><div><br></div></div></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAA7YVg3ebPar2ezMvd0p--U0WoSe18XbLT5D=
6rP-OOGx4JP-iw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg3ebPar2ezM=
vd0p--U0WoSe18XbLT5D6rP-OOGx4JP-iw%40mail.gmail.com</a>.<br />

--047d7b3a8f4a12506c053209108d--

.

--94eb2c05947eb4626005320a1cd6
Content-Type: text/plain; charset=UTF-8

I realize that we're discussing a more in-language solution, but I do this
(figuratively) and it works great:

std::function<int(int)> fibonacci;

fibonacci = [](int x) -> int {
    if (x == 1) {
        return 1;
    } else {
        return fibonacci(x-1) + fibonacci(x-2);
    }
}


On Wed, May 4, 2016 at 12:16 PM, Viacheslav Usov <via.usov@gmail.com> wrote:

> On Wed, May 4, 2016 at 8:30 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
>
> > Alternatively, `(this)()` should be no different from `this()`.
>
> Why *should* it?
>
> > Yet what you propose would require this, because your `this()` syntax is
> not based on an `this` being an expression. It's based on it being the
> keyword `this`.
>
> Yes and yes.
>
> > No, if you want to have recursive lambdas, you're going to have to find
> a better way to do it.
>
> I have mentioned a few other options. Yet, can you explain why this() is
> bad without resorting to ad hoc assumptions?
>
> > ... it takes a special kind of logic to suggest that someone is being
> illogical, while simultaneously proposing that it's perfectly sensible for
> `this()` to behave in a way that is completely inconsistent with *every
> other use* of `this`.
>
> One could say the exact same thing about [] when it was being introduced
> for lambdas. The latter felt a little weird initially, and my proposal felt
> a little weird initially even to myself. I did try to ensure that the
> proposed syntax would in no way affect or be affected by *every other use* of
> `this`. The proposal is self-consistent as far as I can tell.
>
> Cheers,
> V.
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg3ebPar2ezMvd0p--U0WoSe18XbLT5D6rP-OOGx4JP-iw%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg3ebPar2ezMvd0p--U0WoSe18XbLT5D6rP-OOGx4JP-iw%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHJ4w5ppn6EY19SZ9Dz3P6krp2zqKzegRd-%2BLpQQyu5OjPOvng%40mail.gmail.com.

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

<div dir=3D"ltr">I realize that we&#39;re discussing a more in-language sol=
ution, but I do this (figuratively) and it works great:<div><br></div><div>=
<font face=3D"monospace, monospace">std::function&lt;int(int)&gt; fibonacci=
;</font></div><div><font face=3D"monospace, monospace"><br></font></div><di=
v><font face=3D"monospace, monospace">fibonacci =3D [](int x) -&gt; int {</=
font></div><div><font face=3D"monospace, monospace">=C2=A0 =C2=A0 if (x =3D=
=3D 1) {</font></div><div><font face=3D"monospace, monospace">=C2=A0 =C2=A0=
 =C2=A0 =C2=A0 return 1;</font></div><div><font face=3D"monospace, monospac=
e">=C2=A0 =C2=A0 } else {</font></div><div><font face=3D"monospace, monospa=
ce">=C2=A0 =C2=A0 =C2=A0 =C2=A0 return fibonacci(x-1) + fibonacci(x-2);</fo=
nt></div><div><font face=3D"monospace, monospace">=C2=A0 =C2=A0 }</font></d=
iv><div><font face=3D"monospace, monospace">}</font></div><div>=C2=A0 =C2=
=A0=C2=A0</div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Wed, May 4, 2016 at 12:16 PM, Viacheslav Usov <span dir=3D"ltr">&lt;=
<a href=3D"mailto:via.usov@gmail.com" target=3D"_blank">via.usov@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"><div dir=3D"ltr"><d=
iv class=3D"gmail_extra"><div class=3D"gmail_quote"><span class=3D"">On Wed=
, May 4, 2016 at 8:30 PM, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"mail=
to:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</span=
> wrote:<br><div><br></div><div>&gt; Alternatively, `(this)()` should be no=
 different from `this()`.</div><div><br></div></span><div>Why <i>should</i>=
=C2=A0it?</div><span class=3D""><div><br></div><div>&gt; Yet what you propo=
se would require this, because your `this()` syntax is not based on an `thi=
s` being an expression. It&#39;s based on it being the keyword `this`.</div=
><div><br></div></span><div>Yes and yes.</div><span class=3D""><div><br></d=
iv><div>&gt; No, if you want to have recursive lambdas, you&#39;re going to=
 have to find a better way to do it.</div><div><br></div></span><div>I have=
 mentioned a few other options. Yet, can you explain why this() is bad with=
out resorting to ad hoc assumptions?</div><span class=3D""><div><br></div><=
div>&gt; ... it takes a special kind of logic to suggest that someone is be=
ing illogical, while simultaneously proposing that it&#39;s perfectly sensi=
ble for `this()` to behave in a way that is completely inconsistent with <i=
>every other use</i> of `this`.</div><div><br></div></span><div>One could s=
ay the exact same thing about [] when it was being introduced for lambdas. =
The latter felt a little weird initially, and my proposal felt a little wei=
rd initially even to myself. I did try to ensure that the proposed syntax w=
ould in no way affect or be affected by=C2=A0<i>every other use</i>=C2=A0of=
 `this`. The proposal is self-consistent as far as I can tell.</div><div><b=
r></div><div>Cheers,</div><div>V.</div><div><br></div></div></div></div><sp=
an class=3D"">

<p></p>

-- <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" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAA7YVg3ebPar2ezMvd0p--U0WoSe18XbLT5D=
6rP-OOGx4JP-iw%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfooter"=
 target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-propo=
sals/CAA7YVg3ebPar2ezMvd0p--U0WoSe18XbLT5D6rP-OOGx4JP-iw%40mail.gmail.com</=
a>.<br>
</blockquote></div><br></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAHJ4w5ppn6EY19SZ9Dz3P6krp2zqKzegRd-%=
2BLpQQyu5OjPOvng%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHJ4w5ppn6EY19=
SZ9Dz3P6krp2zqKzegRd-%2BLpQQyu5OjPOvng%40mail.gmail.com</a>.<br />

--94eb2c05947eb4626005320a1cd6--

.

--001a113abd1c26649c05320af790
Content-Type: text/plain; charset=UTF-8

My preferred syntax for this is:

  []fib(int n) {
    if (n < 2)
      return n;
    return fib(n-1) + fib(n-2);
  }

where the name 'fib' within the lambda body is syntactic sugar for a
reference to the lambda's 'operator()'. (So its type is 'auto(int)' until
the first 'return' statement, and 'int(int)' afterwards. In a generic
lambda, it denotes the 'operator()' template.)

It'd be nice to be able to refer to the closure object itself within the
lambda, to allow this sort of thing:

  []self(int n) {
    if (!ready) call_later(self);
    else { ... }
  }

.... but there are practical problems with that because the type of 'self'
would be incomplete until the '}', at least for lambdas with a
capture-default.

On Tue, May 3, 2016 at 2:29 AM, Viacheslav Usov <via.usov@gmail.com> wrote:

> Unless this has been covered by a proposal that I have missed, there is no
> way to do something like this:
>
> auto f = [&f]{ f(); };
>
> I believe the reason for this is that the type of f is not yet known
> within the capture list.
>
> Yet such a thing is expressible manually:
>
> struct F
> {
> F &f;
> F() : f(*this) {}
> void operator()() { f(); }
> } f;
>
> Note that the full type F is not known, yet it is perfectly fine to use a
> reference to it.
>
> (I know that the code above is not optimal.)
>
> A problem with the original (invalid) syntax and the manual (valid) syntax
> is that both capture the original object by reference, which may become
> invalid if the value is copied. What we really need is a way to refer to
> 'this' of the lambda's object. We cannot use just 'this' because that would
> conflict with its normal use, as in a lambda defined in a member function.
>
> Therefore we need a special way to refer to 'this' of the lambda's object.
> I therefore propose:
>
> 1. Concept: *some* special syntax so that a lambda's body could refer to
> 'this' of the lambda's object.
>
> 2. Syntax: () is a reference to the lambda's object (the one currently
> executing, which can be different from the one originally instantiated).
>
> Example:
>
> auto f = []{ ()(); };
>
> auto g = [](int a){ ()(a); };
>
> 3. We could probably generalize the special syntax (not necessarily that
> of #2) to be applicable to any function, such that the following
>
> int f() { ()(); };
>
> would be equivalent to
>
> int f() { f(); };
>
> Comments?
>
> Cheers,
> V.
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg3WtXczNiR4q7023Q09Tf6N1d5XuO8jyHnPQuzf3Kzucw%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg3WtXczNiR4q7023Q09Tf6N1d5XuO8jyHnPQuzf3Kzucw%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQqkFpdSQUtaewj2w5ysRMNgY2GxjEq3J7XS7RvrKdi%3DfTg%40mail.gmail.com.

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

<div dir=3D"ltr">My preferred syntax for this is:<div><br></div><div>=C2=A0=
 []fib(int n) {</div><div>=C2=A0 =C2=A0 if (n &lt; 2)</div><div>=C2=A0 =C2=
=A0 =C2=A0 return n;</div><div>=C2=A0 =C2=A0 return fib(n-1) + fib(n-2);</d=
iv><div>=C2=A0 }</div><div><br></div><div>where the name &#39;fib&#39; with=
in the lambda body is syntactic sugar for a reference to the lambda&#39;s &=
#39;operator()&#39;. (So its type is &#39;auto(int)&#39; until the first &#=
39;return&#39; statement, and &#39;int(int)&#39; afterwards. In a generic l=
ambda, it denotes the &#39;operator()&#39; template.)</div><div><br></div><=
div>It&#39;d be nice to be able to refer to the closure object itself withi=
n the lambda, to allow this sort of thing:</div><div><br></div><div>=C2=A0 =
[]self(int n) {</div><div>=C2=A0 =C2=A0 if (!ready) call_later(self);</div>=
<div>=C2=A0 =C2=A0 else { ... }</div><div>=C2=A0 }</div><div><br></div><div=
>... but there are practical problems with that because the type of &#39;se=
lf&#39; would be incomplete until the &#39;}&#39;, at least for lambdas wit=
h a capture-default.</div><div><div class=3D"gmail_extra"><br><div class=3D=
"gmail_quote">On Tue, May 3, 2016 at 2:29 AM, Viacheslav Usov <span dir=3D"=
ltr">&lt;<a href=3D"mailto:via.usov@gmail.com" target=3D"_blank">via.usov@g=
mail.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"><div dir=
=3D"ltr">Unless this has been covered by a proposal that I have missed, the=
re is no way to do something like this:<div><br></div><div>auto f =3D [&amp=
;f]{ f(); };</div><div><br></div><div>I believe the reason for this is that=
 the type of f is not yet known within the capture list.</div><div><br></di=
v><div>Yet such a thing is expressible manually:</div><div><br></div><div><=
div>struct F</div><div>{</div><div><span style=3D"white-space:pre-wrap"> </=
span>F &amp;f;</div><div><span style=3D"white-space:pre-wrap"> </span>F() :=
 f(*this) {}</div><div><span style=3D"white-space:pre-wrap"> </span>void op=
erator()() { f(); }</div><div>} f;</div></div><div><br></div><div>Note that=
 the full type F is not known, yet it is perfectly fine to use a reference =
to it.<br></div><div><br></div><div>(I know that the code above is not opti=
mal.)<br></div><div><br></div><div>A problem with the original (invalid) sy=
ntax and the manual (valid) syntax is that both capture the original object=
 by reference, which may become invalid if the value is copied. What we rea=
lly need is a way to refer to &#39;this&#39; of the lambda&#39;s object. We=
 cannot use just &#39;this&#39; because that would conflict with its normal=
 use, as in a lambda defined in a member function.</div><div><br></div><div=
>Therefore we need a special way to refer to &#39;this&#39; of the lambda&#=
39;s object. I therefore propose:</div><div><br></div><div>1. Concept: <i>s=
ome</i>=C2=A0special syntax so that a lambda&#39;s body could refer to &#39=
;this&#39; of the lambda&#39;s object.</div><div><br></div><div>2. Syntax: =
() is a reference to the lambda&#39;s object (the one currently executing, =
which can be different from the one originally instantiated).</div><div><br=
></div><div>Example:</div><div><br></div><div>auto f =3D []{ ()(); };</div>=
<div><br></div><div>auto g =3D [](int a){ ()(a); };</div><div><br></div><di=
v>3. We could probably generalize the special syntax (not necessarily that =
of #2) to be applicable to any function, such that the following</div><div>=
<br></div><div>int f() { ()(); };</div><div><br></div><div>would be equival=
ent to=C2=A0</div><div><br></div><div>int f() { f(); };<br></div><div><br><=
/div><div>Comments?<br></div><div><br></div><div>Cheers,</div><div>V.</div>=
<span class=3D"HOEnZb"><font color=3D"#888888"><div><br></div></font></span=
></div><span class=3D"HOEnZb"><font color=3D"#888888">

<p></p>

-- <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" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAA7YVg3WtXczNiR4q7023Q09Tf6N1d5XuO8j=
yHnPQuzf3Kzucw%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfooter"=
 target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-propo=
sals/CAA7YVg3WtXczNiR4q7023Q09Tf6N1d5XuO8jyHnPQuzf3Kzucw%40mail.gmail.com</=
a>.<br>
</font></span></blockquote></div><br></div></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOfiQqkFpdSQUtaewj2w5ysRMNgY2GxjEq3J=
7XS7RvrKdi%3DfTg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQqkFpdSQUt=
aewj2w5ysRMNgY2GxjEq3J7XS7RvrKdi%3DfTg%40mail.gmail.com</a>.<br />

--001a113abd1c26649c05320af790--

.

--14dae9340bd706992505320be68b
Content-Type: text/plain; charset=UTF-8

On May 4, 2016 4:32 PM, "Richard Smith" <richard@metafoo.co.uk> wrote:
>
> My preferred syntax for this is:
>
>   []fib(int n) {
>     if (n < 2)
>       return n;
>     return fib(n-1) + fib(n-2);
>   }
>
> where the name 'fib' within the lambda body is syntactic sugar for a
reference to the lambda's 'operator()'. (So its type is 'auto(int)' until
the first 'return' statement, and 'int(int)' afterwards. In a generic
lambda, it denotes the 'operator()' template.)
>

I have been waiting for your paper for this for quite long time (

--
Zhihao

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGsORuAodTNqX7X9_%2BjjV_KY-m0trG0-nA1buYuNxwnBzOZS2w%40mail.gmail.com.

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

<p dir=3D"ltr">On May 4, 2016 4:32 PM, &quot;Richard Smith&quot; &lt;<a hre=
f=3D"mailto:richard@metafoo.co.uk">richard@metafoo.co.uk</a>&gt; wrote:<br>
&gt;<br>
&gt; My preferred syntax for this is:<br>
&gt;<br>
&gt; =C2=A0 []fib(int n) {<br>
&gt; =C2=A0 =C2=A0 if (n &lt; 2)<br>
&gt; =C2=A0 =C2=A0 =C2=A0 return n;<br>
&gt; =C2=A0 =C2=A0 return fib(n-1) + fib(n-2);<br>
&gt; =C2=A0 }<br>
&gt;<br>
&gt; where the name &#39;fib&#39; within the lambda body is syntactic sugar=
 for a reference to the lambda&#39;s &#39;operator()&#39;. (So its type is =
&#39;auto(int)&#39; until the first &#39;return&#39; statement, and &#39;in=
t(int)&#39; afterwards. In a generic lambda, it denotes the &#39;operator()=
&#39; template.)<br>
&gt;</p>
<p dir=3D"ltr">I have been waiting for your paper for this for quite long t=
ime (</p>
<p dir=3D"ltr">--<br>
Zhihao</p>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAGsORuAodTNqX7X9_%2BjjV_KY-m0trG0-nA=
1buYuNxwnBzOZS2w%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGsORuAodTNqX7=
X9_%2BjjV_KY-m0trG0-nA1buYuNxwnBzOZS2w%40mail.gmail.com</a>.<br />

--14dae9340bd706992505320be68b--

.

------=_Part_4533_1250330268.1462402702840
Content-Type: text/plain; charset=UTF-8

If we're bikeshedding syntax, how about a directive that this should designate the closure object and not the enclosing object if any? A contextual identifier after the argument list should work, e.g. 'recursive':

auto fib = [](auto n) recursive {
  if (n < 2)
    return n;
  return (*this)(n-1) + (*this)(n-2);
}

It would still be possible to refer to the enclosing object via an init-capture: [outer=this]() recursive { ... }

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7cd80d86-c5e7-4ba9-b9c2-c7cc5d8f181e%40isocpp.org.

------=_Part_4533_1250330268.1462402702840--

.

--94eb2c06fad6ecaa6c05320c52c9
Content-Type: text/plain; charset=UTF-8

On Wed, May 4, 2016 at 3:58 PM, Edward Catmur <ed@catmur.co.uk> wrote:

> If we're bikeshedding syntax, how about a directive that this should
> designate the closure object and not the enclosing object if any? A
> contextual identifier after the argument list should work, e.g. 'recursive':
>
> auto fib = [](auto n) recursive {
>   if (n < 2)
>     return n;
>   return (*this)(n-1) + (*this)(n-2);
>

How would this work? The type of *this is incomplete here in the general
case (we don't necessarily know all the captures yet).


> }
>
> It would still be possible to refer to the enclosing object via an
> init-capture: [outer=this]() recursive { ... }
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7cd80d86-c5e7-4ba9-b9c2-c7cc5d8f181e%40isocpp.org
> .
>

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQq%3DbK39Uz4P9z%3Doi5RT_sBiS1yEFXZh8dkBLkVsSTW1EMg%40mail.gmail.com.

--94eb2c06fad6ecaa6c05320c52c9
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 W=
ed, May 4, 2016 at 3:58 PM, Edward Catmur <span dir=3D"ltr">&lt;<a href=3D"=
mailto:ed@catmur.co.uk" target=3D"_blank">ed@catmur.co.uk</a>&gt;</span> wr=
ote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex">If we&#39;re bikeshedding syntax, ho=
w about a directive that this should designate the closure object and not t=
he enclosing object if any? A contextual identifier after the argument list=
 should work, e.g. &#39;recursive&#39;:<br>
<br>
auto fib =3D [](auto n) recursive {<br>
<span class=3D"">=C2=A0 if (n &lt; 2)<br>
=C2=A0 =C2=A0 return n;<br>
</span>=C2=A0 return (*this)(n-1) + (*this)(n-2);<br></blockquote><div><br>=
</div><div>How would this work? The type of *this is incomplete here in the=
 general case (we don&#39;t necessarily know all the captures yet).</div><d=
iv>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex">
}<br>
<br>
It would still be possible to refer to the enclosing object via an init-cap=
ture: [outer=3Dthis]() recursive { ... }<br>
<span class=3D""><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>
</span>To view this discussion on the web visit <a href=3D"https://groups.g=
oogle.com/a/isocpp.org/d/msgid/std-proposals/7cd80d86-c5e7-4ba9-b9c2-c7cc5d=
8f181e%40isocpp.org" rel=3D"noreferrer" target=3D"_blank">https://groups.go=
ogle.com/a/isocpp.org/d/msgid/std-proposals/7cd80d86-c5e7-4ba9-b9c2-c7cc5d8=
f181e%40isocpp.org</a>.<br>
</blockquote></div><br></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOfiQq%3DbK39Uz4P9z%3Doi5RT_sBiS1yEF=
XZh8dkBLkVsSTW1EMg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQq%3DbK3=
9Uz4P9z%3Doi5RT_sBiS1yEFXZh8dkBLkVsSTW1EMg%40mail.gmail.com</a>.<br />

--94eb2c06fad6ecaa6c05320c52c9--

.

--94eb2c046c8e2e3cfd05320c877a
Content-Type: text/plain; charset=UTF-8

On 5 May 2016 00:09, "Richard Smith" <richard@metafoo.co.uk> wrote:
>
> On Wed, May 4, 2016 at 3:58 PM, Edward Catmur <ed@catmur.co.uk> wrote:
>>
>> If we're bikeshedding syntax, how about a directive that this should
designate the closure object and not the enclosing object if any? A
contextual identifier after the argument list should work, e.g. 'recursive':
>>
>> auto fib = [](auto n) recursive {
>>   if (n < 2)
>>     return n;
>>   return (*this)(n-1) + (*this)(n-2);
>
>
> How would this work? The type of *this is incomplete here in the general
case (we don't necessarily know all the captures yet).

Recursive lambdas should be barred from having a capture-default, perhaps.

>>
>> }
>>
>> It would still be possible to refer to the enclosing object via an
init-capture: [outer=this]() recursive { ... }
>>
>> --
>> 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.
>> To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7cd80d86-c5e7-4ba9-b9c2-c7cc5d8f181e%40isocpp.org
..
>
>
> --
> You received this message because you are subscribed to a topic in the
Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
https://groups.google.com/a/isocpp.org/d/topic/std-proposals/Yn8uwzSgQ6o/unsubscribe
..
> To unsubscribe from this group and all its topics, send an email to
std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQq%3DbK39Uz4P9z%3Doi5RT_sBiS1yEFXZh8dkBLkVsSTW1EMg%40mail.gmail.com
..

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdOb-3i%3Dw66UeU%2B2T8KxGtONxS%3DzQmb6OP_dKMJK%3DcMq8Vg%40mail.gmail.com.

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

<p dir=3D"ltr"><br>
On 5 May 2016 00:09, &quot;Richard Smith&quot; &lt;<a href=3D"mailto:richar=
d@metafoo.co.uk">richard@metafoo.co.uk</a>&gt; wrote:<br>
&gt;<br>
&gt; On Wed, May 4, 2016 at 3:58 PM, Edward Catmur &lt;<a href=3D"mailto:ed=
@catmur.co.uk">ed@catmur.co.uk</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; If we&#39;re bikeshedding syntax, how about a directive that this =
should designate the closure object and not the enclosing object if any? A =
contextual identifier after the argument list should work, e.g. &#39;recurs=
ive&#39;:<br>
&gt;&gt;<br>
&gt;&gt; auto fib =3D [](auto n) recursive {<br>
&gt;&gt; =C2=A0 if (n &lt; 2)<br>
&gt;&gt; =C2=A0 =C2=A0 return n;<br>
&gt;&gt; =C2=A0 return (*this)(n-1) + (*this)(n-2);<br>
&gt;<br>
&gt;<br>
&gt; How would this work? The type of *this is incomplete here in the gener=
al case (we don&#39;t necessarily know all the captures yet).</p>
<p dir=3D"ltr">Recursive lambdas should be barred from having a capture-def=
ault, perhaps. </p>
<p dir=3D"ltr">&gt;&gt;<br>
&gt;&gt; }<br>
&gt;&gt;<br>
&gt;&gt; It would still be possible to refer to the enclosing object via an=
 init-capture: [outer=3Dthis]() recursive { ... }<br>
&gt;&gt;<br>
&gt;&gt; --<br>
&gt;&gt; You received this message because you are subscribed to the Google=
 Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
&gt;&gt; To unsubscribe from this group and stop receiving emails from it, =
send an email to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">=
std-proposals+unsubscribe@isocpp.org</a>.<br>
&gt;&gt;<br>
&gt;&gt; To post to this group, send email to <a href=3D"mailto:std-proposa=
ls@isocpp.org">std-proposals@isocpp.org</a>.<br>
&gt;&gt; To view this discussion on the web visit <a href=3D"https://groups=
..google.com/a/isocpp.org/d/msgid/std-proposals/7cd80d86-c5e7-4ba9-b9c2-c7cc=
5d8f181e%40isocpp.org">https://groups.google.com/a/isocpp.org/d/msgid/std-p=
roposals/7cd80d86-c5e7-4ba9-b9c2-c7cc5d8f181e%40isocpp.org</a>.<br>
&gt;<br>
&gt;<br>
&gt; -- <br>
&gt; You received this message because you are subscribed to a topic in the=
 Google Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
&gt; To unsubscribe from this topic, visit <a href=3D"https://groups.google=
..com/a/isocpp.org/d/topic/std-proposals/Yn8uwzSgQ6o/unsubscribe">https://gr=
oups.google.com/a/isocpp.org/d/topic/std-proposals/Yn8uwzSgQ6o/unsubscribe<=
/a>.<br>
&gt; To unsubscribe from this group and all its topics, send an email to <a=
 href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-proposals+unsub=
scribe@isocpp.org</a>.<br>
&gt; To post to this group, send email to <a href=3D"mailto:std-proposals@i=
socpp.org">std-proposals@isocpp.org</a>.<br>
&gt; To view this discussion on the web visit <a href=3D"https://groups.goo=
gle.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQq%3DbK39Uz4P9z%3Doi5RT_sBi=
S1yEFXZh8dkBLkVsSTW1EMg%40mail.gmail.com">https://groups.google.com/a/isocp=
p.org/d/msgid/std-proposals/CAOfiQq%3DbK39Uz4P9z%3Doi5RT_sBiS1yEFXZh8dkBLkV=
sSTW1EMg%40mail.gmail.com</a>.<br>
</p>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAJnLdOb-3i%3Dw66UeU%2B2T8KxGtONxS%3D=
zQmb6OP_dKMJK%3DcMq8Vg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdOb-=
3i%3Dw66UeU%2B2T8KxGtONxS%3DzQmb6OP_dKMJK%3DcMq8Vg%40mail.gmail.com</a>.<br=
 />

--94eb2c046c8e2e3cfd05320c877a--

.

------=_Part_6543_502380552.1462413002415
Content-Type: multipart/alternative;
 boundary="----=_Part_6544_685576374.1462413002416"

------=_Part_6544_685576374.1462413002416
Content-Type: text/plain; charset=UTF-8

On Tuesday, May 3, 2016 at 2:29:51 AM UTC-7, Viacheslav Usov wrote:
>
> Unless this has been covered by a proposal that I have missed, there is no
> way to do something like this:
>
> auto f = [&f]{ f(); };
>

auto f = fix([](auto&& f) { f(); });

where fix is defined as something like

template<class F> auto fix(F fa) {
    return [fa](auto... args) {
        auto f = [&](auto... args){ fa(f, args...) };
        return f(args...);
    }
}

(modulo metaprogramming improvements that might be made by a real library
implementor, such as the moves/forwards I omitted for brevity).
I believe this has been proposed before as std::fix, and probably
(unsuccessfully, of course) as std::y. If there's a need for the
functionality, I'm sure it could get proposed again.

I don't see any reason to add core language syntax for this feature, if the
library solution is well understood and efficient. Is it possible that the
above solution could be inefficient in any way?

Arthur

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/90a97b92-9dca-4959-97fb-6a8b714e120d%40isocpp.org.

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

<div dir=3D"ltr">On Tuesday, May 3, 2016 at 2:29:51 AM UTC-7, Viacheslav Us=
ov 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">Unle=
ss this has been covered by a proposal that I have missed, there is no way =
to do something like this:<div><br></div><div>auto f =3D [&amp;f]{ f(); };<=
/div></div></blockquote><div><br></div><div><font face=3D"courier new, mono=
space">auto f =3D fix([](auto&amp;&amp; f) { f(); });</font></div><div><br>=
</div><div>where fix is defined as something like</div><div><br></div><div>=
<font face=3D"courier new, monospace">template&lt;class F&gt; auto fix(F fa=
) {</font></div><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 re=
turn [fa](auto... args) {</font></div><div><font face=3D"courier new, monos=
pace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 auto f =3D [&amp;](auto... args){ fa(f, a=
rgs...) };</font></div><div><font face=3D"courier new, monospace">=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 return f(args...);</font></div><div><font face=3D"cour=
ier new, monospace">=C2=A0 =C2=A0 }</font></div><div><font face=3D"courier =
new, monospace">}</font></div><div><br></div><div>(modulo metaprogramming i=
mprovements that might be made by a real library implementor, such as the m=
oves/forwards I omitted for brevity).</div><div>I believe this has been pro=
posed before as <font face=3D"courier new, monospace">std::fix</font>, and =
probably (unsuccessfully, of course) as <font face=3D"courier new, monospac=
e">std::y</font>. If there&#39;s a need for the functionality, I&#39;m sure=
 it could get proposed again.</div><div><br></div><div>I don&#39;t see any =
reason to add core language syntax for this feature, if the library solutio=
n is well understood and efficient. Is it possible that the above solution =
could be inefficient in any way?</div><div><br></div><div>Arthur</div></div=
>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/90a97b92-9dca-4959-97fb-6a8b714e120d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/90a97b92-9dca-4959-97fb-6a8b714e120d=
%40isocpp.org</a>.<br />

------=_Part_6544_685576374.1462413002416--
------=_Part_6543_502380552.1462413002415--

.

--94eb2c05056674179a05321016e2
Content-Type: text/plain; charset=UTF-8

What about:
auto recursive = [](int i, float f) {
  if(i)
    [](i, f);
};

[](...); Meaning self lambda call.

Please note that would be different of:
auto lambda_in_lambda = [](int i, float f) {
  [](int i, float f) { /*other body*/ }(i, f);
};

My $0.02.
Cheers,
Ricardo


On Wednesday, May 4, 2016, Arthur O'Dwyer <arthur.j.odwyer@gmail.com> wrote:

> On Tuesday, May 3, 2016 at 2:29:51 AM UTC-7, Viacheslav Usov wrote:
>>
>> Unless this has been covered by a proposal that I have missed, there is
>> no way to do something like this:
>>
>> auto f = [&f]{ f(); };
>>
>
> auto f = fix([](auto&& f) { f(); });
>
> where fix is defined as something like
>
> template<class F> auto fix(F fa) {
>     return [fa](auto... args) {
>         auto f = [&](auto... args){ fa(f, args...) };
>         return f(args...);
>     }
> }
>
> (modulo metaprogramming improvements that might be made by a real library
> implementor, such as the moves/forwards I omitted for brevity).
> I believe this has been proposed before as std::fix, and probably
> (unsuccessfully, of course) as std::y. If there's a need for the
> functionality, I'm sure it could get proposed again.
>
> I don't see any reason to add core language syntax for this feature, if
> the library solution is well understood and efficient. Is it possible that
> the above solution could be inefficient in any way?
>
> Arthur
>
> --
> 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
> <javascript:_e(%7B%7D,'cvml','std-proposals%2Bunsubscribe@isocpp.org');>.
> To post to this group, send email to std-proposals@isocpp.org
> <javascript:_e(%7B%7D,'cvml','std-proposals@isocpp.org');>.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/90a97b92-9dca-4959-97fb-6a8b714e120d%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/90a97b92-9dca-4959-97fb-6a8b714e120d%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BfGSbPS4LSbYYqELwg8cx0y%3DDH5v7KhN0jq_V50FwaER7pngQ%40mail.gmail.com.

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

What about:<div>auto recursive =3D=C2=A0[](int i, float f) {</div><div>=C2=
=A0=C2=A0if(i)</div><div>=C2=A0 =C2=A0 [](i, f);</div><div>};</div><div><br=
></div><div>[](...);=C2=A0Meaning self lambda call.</div><div><br></div><di=
v>Please note that would be different of:</div><div>auto lambda_in_lambda =
=3D [](int i, float f) {</div><div>=C2=A0 [](int i, float f) { /*other body=
*/ }(i, f);</div><div>};<br><br>My $0.02.</div><div>Cheers,</div><div>Ricar=
do</div><div><br><br>On Wednesday, May 4, 2016, Arthur O&#39;Dwyer &lt;<a h=
ref=3D"mailto:arthur.j.odwyer@gmail.com">arthur.j.odwyer@gmail.com</a>&gt; =
wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Tuesday, May 3=
, 2016 at 2:29:51 AM UTC-7, Viacheslav Usov wrote:<blockquote class=3D"gmai=
l_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;pad=
ding-left:1ex"><div dir=3D"ltr">Unless this has been covered by a proposal =
that I have missed, there is no way to do something like this:<div><br></di=
v><div>auto f =3D [&amp;f]{ f(); };</div></div></blockquote><div><br></div>=
<div><font face=3D"courier new, monospace">auto f =3D fix([](auto&amp;&amp;=
 f) { f(); });</font></div><div><br></div><div>where fix is defined as some=
thing like</div><div><br></div><div><font face=3D"courier new, monospace">t=
emplate&lt;class F&gt; auto fix(F fa) {</font></div><div><font face=3D"cour=
ier new, monospace">=C2=A0 =C2=A0 return [fa](auto... args) {</font></div><=
div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 auto =
f =3D [&amp;](auto... args){ fa(f, args...) };</font></div><div><font face=
=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 return f(args...);<=
/font></div><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 }</fon=
t></div><div><font face=3D"courier new, monospace">}</font></div><div><br><=
/div><div>(modulo metaprogramming improvements that might be made by a real=
 library implementor, such as the moves/forwards I omitted for brevity).</d=
iv><div>I believe this has been proposed before as <font face=3D"courier ne=
w, monospace">std::fix</font>, and probably (unsuccessfully, of course) as =
<font face=3D"courier new, monospace">std::y</font>. If there&#39;s a need =
for the functionality, I&#39;m sure it could get proposed again.</div><div>=
<br></div><div>I don&#39;t see any reason to add core language syntax for t=
his feature, if the library solution is well understood and efficient. Is i=
t possible that the above solution could be inefficient in any way?</div><d=
iv><br></div><div>Arthur</div></div>

<p></p>

-- <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"javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;std-proposals%2=
Bunsubscribe@isocpp.org&#39;);" target=3D"_blank">std-proposals+unsubscribe=
@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:_e(%7B%7D,&#39;c=
vml&#39;,&#39;std-proposals@isocpp.org&#39;);" target=3D"_blank">std-propos=
als@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/90a97b92-9dca-4959-97fb-6a8b714e120d%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/90a97b92-9dca-=
4959-97fb-6a8b714e120d%40isocpp.org</a>.<br>
</blockquote></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CA%2BfGSbPS4LSbYYqELwg8cx0y%3DDH5v7Kh=
N0jq_V50FwaER7pngQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BfGSbPS4L=
SbYYqELwg8cx0y%3DDH5v7KhN0jq_V50FwaER7pngQ%40mail.gmail.com</a>.<br />

--94eb2c05056674179a05321016e2--

.

--001a1148d28e532145053210bb47
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, May 4, 2016 at 8:39 PM, Ricardo Fabiano de Andrade <
ricardofabianodeandrade@gmail.com> wrote:

> What about:
> auto recursive =3D [](int i, float f) {
>   if(i)
>     [](i, f);
> };
>
> [](...); Meaning self lambda call.
>
> Please note that would be different of:
> auto lambda_in_lambda =3D [](int i, float f) {
>   [](int i, float f) { /*other body*/ }(i, f);
> };
>

I'm not sure I understand your point, but my point was that the above is
achievable today via

    auto recursive =3D fix([](auto&& thisfunc, int i, float f) {
        if (i)
            thisfunc(i, f);
    });

and doesn't require core language changes to achieve.

=E2=80=93Arthur



> On Wednesday, May 4, 2016, Arthur O'Dwyer <arthur.j.odwyer@gmail.com>
> wrote:
>
>> On Tuesday, May 3, 2016 at 2:29:51 AM UTC-7, Viacheslav Usov wrote:
>>>
>>> Unless this has been covered by a proposal that I have missed, there is
>>> no way to do something like this:
>>>
>>> auto f =3D [&f]{ f(); };
>>>
>>
>> auto f =3D fix([](auto&& f) { f(); });
>>
>> where fix is defined as something like
>>
>> template<class F> auto fix(F fa) {
>>     return [fa](auto... args) {
>>         auto f =3D [&](auto... args){ fa(f, args...) };
>>         return f(args...);
>>     }
>> }
>>
>> (modulo metaprogramming improvements that might be made by a real librar=
y
>> implementor, such as the moves/forwards I omitted for brevity).
>> I believe this has been proposed before as std::fix, and probably
>> (unsuccessfully, of course) as std::y. If there's a need for the
>> functionality, I'm sure it could get proposed again.
>>
>> I don't see any reason to add core language syntax for this feature, if
>> the library solution is well understood and efficient. Is it possible th=
at
>> the above solution could be inefficient in any way?
>>
>> Arthur
>>
>> --
>> You received this message because you are subscribed to the Google Group=
s
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> email to std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> To view this discussion on the web visit
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/90a97b92-9d=
ca-4959-97fb-6a8b714e120d%40isocpp.org
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/90a97b92-9=
dca-4959-97fb-6a8b714e120d%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoo=
ter>
>> .
>>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/Yn8uwzSgQ6o/=
unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BfGSbPS4=
LSbYYqELwg8cx0y%3DDH5v7KhN0jq_V50FwaER7pngQ%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BfGSbPS=
4LSbYYqELwg8cx0y%3DDH5v7KhN0jq_V50FwaER7pngQ%40mail.gmail.com?utm_medium=3D=
email&utm_source=3Dfooter>
> .
>

--=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CADvuK0Kqf%3DbRX4%3DcX%3D%3D-PN806fUJ2cZVqeToB0v=
i-z1Nmbg3Gw%40mail.gmail.com.

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

<div dir=3D"ltr">On Wed, May 4, 2016 at 8:39 PM, Ricardo Fabiano de Andrade=
 <span dir=3D"ltr">&lt;<a href=3D"mailto:ricardofabianodeandrade@gmail.com"=
 target=3D"_blank">ricardofabianodeandrade@gmail.com</a>&gt;</span> wrote:<=
br><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">What about:<div>auto recursive =3D=C2=A0[](int i, float f) {<=
/div><div>=C2=A0=C2=A0if(i)</div><div>=C2=A0 =C2=A0 [](i, f);</div><div>};<=
/div><div><br></div><div>[](...);=C2=A0Meaning self lambda call.</div><div>=
<br></div><div>Please note that would be different of:</div><div>auto lambd=
a_in_lambda =3D [](int i, float f) {</div><div>=C2=A0 [](int i, float f) { =
/*other body*/ }(i, f);</div><div>};<br></div></blockquote><div><br></div><=
div>I&#39;m not sure I understand your point, but my point was that the abo=
ve is achievable today via</div><div><br></div><div><font face=3D"monospace=
, monospace">=C2=A0 =C2=A0 auto recursive =3D fix([](auto&amp;&amp; thisfun=
c, int i, float f) {</font></div><div><font face=3D"monospace, monospace">=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 if (i)</font></div><div><font face=3D"monospace=
, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 thisfunc(i, f);</fon=
t></div><div><font face=3D"monospace, monospace">=C2=A0 =C2=A0 });</font></=
div><div><br></div><div>and doesn&#39;t require core language changes to ac=
hieve.</div><div><br></div><div>=E2=80=93Arthur</div><div><br></div><div>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div>On Wednesday, May 4, 2016, =
Arthur O&#39;Dwyer &lt;<a href=3D"mailto:arthur.j.odwyer@gmail.com" target=
=3D"_blank">arthur.j.odwyer@gmail.com</a>&gt; wrote:<br></div><div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr">On Tuesday, May 3, 2016 at 2:29:51 =
AM UTC-7, Viacheslav Usov wrote:<blockquote class=3D"gmail_quote" style=3D"=
margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><di=
v dir=3D"ltr">Unless this has been covered by a proposal that I have missed=
, there is no way to do something like this:<div><br></div><div>auto f =3D =
[&amp;f]{ f(); };</div></div></blockquote><div><br></div><div><font face=3D=
"courier new, monospace">auto f =3D fix([](auto&amp;&amp; f) { f(); });</fo=
nt></div><div><br></div><div>where fix is defined as something like</div><d=
iv><br></div><div><font face=3D"courier new, monospace">template&lt;class F=
&gt; auto fix(F fa) {</font></div><div><font face=3D"courier new, monospace=
">=C2=A0 =C2=A0 return [fa](auto... args) {</font></div><div><font face=3D"=
courier new, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 auto f =3D [&amp;](auto=
.... args){ fa(f, args...) };</font></div><div><font face=3D"courier new, mo=
nospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 return f(args...);</font></div><div><f=
ont face=3D"courier new, monospace">=C2=A0 =C2=A0 }</font></div><div><font =
face=3D"courier new, monospace">}</font></div><div><br></div><div>(modulo m=
etaprogramming improvements that might be made by a real library implemento=
r, such as the moves/forwards I omitted for brevity).</div><div>I believe t=
his has been proposed before as <font face=3D"courier new, monospace">std::=
fix</font>, and probably (unsuccessfully, of course) as <font face=3D"couri=
er new, monospace">std::y</font>. If there&#39;s a need for the functionali=
ty, I&#39;m sure it could get proposed again.</div><div><br></div><div>I do=
n&#39;t see any reason to add core language syntax for this feature, if the=
 library solution is well understood and efficient. Is it possible that the=
 above solution could be inefficient in any way?</div><div><br></div><div>A=
rthur</div></div><span class=3D"HOEnZb"><font color=3D"#888888">

<p></p>

-- <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>std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a>std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/90a97b92-9dca-4959-97fb-6a8b714e120d%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/90a97b92-9dca-=
4959-97fb-6a8b714e120d%40isocpp.org</a>.<br>
</font></span></blockquote></div><span class=3D"HOEnZb"><font color=3D"#888=
888">

<p></p>

-- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/Yn8uwzSgQ6o/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/Yn8uwzSgQ6o=
/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CA%2BfGSbPS4LSbYYqELwg8cx0y%3DDH5v7Kh=
N0jq_V50FwaER7pngQ%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoo=
ter" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-p=
roposals/CA%2BfGSbPS4LSbYYqELwg8cx0y%3DDH5v7KhN0jq_V50FwaER7pngQ%40mail.gma=
il.com</a>.<br>
</font></span></blockquote></div><br></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CADvuK0Kqf%3DbRX4%3DcX%3D%3D-PN806fUJ=
2cZVqeToB0vi-z1Nmbg3Gw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADvuK0Kq=
f%3DbRX4%3DcX%3D%3D-PN806fUJ2cZVqeToB0vi-z1Nmbg3Gw%40mail.gmail.com</a>.<br=
 />

--001a1148d28e532145053210bb47--

.

--bcaec54ee86eea45db0532119cc9
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I didn't mean to answer directly to you, just bringing more ideas for a
syntax.
But what the language offers currently is neither obvious or simple to come
up with, when compared to regular recursive functions.

On Wednesday, May 4, 2016, Arthur O'Dwyer <arthur.j.odwyer@gmail.com
<javascript:_e(%7B%7D,'cvml','arthur.j.odwyer@gmail.com');>> wrote:

> On Wed, May 4, 2016 at 8:39 PM, Ricardo Fabiano de Andrade <
> ricardofabianodeandrade@gmail.com> wrote:
>
>> What about:
>> auto recursive =3D [](int i, float f) {
>>   if(i)
>>     [](i, f);
>> };
>>
>> [](...); Meaning self lambda call.
>>
>> Please note that would be different of:
>> auto lambda_in_lambda =3D [](int i, float f) {
>>   [](int i, float f) { /*other body*/ }(i, f);
>> };
>>
>
> I'm not sure I understand your point, but my point was that the above is
> achievable today via
>
>     auto recursive =3D fix([](auto&& thisfunc, int i, float f) {
>         if (i)
>             thisfunc(i, f);
>     });
>
> and doesn't require core language changes to achieve.
>
> =E2=80=93Arthur
>
>
Following your reasoning lambdas itself would be a completely unnecessary
language feature and we should keep writing callable objects by hand.


>
>> On Wednesday, May 4, 2016, Arthur O'Dwyer <arthur.j.odwyer@gmail.com>
>> wrote:
>>
>>> On Tuesday, May 3, 2016 at 2:29:51 AM UTC-7, Viacheslav Usov wrote:
>>>>
>>>> Unless this has been covered by a proposal that I have missed, there i=
s
>>>> no way to do something like this:
>>>>
>>>> auto f =3D [&f]{ f(); };
>>>>
>>>
>>> auto f =3D fix([](auto&& f) { f(); });
>>>
>>> where fix is defined as something like
>>>
>>> template<class F> auto fix(F fa) {
>>>     return [fa](auto... args) {
>>>         auto f =3D [&](auto... args){ fa(f, args...) };
>>>         return f(args...);
>>>     }
>>> }
>>>
>>> (modulo metaprogramming improvements that might be made by a real
>>> library implementor, such as the moves/forwards I omitted for brevity).
>>> I believe this has been proposed before as std::fix, and probably
>>> (unsuccessfully, of course) as std::y. If there's a need for the
>>> functionality, I'm sure it could get proposed again.
>>>
>>> I don't see any reason to add core language syntax for this feature, if
>>> the library solution is well understood and efficient. Is it possible t=
hat
>>> the above solution could be inefficient in any way?
>>>
>>>
Now, if you allow me...
Let's suppose a syntax for recursive lambda call is introduced and the
compiler is smart enough to replace it by a direct call to the lambda's own
operator() - or equivalent - which potentially would enable some
optimizations such as tail recursion.

I don't quite see that possibility with your suggested implementation of
"fix" or if possible, it just made the compiler/optimizer work much more
complex than it should be.


> Arthur
>>>
>>> --
>>> 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.
>>> To view this discussion on the web visit
>>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/90a97b92-9=
dca-4959-97fb-6a8b714e120d%40isocpp.org
>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/90a97b92-=
9dca-4959-97fb-6a8b714e120d%40isocpp.org?utm_medium=3Demail&utm_source=3Dfo=
oter>
>>> .
>>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/Yn8uwzSgQ6o=
/unsubscribe
>> .
>> To unsubscribe from this group and all its topics, send an email to
>> std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> To view this discussion on the web visit
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BfGSbPS=
4LSbYYqELwg8cx0y%3DDH5v7KhN0jq_V50FwaER7pngQ%40mail.gmail.com
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BfGSbP=
S4LSbYYqELwg8cx0y%3DDH5v7KhN0jq_V50FwaER7pngQ%40mail.gmail.com?utm_medium=
=3Demail&utm_source=3Dfooter>
>> .
>>
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADvuK0Kqf%3=
DbRX4%3DcX%3D%3D-PN806fUJ2cZVqeToB0vi-z1Nmbg3Gw%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADvuK0Kqf%=
3DbRX4%3DcX%3D%3D-PN806fUJ2cZVqeToB0vi-z1Nmbg3Gw%40mail.gmail.com?utm_mediu=
m=3Demail&utm_source=3Dfooter>
> .
>

--=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CA%2BfGSbOx1AGEoaAiXaNDxaE2CS1fCjA9QV8WEwvSjVDpX=
U2t9A%40mail.gmail.com.

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

<div>I didn&#39;t mean to answer directly to you, just bringing more ideas =
for a syntax.</div>But what the language offers currently is neither obviou=
s or simple to come up with,=C2=A0when compared to=C2=A0regular recursive f=
unctions.<div><div><br></div>On Wednesday, May 4, 2016, Arthur O&#39;Dwyer =
&lt;<a href=3D"javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;arthur.j.odwyer@gma=
il.com&#39;);" target=3D"_blank">arthur.j.odwyer@gmail.com</a>&gt; wrote:<b=
r><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Wed, May 4, 2016 at 8:=
39 PM, Ricardo Fabiano de Andrade <span dir=3D"ltr">&lt;<a>ricardofabianode=
andrade@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div =
class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">What about:<div>auto r=
ecursive =3D=C2=A0[](int i, float f) {</div><div>=C2=A0=C2=A0if(i)</div><di=
v>=C2=A0 =C2=A0 [](i, f);</div><div>};</div><div><br></div><div>[](...);=C2=
=A0Meaning self lambda call.</div><div><br></div><div>Please note that woul=
d be different of:</div><div>auto lambda_in_lambda =3D [](int i, float f) {=
</div><div>=C2=A0 [](int i, float f) { /*other body*/ }(i, f);</div><div>};=
<br></div></blockquote><div><br></div><div>I&#39;m not sure I understand yo=
ur point, but my point was that the above is achievable today via</div><div=
><br></div><div><font face=3D"monospace, monospace">=C2=A0 =C2=A0 auto recu=
rsive =3D fix([](auto&amp;&amp; thisfunc, int i, float f) {</font></div><di=
v><font face=3D"monospace, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 if (i)</f=
ont></div><div><font face=3D"monospace, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 thisfunc(i, f);</font></div><div><font face=3D"monospace,=
 monospace">=C2=A0 =C2=A0 });</font></div><div><br></div><div>and doesn&#39=
;t require core language changes to achieve.</div><div><br></div><div>=E2=
=80=93Arthur</div><div><br></div></div></div></div></blockquote><div><br></=
div>Following your reasoning lambdas itself=C2=A0would be a=C2=A0completely=
=C2=A0unnecessary language feature=C2=A0and we should keep writing callable=
 objects by hand.</div><div><br><blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"=
ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div>=C2=A0</div=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div>On Wednesday, May 4, 2016, Arthur O&#3=
9;Dwyer &lt;<a>arthur.j.odwyer@gmail.com</a>&gt; wrote:<br></div><div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc=
c solid;padding-left:1ex"><div dir=3D"ltr">On Tuesday, May 3, 2016 at 2:29:=
51 AM UTC-7, Viacheslav Usov 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">Unless this has been covered by a proposal that I have mi=
ssed, there is no way to do something like this:<div><br></div><div>auto f =
=3D [&amp;f]{ f(); };</div></div></blockquote><div><br></div><div><font fac=
e=3D"courier new, monospace">auto f =3D fix([](auto&amp;&amp; f) { f(); });=
</font></div><div><br></div><div>where fix is defined as something like</di=
v><div><br></div><div><font face=3D"courier new, monospace">template&lt;cla=
ss F&gt; auto fix(F fa) {</font></div><div><font face=3D"courier new, monos=
pace">=C2=A0 =C2=A0 return [fa](auto... args) {</font></div><div><font face=
=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 auto f =3D [&amp;](=
auto... args){ fa(f, args...) };</font></div><div><font face=3D"courier new=
, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 return f(args...);</font></div><di=
v><font face=3D"courier new, monospace">=C2=A0 =C2=A0 }</font></div><div><f=
ont face=3D"courier new, monospace">}</font></div><div><br></div><div>(modu=
lo metaprogramming improvements that might be made by a real library implem=
entor, such as the moves/forwards I omitted for brevity).</div><div>I belie=
ve this has been proposed before as <font face=3D"courier new, monospace">s=
td::fix</font>, and probably (unsuccessfully, of course) as <font face=3D"c=
ourier new, monospace">std::y</font>. If there&#39;s a need for the functio=
nality, I&#39;m sure it could get proposed again.</div><div><br></div><div>=
I don&#39;t see any reason to add core language syntax for this feature, if=
 the library solution is well understood and efficient. Is it possible that=
 the above solution could be inefficient in any way?</div><div><br></div></=
div></blockquote></div></blockquote></div></div></div></blockquote><div><br=
></div><div>Now, if you allow me...</div><div>Let&#39;s suppose a syntax fo=
r recursive lambda call is introduced and the compiler is smart enough to r=
eplace it by a direct call to the lambda&#39;s own operator() - or equivale=
nt -=C2=A0which=C2=A0potentially would=C2=A0enable=C2=A0some optimizations =
such as tail recursion.</div><div><br></div><div>I don&#39;t quite see that=
 possibility with your suggested implementation of &quot;fix&quot; or if po=
ssible, it just made=C2=A0the compiler/optimizer=C2=A0work much more comple=
x than it should be.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><=
div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc=
c solid;padding-left:1ex"><div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"l=
tr"><div>Arthur</div></div><span><font color=3D"#888888">

<p></p>

-- <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>std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a>std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/90a97b92-9dca-4959-97fb-6a8b714e120d%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/90a97b92-9dca-=
4959-97fb-6a8b714e120d%40isocpp.org</a>.<br>
</font></span></blockquote></div><span><font color=3D"#888888">

<p></p>

-- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/Yn8uwzSgQ6o/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/Yn8uwzSgQ6o=
/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a>std-=
proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a>std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CA%2BfGSbPS4LSbYYqELwg8cx0y%3DDH5v7Kh=
N0jq_V50FwaER7pngQ%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoo=
ter" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-p=
roposals/CA%2BfGSbPS4LSbYYqELwg8cx0y%3DDH5v7KhN0jq_V50FwaER7pngQ%40mail.gma=
il.com</a>.<br>
</font></span></blockquote></div><br></div></div>

<p></p>

-- <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>std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a>std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CADvuK0Kqf%3DbRX4%3DcX%3D%3D-PN806fUJ=
2cZVqeToB0vi-z1Nmbg3Gw%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=
=3Dfooter" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid=
/std-proposals/CADvuK0Kqf%3DbRX4%3DcX%3D%3D-PN806fUJ2cZVqeToB0vi-z1Nmbg3Gw%=
40mail.gmail.com</a>.<br>
</blockquote>
</div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CA%2BfGSbOx1AGEoaAiXaNDxaE2CS1fCjA9QV=
8WEwvSjVDpXU2t9A%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BfGSbOx1AGE=
oaAiXaNDxaE2CS1fCjA9QV8WEwvSjVDpXU2t9A%40mail.gmail.com</a>.<br />

--bcaec54ee86eea45db0532119cc9--

.

--001a11c335363d14c60532153ecd
Content-Type: text/plain; charset=UTF-8

On Thu, May 5, 2016 at 3:50 AM, Arthur O'Dwyer <arthur.j.odwyer@gmail.com>
wrote:

auto f = fix([](auto&& f) { f(); });
>
> where fix is defined as something like
>
> template<class F> auto fix(F fa) {
>     return [fa](auto... args) {
>         auto f = [&](auto... args){ fa(f, args...) };
>         return f(args...);
>     }
> }
>

The wrapper must contain the original lambda, by copy, move or reference.
Containment by reference is unsafe. Containment by move or copy can be
impossible or have unexpected results. The fundamental issue here is that
what is supposed to be a "recursive call to itself" is a call to a
*different* functional object.

I touched upon this area in my original message very briefly, and my
conclusion was that a lambda  should have a way to call *itself*, not some
other object. In which case the issues of safety and correctness simply do
not arise. I doubt it is possible to achieve this with any library means,
except perhaps through some magic std::this_function device callable from
the body of a lambda (or, indeed, any function), but that is really just a
way to extend the language without introducing a syntactical extension.

std::this_function, however, may be beneficial in certain other ways,
because it could also be used for introspection. I'd hate the verbosity of
it, though :)

Cheers,
V.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg0zVPvdgEEoOwp6f3Ec4JhAY%2Be66T-DtaT%2BGPsXSTk15Q%40mail.gmail.com.

--001a11c335363d14c60532153ecd
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, May 5, 2016 at 3:50 AM, Arthur O&#39;Dwyer <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:arthur.j.odwyer@gmail.com" target=3D"_blank">arthur.j.odwyer@gm=
ail.com</a>&gt;</span> wrote:</div><div class=3D"gmail_quote"><br><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex"><div dir=3D"ltr"><div><font face=3D"courier new, mono=
space">auto f =3D fix([](auto&amp;&amp; f) { f(); });</font></div><div><br>=
</div><div>where fix is defined as something like</div><div><br></div><div>=
<font face=3D"courier new, monospace">template&lt;class F&gt; auto fix(F fa=
) {</font></div><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 re=
turn [fa](auto... args) {</font></div><div><font face=3D"courier new, monos=
pace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 auto f =3D [&amp;](auto... args){ fa(f, a=
rgs...) };</font></div><div><font face=3D"courier new, monospace">=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 return f(args...);</font></div><div><font face=3D"cour=
ier new, monospace">=C2=A0 =C2=A0 }</font></div><div><font face=3D"courier =
new, monospace">}</font></div></div></blockquote><div><br></div><div>The wr=
apper must contain the original lambda, by copy, move or reference. Contain=
ment by reference is unsafe. Containment by move or copy can be impossible =
or have unexpected results. The fundamental issue here is that what is supp=
osed to be a &quot;recursive call to itself&quot; is a call to a <i>differe=
nt</i>=C2=A0functional object.</div><div><br></div><div>I touched upon this=
 area in my original message very briefly, and my conclusion was that a lam=
bda =C2=A0should have a way to call <i>itself</i>, not some other object. I=
n which case the issues of safety and correctness simply do not arise. I do=
ubt it is possible to achieve this with any library means, except perhaps t=
hrough some magic std::this_function device callable from the body of a lam=
bda (or, indeed, any function), but that is really just a way to extend the=
 language without introducing a syntactical extension.</div><div><br></div>=
<div>std::this_function, however, may be beneficial in certain other ways, =
because it could also be used for introspection. I&#39;d hate the verbosity=
 of it, though :)</div><div><br></div><div>Cheers,</div><div>V.</div></div>=
</div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAA7YVg0zVPvdgEEoOwp6f3Ec4JhAY%2Be66T=
-DtaT%2BGPsXSTk15Q%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg0zVPvd=
gEEoOwp6f3Ec4JhAY%2Be66T-DtaT%2BGPsXSTk15Q%40mail.gmail.com</a>.<br />

--001a11c335363d14c60532153ecd--

.

------=_Part_709_1008413585.1462475535641
Content-Type: multipart/alternative;
 boundary="----=_Part_710_1715611346.1462475535642"

------=_Part_710_1715611346.1462475535642
Content-Type: text/plain; charset=UTF-8

How about allowing local functions? It seems awkward to invent a way to
name lambdas when we already have named functions. The obvious problem
would be how to define the capture of the local function. I would say, make
it simple: Always imply a [&] capture.

If controllable capture is seen as a necessary feature I suggest to
rephrase the previously suggested [&]name(pars) {} style as:

Local functions are now allowed. Local functions with a trailing return
type may be preceeded by a capture clause instead of the auto keyword. If
no capture clause is explicitly given the default capture is equivalent to
[&].

This would give us "pascal style" local functions and solve the recursive
lambda problem at the same time.

Is there a parsing problem with this that I fail to see? Or is there some
other subtle difference between a lambda and a named function that prevents
allowing local functions with classic syntax?



Den torsdag 5 maj 2016 kl. 11:48:30 UTC+2 skrev Viacheslav Usov:
>
> On Thu, May 5, 2016 at 3:50 AM, Arthur O'Dwyer <arthur....@gmail.com
> <javascript:>> wrote:
>
> auto f = fix([](auto&& f) { f(); });
>>
>> where fix is defined as something like
>>
>> template<class F> auto fix(F fa) {
>>     return [fa](auto... args) {
>>         auto f = [&](auto... args){ fa(f, args...) };
>>         return f(args...);
>>     }
>> }
>>
>
> The wrapper must contain the original lambda, by copy, move or reference.
> Containment by reference is unsafe. Containment by move or copy can be
> impossible or have unexpected results. The fundamental issue here is that
> what is supposed to be a "recursive call to itself" is a call to a
> *different* functional object.
>
> I touched upon this area in my original message very briefly, and my
> conclusion was that a lambda  should have a way to call *itself*, not
> some other object. In which case the issues of safety and correctness
> simply do not arise. I doubt it is possible to achieve this with any
> library means, except perhaps through some magic std::this_function device
> callable from the body of a lambda (or, indeed, any function), but that is
> really just a way to extend the language without introducing a syntactical
> extension.
>
> std::this_function, however, may be beneficial in certain other ways,
> because it could also be used for introspection. I'd hate the verbosity of
> it, though :)
>
> Cheers,
> V.
>

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/51b9e2e1-8905-42a8-88f3-45a0a83b55be%40isocpp.org.

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

<div dir=3D"ltr">How about allowing local functions? It seems awkward to in=
vent a way to name lambdas when we already have named functions. The obviou=
s problem would be how to define the capture of the local function. I would=
 say, make it simple: Always imply a [&amp;] capture.<div><br></div><div>If=
 controllable capture is seen as a necessary feature I suggest to rephrase =
the previously suggested [&amp;]name(pars) {} style as:</div><div><br></div=
><div>Local functions are now allowed. Local functions with a trailing retu=
rn type may be preceeded by a capture clause instead of the auto keyword. I=
f no capture clause is explicitly given the default capture is equivalent t=
o [&amp;].</div><div><br></div><div>This would give us &quot;pascal style&q=
uot; local functions and solve the recursive lambda problem at the same tim=
e.</div><div><br></div><div>Is there a parsing problem with this that I fai=
l to see? Or is there some other subtle difference between a lambda and a n=
amed function that prevents allowing local functions with classic syntax?</=
div><div><br></div><div><br><br>Den torsdag 5 maj 2016 kl. 11:48:30 UTC+2 s=
krev Viacheslav Usov:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div><div class=3D"gmail_quote">On Thu, May 5, 2016 at 3:50 AM, Ar=
thur O&#39;Dwyer <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_b=
lank" gdf-obfuscated-mailto=3D"zwFhZwVhBgAJ" rel=3D"nofollow" onmousedown=
=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D=
&#39;javascript:&#39;;return true;">arthur....@gmail.com</a>&gt;</span> wro=
te:</div><div class=3D"gmail_quote"><br><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div=
 dir=3D"ltr"><div><font face=3D"courier new, monospace">auto f =3D fix([](a=
uto&amp;&amp; f) { f(); });</font></div><div><br></div><div>where fix is de=
fined as something like</div><div><br></div><div><font face=3D"courier new,=
 monospace">template&lt;class F&gt; auto fix(F fa) {</font></div><div><font=
 face=3D"courier new, monospace">=C2=A0 =C2=A0 return [fa](auto... args) {<=
/font></div><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=A0=
 =C2=A0 auto f =3D [&amp;](auto... args){ fa(f, args...) };</font></div><di=
v><font face=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 return =
f(args...);</font></div><div><font face=3D"courier new, monospace">=C2=A0 =
=C2=A0 }</font></div><div><font face=3D"courier new, monospace">}</font></d=
iv></div></blockquote><div><br></div><div>The wrapper must contain the orig=
inal lambda, by copy, move or reference. Containment by reference is unsafe=
.. Containment by move or copy can be impossible or have unexpected results.=
 The fundamental issue here is that what is supposed to be a &quot;recursiv=
e call to itself&quot; is a call to a <i>different</i>=C2=A0functional obje=
ct.</div><div><br></div><div>I touched upon this area in my original messag=
e very briefly, and my conclusion was that a lambda =C2=A0should have a way=
 to call <i>itself</i>, not some other object. In which case the issues of =
safety and correctness simply do not arise. I doubt it is possible to achie=
ve this with any library means, except perhaps through some magic std::this=
_function device callable from the body of a lambda (or, indeed, any functi=
on), but that is really just a way to extend the language without introduci=
ng a syntactical extension.</div><div><br></div><div>std::this_function, ho=
wever, may be beneficial in certain other ways, because it could also be us=
ed for introspection. I&#39;d hate the verbosity of it, though :)</div><div=
><br></div><div>Cheers,</div><div>V.</div></div></div></div>
</blockquote></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/51b9e2e1-8905-42a8-88f3-45a0a83b55be%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/51b9e2e1-8905-42a8-88f3-45a0a83b55be=
%40isocpp.org</a>.<br />

------=_Part_710_1715611346.1462475535642--
------=_Part_709_1008413585.1462475535641--

.

--001a114075ae7bc76b05321d3dd3
Content-Type: text/plain; charset=UTF-8

You can already make local function objects, where you can manage the
capture/state explicitly.
The only restriction is that local function objects may not have a template
member function, which is arguably a restriction we need to remove.

On 5 May 2016 at 20:12, Bengt Gustafsson <bengt.gustafsson@beamways.com>
wrote:

> How about allowing local functions? It seems awkward to invent a way to
> name lambdas when we already have named functions. The obvious problem
> would be how to define the capture of the local function. I would say, make
> it simple: Always imply a [&] capture.
>
> If controllable capture is seen as a necessary feature I suggest to
> rephrase the previously suggested [&]name(pars) {} style as:
>
> Local functions are now allowed. Local functions with a trailing return
> type may be preceeded by a capture clause instead of the auto keyword. If
> no capture clause is explicitly given the default capture is equivalent to
> [&].
>
> This would give us "pascal style" local functions and solve the recursive
> lambda problem at the same time.
>
> Is there a parsing problem with this that I fail to see? Or is there some
> other subtle difference between a lambda and a named function that prevents
> allowing local functions with classic syntax?
>
>
>
> Den torsdag 5 maj 2016 kl. 11:48:30 UTC+2 skrev Viacheslav Usov:
>>
>> On Thu, May 5, 2016 at 3:50 AM, Arthur O'Dwyer <arthur....@gmail.com>
>> wrote:
>>
>> auto f = fix([](auto&& f) { f(); });
>>>
>>> where fix is defined as something like
>>>
>>> template<class F> auto fix(F fa) {
>>>     return [fa](auto... args) {
>>>         auto f = [&](auto... args){ fa(f, args...) };
>>>         return f(args...);
>>>     }
>>> }
>>>
>>
>> The wrapper must contain the original lambda, by copy, move or reference.
>> Containment by reference is unsafe. Containment by move or copy can be
>> impossible or have unexpected results. The fundamental issue here is that
>> what is supposed to be a "recursive call to itself" is a call to a
>> *different* functional object.
>>
>> I touched upon this area in my original message very briefly, and my
>> conclusion was that a lambda  should have a way to call *itself*, not
>> some other object. In which case the issues of safety and correctness
>> simply do not arise. I doubt it is possible to achieve this with any
>> library means, except perhaps through some magic std::this_function device
>> callable from the body of a lambda (or, indeed, any function), but that is
>> really just a way to extend the language without introducing a syntactical
>> extension.
>>
>> std::this_function, however, may be beneficial in certain other ways,
>> because it could also be used for introspection. I'd hate the verbosity of
>> it, though :)
>>
>> Cheers,
>> V.
>>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/51b9e2e1-8905-42a8-88f3-45a0a83b55be%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/51b9e2e1-8905-42a8-88f3-45a0a83b55be%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALnjya_EWWrYnKOLMogUmiFZW9ZkhL3kPxgnqVQCX3yK2aW%2BXw%40mail.gmail.com.

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

<div dir=3D"ltr">You can already make local function objects, where you can=
 manage the capture/state explicitly.<div>The only restriction is that loca=
l function objects may not have a template member function, which is arguab=
ly a restriction we need to remove.<br><div class=3D"gmail_extra"><br><div =
class=3D"gmail_quote">On 5 May 2016 at 20:12, Bengt Gustafsson <span dir=3D=
"ltr">&lt;<a href=3D"mailto:bengt.gustafsson@beamways.com" target=3D"_blank=
">bengt.gustafsson@beamways.com</a>&gt;</span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr">How about allowing local functions? It seems=
 awkward to invent a way to name lambdas when we already have named functio=
ns. The obvious problem would be how to define the capture of the local fun=
ction. I would say, make it simple: Always imply a [&amp;] capture.<div><br=
></div><div>If controllable capture is seen as a necessary feature I sugges=
t to rephrase the previously suggested [&amp;]name(pars) {} style as:</div>=
<div><br></div><div>Local functions are now allowed. Local functions with a=
 trailing return type may be preceeded by a capture clause instead of the a=
uto keyword. If no capture clause is explicitly given the default capture i=
s equivalent to [&amp;].</div><div><br></div><div>This would give us &quot;=
pascal style&quot; local functions and solve the recursive lambda problem a=
t the same time.</div><div><br></div><div>Is there a parsing problem with t=
his that I fail to see? Or is there some other subtle difference between a =
lambda and a named function that prevents allowing local functions with cla=
ssic syntax?</div><div><br></div><div><br><br>Den torsdag 5 maj 2016 kl. 11=
:48:30 UTC+2 skrev Viacheslav Usov:<span class=3D""><blockquote class=3D"gm=
ail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;p=
adding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote">On Thu, M=
ay 5, 2016 at 3:50 AM, Arthur O&#39;Dwyer <span dir=3D"ltr">&lt;<a rel=3D"n=
ofollow">arthur....@gmail.com</a>&gt;</span> wrote:</div><div class=3D"gmai=
l_quote"><br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><font fac=
e=3D"courier new, monospace">auto f =3D fix([](auto&amp;&amp; f) { f(); });=
</font></div><div><br></div><div>where fix is defined as something like</di=
v><div><br></div><div><font face=3D"courier new, monospace">template&lt;cla=
ss F&gt; auto fix(F fa) {</font></div><div><font face=3D"courier new, monos=
pace">=C2=A0 =C2=A0 return [fa](auto... args) {</font></div><div><font face=
=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 auto f =3D [&amp;](=
auto... args){ fa(f, args...) };</font></div><div><font face=3D"courier new=
, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 return f(args...);</font></div><di=
v><font face=3D"courier new, monospace">=C2=A0 =C2=A0 }</font></div><div><f=
ont face=3D"courier new, monospace">}</font></div></div></blockquote><div><=
br></div><div>The wrapper must contain the original lambda, by copy, move o=
r reference. Containment by reference is unsafe. Containment by move or cop=
y can be impossible or have unexpected results. The fundamental issue here =
is that what is supposed to be a &quot;recursive call to itself&quot; is a =
call to a <i>different</i>=C2=A0functional object.</div><div><br></div><div=
>I touched upon this area in my original message very briefly, and my concl=
usion was that a lambda =C2=A0should have a way to call <i>itself</i>, not =
some other object. In which case the issues of safety and correctness simpl=
y do not arise. I doubt it is possible to achieve this with any library mea=
ns, except perhaps through some magic std::this_function device callable fr=
om the body of a lambda (or, indeed, any function), but that is really just=
 a way to extend the language without introducing a syntactical extension.<=
/div><div><br></div><div>std::this_function, however, may be beneficial in =
certain other ways, because it could also be used for introspection. I&#39;=
d hate the verbosity of it, though :)</div><div><br></div><div>Cheers,</div=
><div>V.</div></div></div></div>
</blockquote></span></div></div><span class=3D"">

<p></p>

-- <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" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/51b9e2e1-8905-42a8-88f3-45a0a83b55be%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/51b9e2e1-8905-=
42a8-88f3-45a0a83b55be%40isocpp.org</a>.<br>
</blockquote></div><br></div></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALnjya_EWWrYnKOLMogUmiFZW9ZkhL3kPxgn=
qVQCX3yK2aW%2BXw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALnjya_EWWrYnK=
OLMogUmiFZW9ZkhL3kPxgnqVQCX3yK2aW%2BXw%40mail.gmail.com</a>.<br />

--001a114075ae7bc76b05321d3dd3--

.

------=_Part_11_1552819940.1462478896757
Content-Type: multipart/alternative;
 boundary="----=_Part_12_349377178.1462478896757"

------=_Part_12_349377178.1462478896757
Content-Type: text/plain; charset=UTF-8

On Thursday, May 5, 2016 at 3:20:53 PM UTC-4, Mathias Gaunard wrote:
>
> You can already make local function objects, where you can manage the
> capture/state explicitly.
>

The cost in terms of code brevity between lambdas and local structs is
substantial. Lambdas offer way too many options for brevity. Captures,
dealing with `this` transparently, and so forth. Even if local structs
allowed template members, they're exceedingly verbose.

To me, we don't need recursive lambdas. What I think we need is a way to
name the lambda instance itself from within the lambda. With direct access
to that, we have recursive lambdas, but we also have the ability for the
lambda to do things like pass itself to someone or some-such.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/8fe18e75-d977-4cee-ab4a-47100417a442%40isocpp.org.

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

<div dir=3D"ltr">On Thursday, May 5, 2016 at 3:20:53 PM UTC-4, Mathias Gaun=
ard 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">You=
 can already make local function objects, where you can manage the capture/=
state explicitly.</div></blockquote><div><br>The cost in terms of code brev=
ity between lambdas and local structs is substantial. Lambdas offer way too=
 many options for brevity. Captures, dealing with `this` transparently, and=
 so forth. Even if local structs allowed template members, they&#39;re exce=
edingly verbose.<br></div><br>To me, we don&#39;t need recursive lambdas. W=
hat I think we need is a way to name the lambda instance itself from within=
 the lambda. With direct access to that, we have recursive lambdas, but we =
also have the ability for the lambda to do things like pass itself to someo=
ne or some-such.<br></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/8fe18e75-d977-4cee-ab4a-47100417a442%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/8fe18e75-d977-4cee-ab4a-47100417a442=
%40isocpp.org</a>.<br />

------=_Part_12_349377178.1462478896757--
------=_Part_11_1552819940.1462478896757--

.

------=_Part_211_1634604365.1462504424500
Content-Type: multipart/alternative;
 boundary="----=_Part_212_129498492.1462504424501"

------=_Part_212_129498492.1462504424501
Content-Type: text/plain; charset=UTF-8



On Wednesday, May 4, 2016 at 2:32:42 PM UTC-7, Richard Smith wrote:
>
> My preferred syntax for this is:
>
>   []fib(int n) {
>     if (n < 2)
>       return n;
>     return fib(n-1) + fib(n-2);
>   }
>
> where the name 'fib' within the lambda body is syntactic sugar for a
> reference to the lambda's 'operator()'.
>
> It'd be nice to be able to refer to the closure object itself within the
> lambda, to allow this sort of thing:
>
>   []self(int n) {
>     if (!ready) call_later(self);
>     else { ... }
>   }
>
> ... but there are practical problems with that because the type of 'self'
> would be incomplete until the '}', at least for lambdas with a
> capture-default.
>

I like your preferred syntax, provided that the name refers to the closure
object itself.  What is the underlying reason why the type needs to be
incomplete until the '}' for lambdas with a capture default?  Is there some
case in which, given this feature, the set of captured variables would
somehow depend on the type of the closure?

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/13bb6751-d5dc-42b4-82d8-b93ad55f367d%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Wednesday, May 4, 2016 at 2:32:42 PM UTC-7, Ric=
hard Smith wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr">My preferred syntax for this is:<div><br></div><div>=C2=A0 []fib(int n)=
 {</div><div>=C2=A0 =C2=A0 if (n &lt; 2)</div><div>=C2=A0 =C2=A0 =C2=A0 ret=
urn n;</div><div>=C2=A0 =C2=A0 return fib(n-1) + fib(n-2);</div><div>=C2=A0=
 }</div><div><br></div><div>where the name &#39;fib&#39; within the lambda =
body is syntactic sugar for a reference to the lambda&#39;s &#39;operator()=
&#39;. <br></div><div><br></div><div>It&#39;d be nice to be able to refer t=
o the closure object itself within the lambda, to allow this sort of thing:=
</div><div><br></div><div>=C2=A0 []self(int n) {</div><div>=C2=A0 =C2=A0 if=
 (!ready) call_later(self);</div><div>=C2=A0 =C2=A0 else { ... }</div><div>=
=C2=A0 }</div><div><br></div><div>... but there are practical problems with=
 that because the type of &#39;self&#39; would be incomplete until the &#39=
;}&#39;, at least for lambdas with a capture-default.</div></div></blockquo=
te><div>=C2=A0<br>I like your preferred syntax, provided that the name refe=
rs to the closure object itself.=C2=A0 What is the underlying reason why th=
e type needs to be incomplete until the &#39;}&#39; for lambdas with a capt=
ure default?=C2=A0 Is there some case in which, given this feature, the set=
 of captured variables would somehow depend on the type of the closure?<br>=
</div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/13bb6751-d5dc-42b4-82d8-b93ad55f367d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/13bb6751-d5dc-42b4-82d8-b93ad55f367d=
%40isocpp.org</a>.<br />

------=_Part_212_129498492.1462504424501--
------=_Part_211_1634604365.1462504424500--

.

--Apple-Mail=_F98ED015-E8BF-40AF-8245-23A42E3F7189
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2016=E2=80=9305=E2=80=9306, at 11:13 AM, Jeremy Maitin-Shepard <jeremy=
@jeremyms.com> wrote:
>=20
> I like your preferred syntax, provided that the name refers to the closur=
e object itself.  What is the underlying reason why the type needs to be in=
complete until the '}' for lambdas with a capture default?  Is there some c=
ase in which, given this feature, the set of captured variables would someh=
ow depend on the type of the closure?

Given if constexpr, assuming that captures don=E2=80=99t occur in uninstant=
iated blocks (I=E2=80=99m not checking now to see), it=E2=80=99s easy to co=
nstruct such an example.

Besides that, it gets rid of an implementation headache involving an extra =
parser pass dedicated to collecting captures.

--=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/6752B77A-D63F-4D4B-AF0D-2F204DB2D3C2%40gmail.com=
..

--Apple-Mail=_F98ED015-E8BF-40AF-8245-23A42E3F7189
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2016=E2=80=9305=
=E2=80=9306, at 11:13 AM, Jeremy Maitin-Shepard &lt;<a href=3D"mailto:jerem=
y@jeremyms.com" class=3D"">jeremy@jeremyms.com</a>&gt; wrote:</div><br clas=
s=3D"Apple-interchange-newline"><div class=3D""><div dir=3D"ltr" class=3D""=
>I like your preferred syntax, provided that the name refers to the closure=
 object itself.&nbsp; What is the underlying reason why the type needs to b=
e incomplete until the '}' for lambdas with a capture default?&nbsp; Is the=
re some case in which, given this feature, the set of captured variables wo=
uld somehow depend on the type of the closure?</div></div></blockquote><div=
><br class=3D""></div><div>Given <font face=3D"Courier" class=3D"">if const=
expr</font>, assuming that captures don=E2=80=99t occur in uninstantiated b=
locks (I=E2=80=99m not checking now to see), it=E2=80=99s easy to construct=
 such an example.</div></div><br class=3D""><div class=3D"">Besides that, i=
t gets rid of an implementation headache involving an extra parser pass ded=
icated to collecting captures.</div><div class=3D""><br class=3D""></div></=
body></html>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/6752B77A-D63F-4D4B-AF0D-2F204DB2D3C2%=
40gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/6752B77A-D63F-4D4B-AF0D-2F204DB2D3C2%=
40gmail.com</a>.<br />

--Apple-Mail=_F98ED015-E8BF-40AF-8245-23A42E3F7189--

.

--001a113f1d68d6ba90053228f537
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Top posting because I am responding to the thread in general, not to this
particular message.

I think we have two strong contenders:

1. Syntax proposed by Richard Smith [...] *name* (...), where the *name* is
"syntactic sugar for a reference to the lambda's 'operator()'"   More
details are to be found in Richard's email (May 4th) in this thread.

2. A magic library device proposed by me after a cue from Arthur O'Dwyer. A
provisional name for it is std::this_function, and it is essentially the
same "syntactic sugar for a reference to the lambda's 'operator()'" as per
Richard's proposal. The benefit here is that no syntactical extension is
required; another potential benefit is that the device can be used for
introspection in any functional context. The disadvantage is that it can
easily be more verbose, while brevity is important for lambdas. I think,
however, that this is not something that will be used very often, and its
prime use case - recursion - needs some control structure anyway, so we are
not talking about some *really* short lambdas here.

Comments?

Cheers,
V.

On Fri, May 6, 2016 at 9:34 AM, David Krauss <potswa@gmail.com> wrote:

>
> On 2016=E2=80=9305=E2=80=9306, at 11:13 AM, Jeremy Maitin-Shepard <jeremy=
@jeremyms.com>
> wrote:
>
> I like your preferred syntax, provided that the name refers to the closur=
e
> object itself.  What is the underlying reason why the type needs to be
> incomplete until the '}' for lambdas with a capture default?  Is there so=
me
> case in which, given this feature, the set of captured variables would
> somehow depend on the type of the closure?
>
>
> Given if constexpr, assuming that captures don=E2=80=99t occur in uninsta=
ntiated
> blocks (I=E2=80=99m not checking now to see), it=E2=80=99s easy to constr=
uct such an
> example.
>
> Besides that, it gets rid of an implementation headache involving an extr=
a
> parser pass dedicated to collecting captures.
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/6752B77A-D63=
F-4D4B-AF0D-2F204DB2D3C2%40gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/6752B77A-D6=
3F-4D4B-AF0D-2F204DB2D3C2%40gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r>
> .
>

--=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAA7YVg18S2g7XLt1iZO0%2BAby%2BEitLEWLAUuNpiLrMDv=
dP8c3mQ%40mail.gmail.com.

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

<div dir=3D"ltr">Top posting because I am responding to the thread in gener=
al, not to this particular message.<div><br></div><div>I think we have two =
strong contenders:</div><div><br></div><div>1. Syntax proposed by Richard S=
mith [...] <i>name</i>=C2=A0(...), where the <i>name</i> is &quot;<span sty=
le=3D"font-size:12.8px">syntactic sugar for a reference to the lambda&#39;s=
 &#39;operator()&#39;</span>&quot; =C2=A0 More details are to be found in R=
ichard&#39;s email (May 4th) in this thread.</div><div><br></div><div>2. A =
magic library device proposed by me after a cue from=C2=A0<span style=3D"fo=
nt-size:12.8px">Arthur O&#39;Dwyer. A provisional name for it is std::this_=
function, and it is essentially the same &quot;</span><span style=3D"font-s=
ize:12.8px">syntactic sugar for a reference to the lambda&#39;s &#39;operat=
or()&#39;</span><span style=3D"font-size:12.8px">&quot; as per Richard&#39;=
s proposal. The benefit here is that no syntactical extension is required; =
another potential benefit is that the device can be used for introspection =
in any functional context. The disadvantage is that it can easily be more v=
erbose, while brevity is important for lambdas. I think, however, that this=
 is not something that will be used very often, and its prime use case - re=
cursion - needs some control structure anyway, so we are not talking about =
some <i>really</i>=C2=A0short lambdas here.</span></div><div class=3D"gmail=
_extra"><br></div><div class=3D"gmail_extra">Comments?</div><div class=3D"g=
mail_extra"><br></div><div class=3D"gmail_extra">Cheers,</div><div class=3D=
"gmail_extra">V.</div><div class=3D"gmail_extra"><br><div class=3D"gmail_qu=
ote">On Fri, May 6, 2016 at 9:34 AM, David Krauss <span dir=3D"ltr">&lt;<a =
href=3D"mailto:potswa@gmail.com" target=3D"_blank">potswa@gmail.com</a>&gt;=
</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px=
 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:=
rgb(204,204,204);padding-left:1ex"><div style=3D"word-wrap:break-word"><br>=
<div><blockquote type=3D"cite"><div>On 2016=E2=80=9305=E2=80=9306, at 11:13=
 AM, Jeremy Maitin-Shepard &lt;<a href=3D"mailto:jeremy@jeremyms.com" targe=
t=3D"_blank">jeremy@jeremyms.com</a>&gt; wrote:</div><br><div><div dir=3D"l=
tr">I like your preferred syntax, provided that the name refers to the clos=
ure object itself.=C2=A0 What is the underlying reason why the type needs t=
o be incomplete until the &#39;}&#39; for lambdas with a capture default?=
=C2=A0 Is there some case in which, given this feature, the set of captured=
 variables would somehow depend on the type of the closure?</div></div></bl=
ockquote><div><br></div><div>Given <font face=3D"Courier">if constexpr</fon=
t>, assuming that captures don=E2=80=99t occur in uninstantiated blocks (I=
=E2=80=99m not checking now to see), it=E2=80=99s easy to construct such an=
 example.</div></div><br><div>Besides that, it gets rid of an implementatio=
n headache involving an extra parser pass dedicated to collecting captures.=
</div><span><font color=3D"#888888"><div><br></div></font></span></div><spa=
n><font color=3D"#888888">

<p></p>

-- <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" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/6752B77A-D63F-4D4B-AF0D-2F204DB2D3C2%=
40gmail.com?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/6752B77A-D63F-4=
D4B-AF0D-2F204DB2D3C2%40gmail.com</a>.<br>
</font></span></blockquote></div><br></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAA7YVg18S2g7XLt1iZO0%2BAby%2BEitLEWL=
AUuNpiLrMDvdP8c3mQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg18S2g7=
XLt1iZO0%2BAby%2BEitLEWLAUuNpiLrMDvdP8c3mQ%40mail.gmail.com</a>.<br />

--001a113f1d68d6ba90053228f537--

.

--001a113ba71695cf7005322a4ef2
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Fri, May 6, 2016 at 8:34 AM, David Krauss <potswa@gmail.com> wrote:

> On 2016=E2=80=9305=E2=80=9306, at 11:13 AM, Jeremy Maitin-Shepard <jeremy=
@jeremyms.com>
> wrote:
>
> I like your preferred syntax, provided that the name refers to the closur=
e
> object itself.  What is the underlying reason why the type needs to be
> incomplete until the '}' for lambdas with a capture default?  Is there so=
me
> case in which, given this feature, the set of captured variables would
> somehow depend on the type of the closure?
>
>
> Given if constexpr, assuming that captures don=E2=80=99t occur in uninsta=
ntiated
> blocks (I=E2=80=99m not checking now to see), it=E2=80=99s easy to constr=
uct such an
> example.
>

It's also easy to construct an example using overload resolution and the
rules on odr-usage of locally defined const primitives, adapted from
[expr.prim.lambda]/13:

void f(int (&)[1], int const&) {} // #1
void f(int (&)[sizeof(int)], int) {} // #2
void g() {
  int const i =3D 12;
  [=3D] self {
    int selector[sizeof(self)];
    f(selector, i);
  }();
}

If self is an empty class, #1 is selected, so i is odr-used, so self is
non-empty; if self is non-empty, #2 is selected, so i is not odr-used, so
self is empty.

--=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAJnLdObScHrB_n5ovcqMdKUvX_mnnYO8EUkqn-6PfJcT7s2=
2Yg%40mail.gmail.com.

--001a113ba71695cf7005322a4ef2
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 F=
ri, May 6, 2016 at 8:34 AM, David Krauss <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:potswa@gmail.com" target=3D"_blank">potswa@gmail.com</a>&gt;</span> w=
rote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-styl=
e:solid;padding-left:1ex"><div style=3D"word-wrap:break-word"><div><span cl=
ass=3D""><blockquote type=3D"cite"><div>On 2016=E2=80=9305=E2=80=9306, at 1=
1:13 AM, Jeremy Maitin-Shepard &lt;<a href=3D"mailto:jeremy@jeremyms.com" t=
arget=3D"_blank">jeremy@jeremyms.com</a>&gt; wrote:</div><br><div><div dir=
=3D"ltr">I like your preferred syntax, provided that the name refers to the=
 closure object itself.=C2=A0 What is the underlying reason why the type ne=
eds to be incomplete until the &#39;}&#39; for lambdas with a capture defau=
lt?=C2=A0 Is there some case in which, given this feature, the set of captu=
red variables would somehow depend on the type of the closure?</div></div><=
/blockquote><div><br></div></span><div>Given <font face=3D"Courier">if cons=
texpr</font>, assuming that captures don=E2=80=99t occur in uninstantiated =
blocks (I=E2=80=99m not checking now to see), it=E2=80=99s easy to construc=
t such an example.</div></div></div></blockquote></div><br></div><div class=
=3D"gmail_extra">It&#39;s also easy to construct an example using overload =
resolution and the rules on odr-usage of locally defined const primitives, =
adapted from [expr.prim.lambda]/13:</div><div class=3D"gmail_extra"><br></d=
iv><div class=3D"gmail_extra"><div class=3D"gmail_extra"><font face=3D"mono=
space, monospace">void f(int (&amp;)[1], int const&amp;) {} // #1</font></d=
iv><div class=3D"gmail_extra"><font face=3D"monospace, monospace">void f(in=
t (&amp;)[sizeof(int)], int) {} // #2</font></div><div class=3D"gmail_extra=
"><font face=3D"monospace, monospace">void g() {</font></div><div class=3D"=
gmail_extra"><font face=3D"monospace, monospace">=C2=A0 int const i =3D 12;=
<br></font></div><div class=3D"gmail_extra"><font face=3D"monospace, monosp=
ace">=C2=A0 [=3D] self {</font></div><div class=3D"gmail_extra"><font face=
=3D"monospace, monospace">=C2=A0 =C2=A0 int selector[sizeof(self)];</font><=
/div><div class=3D"gmail_extra"><font face=3D"monospace, monospace">=C2=A0 =
=C2=A0 f(selector, i);</font></div><div class=3D"gmail_extra"><font face=3D=
"monospace, monospace">=C2=A0 }();</font></div><div class=3D"gmail_extra"><=
font face=3D"monospace, monospace">}</font></div><div class=3D"gmail_extra"=
><br></div><div class=3D"gmail_extra">If self is an empty class, #1 is sele=
cted, so i is odr-used, so self is non-empty; if self is non-empty, #2 is s=
elected, so i is not odr-used, so self is empty.</div></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAJnLdObScHrB_n5ovcqMdKUvX_mnnYO8EUkq=
n-6PfJcT7s22Yg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdObScHrB_n5o=
vcqMdKUvX_mnnYO8EUkqn-6PfJcT7s22Yg%40mail.gmail.com</a>.<br />

--001a113ba71695cf7005322a4ef2--

.

------=_Part_609_1696625461.1462533717839
Content-Type: multipart/alternative;
 boundary="----=_Part_610_1403470588.1462533717840"

------=_Part_610_1403470588.1462533717840
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Perhaps I was not making myself clear earlier, but when I said local=20
function I meant local *function*, not local class with operator(). This is=
=20
the syntactical side of the suggestion, while semantically it would imply a=
=20
[&] capture:

int outer()
{
   int factor =3D 3;
   int inner(int x) {
     if (x =3D=3D 0)
        return 0;
     return x * factor + inner(x - 1);
   }

   return inner(3);
}

cout << outer(); // Prints 18 (if my head did the math right)



Then I suggested that if you absolutely need to be able to control the=20
capture an inner function with trailing return type could be allowed to=20
have a lambda introducer to specify something else than [&]:

int outer()
{
   int factor =3D 3;
   [factor]inner(int x)->int {
     ...
   }

   ...
}






Den fredag 6 maj 2016 kl. 12:56:13 UTC+2 skrev Edward Catmur:
>
> On Fri, May 6, 2016 at 8:34 AM, David Krauss <pot...@gmail.com=20
> <javascript:>> wrote:
>
>> On 2016=E2=80=9305=E2=80=9306, at 11:13 AM, Jeremy Maitin-Shepard <jer..=
..@jeremyms.com=20
>> <javascript:>> wrote:
>>
>> I like your preferred syntax, provided that the name refers to the=20
>> closure object itself.  What is the underlying reason why the type needs=
 to=20
>> be incomplete until the '}' for lambdas with a capture default?  Is ther=
e=20
>> some case in which, given this feature, the set of captured variables wo=
uld=20
>> somehow depend on the type of the closure?
>>
>>
>> Given if constexpr, assuming that captures don=E2=80=99t occur in uninst=
antiated=20
>> blocks (I=E2=80=99m not checking now to see), it=E2=80=99s easy to const=
ruct such an=20
>> example.
>>
>
> It's also easy to construct an example using overload resolution and the=
=20
> rules on odr-usage of locally defined const primitives, adapted from=20
> [expr.prim.lambda]/13:
>
> void f(int (&)[1], int const&) {} // #1
> void f(int (&)[sizeof(int)], int) {} // #2
> void g() {
>   int const i =3D 12;
>   [=3D] self {
>     int selector[sizeof(self)];
>     f(selector, i);
>   }();
> }
>
> If self is an empty class, #1 is selected, so i is odr-used, so self is=
=20
> non-empty; if self is non-empty, #2 is selected, so i is not odr-used, so=
=20
> self is empty.
>

--=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/1e70a376-4baf-4467-8fc5-82c055319fbf%40isocpp.or=
g.

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

<div dir=3D"ltr">Perhaps I was not making myself clear earlier, but when I =
said local function I meant local <i>function</i>, not local class with ope=
rator(). This is the syntactical side of the suggestion, while semantically=
 it would imply a [&amp;] capture:<div><br></div><div><div class=3D"prettyp=
rint" style=3D"border: 1px solid rgb(187, 187, 187); word-wrap: break-word;=
 background-color: rgb(250, 250, 250);"><code class=3D"prettyprint"><div cl=
ass=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-pret=
tify">int</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
outer</span><span style=3D"color: #660;" class=3D"styled-by-prettify">()</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0</span><spa=
n style=3D"color: #008;" class=3D"styled-by-prettify">int</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> factor </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #066;=
" class=3D"styled-by-prettify">3</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br>=C2=A0 =C2=A0</span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">int</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> inner</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">(</span><span style=3D"color: #008;" class=3D"styled-by-pretti=
fy">int</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> x<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><fo=
nt color=3D"#000000"><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> </span></font><span style=3D"color: #660;" class=3D"styled-by-prettify=
">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=
=A0 =C2=A0 =C2=A0</span><span style=3D"color: #008;" class=3D"styled-by-pre=
ttify">if</span><font color=3D"#666600"><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify">x </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
=3D=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </s=
pan><span style=3D"color: #066;" class=3D"styled-by-prettify">0</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"><br></span></font><span style=
=3D"color: #000;" class=3D"styled-by-prettify">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
</span><span style=3D"color: #008;" class=3D"styled-by-prettify">return</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><font =
color=3D"#006666"><span style=3D"color: #066;" class=3D"styled-by-prettify"=
>0</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span>=
</font><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0=
 =C2=A0 =C2=A0</span><span style=3D"color: #008;" class=3D"styled-by-pretti=
fy">return</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
 x </span><span style=3D"color: #660;" class=3D"styled-by-prettify">*</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> factor </span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">+</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> inner</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify">x </span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">-</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> </span><span style=3D"color: #066;" class=3D"styled-by-p=
rettify">1</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
);</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=
=A0 =C2=A0</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
}</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br>=
=C2=A0 =C2=A0</span><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">return</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
inner</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</sp=
an><span style=3D"color: #066;" class=3D"styled-by-prettify">3</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">}</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"><br><br>cout </span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">&lt;&lt;</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"> outer</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">();</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> </span><span style=3D"color: #800;" class=3D"styled-by-=
prettify">// Prints 18 (if my head did the math right)</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"><br><br><br></span></div></code=
></div><br>Then I suggested that if you absolutely need to be able to contr=
ol the capture an inner function with trailing return type could be allowed=
 to have a lambda introducer to specify something else than [&amp;]:</div><=
div><br></div><div><div class=3D"prettyprint" style=3D"border: 1px solid rg=
b(187, 187, 187); word-wrap: break-word; background-color: rgb(250, 250, 25=
0);"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=
=3D"color: #008;" class=3D"styled-by-prettify">int</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> outer</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>=C2=A0 =C2=A0</span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">int</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> factor </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> </span><span style=3D"color: #066;" class=3D"styled-by-prettify">3=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">[</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify">factor</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">]</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify">inner</span><span style=3D"color: =
#660;" 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">)-&gt;</span><span style=3D"color: #008;" class=3D"styled-by-pr=
ettify">int</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>=C2=A0 =C2=A0=
 =C2=A0</span><font color=3D"#000088"><span style=3D"color: #660;" class=3D=
"styled-by-prettify">...</span></font><span style=3D"color: #000;" class=3D=
"styled-by-prettify"><br>=C2=A0 =C2=A0</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">}</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br><br>=C2=A0 =C2=A0</span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">...</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">}</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br><br></span></div></code></div><br><div><br></div><div><br></di=
v><div><br><br>Den fredag 6 maj 2016 kl. 12:56:13 UTC+2 skrev Edward Catmur=
:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bo=
rder-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div cl=
ass=3D"gmail_quote">On Fri, May 6, 2016 at 8:34 AM, David Krauss <span dir=
=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailt=
o=3D"VjnaB0yzBgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascr=
ipt:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return=
 true;">pot...@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-lef=
t-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div sty=
le=3D"word-wrap:break-word"><div><span><blockquote type=3D"cite"><div>On 20=
16=E2=80=9305=E2=80=9306, at 11:13 AM, Jeremy Maitin-Shepard &lt;<a href=3D=
"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"VjnaB0yzBgAJ" rel=
=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;=
" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;">jer...@jeremym=
s.com</a>&gt; wrote:</div><br><div><div dir=3D"ltr">I like your preferred s=
yntax, provided that the name refers to the closure object itself.=C2=A0 Wh=
at is the underlying reason why the type needs to be incomplete until the &=
#39;}&#39; for lambdas with a capture default?=C2=A0 Is there some case in =
which, given this feature, the set of captured variables would somehow depe=
nd on the type of the closure?</div></div></blockquote><div><br></div></spa=
n><div>Given <font face=3D"Courier">if constexpr</font>, assuming that capt=
ures don=E2=80=99t occur in uninstantiated blocks (I=E2=80=99m not checking=
 now to see), it=E2=80=99s easy to construct such an example.</div></div></=
div></blockquote></div><br></div><div>It&#39;s also easy to construct an ex=
ample using overload resolution and the rules on odr-usage of locally defin=
ed const primitives, adapted from [expr.prim.lambda]/13:</div><div><br></di=
v><div><div><font face=3D"monospace, monospace">void f(int (&amp;)[1], int =
const&amp;) {} // #1</font></div><div><font face=3D"monospace, monospace">v=
oid f(int (&amp;)[sizeof(int)], int) {} // #2</font></div><div><font face=
=3D"monospace, monospace">void g() {</font></div><div><font face=3D"monospa=
ce, monospace">=C2=A0 int const i =3D 12;<br></font></div><div><font face=
=3D"monospace, monospace">=C2=A0 [=3D] self {</font></div><div><font face=
=3D"monospace, monospace">=C2=A0 =C2=A0 int selector[sizeof(self)];</font><=
/div><div><font face=3D"monospace, monospace">=C2=A0 =C2=A0 f(selector, i);=
</font></div><div><font face=3D"monospace, monospace">=C2=A0 }();</font></d=
iv><div><font face=3D"monospace, monospace">}</font></div><div><br></div><d=
iv>If self is an empty class, #1 is selected, so i is odr-used, so self is =
non-empty; if self is non-empty, #2 is selected, so i is not odr-used, so s=
elf is empty.</div></div></div>
</blockquote></div></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/1e70a376-4baf-4467-8fc5-82c055319fbf%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/1e70a376-4baf-4467-8fc5-82c055319fbf=
%40isocpp.org</a>.<br />

------=_Part_610_1403470588.1462533717840--
------=_Part_609_1696625461.1462533717839--

.

On 6 May 2016 at 14:21, Bengt Gustafsson <bengt.gustafsson@beamways.com> wrote:
> Perhaps I was not making myself clear earlier, but when I said local
> function I meant local function, not local class with operator(). This is
> the syntactical side of the suggestion, while semantically it would imply a
> [&] capture:
>
> int outer()
> {
>    int factor = 3;
>    int inner(int x) {
>      if (x == 0)
>         return 0;
>      return x * factor + inner(x - 1);
>    }
>
>    return inner(3);
> }


Do remember that local function definitions aren't currently allowed,
but local function declarations are,
with well-defined meaning that we can't change due to too much
existing code relying on it.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUYQPfbtyMaru-7JF6LxFczzjVdvauuo1tFTumAyYa%2BHTA%40mail.gmail.com.

.

------=_Part_364_158140705.1462553370321
Content-Type: multipart/alternative;
 boundary="----=_Part_365_1464011451.1462553370322"

------=_Part_365_1464011451.1462553370322
Content-Type: text/plain; charset=UTF-8


>
>
> It's also easy to construct an example using overload resolution and the
> rules on odr-usage of locally defined const primitives, adapted from
> [expr.prim.lambda]/13:
>
> void f(int (&)[1], int const&) {} // #1
> void f(int (&)[sizeof(int)], int) {} // #2
> void g() {
>   int const i = 12;
>   [=] self {
>     int selector[sizeof(self)];
>     f(selector, i);
>   }();
> }
>
> If self is an empty class, #1 is selected, so i is odr-used, so self is
> non-empty; if self is non-empty, #2 is selected, so i is not odr-used, so
> self is empty.
>

This is amazing. Nicely done.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/3c3063b1-c965-4d85-849c-68fd295e79bb%40isocpp.org.

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

<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><br></di=
v><div>It&#39;s also easy to construct an example using overload resolution=
 and the rules on odr-usage of locally defined const primitives, adapted fr=
om [expr.prim.lambda]/13:</div><div><br></div><div><div><font face=3D"monos=
pace, monospace">void f(int (&amp;)[1], int const&amp;) {} // #1</font></di=
v><div><font face=3D"monospace, monospace">void f(int (&amp;)[sizeof(int)],=
 int) {} // #2</font></div><div><font face=3D"monospace, monospace">void g(=
) {</font></div><div><font face=3D"monospace, monospace">=C2=A0 int const i=
 =3D 12;<br></font></div><div><font face=3D"monospace, monospace">=C2=A0 [=
=3D] self {</font></div><div><font face=3D"monospace, monospace">=C2=A0 =C2=
=A0 int selector[sizeof(self)];</font></div><div><font face=3D"monospace, m=
onospace">=C2=A0 =C2=A0 f(selector, i);</font></div><div><font face=3D"mono=
space, monospace">=C2=A0 }();</font></div><div><font face=3D"monospace, mon=
ospace">}</font></div><div><br></div><div>If self is an empty class, #1 is =
selected, so i is odr-used, so self is non-empty; if self is non-empty, #2 =
is selected, so i is not odr-used, so self is empty.</div></div></div></blo=
ckquote><div><br></div><div>This is amazing. Nicely done. =C2=A0</div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/3c3063b1-c965-4d85-849c-68fd295e79bb%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/3c3063b1-c965-4d85-849c-68fd295e79bb=
%40isocpp.org</a>.<br />

------=_Part_365_1464011451.1462553370322--
------=_Part_364_158140705.1462553370321--

.

--_000_9FDB7A8A8AF7CC4DB0D7FA433D60672F583D0228xirpvexmbx01xln_
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


From: Nicol Bolas [mailto:jmckesson@gmail.com]
Sent: 05 May 2016 21:08
To: ISO C++ Standard - Future Proposals
Subject: Re: [std-proposals] Re: recursive lambdas

On Thursday, May 5, 2016 at 3:20:53 PM UTC-4, Mathias Gaunard wrote:
You can already make local function objects, where you can manage the captu=
re/state explicitly.

The cost in terms of code brevity between lambdas and local structs is subs=
tantial. Lambdas offer way too many options for brevity. Captures, dealing =
with `this` transparently, and so forth. Even if local structs allowed temp=
late members, they're exceedingly verbose.

To me, we don't need recursive lambdas. What I think we need is a way to na=
me the lambda instance itself from within the lambda. With direct access to=
 that, we have recursive lambdas, but we also have the ability for the lamb=
da to do things like pass itself to someone or some-such.

[Ronan] In the SYCL-inspired proposal ( http://www.open-std.org/jtc1/sc22/w=
g21/docs/papers/2016/p0236r0.pdf ), we need named lambda too to be able to =
call the off-loaded lambda on the accelerator whereas it has been compiled =
with another compiler. If 2 different compilers are used for the host code =
and the accelerator code, different (unspecified) internal naming conventio=
ns may be used that renders the interop at link time level difficult.

For now we put the name in template parameters for this purpose as dummy cl=
ass such as =E2=80=9Cnothing=E2=80=9D below to give this name
    myQueue.submit([&](handler &cgh) {
        auto acc =3D a.get_access<access::write>(cgh);
        cgh.parallel_for<class nothing>(range<1> { N }, /* Offset */ id<1> =
{ 7 },
                                        [=3D] (item<1> index) {
                                          acc[index[0] - 7] =3D index[0];
                                        });
      });

So if there is a proposal to name lambdas, I am in!
--
Ronan Keryell, Xilinx Research Labs / Ireland.



This email and any attachments are intended for the sole use of the named r=
ecipient(s) and contain(s) confidential information that may be proprietary=
, privileged or copyrighted under applicable law. If you are not the intend=
ed recipient, do not read, copy, or forward this email message or any attac=
hments. Delete this email message and any attachments immediately.

--=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/9FDB7A8A8AF7CC4DB0D7FA433D60672F583D0228%40xir-p=
vexmbx01.xlnx.xilinx.com.

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

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf-8">
<meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
 {font-family:"Cambria Math";
 panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
 {font-family:Calibri;
 panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
 {margin:0cm;
 margin-bottom:.0001pt;
 font-size:12.0pt;
 font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
 {mso-style-priority:99;
 color:blue;
 text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
 {mso-style-priority:99;
 color:purple;
 text-decoration:underline;}
p
 {mso-style-priority:99;
 mso-margin-top-alt:auto;
 margin-right:0cm;
 mso-margin-bottom-alt:auto;
 margin-left:0cm;
 font-size:12.0pt;
 font-family:"Times New Roman","serif";}
span.EmailStyle18
 {mso-style-type:personal-reply;
 font-family:"Calibri","sans-serif";
 color:#1F497D;}
..MsoChpDefault
 {mso-style-type:export-only;
 font-size:10.0pt;}
@page WordSection1
 {size:612.0pt 792.0pt;
 margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
 {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-GB" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D;mso-fareast-language:EN-US=
"><o:p>&nbsp;</o:p></span></p>
<div style=3D"border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm =
4.0pt">
<div>
<div style=3D"border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm =
0cm 0cm">
<p class=3D"MsoNormal"><b><span lang=3D"EN-US" style=3D"font-size:11.0pt;fo=
nt-family:&quot;Calibri&quot;,&quot;sans-serif&quot;">From:</span></b><span=
 lang=3D"EN-US" style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&=
quot;sans-serif&quot;"> Nicol Bolas [mailto:jmckesson@gmail.com]
<br>
<b>Sent:</b> 05 May 2016 21:08<br>
<b>To:</b> ISO C&#43;&#43; Standard - Future Proposals<br>
<b>Subject:</b> Re: [std-proposals] Re: recursive lambdas<o:p></o:p></span>=
</p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<div>
<p class=3D"MsoNormal">On Thursday, May 5, 2016 at 3:20:53 PM UTC-4, Mathia=
s Gaunard wrote:<o:p></o:p></p>
<blockquote style=3D"border:none;border-left:solid #CCCCCC 1.0pt;padding:0c=
m 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-=
bottom:5.0pt">
<div>
<p class=3D"MsoNormal">You can already make local function objects, where y=
ou can manage the capture/state explicitly.<o:p></o:p></p>
</div>
</blockquote>
<div>
<p class=3D"MsoNormal"><br>
The cost in terms of code brevity between lambdas and local structs is subs=
tantial. Lambdas offer way too many options for brevity. Captures, dealing =
with `this` transparently, and so forth. Even if local structs allowed temp=
late members, they're exceedingly
 verbose.<o:p></o:p></p>
</div>
<p class=3D"MsoNormal"><br>
To me, we don't need recursive lambdas. What I think we need is a way to na=
me the lambda instance itself from within the lambda. With direct access to=
 that, we have recursive lambdas, but we also have the ability for the lamb=
da to do things like pass itself
 to someone or some-such.<o:p></o:p></p>
</div>
</div>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><b><i><span style=3D"font-size:11.0pt;font-family:&q=
uot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">[Ronan] In the SYCL=
-inspired proposal (
<a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0236r0.=
pdf">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0236r0.pdf</a=
> ), we need named lambda too to be able to call the off-loaded lambda on t=
he accelerator whereas it has been
 compiled with another compiler. If 2 different compilers are used for the =
host code and the accelerator code, different (unspecified) internal naming=
 conventions may be used that renders the interop at link time level diffic=
ult.<o:p></o:p></span></i></b></p>
<p class=3D"MsoNormal"><b><i><span style=3D"font-size:11.0pt;font-family:&q=
uot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></=
span></i></b></p>
<p class=3D"MsoNormal"><b><i><span style=3D"font-size:11.0pt;font-family:&q=
uot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">For now we put the =
name in template parameters for this purpose as dummy class such as =E2=80=
=9Cnothing=E2=80=9D below to give this name<o:p></o:p></span></i></b></p>
<p class=3D"MsoNormal"><b><i><span style=3D"font-size:11.0pt;font-family:&q=
uot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">&nbsp;&nbsp;&nbsp; =
myQueue.submit([&amp;](handler &amp;cgh) {<o:p></o:p></span></i></b></p>
<p class=3D"MsoNormal"><b><i><span style=3D"font-size:11.0pt;font-family:&q=
uot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp; auto acc =3D a.get_access&lt;access::write&gt;(cgh)=
;<o:p></o:p></span></i></b></p>
<p class=3D"MsoNormal"><b><i><span style=3D"font-size:11.0pt;font-family:&q=
uot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp; cgh.parallel_for&lt;class nothing&gt;(range&lt;1&gt=
; { N }, /* Offset */ id&lt;1&gt; { 7 },<o:p></o:p></span></i></b></p>
<p class=3D"MsoNormal"><b><i><span style=3D"font-size:11.0pt;font-family:&q=
uot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[=3D] (it=
em&lt;1&gt; index) {<o:p></o:p></span></i></b></p>
<p class=3D"MsoNormal"><b><i><span style=3D"font-size:11.0pt;font-family:&q=
uot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; acc[index[0] - 7] =3D index[0];<o:p></o:p></span></i></b></p>
<p class=3D"MsoNormal"><b><i><span style=3D"font-size:11.0pt;font-family:&q=
uot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; });<o:p><=
/o:p></span></i></b></p>
<p class=3D"MsoNormal"><b><i><span style=3D"font-size:11.0pt;font-family:&q=
uot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp; });<o:p></o:p></span></i></b></p>
<p class=3D"MsoNormal"><b><i><span style=3D"font-size:11.0pt;font-family:&q=
uot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></=
span></i></b></p>
<p class=3D"MsoNormal"><b><i><span style=3D"font-size:11.0pt;font-family:&q=
uot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">So if there is a pr=
oposal to name lambdas, I am in!<o:p></o:p></span></i></b></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">--
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Ronan Keryell, Xilinx Res=
earch Labs / Ireland.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><b><i><span style=3D"font-size:11.0pt;font-family:&q=
uot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></=
span></i></b></p>
</div>
<br>
<br>
This email and any attachments are intended for the sole use of the named r=
ecipient(s) and contain(s) confidential information that may be proprietary=
, privileged or copyrighted under applicable law. If you are not the intend=
ed recipient, do not read, copy,
 or forward this email message or any attachments. Delete this email messag=
e and any attachments immediately.
<br>
<br>
</body>
</html>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/9FDB7A8A8AF7CC4DB0D7FA433D60672F583D0=
228%40xir-pvexmbx01.xlnx.xilinx.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/9FDB7A8A8AF7C=
C4DB0D7FA433D60672F583D0228%40xir-pvexmbx01.xlnx.xilinx.com</a>.<br />

--_000_9FDB7A8A8AF7CC4DB0D7FA433D60672F583D0228xirpvexmbx01xln_--

.