Topic: An abbreviated lambda syntax
Author: Barry Revzin <barry.revzin@gmail.com>
Date: Tue, 11 Oct 2016 10:32:57 -0700 (PDT)
Raw View
------=_Part_677_1064360153.1476207177562
Content-Type: multipart/alternative;
boundary="----=_Part_678_1145372697.1476207177563"
------=_Part_678_1145372697.1476207177563
Content-Type: text/plain; charset=UTF-8
Here is a contrasting proposal for how to handle overload sets as function
arguments. While a lot more verbose in the simple case of just naming a
function (where instead of just naming the function you have to actually
enumerate the arguments list twice), I think it offers more flexibility in
writing short lambdas. There are some motivating examples in the proposal.
It's also getting pretty verbose to write correct generic functions with
regards to SFINAE and noexcept, so this attempts to make it a little bit
easier - at least in the easy case.
Also I'm proposing a shorter syntax for forwarding arguments. I picked
unary>> because it looks like moving something forward but really anything
shorter would be nice. std::forward<Arg>(arg) is particularly verbose,
especially in a generic lambda where you have to write
std::forward<decltype(arg)>(arg), where the actual forwarding just
dominates the code itself.
--
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/63ddd09e-d05f-49a4-ae6c-6adf833376f9%40isocpp.org.
------=_Part_678_1145372697.1476207177563
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Here is a contrasting proposal for how to handle overload =
sets as function arguments. While a lot more verbose in the simple case of =
just naming a function (where instead of just naming the function you have =
to actually enumerate the arguments list twice), I think it offers more fle=
xibility in writing short lambdas. There are some motivating examples in th=
e proposal. It's also getting pretty verbose to write correct generic f=
unctions with regards to SFINAE and noexcept, so this attempts to make it a=
little bit easier - at least in the easy case.=C2=A0<div><div><br></div><d=
iv>Also I'm proposing a shorter syntax for forwarding arguments. I pick=
ed unary>> because it looks like moving something forward but really =
anything shorter would be nice. <font face=3D"courier new, monospace">std::=
forward<Arg>(arg)</font> is particularly verbose, especially in a gen=
eric lambda where you have to write <font face=3D"courier new, monospace">s=
td::forward<decltype(arg)>(arg)</font><font face=3D"arial, sans-serif=
">, where the actual forwarding just dominates the code itself.=C2=A0</font=
></div><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" 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/63ddd09e-d05f-49a4-ae6c-6adf833376f9%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/63ddd09e-d05f-49a4-ae6c-6adf833376f9=
%40isocpp.org</a>.<br />
------=_Part_678_1145372697.1476207177563--
------=_Part_677_1064360153.1476207177562
Content-Type: text/html; charset=US-ASCII; name=abbrev_lambda.html
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename=abbrev_lambda.html
X-Attachment-Id: 77f0cb27-b544-4ccc-b2f6-524164b3821d
Content-ID: <77f0cb27-b544-4ccc-b2f6-524164b3821d>
<html>
<head>
<title>abbreviated lambdas</title>
<style>
p {text-align:justify}
li {text-align:justify}
blockquote.note
{
background-color:#E0E0E0;
padding-left: 15px;
padding-right: 15px;
padding-top: 1px;
padding-bottom: 1px;
}
ins {color:#00A000}
del {color:#A00000}
code {white-space:pre;}
</style>
</head>
<body>
<address align=right>
Document number: DxxxxR0<br>
<br/>
<a href="mailto:barry.revzin@gmail.com">Barry Revzin</a><br/>
2016-10-10<br/>
</address>
<hr/>
<h1 align=center>Abbreviated Lambdas for fun and profit</h1>
<h2>Contents</h2>
<ul>
<li><a href="#Motivation">Motivation</a></li>
<li><a href="#Proposal">Proposal</a></li>
<li><a href="#Examples">Examples</a></li>
<li><a href="#Effects">Effects on Existing Code</a></li>
</ul>
<a name="Motivation"></a><h2>Motivation</h2>
<p>There are two, somewhat related motivations for an abbreviated lambda syntax. The first is to address the problem of trying to pass in overload sets as function arguments [1]:
<blockquote><pre>
template <class T>
T twice(T x) { return x + x; }
template <class I>
void f(I first, I last) {
transform(first, last, twice); // error
}
</pre></blockquote>
C++14 generic lambdas allow us a way to solve this problem by just wrapping the overloaded name in a lambda:
<blockquote><pre>
transform(first, last, [](auto&& x) {
return twice(std::forward<decltype(x)>(x));
});
</pre></blockquote>
<p>But that isn't actually correct, although it's the "obvious" code that most people would produce. It's not SFINAE-friendly and it's not <code>noexcept</code>-correct. Which could lead to avoidable errors:
<blockquote><pre>
struct Widget;
bool test(int );
bool test(Widget );
void invoke(std::function<bool(int)> ); // #1
void invoke(std::function<bool(std::string)> ); // #2
// error: unresolved overloaded function type
invoke(test);
// still error: no known conversion from std::string to int or Widget
invoke([](auto&& x) {
return test(std::forward<decltype(x)>(x));
});
</pre></blockquote>
You'd really have to write:
<blockquote><code>// OK: calls #1
<font color="blue"><b>invoke</b></font>([](auto&& <font color="blue"><b>x</b></font>) noexcept(noexcept(test(std::forward<decltype(x)>(x))))
-> decltype(test(std::forward<decltype(x)>(x)))
{
return <font color="blue"><b>test</b></font>(std::<font color="blue"><b>forward</b></font><decltype(x)>(<font color="blue"><b>x</b></font>));
});
</code></blockquote>
<p>And that's a lot to have to type. Which brings me to the second motivation: not having to write that. For simple lambdas, those lambdas whose entire body is <code>return expr;</code>, the noisy stuff you have to write to get it correct where you need to use it just drowns out the signal of what it was you wanted your lambda to do in the first place. That is assuming that I succeed in writing the same code in all three places without accidentally introducing subtle differences.
<p>Arguably the only important code in the above block is that which has been marked in <font color="blue"><b>blue</b></font>. All I want to do is <code>test(x)</code>, why so much boilerplate?
<a name="Proposal"></a><h2>Proposal</h2>
<p>This paper proposes the creation of a new lambda introducer, <code>=></code>, which allows for a single expression in the body that will be its return. This will synthesize a SFINAE-friendly, <code>noexcept</code>-correct lambda by doing the code triplication for you.
<p>At its simplest:
<blockquote><pre>
[](auto&& x) => test(x)
</pre></blockquote>
shall be exactly equivalent to the lambda:
<blockquote><pre>
[](auto&& x) noexcept(noexcept(test(x))) -> decltype(test(x)) {
return test(x);
}
</pre></blockquote>
But since <code>auto&&</code> has become such a regular choice of argument for lambdas, that too can become optional. An omitted type would be assumed as <code>auto&&</code>. Moreover, since the token <code>=></code> cannot appear in C++ code currently, we can even make the capture brackets optional for no-capture lambdas. And, for non-capturing lambdas that take a single argument, the parentheses around the argument can be optional as well. That is, introducing:
<blockquote><pre>
[](x) => test(x) // equivalent to the above
(x) => test(x) // equivalent to the above
x => test(x) // equivalent to the above
</pre></blockquote>
Multiple arguments would still have to be parenthesized.
</p>
<p>One of the last sources of boilerplate is <code>std::forward</code>. In a lot of generic code, the uses of <code>forward</code> overwhelm all the rest of the code, to the point where many talks and examples just omit references entirely to save space. I'm occasionally tempted to introduce a macro (<code>#define FWD(x) decltype(x)(x)</code>) which is just wrong. This paper would like to see a shorter way to forward arguments and proposes non-overloadable unary <code>operator >></code>. Putting it all together we get:
<blockquote><pre>
// old way
transform(first, last, [](auto&& x) noexcept(noexcept(test(std::forward<decltype(x)>(x))))
-> decltype(test(std::forward<decltype(x)>(x)))
{
return test(std::forward<decltype(x)>(x));
});
// proposed new way
transform(first, last, x => twice(>>x));
</pre></blockquote>
<a name="Examples"></a><h2>Examples</h2>
<p>Other examples of improved usage as compared to C++14 best practices.
<p>Sorting in decreasing order: roughly comparable typing, but arguably clearer:
<blockquote><pre>
std::sort(begin(v), end(v), std::greater<>{}); // C++14
std::sort(begin(v), end(v), (x,y) => x > y); // this proposal
</pre></blockquote>
<p>Sorting in decreasing order by ID
<blockquote><pre>
std::sort(begin(v), end(v), [](auto&& x, auto&& y) { return x.id > y.id; }); // C++14
std::sort(begin(v), end(v), std::greater<>{}, &Object::id); // ranges with projections
std::sort(begin(v), end(v), (x,y) => x.id > y.id); // this proposal
</pre></blockquote>
<p>Calling an overload where SFINAE matters and getting it wrong is a mess:
<blockquote><pre>
bool invoke(std::function<bool(int)> f); // #1
bool invoke(std::function<bool(std::string)> f); // #2
invoke([](auto x) { return x == 2; }); // error! (283 lines of diagnostic on gcc)
invoke([](auto x) -> decltype(x == 2) { return x == 2; }); // OK C++14: calls #1
invoke(x => x == 2); // OK this proposal: calls #1
</pre></blockquote>
<p>Binding an overloaded member function that takes arbitrarily many arguments to an instance, even without <code>noexcept</code>-correctness:
<blockquote><pre>
// C++14
[&obj](auto&&... args) -> decltype(obj.func(std::forward<decltype(args)>(args)...) {
return obj.func(std::forward<decltype(args)>(args));
};
// this proposal
[&obj](auto&&... args) => obj.func(>>args...)
</pre></blockquote>
<p>Chaining lots of functions together from range-v3: summing the squares under 1000:
<blockquote><pre>
// C++14
int sum = accumulate(ints(1)
| transform([](int i){ return i*i; })
| take_while([](int i){ return i < 1000; }));
// this proposal
int sum = accumulate(ints(1) | transform(i => i*i) | take_while(i => i < 1000));
// with UFCS
int sum = ints(1).transform(i => i*i).take_while(i => i < 1000).accumulate();
</pre></blockquote>
<a name="Effects"></a><h2>Effects on Existing Code</h2>
Neither the token <code>=></code> nor a usage of unary <code>operator>></code> can appear in legal code today, so no currently existing code behavior would be changed. This is a pure language extension.
<p> [1] <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0119r2.pdf">Overload sets as function arguments</a>
</body>
</html>
------=_Part_677_1064360153.1476207177562--
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Tue, 11 Oct 2016 10:48:40 -0700
Raw View
--001a1147cbeca650d0053e9a7c63
Content-Type: text/plain; charset=UTF-8
On Tue, Oct 11, 2016 at 10:32 AM, Barry Revzin <barry.revzin@gmail.com>
wrote:
> Here is a contrasting proposal for how to handle overload sets as function
> arguments. While a lot more verbose in the simple case of just naming a
> function (where instead of just naming the function you have to actually
> enumerate the arguments list twice), I think it offers more flexibility in
> writing short lambdas. There are some motivating examples in the proposal.
> It's also getting pretty verbose to write correct generic functions with
> regards to SFINAE and noexcept, so this attempts to make it a little bit
> easier - at least in the easy case.
>
> Also I'm proposing a shorter syntax for forwarding arguments. I picked
> unary>> because it looks like moving something forward but really anything
> shorter would be nice. std::forward<Arg>(arg) is particularly verbose,
> especially in a generic lambda where you have to write
> std::forward<decltype(arg)>(arg), where the actual forwarding just
> dominates the code itself.
>
Seems like an interesting approach.
Minor correction to your "Effects on Existing Code" section: the character
sequence => can appear in legal C++ programs today. For instance,
X<&Y::operator=>. That said, I've searched a large codebase for this
(>100MLoC) and the only occurrence of => (outside of comments, string
literals, etc.) was in a compiler test suite.
--
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%3DJZaxZ2YgYdwpFsRfj49Q-%2BWG%3DYOnssHP%3DjLozXfai2A%40mail.gmail.com.
--001a1147cbeca650d0053e9a7c63
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, Oct 11, 2016 at 10:32 AM, Barry Revzin <span dir=3D"ltr"><<a href=3D=
"mailto:barry.revzin@gmail.com" target=3D"_blank">barry.revzin@gmail.com</a=
>></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">Here=
is a contrasting proposal for how to handle overload sets as function argu=
ments. While a lot more verbose in the simple case of just naming a functio=
n (where instead of just naming the function you have to actually enumerate=
the arguments list twice), I think it offers more flexibility in writing s=
hort lambdas. There are some motivating examples in the proposal. It's =
also getting pretty verbose to write correct generic functions with regards=
to SFINAE and noexcept, so this attempts to make it a little bit easier - =
at least in the easy case.=C2=A0<div><div><br></div><div>Also I'm propo=
sing a shorter syntax for forwarding arguments. I picked unary>> beca=
use it looks like moving something forward but really anything shorter woul=
d be nice. <font face=3D"courier new, monospace">std::forward<Arg>(ar=
g)</font> is particularly verbose, especially in a generic lambda where you=
have to write <font face=3D"courier new, monospace">std::forward<declty=
pe(arg)>(<wbr>arg)</font><font face=3D"arial, sans-serif">, where the ac=
tual forwarding just dominates the code itself.=C2=A0</font></div></div></d=
iv></blockquote><div><br></div><div>Seems like an interesting approach.</di=
v><div><br></div><div>Minor correction to your "Effects on Existing Co=
de" section: the character sequence =3D> can appear in legal C++ pr=
ograms today. For instance, X<&Y::operator=3D>. That said, I'=
ve searched a large codebase for this (>100MLoC) and the only occurrence=
of =3D> (outside of comments, string literals, etc.) was in a compiler =
test suite.</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" 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%3DJZaxZ2YgYdwpFsRfj49Q-%2BWG%=
3DYOnssHP%3DjLozXfai2A%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQq%3=
DJZaxZ2YgYdwpFsRfj49Q-%2BWG%3DYOnssHP%3DjLozXfai2A%40mail.gmail.com</a>.<br=
/>
--001a1147cbeca650d0053e9a7c63--
.
Author: szollosi.lorand@gmail.com
Date: Tue, 11 Oct 2016 13:37:41 -0700 (PDT)
Raw View
------=_Part_1031_1833740448.1476218261518
Content-Type: multipart/alternative;
boundary="----=_Part_1032_1393171386.1476218261518"
------=_Part_1032_1393171386.1476218261518
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Hi,
Also, some corner cases like default argument values and variables already=
=20
defined are on the list you might want to address. Like `auto x =3D x =3D> =
x =3D>=20
x =3D>x;` and `auto x =3D x =3D> x =3D x =3D> x =3D x;` are non-obvious to =
me. (`Is =3D=20
x` an assignment / initialization in caller (later called) code, or a=20
default parameter value?)
My wishlist entry is support for short nullary lambdas in addition to these=
..
Thanks,
-lorro
2016. okt=C3=B3ber 11., kedd 19:48:46 UTC+2 id=C5=91pontban Richard Smith a=
=20
k=C3=B6vetkez=C5=91t =C3=ADrta:
>
> On Tue, Oct 11, 2016 at 10:32 AM, Barry Revzin <barry....@gmail.com=20
> <javascript:>> wrote:
>
>> Here is a contrasting proposal for how to handle overload sets as=20
>> function arguments. While a lot more verbose in the simple case of just=
=20
>> naming a function (where instead of just naming the function you have to=
=20
>> actually enumerate the arguments list twice), I think it offers more=20
>> flexibility in writing short lambdas. There are some motivating examples=
in=20
>> the proposal. It's also getting pretty verbose to write correct generic=
=20
>> functions with regards to SFINAE and noexcept, so this attempts to make =
it=20
>> a little bit easier - at least in the easy case.=20
>>
>> Also I'm proposing a shorter syntax for forwarding arguments. I picked=
=20
>> unary>> because it looks like moving something forward but really anythi=
ng=20
>> shorter would be nice. std::forward<Arg>(arg) is particularly verbose,=
=20
>> especially in a generic lambda where you have to write=20
>> std::forward<decltype(arg)>(arg), where the actual forwarding just=20
>> dominates the code itself.=20
>>
>
> Seems like an interesting approach.
>
> Minor correction to your "Effects on Existing Code" section: the characte=
r=20
> sequence =3D> can appear in legal C++ programs today. For instance,=20
> X<&Y::operator=3D>. That said, I've searched a large codebase for this=20
> (>100MLoC) and the only occurrence of =3D> (outside of comments, string=
=20
> literals, etc.) was in a compiler test suite.
>
--=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/5cd58eef-df4a-4ef4-8cc7-3f5efaf84639%40isocpp.or=
g.
------=_Part_1032_1393171386.1476218261518
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi,<br><br>Also, some corner cases like default argument v=
alues and variables already defined are on the list you might want to addre=
ss. Like `auto x =3D x =3D> x =3D> x =3D>x;` and `auto x =3D x =3D=
> x =3D x =3D> x =3D x;` are non-obvious to me. (`Is =3D x` an assign=
ment / initialization in caller (later called) code, or a default parameter=
value?)<br>My wishlist entry is support for short nullary lambdas in addit=
ion to these.<br><br>Thanks,<br>-lorro<br><br>2016. okt=C3=B3ber 11., kedd =
19:48:46 UTC+2 id=C5=91pontban Richard Smith a k=C3=B6vetkez=C5=91t =C3=ADr=
ta:<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"><div><div =
class=3D"gmail_quote">On Tue, Oct 11, 2016 at 10:32 AM, Barry Revzin <span =
dir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-ma=
ilto=3D"OEyyWrkfAQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'java=
script:';return true;" onclick=3D"this.href=3D'javascript:';ret=
urn true;">barry....@gmail.com</a>></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">Here is a contrasting proposal for how to ha=
ndle overload sets as function arguments. While a lot more verbose in the s=
imple case of just naming a function (where instead of just naming the func=
tion you have to actually enumerate the arguments list twice), I think it o=
ffers more flexibility in writing short lambdas. There are some motivating =
examples in the proposal. It's also getting pretty verbose to write cor=
rect generic functions with regards to SFINAE and noexcept, so this attempt=
s to make it a little bit easier - at least in the easy case.=C2=A0<div><di=
v><br></div><div>Also I'm proposing a shorter syntax for forwarding arg=
uments. I picked unary>> because it looks like moving something forwa=
rd but really anything shorter would be nice. <font face=3D"courier new, mo=
nospace">std::forward<Arg>(arg)</font> is particularly verbose, espec=
ially in a generic lambda where you have to write <font face=3D"courier new=
, monospace">std::forward<decltype(arg)>(<wbr>arg)</font><font face=
=3D"arial, sans-serif">, where the actual forwarding just dominates the cod=
e itself.=C2=A0</font></div></div></div></blockquote><div><br></div><div>Se=
ems like an interesting approach.</div><div><br></div><div>Minor correction=
to your "Effects on Existing Code" section: the character sequen=
ce =3D> can appear in legal C++ programs today. For instance, X<&=
Y::operator=3D>. That said, I've searched a large codebase for this =
(>100MLoC) and the only occurrence of =3D> (outside of comments, stri=
ng literals, etc.) was in a compiler test suite.</div></div></div></div>
</blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/5cd58eef-df4a-4ef4-8cc7-3f5efaf84639%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5cd58eef-df4a-4ef4-8cc7-3f5efaf84639=
%40isocpp.org</a>.<br />
------=_Part_1032_1393171386.1476218261518--
------=_Part_1031_1833740448.1476218261518--
.
Author: Barry Revzin <barry.revzin@gmail.com>
Date: Tue, 11 Oct 2016 14:46:15 -0700 (PDT)
Raw View
------=_Part_1617_594641078.1476222375487
Content-Type: multipart/alternative;
boundary="----=_Part_1618_170051129.1476222375487"
------=_Part_1618_170051129.1476222375487
Content-Type: text/plain; charset=UTF-8
>
> Minor correction to your "Effects on Existing Code" section: the character
> sequence => can appear in legal C++ programs today. For instance,
> X<&Y::operator=>. That said, I've searched a large codebase for this
> (>100MLoC) and the only occurrence of => (outside of comments, string
> literals, etc.) was in a compiler test suite.
Ahh, figures it'd have to show up somewhere. Still, that's pretty good.
Also, some corner cases like default argument values and variables already
> defined are on the list you might want to address. Like `auto x = x => x =>
> x =>x;` and `auto x = x => x = x => x = x;` are non-obvious to me. (`Is =
> x` an assignment / initialization in caller (later called) code, or a
> default parameter value?)
> My wishlist entry is support for short nullary lambdas in addition to
> these.
>
I think you'd have to be maximally greedy in scoping these. So parsing them
as:
auto x = x => x => x => x;
auto x = [](auto&& x){
return [](auto&& x){
return [](auto&& x){
return x;
};
};
};
and
auto x = x => x = x => x = x;
auto x = [](auto&& x){
return x = [](auto&& x){
return x = x;
};
};
Nullary lambdas fall out naturally too:
auto just5 = () => 5;
Default arguments would have to be parenthesized.
auto maybe5 = (x=5) => x;
--
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/5354d613-6694-425f-8c4d-04c254cd17f7%40isocpp.org.
------=_Part_1618_170051129.1476222375487
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px=
0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">=
Minor correction to your "Effects on Existing Code" section: the =
character sequence =3D> can appear in legal C++ programs today. For inst=
ance, X<&Y::operator=3D>. That said, I've searched a large co=
debase for this (>100MLoC) and the only occurrence of =3D> (outside o=
f comments, string literals, etc.) was in a compiler test suite.</blockquot=
e><div>=C2=A0</div><div>Ahh, figures it'd have to show up somewhere. St=
ill, that's pretty good.</div><div><br></div><blockquote class=3D"gmail=
_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;p=
adding-left: 1ex;"><div dir=3D"ltr">Also, some corner cases like default ar=
gument values and variables already defined are on the list you might want =
to address. Like `auto x =3D x =3D> x =3D> x =3D>x;` and `auto x =
=3D x =3D> x =3D x =3D> x =3D x;` are non-obvious to me. (`Is =3D x` =
an assignment / initialization in caller (later called) code, or a default =
parameter value?)<br>My wishlist entry is support for short nullary lambdas=
in addition to these.</div></blockquote><div><br></div><div>I think you=
9;d have to be maximally greedy in scoping these. So parsing them as:</div>=
<div><br></div><div><div class=3D"prettyprint" style=3D"background-color: r=
gb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: solid; b=
order-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div =
class=3D"subprettyprint"><font color=3D"#660066"><span style=3D"color: #008=
;" class=3D"styled-by-prettify">auto</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> x </span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> x </span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">=3D></span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> x </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D&g=
t;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> x </spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D></span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> x</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"><br><br></span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">auto</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> x </span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">[](</span><span style=3D"color: #008;" class=3D"styled-by-prettify=
">auto</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;" class=3D"styled-by-prettify">){</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </=
span><span style=3D"color: #008;" class=3D"styled-by-prettify">return</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">[](</span><span style=3D"=
color: #008;" class=3D"styled-by-prettify">auto</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;" =
class=3D"styled-by-prettify">){</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"=
color: #008;" class=3D"styled-by-prettify">return</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;"=
class=3D"styled-by-prettify">[](</span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">auto</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">&&</span><span style=3D"color: #000;" class=3D"st=
yled-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=
"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">return</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> x</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"colo=
r: #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"colo=
r: #660;" class=3D"styled-by-prettify">};</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">};</span></font></div></code></div><br>=C2=A0and</=
div><div><br></div><div><div class=3D"prettyprint" style=3D"background-colo=
r: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: soli=
d; border-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><=
div class=3D"subprettyprint"><span style=3D"font-family: Arial, Helvetica, =
sans-serif; background-color: rgb(255, 255, 255);"><span style=3D"color: #0=
08;" class=3D"styled-by-prettify">auto</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> x </span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> x </span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">=3D></span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> x </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> x </span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">=3D></span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> x </span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> x</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span></span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" class=3D"s=
tyled-by-prettify">auto</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> x </span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">=3D</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: #008;" class=3D"styled-by-prettify">auto</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;" 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: #008;" class=3D"styled-by-prettify">return</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> x</span><font color=3D"#666600"><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> </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: #660;=
" class=3D"styled-by-prettify">[](</span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">auto</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">&&</span><span style=3D"color: #000;" class=3D"st=
yled-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=
"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0</span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">return</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> x </span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> x</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"><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"styled-by-prettify">};</span></font></=
div></code></div><br>Nullary lambdas fall out naturally too:</div><div><br>=
</div><div><div class=3D"prettyprint" style=3D"background-color: rgb(250, 2=
50, 250); border-color: rgb(187, 187, 187); border-style: solid; border-wid=
th: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"=
subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettify">a=
uto</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> just5 =
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">()</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">=3D></span><font color=3D"#006666"><span=
style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D=
"color: #066;" class=3D"styled-by-prettify">5</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">;</span></font></div></code></div><div><=
br></div>Default arguments would have to be parenthesized.</div><div><br></=
div><div><div class=3D"prettyprint" style=3D"background-color: rgb(250, 250=
, 250); border-color: rgb(187, 187, 187); border-style: solid; border-width=
: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"su=
bprettyprint"><font color=3D"#660066"><span style=3D"color: #008;" class=3D=
"styled-by-prettify">auto</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> maybe5 </span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify">x</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=
=3D"color: #066;" class=3D"styled-by-prettify">5</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">)</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">=3D></span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> x</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">;</span></font></div></code></div><br><br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/5354d613-6694-425f-8c4d-04c254cd17f7%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5354d613-6694-425f-8c4d-04c254cd17f7=
%40isocpp.org</a>.<br />
------=_Part_1618_170051129.1476222375487--
------=_Part_1617_594641078.1476222375487--
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Tue, 11 Oct 2016 14:53:50 -0700
Raw View
--001a11444802713cb1053e9de9ec
Content-Type: text/plain; charset=UTF-8
On Tue, Oct 11, 2016 at 2:46 PM, Barry Revzin <barry.revzin@gmail.com>
wrote:
> Minor correction to your "Effects on Existing Code" section: the character
>> sequence => can appear in legal C++ programs today. For instance,
>> X<&Y::operator=>. That said, I've searched a large codebase for this
>> (>100MLoC) and the only occurrence of => (outside of comments, string
>> literals, etc.) was in a compiler test suite.
>
>
> Ahh, figures it'd have to show up somewhere. Still, that's pretty good.
>
> Also, some corner cases like default argument values and variables already
>> defined are on the list you might want to address. Like `auto x = x => x =>
>> x =>x;` and `auto x = x => x = x => x = x;` are non-obvious to me. (`Is =
>> x` an assignment / initialization in caller (later called) code, or a
>> default parameter value?)
>> My wishlist entry is support for short nullary lambdas in addition to
>> these.
>>
>
> I think you'd have to be maximally greedy in scoping these. So parsing
> them as:
>
> auto x = x => x => x => x;
>
> auto x = [](auto&& x){
> return [](auto&& x){
> return [](auto&& x){
> return x;
> };
> };
> };
>
> and
>
> auto x = x => x = x => x = x;
>
> auto x = [](auto&& x){
> return x = [](auto&& x){
> return x = x;
> };
> };
>
> Nullary lambdas fall out naturally too:
>
> auto just5 = () => 5;
>
> Default arguments would have to be parenthesized.
>
> auto maybe5 = (x=5) => x;
>
This will be difficult to parse. Requiring lookahead past the ) whenever we
see a ( is likely not going to be acceptable. Handling "(identifier-list)
=>" would already be a rather special case, but is probably manageable
because you can defer handling the identifier-list part until after you
reach the ")" and see whether there's a "=>" next. But once you add in
default arguments / assignment-expressions (where the rules for valid
expressions are subtly different, especially since earlier parameter names
are in scope in the default arguments of later parameters), you can't use
that same strategy.
--
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/CAOfiQqn3ouZcVc6CJJ6G6i%2B5rfJiFntvd1qkRGs-%3DoWyPinxGg%40mail.gmail.com.
--001a11444802713cb1053e9de9ec
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, Oct 11, 2016 at 2:46 PM, Barry Revzin <span dir=3D"ltr"><<a href=3D"=
mailto:barry.revzin@gmail.com" target=3D"_blank">barry.revzin@gmail.com</a>=
></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"><span=
class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
..8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Minor correct=
ion to your "Effects on Existing Code" section: the character seq=
uence =3D> can appear in legal C++ programs today. For instance, X<&a=
mp;Y::operator=3D>. That said, I've searched a large codebase for th=
is (>100MLoC) and the only occurrence of =3D> (outside of comments, s=
tring literals, etc.) was in a compiler test suite.</blockquote><div>=C2=A0=
</div></span><div>Ahh, figures it'd have to show up somewhere. Still, t=
hat's pretty good.</div><span class=3D""><div><br></div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc=
solid;padding-left:1ex"><div dir=3D"ltr">Also, some corner cases like defa=
ult argument values and variables already defined are on the list you might=
want to address. Like `auto x =3D x =3D> x =3D> x =3D>x;` and `au=
to x =3D x =3D> x =3D x =3D> x =3D x;` are non-obvious to me. (`Is =
=3D x` an assignment / initialization in caller (later called) code, or a d=
efault parameter value?)<br>My wishlist entry is support for short nullary =
lambdas in addition to these.</div></blockquote><div><br></div></span><div>=
I think you'd have to be maximally greedy in scoping these. So parsing =
them as:</div><div><br></div><div><div class=3D"m_8983686960950134116pretty=
print" style=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,=
187);border-style:solid;border-width:1px;word-wrap:break-word"><code class=
=3D"m_8983686960950134116prettyprint"><div class=3D"m_8983686960950134116su=
bprettyprint"><font color=3D"#660066"><span class=3D""><span style=3D"color=
:#008" class=3D"m_8983686960950134116styled-by-prettify">auto</span><span s=
tyle=3D"color:#000" class=3D"m_8983686960950134116styled-by-prettify"> x </=
span><span style=3D"color:#660" class=3D"m_8983686960950134116styled-by-pre=
ttify">=3D</span><span style=3D"color:#000" class=3D"m_8983686960950134116s=
tyled-by-prettify"> x </span><span style=3D"color:#660" class=3D"m_89836869=
60950134116styled-by-prettify">=3D></span><span style=3D"color:#000" cla=
ss=3D"m_8983686960950134116styled-by-prettify"> x </span><span style=3D"col=
or:#660" class=3D"m_8983686960950134116styled-by-prettify">=3D></span><s=
pan style=3D"color:#000" class=3D"m_8983686960950134116styled-by-prettify">=
x </span><span style=3D"color:#660" class=3D"m_8983686960950134116styled-b=
y-prettify">=3D></span><span style=3D"color:#000" class=3D"m_89836869609=
50134116styled-by-prettify"> x</span><span style=3D"color:#660" class=3D"m_=
8983686960950134116styled-by-prettify">;</span><span style=3D"color:#000" c=
lass=3D"m_8983686960950134116styled-by-prettify"><br><br></span></span><spa=
n style=3D"color:#008" class=3D"m_8983686960950134116styled-by-prettify">au=
to</span><span style=3D"color:#000" class=3D"m_8983686960950134116styled-by=
-prettify"> x </span><span style=3D"color:#660" class=3D"m_8983686960950134=
116styled-by-prettify">=3D</span><span style=3D"color:#000" class=3D"m_8983=
686960950134116styled-by-prettify"> </span><span style=3D"color:#660" class=
=3D"m_8983686960950134116styled-by-prettify">[](</span><span style=3D"color=
:#008" class=3D"m_8983686960950134116styled-by-prettify">auto</span><span s=
tyle=3D"color:#660" class=3D"m_8983686960950134116styled-by-prettify">&=
&</span><span style=3D"color:#000" class=3D"m_8983686960950134116styled=
-by-prettify"> x</span><span style=3D"color:#660" class=3D"m_89836869609501=
34116styled-by-prettify">){</span><span style=3D"color:#000" class=3D"m_898=
3686960950134116styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D=
"color:#008" class=3D"m_8983686960950134116styled-by-prettify">return</span=
><span style=3D"color:#000" class=3D"m_8983686960950134116styled-by-prettif=
y"> </span><span style=3D"color:#660" class=3D"m_8983686960950134116styled-=
by-prettify">[](</span><span style=3D"color:#008" class=3D"m_89836869609501=
34116styled-by-prettify">auto</span><span style=3D"color:#660" class=3D"m_8=
983686960950134116styled-by-prettify">&&</span><span style=3D"color=
:#000" class=3D"m_8983686960950134116styled-by-prettify"> x</span><span sty=
le=3D"color:#660" class=3D"m_8983686960950134116styled-by-prettify">){</spa=
n><span style=3D"color:#000" class=3D"m_8983686960950134116styled-by-pretti=
fy"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color:#008" class=
=3D"m_8983686960950134116styled-by-prettify">return</span><span style=3D"co=
lor:#000" class=3D"m_8983686960950134116styled-by-prettify"> </span><span s=
tyle=3D"color:#660" class=3D"m_8983686960950134116styled-by-prettify">[](</=
span><span style=3D"color:#008" class=3D"m_8983686960950134116styled-by-pre=
ttify">auto</span><span style=3D"color:#660" class=3D"m_8983686960950134116=
styled-by-prettify">&&</span><span style=3D"color:#000" class=3D"m_=
8983686960950134116styled-by-prettify"> x</span><span style=3D"color:#660" =
class=3D"m_8983686960950134116styled-by-prettify">){</span><span style=3D"c=
olor:#000" class=3D"m_8983686960950134116styled-by-prettify"><br>=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color:#008" class=3D"=
m_8983686960950134116styled-by-prettify">return</span><span style=3D"color:=
#000" class=3D"m_8983686960950134116styled-by-prettify"> x</span><span styl=
e=3D"color:#660" class=3D"m_8983686960950134116styled-by-prettify">;</span>=
<span style=3D"color:#000" class=3D"m_8983686960950134116styled-by-prettify=
"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color:#660" class=
=3D"m_8983686960950134116styled-by-prettify">};</span><span style=3D"color:=
#000" class=3D"m_8983686960950134116styled-by-prettify"><br>=C2=A0 =C2=A0 <=
/span><span style=3D"color:#660" class=3D"m_8983686960950134116styled-by-pr=
ettify">};</span><span style=3D"color:#000" class=3D"m_8983686960950134116s=
tyled-by-prettify"><br></span><span style=3D"color:#660" class=3D"m_8983686=
960950134116styled-by-prettify">};</span></font></div></code></div><br>=C2=
=A0and</div><div><br></div><div><div class=3D"m_8983686960950134116prettypr=
int" style=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,18=
7);border-style:solid;border-width:1px;word-wrap:break-word"><code class=3D=
"m_8983686960950134116prettyprint"><div class=3D"m_8983686960950134116subpr=
ettyprint"><span class=3D""><span style=3D"font-family:Arial,Helvetica,sans=
-serif;background-color:rgb(255,255,255)"><span style=3D"color:#008" class=
=3D"m_8983686960950134116styled-by-prettify">auto</span><span style=3D"colo=
r:#000" class=3D"m_8983686960950134116styled-by-prettify"> x </span><span s=
tyle=3D"color:#660" class=3D"m_8983686960950134116styled-by-prettify">=3D</=
span><span style=3D"color:#000" class=3D"m_8983686960950134116styled-by-pre=
ttify"> x </span><span style=3D"color:#660" class=3D"m_8983686960950134116s=
tyled-by-prettify">=3D></span><span style=3D"color:#000" class=3D"m_8983=
686960950134116styled-by-prettify"> x </span><span style=3D"color:#660" cla=
ss=3D"m_8983686960950134116styled-by-prettify">=3D</span><span style=3D"col=
or:#000" class=3D"m_8983686960950134116styled-by-prettify"> x </span><span =
style=3D"color:#660" class=3D"m_8983686960950134116styled-by-prettify">=3D&=
gt;</span><span style=3D"color:#000" class=3D"m_8983686960950134116styled-b=
y-prettify"> x </span><span style=3D"color:#660" class=3D"m_898368696095013=
4116styled-by-prettify">=3D</span><span style=3D"color:#000" class=3D"m_898=
3686960950134116styled-by-prettify"> x</span><span style=3D"color:#660" cla=
ss=3D"m_8983686960950134116styled-by-prettify">;</span><span style=3D"color=
:#000" class=3D"m_8983686960950134116styled-by-prettify"><br></span></span>=
<span style=3D"color:#000" class=3D"m_8983686960950134116styled-by-prettify=
"><br></span></span><span style=3D"color:#008" class=3D"m_89836869609501341=
16styled-by-prettify">auto</span><span style=3D"color:#000" class=3D"m_8983=
686960950134116styled-by-prettify"> x </span><span style=3D"color:#660" cla=
ss=3D"m_8983686960950134116styled-by-prettify">=3D</span><span style=3D"col=
or:#000" class=3D"m_8983686960950134116styled-by-prettify"> </span><span st=
yle=3D"color:#660" class=3D"m_8983686960950134116styled-by-prettify">[](</s=
pan><span style=3D"color:#008" class=3D"m_8983686960950134116styled-by-pret=
tify">auto</span><span style=3D"color:#660" class=3D"m_8983686960950134116s=
tyled-by-prettify">&&</span><span style=3D"color:#000" class=3D"m_8=
983686960950134116styled-by-prettify"> x</span><span style=3D"color:#660" c=
lass=3D"m_8983686960950134116styled-by-prettify">){</span><span style=3D"co=
lor:#000" class=3D"m_8983686960950134116styled-by-prettify"><br>=C2=A0 =C2=
=A0</span><span style=3D"color:#008" class=3D"m_8983686960950134116styled-b=
y-prettify">return</span><span style=3D"color:#000" class=3D"m_898368696095=
0134116styled-by-prettify"> x</span><font color=3D"#666600"><span style=3D"=
color:#000" class=3D"m_8983686960950134116styled-by-prettify"> </span><span=
style=3D"color:#660" class=3D"m_8983686960950134116styled-by-prettify">=3D=
</span><span style=3D"color:#000" class=3D"m_8983686960950134116styled-by-p=
rettify"> </span><span style=3D"color:#660" class=3D"m_8983686960950134116s=
tyled-by-prettify">[](</span><span style=3D"color:#008" class=3D"m_89836869=
60950134116styled-by-prettify">auto</span><span style=3D"color:#660" class=
=3D"m_8983686960950134116styled-by-prettify">&&</span><span style=
=3D"color:#000" class=3D"m_8983686960950134116styled-by-prettify"> x</span>=
<span style=3D"color:#660" class=3D"m_8983686960950134116styled-by-prettify=
">){</span><span style=3D"color:#000" class=3D"m_8983686960950134116styled-=
by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0</span><span style=3D"color:#00=
8" class=3D"m_8983686960950134116styled-by-prettify">return</span><span sty=
le=3D"color:#000" class=3D"m_8983686960950134116styled-by-prettify"> x </sp=
an><span style=3D"color:#660" class=3D"m_8983686960950134116styled-by-prett=
ify">=3D</span><span style=3D"color:#000" class=3D"m_8983686960950134116sty=
led-by-prettify"> x</span><span style=3D"color:#660" class=3D"m_89836869609=
50134116styled-by-prettify">;</span><span style=3D"color:#000" class=3D"m_8=
983686960950134116styled-by-prettify"><br>=C2=A0 =C2=A0</span><span style=
=3D"color:#660" class=3D"m_8983686960950134116styled-by-prettify">};</span>=
<span style=3D"color:#000" class=3D"m_8983686960950134116styled-by-prettify=
"><br></span><span style=3D"color:#660" class=3D"m_8983686960950134116style=
d-by-prettify">};</span></font></div></code></div><br>Nullary lambdas fall =
out naturally too:</div><div><br></div><div><div class=3D"m_898368696095013=
4116prettyprint" style=3D"background-color:rgb(250,250,250);border-color:rg=
b(187,187,187);border-style:solid;border-width:1px;word-wrap:break-word"><c=
ode class=3D"m_8983686960950134116prettyprint"><div class=3D"m_898368696095=
0134116subprettyprint"><span style=3D"color:#008" class=3D"m_89836869609501=
34116styled-by-prettify">auto</span><span style=3D"color:#000" class=3D"m_8=
983686960950134116styled-by-prettify"> just5 </span><span style=3D"color:#6=
60" class=3D"m_8983686960950134116styled-by-prettify">=3D</span><span style=
=3D"color:#000" class=3D"m_8983686960950134116styled-by-prettify"> </span><=
span style=3D"color:#660" class=3D"m_8983686960950134116styled-by-prettify"=
>()</span><span style=3D"color:#000" class=3D"m_8983686960950134116styled-b=
y-prettify"> </span><span style=3D"color:#660" class=3D"m_89836869609501341=
16styled-by-prettify">=3D></span><font color=3D"#006666"><span style=3D"=
color:#000" class=3D"m_8983686960950134116styled-by-prettify"> </span><span=
style=3D"color:#066" class=3D"m_8983686960950134116styled-by-prettify">5</=
span><span style=3D"color:#660" class=3D"m_8983686960950134116styled-by-pre=
ttify">;</span></font></div></code></div><div><br></div>Default arguments w=
ould have to be parenthesized.</div><div><br></div><div><div class=3D"m_898=
3686960950134116prettyprint" style=3D"background-color:rgb(250,250,250);bor=
der-color:rgb(187,187,187);border-style:solid;border-width:1px;word-wrap:br=
eak-word"><code class=3D"m_8983686960950134116prettyprint"><div class=3D"m_=
8983686960950134116subprettyprint"><font color=3D"#660066"><span style=3D"c=
olor:#008" class=3D"m_8983686960950134116styled-by-prettify">auto</span><sp=
an style=3D"color:#000" class=3D"m_8983686960950134116styled-by-prettify"> =
maybe5 </span><span style=3D"color:#660" class=3D"m_8983686960950134116styl=
ed-by-prettify">=3D</span><span style=3D"color:#000" class=3D"m_89836869609=
50134116styled-by-prettify"> </span><span style=3D"color:#660" class=3D"m_8=
983686960950134116styled-by-prettify">(</span><span style=3D"color:#000" cl=
ass=3D"m_8983686960950134116styled-by-prettify">x</span><span style=3D"colo=
r:#660" class=3D"m_8983686960950134116styled-by-prettify">=3D</span><span s=
tyle=3D"color:#066" class=3D"m_8983686960950134116styled-by-prettify">5</sp=
an><span style=3D"color:#660" class=3D"m_8983686960950134116styled-by-prett=
ify">)</span><span style=3D"color:#000" class=3D"m_8983686960950134116style=
d-by-prettify"> </span><span style=3D"color:#660" class=3D"m_89836869609501=
34116styled-by-prettify">=3D></span><span style=3D"color:#000" class=3D"=
m_8983686960950134116styled-by-prettify"> x</span><span style=3D"color:#660=
" class=3D"m_8983686960950134116styled-by-prettify">;</span></font></div></=
code></div></div></div></blockquote><div><br></div><div>This will be diffic=
ult to parse. Requiring lookahead past the ) whenever we see a ( is likely =
not going to be acceptable. Handling "(identifier-list) =3D>" =
would already be a rather special case, but is probably manageable because =
you can defer handling the identifier-list part until after you reach the &=
quot;)" and see whether there's a "=3D>" next.=C2=A0 =
But once you add in default arguments / assignment-expressions (where the r=
ules for valid expressions are subtly different, especially since earlier p=
arameter names are in scope in the default arguments of later parameters), =
you can't use that same strategy.</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" 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/CAOfiQqn3ouZcVc6CJJ6G6i%2B5rfJiFntvd1=
qkRGs-%3DoWyPinxGg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQqn3ouZc=
Vc6CJJ6G6i%2B5rfJiFntvd1qkRGs-%3DoWyPinxGg%40mail.gmail.com</a>.<br />
--001a11444802713cb1053e9de9ec--
.
Author: Andrey Semashev <andrey.semashev@gmail.com>
Date: Wed, 12 Oct 2016 00:56:14 +0300
Raw View
On 10/11/16 20:32, Barry Revzin wrote:
> Here is a contrasting proposal for how to handle overload sets as
> function arguments. While a lot more verbose in the simple case of just
> naming a function (where instead of just naming the function you have to
> actually enumerate the arguments list twice), I think it offers more
> flexibility in writing short lambdas. There are some motivating examples
> in the proposal. It's also getting pretty verbose to write correct
> generic functions with regards to SFINAE and noexcept, so this attempts
> to make it a little bit easier - at least in the easy case.
>
> Also I'm proposing a shorter syntax for forwarding arguments. I picked
> unary>> because it looks like moving something forward but really
> anything shorter would be nice. std::forward<Arg>(arg) is particularly
> verbose, especially in a generic lambda where you have to write
> std::forward<decltype(arg)>(arg), where the actual forwarding just
> dominates the code itself.
IMHO, this new syntax makes the code more obscure. The proposed
abbreviated lambdas no longer have any resemblence with functions and
blend in the surrounding code too much (yes, this is a bad thing).
Consider this slightly modified example from the proposal:
int sum = 0;
for (int i = 0; i < 100; ++i)
{
sum += accumulate(ints(i) |
transform(i => i*i) | take_while(i => i < 1000));
}
Can you immediately tell what is i in each occurrence? Can a novice
programmer? What are the structural blocks (scopes) for each meaning of i?
While I'm in general in favor of shorter (yet descriptive!) names, this
makes C++ look more like Perl, which is sometimes called "the language
that you write code in but never read".
--
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/807ababf-d447-8a22-1379-c2b6bde1df2c%40gmail.com.
.
Author: Zhihao Yuan <zy@miator.net>
Date: Tue, 11 Oct 2016 17:59:45 -0500
Raw View
On Tue, Oct 11, 2016 at 12:48 PM, Richard Smith <richard@metafoo.co.uk> wrote:
>
> Minor correction to your "Effects on Existing Code" section: the character
> sequence => can appear in legal C++ programs today. For instance,
> X<&Y::operator=>. That said, I've searched a large codebase for this
> (>100MLoC) and the only occurrence of => (outside of comments, string
> literals, etc.) was in a compiler test suite.
A syntax I raised somewhere else is
transform(i = return i * i)
"= return" should have been legal nowhere, and the syntax is
more friendly to my mental model, where "=>" is to introduce
names to types (as in Haskell)...
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://blog.miator.net/
--
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/CAGsORuBG5r4q7PMxy4vhv4NTxrjJn1hc2wXzJZ6WgcHJo9VbeA%40mail.gmail.com.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 11 Oct 2016 17:18:49 -0700 (PDT)
Raw View
------=_Part_620_1463107609.1476231529980
Content-Type: multipart/alternative;
boundary="----=_Part_621_1199086196.1476231529980"
------=_Part_621_1199086196.1476231529980
Content-Type: text/plain; charset=UTF-8
On Tuesday, October 11, 2016 at 1:32:57 PM UTC-4, Barry Revzin wrote:
>
> Here is a contrasting proposal for how to handle overload sets as function
> arguments. While a lot more verbose in the simple case of just naming a
> function (where instead of just naming the function you have to actually
> enumerate the arguments list twice), I think it offers more flexibility in
> writing short lambdas. There are some motivating examples in the proposal.
> It's also getting pretty verbose to write correct generic functions with
> regards to SFINAE and noexcept, so this attempts to make it a little bit
> easier - at least in the easy case.
>
> Also I'm proposing a shorter syntax for forwarding arguments. I picked
> unary>> because it looks like moving something forward but really anything
> shorter would be nice. std::forward<Arg>(arg) is particularly verbose,
> especially in a generic lambda where you have to write
> std::forward<decltype(arg)>(arg), where the actual forwarding just
> dominates the code itself.
>
>
I really don't like the idea of a naked `(x)` having a completely different
meaning when it's followed by `=>` than when it isn't. And that goes double
for any `x`.
People have long-since wanted a terse lambda syntax that doesn't require
you to write typenames for variables. I understand that there are some
parsing issues related to this concept, but if those can be worked out, I'd
be fine with `[](x, y, ...z)` translating to `[](auto &&x, auto &&y,
auto... &&z)`.
Given that, I would be fine with `=>` meaning "the following expression
will be returned with a noexcept specification based on the expression and
decltype(auto) return type deduction".
--
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/93724995-cfd3-4e71-8072-f0c1c9929842%40isocpp.org.
------=_Part_621_1199086196.1476231529980
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, October 11, 2016 at 1:32:57 PM UTC-4, Barry Re=
vzin 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">He=
re is a contrasting proposal for how to handle overload sets as function ar=
guments. While a lot more verbose in the simple case of just naming a funct=
ion (where instead of just naming the function you have to actually enumera=
te the arguments list twice), I think it offers more flexibility in writing=
short lambdas. There are some motivating examples in the proposal. It'=
s also getting pretty verbose to write correct generic functions with regar=
ds to SFINAE and noexcept, so this attempts to make it a little bit easier =
- at least in the easy case.=C2=A0<div><div><br></div><div>Also I'm pro=
posing a shorter syntax for forwarding arguments. I picked unary>> be=
cause it looks like moving something forward but really anything shorter wo=
uld be nice. <font face=3D"courier new, monospace">std::forward<Arg>(=
arg)</font> is particularly verbose, especially in a generic lambda where y=
ou have to write <font face=3D"courier new, monospace">std::forward<decl=
type(arg)>(<wbr>arg)</font><font face=3D"arial, sans-serif">, where the =
actual forwarding just dominates the code itself.=C2=A0</font></div><div><b=
r></div></div></div></blockquote><div><br>I really don't like the idea =
of a naked `(x)` having a completely different meaning when it's follow=
ed by `=3D>` than when it isn't. And that goes double for any `x`.<b=
r><br>People have long-since wanted a terse lambda syntax that doesn't =
require you to write typenames for variables. I understand that there are s=
ome parsing issues related to this concept, but if those can be worked out,=
I'd be fine with `[](x, y, ...z)` translating to `[](auto &&x,=
auto &&y, auto... &&z)`.<br><br>Given that, I would be fin=
e with `=3D>` meaning "the following expression will be returned wi=
th a noexcept specification based on the expression and decltype(auto) retu=
rn type deduction".<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/93724995-cfd3-4e71-8072-f0c1c9929842%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/93724995-cfd3-4e71-8072-f0c1c9929842=
%40isocpp.org</a>.<br />
------=_Part_621_1199086196.1476231529980--
------=_Part_620_1463107609.1476231529980--
.
Author: Tomasz <tomaszkam@gmail.com>
Date: Tue, 11 Oct 2016 21:13:30 -0700 (PDT)
Raw View
------=_Part_1513_1331155681.1476245610984
Content-Type: multipart/alternative;
boundary="----=_Part_1514_590836905.1476245610984"
------=_Part_1514_590836905.1476245610984
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
I would like to suggest exstending the =3D> expr to be valid replacement fo=
r=20
the function body for any kind of function. I mean that:
template<typename C>
auto begin(C&& c) =3D> std::forward<C>(c).begin();
Would be valid definition, equivalent to:
template<typename C>
inline auto begin(C&& c)
noexcept(std::forward<C>(c).begin())
-> decltype(std::forward<C>(c).begin())
{ return std::forward<C>(c).begin(); }
The following restriction will apply:
1) Function with expression-body cannot be forward declared.
2) Explicit inline
4) Can have only auto introducer
As this will use decltype(expr) deduction (not decltype(auto)) it will make=
=20
the function SFINAE'able on the function body, and will basically resolve=
=20
problems listed in=20
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0238r0.html paper.
W dniu wtorek, 11 pa=C5=BAdziernika 2016 19:32:57 UTC+2 u=C5=BCytkownik Bar=
ry Revzin=20
napisa=C5=82:
>
> Here is a contrasting proposal for how to handle overload sets as functio=
n=20
> arguments. While a lot more verbose in the simple case of just naming a=
=20
> function (where instead of just naming the function you have to actually=
=20
> enumerate the arguments list twice), I think it offers more flexibility i=
n=20
> writing short lambdas. There are some motivating examples in the proposal=
..=20
> It's also getting pretty verbose to write correct generic functions with=
=20
> regards to SFINAE and noexcept, so this attempts to make it a little bit=
=20
> easier - at least in the easy case.=20
>
> Also I'm proposing a shorter syntax for forwarding arguments. I picked=20
> unary>> because it looks like moving something forward but really anythin=
g=20
> shorter would be nice. std::forward<Arg>(arg) is particularly verbose,=20
> especially in a generic lambda where you have to write=20
> std::forward<decltype(arg)>(arg), where the actual forwarding just=20
> dominates the code itself.=20
>
>
--=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/f6b38db0-e9e2-494f-9f7e-03a3cb0d8d59%40isocpp.or=
g.
------=_Part_1514_590836905.1476245610984
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I would like to suggest exstending the =3D> expr to be =
valid replacement for the function body for any kind of function. I mean th=
at:<br>template<typename C><br>auto begin(C&& c) =3D> std:=
:forward<C>(c).begin();<br><br>Would be valid definition, equivalent =
to:<br>template<typename C><br>inline auto begin(C&& c)<br>=
=C2=A0 noexcept(std::forward<C>(c).begin())<br>=C2=A0=C2=A0=C2=A0 -&g=
t; decltype(std::forward<C>(c).begin())<br>{ return std::forward<C=
>(c).begin(); }<br><br>The following restriction will apply:<br>1) Funct=
ion with expression-body cannot be forward declared.<br>2) Explicit inline<=
br>4) Can have only auto introducer<br><br>As this will use decltype(expr) =
deduction (not decltype(auto)) it will make the function SFINAE'able on=
the function body, and will basically resolve problems listed in http://ww=
w.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0238r0.html paper.<br><br><=
br><br>W dniu wtorek, 11 pa=C5=BAdziernika 2016 19:32:57 UTC+2 u=C5=BCytkow=
nik Barry Revzin napisa=C5=82:<blockquote class=3D"gmail_quote" style=3D"ma=
rgin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">=
<div dir=3D"ltr">Here is a contrasting proposal for how to handle overload =
sets as function arguments. While a lot more verbose in the simple case of =
just naming a function (where instead of just naming the function you have =
to actually enumerate the arguments list twice), I think it offers more fle=
xibility in writing short lambdas. There are some motivating examples in th=
e proposal. It's also getting pretty verbose to write correct generic f=
unctions with regards to SFINAE and noexcept, so this attempts to make it a=
little bit easier - at least in the easy case.=C2=A0<div><div><br></div><d=
iv>Also I'm proposing a shorter syntax for forwarding arguments. I pick=
ed unary>> because it looks like moving something forward but really =
anything shorter would be nice. <font face=3D"courier new, monospace">std::=
forward<Arg>(arg)</font> is particularly verbose, especially in a gen=
eric lambda where you have to write <font face=3D"courier new, monospace">s=
td::forward<decltype(arg)>(<wbr>arg)</font><font face=3D"arial, sans-=
serif">, where the actual forwarding just dominates the code itself.=C2=A0<=
/font></div><div><br></div></div></div></blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/f6b38db0-e9e2-494f-9f7e-03a3cb0d8d59%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f6b38db0-e9e2-494f-9f7e-03a3cb0d8d59=
%40isocpp.org</a>.<br />
------=_Part_1514_590836905.1476245610984--
------=_Part_1513_1331155681.1476245610984--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 11 Oct 2016 22:09:19 -0700 (PDT)
Raw View
------=_Part_1849_191753869.1476248959158
Content-Type: multipart/alternative;
boundary="----=_Part_1850_2060292154.1476248959158"
------=_Part_1850_2060292154.1476248959158
Content-Type: text/plain; charset=UTF-8
On Wednesday, October 12, 2016 at 12:13:31 AM UTC-4, Tomasz wrote:
>
> I would like to suggest exstending the => expr to be valid replacement for
> the function body for any kind of function. I mean that:
> template<typename C>
> auto begin(C&& c) => std::forward<C>(c).begin();
>
> Would be valid definition, equivalent to:
> template<typename C>
> inline auto begin(C&& c)
> noexcept(std::forward<C>(c).begin())
> -> decltype(std::forward<C>(c).begin())
> { return std::forward<C>(c).begin(); }
>
> The following restriction will apply:
> 1) Function with expression-body cannot be forward declared.
> 2) Explicit inline
> 4) Can have only auto introducer
>
> As this will use decltype(expr) deduction (not decltype(auto)) it will
> make the function SFINAE'able on the function body, and will basically
> resolve problems listed in
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0238r0.html
> paper.
>
But returning `decltype(expr)` is (SFINAE-aside) equivalent to `auto`.
Which means that it will *always* return by value. So if `expr` results in
a reference... too bad; it's returning a value now.
To me, the point of the `=>` syntax is to say "perfectly forward and return
this expression as much as possible as if you had written it in-situ".
Returning `decltype(expr)` won't do that. But returning `decltype((expr))`
would.
Other than that, I'm fine with extending `=>` to functions in general.
--
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/4f16e01f-2c03-425e-beb7-0a40c03c8f3c%40isocpp.org.
------=_Part_1850_2060292154.1476248959158
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wednesday, October 12, 2016 at 12:13:31 AM UTC-4, Tomas=
z 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">I wou=
ld like to suggest exstending the =3D> expr to be valid replacement for =
the function body for any kind of function. I mean that:<br>template<typ=
ename C><br>auto begin(C&& c) =3D> std::forward<C>(c).b=
egin();<br><br>Would be valid definition, equivalent to:<br>template<typ=
ename C><br>inline auto begin(C&& c)<br>=C2=A0 noexcept(std::for=
ward<C>(c).<wbr>begin())<br>=C2=A0=C2=A0=C2=A0 -> decltype(std::fo=
rward<C>(c).<wbr>begin())<br>{ return std::forward<C>(c).begin(=
); }<br><br>The following restriction will apply:<br>1) Function with expre=
ssion-body cannot be forward declared.<br>2) Explicit inline<br>4) Can have=
only auto introducer<br><br>As this will use decltype(expr) deduction (not=
decltype(auto)) it will make the function SFINAE'able on the function =
body, and will basically resolve problems listed in <a href=3D"http://www.o=
pen-std.org/jtc1/sc22/wg21/docs/papers/2016/p0238r0.html" target=3D"_blank"=
rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.google.com/url=
?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F=
2016%2Fp0238r0.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHR2O2WpZ1MMv9CQ=
LLWTb-Lc143Ow';return true;" onclick=3D"this.href=3D'http://www.goo=
gle.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%=
2Fpapers%2F2016%2Fp0238r0.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHR2O=
2WpZ1MMv9CQLLWTb-Lc143Ow';return true;">http://www.open-std.org/jtc1/<w=
br>sc22/wg21/docs/papers/2016/<wbr>p0238r0.html</a> paper.<br></div></block=
quote><div><br>But returning `decltype(expr)` is (SFINAE-aside) equivalent =
to `auto`. Which means that it will <i>always</i> return by value. So if `e=
xpr` results in a reference... too bad; it's returning a value now.<br>=
<br>To me, the point of the `=3D>` syntax is to say "perfectly forw=
ard and return this expression as much as possible as if you had written it=
in-situ". Returning `decltype(expr)` won't do that. But returning=
`decltype((expr))` would.<br><br>Other than that, I'm fine with extend=
ing `=3D>` to functions in general.</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/4f16e01f-2c03-425e-beb7-0a40c03c8f3c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/4f16e01f-2c03-425e-beb7-0a40c03c8f3c=
%40isocpp.org</a>.<br />
------=_Part_1850_2060292154.1476248959158--
------=_Part_1849_191753869.1476248959158--
.
Author: Tomasz <tomaszkam@gmail.com>
Date: Tue, 11 Oct 2016 22:24:29 -0700 (PDT)
Raw View
------=_Part_1462_2139014722.1476249869502
Content-Type: multipart/alternative;
boundary="----=_Part_1463_249913845.1476249869502"
------=_Part_1463_249913845.1476249869502
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
W dniu =C5=9Broda, 12 pa=C5=BAdziernika 2016 07:09:19 UTC+2 u=C5=BCytkownik=
Nicol Bolas=20
napisa=C5=82:
>
> On Wednesday, October 12, 2016 at 12:13:31 AM UTC-4, Tomasz wrote:
>>
>> I would like to suggest exstending the =3D> expr to be valid replacement=
=20
>> for the function body for any kind of function. I mean that:
>> template<typename C>
>> auto begin(C&& c) =3D> std::forward<C>(c).begin();
>>
>> Would be valid definition, equivalent to:
>> template<typename C>
>> inline auto begin(C&& c)
>> noexcept(std::forward<C>(c).begin())
>> -> decltype(std::forward<C>(c).begin())
>> { return std::forward<C>(c).begin(); }
>>
>> The following restriction will apply:
>> 1) Function with expression-body cannot be forward declared.
>> 2) Explicit inline
>> 4) Can have only auto introducer
>>
>> As this will use decltype(expr) deduction (not decltype(auto)) it will=
=20
>> make the function SFINAE'able on the function body, and will basically=
=20
>> resolve problems listed in=20
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0238r0.html=20
>> paper.
>>
>
> But returning `decltype(expr)` is (SFINAE-aside) equivalent to `auto`.=20
> Which means that it will *always* return by value. So if `expr` results=
=20
> in a reference... too bad; it's returning a value now.
>
No, it does not. decltype(auto) and decltype(expr) are equivalent if the=20
function return statement is return expr, and the only situation when it=20
returns by value, is when expr is actually an prvalue, in which case=20
returnning by value is only way to avoid dangling references.
And live example:
http://melpon.org/wandbox/permlink/u3oE3UCBrVHivK12#
--=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/075deae8-dcde-4a68-9729-936b3f8c7407%40isocpp.or=
g.
------=_Part_1463_249913845.1476249869502
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">W dniu =C5=9Broda, 12 pa=C5=BAdziernika 2016 07:09:19 UTC+=
2 u=C5=BCytkownik Nicol Bolas napisa=C5=82:<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">On Wednesday, October 12, 2016 at 12:13:31 AM=
UTC-4, Tomasz wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;ma=
rgin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"lt=
r">I would like to suggest exstending the =3D> expr to be valid replacem=
ent for the function body for any kind of function. I mean that:<br>templat=
e<typename C><br>auto begin(C&& c) =3D> std::forward<C&=
gt;(c).begin();<br><br>Would be valid definition, equivalent to:<br>templat=
e<typename C><br>inline auto begin(C&& c)<br>=C2=A0 noexcept(=
std::forward<C>(c).<wbr>begin())<br>=C2=A0=C2=A0=C2=A0 -> decltype=
(std::forward<C>(c).<wbr>begin())<br>{ return std::forward<C>(c=
).begin(); }<br><br>The following restriction will apply:<br>1) Function wi=
th expression-body cannot be forward declared.<br>2) Explicit inline<br>4) =
Can have only auto introducer<br><br>As this will use decltype(expr) deduct=
ion (not decltype(auto)) it will make the function SFINAE'able on the f=
unction body, and will basically resolve problems listed in <a href=3D"http=
://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0238r0.html" rel=3D"no=
follow" target=3D"_blank" onmousedown=3D"this.href=3D'http://www.google=
..com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fp=
apers%2F2016%2Fp0238r0.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHR2O2Wp=
Z1MMv9CQLLWTb-Lc143Ow';return true;" onclick=3D"this.href=3D'http:/=
/www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21=
%2Fdocs%2Fpapers%2F2016%2Fp0238r0.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAF=
QjCNHR2O2WpZ1MMv9CQLLWTb-Lc143Ow';return true;">http://www.open-std.org=
/jtc1/<wbr>sc22/wg21/docs/papers/2016/<wbr>p0238r0.html</a> paper.<br></div=
></blockquote><div><br>But returning `decltype(expr)` is (SFINAE-aside) equ=
ivalent to `auto`. Which means that it will <i>always</i> return by value. =
So if `expr` results in a reference... too bad; it's returning a value =
now.<br></div></div></blockquote><div><br>No, it does not. decltype(auto) a=
nd decltype(expr) are equivalent if the function return statement is return=
expr, and the only situation when it returns by value, is when expr is act=
ually an prvalue, in which case returnning by value is only way to avoid da=
ngling references.<br><br>And live example:<br>http://melpon.org/wandbox/pe=
rmlink/u3oE3UCBrVHivK12#<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/075deae8-dcde-4a68-9729-936b3f8c7407%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/075deae8-dcde-4a68-9729-936b3f8c7407=
%40isocpp.org</a>.<br />
------=_Part_1463_249913845.1476249869502--
------=_Part_1462_2139014722.1476249869502--
.
Author: Tomasz <tomaszkam@gmail.com>
Date: Tue, 11 Oct 2016 22:27:29 -0700 (PDT)
Raw View
------=_Part_1464_2054429466.1476250049537
Content-Type: multipart/alternative;
boundary="----=_Part_1465_1038310150.1476250049537"
------=_Part_1465_1038310150.1476250049537
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
W dniu =C5=9Broda, 12 pa=C5=BAdziernika 2016 07:24:29 UTC+2 u=C5=BCytkownik=
Tomasz napisa=C5=82:
>
> W dniu =C5=9Broda, 12 pa=C5=BAdziernika 2016 07:09:19 UTC+2 u=C5=BCytkown=
ik Nicol Bolas=20
> napisa=C5=82:
>>
>> On Wednesday, October 12, 2016 at 12:13:31 AM UTC-4, Tomasz wrote:
>>>
>>> I would like to suggest exstending the =3D> expr to be valid replacemen=
t=20
>>> for the function body for any kind of function. I mean that:
>>> template<typename C>
>>> auto begin(C&& c) =3D> std::forward<C>(c).begin();
>>>
>>> Would be valid definition, equivalent to:
>>> template<typename C>
>>> inline auto begin(C&& c)
>>> noexcept(std::forward<C>(c).begin())
>>> -> decltype(std::forward<C>(c).begin())
>>> { return std::forward<C>(c).begin(); }
>>>
>>> The following restriction will apply:
>>> 1) Function with expression-body cannot be forward declared.
>>> 2) Explicit inline
>>> 4) Can have only auto introducer
>>>
>>> As this will use decltype(expr) deduction (not decltype(auto)) it will=
=20
>>> make the function SFINAE'able on the function body, and will basically=
=20
>>> resolve problems listed in=20
>>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0238r0.html=20
>>> paper.
>>>
>>
>> But returning `decltype(expr)` is (SFINAE-aside) equivalent to `auto`.=
=20
>> Which means that it will *always* return by value. So if `expr` results=
=20
>> in a reference... too bad; it's returning a value now.
>>
>
> No, it does not. decltype(auto) and decltype(expr) are equivalent if the=
=20
> function return statement is return expr, and the only situation when it=
=20
> returns by value, is when expr is actually an prvalue, in which case=20
> returnning by value is only way to avoid dangling references.
>
> And live example:
> http://melpon.org/wandbox/permlink/u3oE3UCBrVHivK12#
>
Correct link: http://melpon.org/wandbox/permlink/9XhOLN8S0rD7603x =20
--=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/17422161-fe6d-4949-9e9e-381bc4fcd417%40isocpp.or=
g.
------=_Part_1465_1038310150.1476250049537
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">W dniu =C5=9Broda, 12 pa=C5=BAdziernika 2016 07:24:29 UTC+=
2 u=C5=BCytkownik Tomasz napisa=C5=82:<blockquote class=3D"gmail_quote" sty=
le=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left=
: 1ex;"><div dir=3D"ltr">W dniu =C5=9Broda, 12 pa=C5=BAdziernika 2016 07:09=
:19 UTC+2 u=C5=BCytkownik Nicol Bolas napisa=C5=82:<blockquote class=3D"gma=
il_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;pa=
dding-left:1ex"><div dir=3D"ltr">On Wednesday, October 12, 2016 at 12:13:31=
AM UTC-4, Tomasz 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">I would like to suggest exstending the =3D> expr to be valid repla=
cement for the function body for any kind of function. I mean that:<br>temp=
late<typename C><br>auto begin(C&& c) =3D> std::forward<=
;C>(c).begin();<br><br>Would be valid definition, equivalent to:<br>temp=
late<typename C><br>inline auto begin(C&& c)<br>=C2=A0 noexce=
pt(std::forward<C>(c).<wbr>begin())<br>=C2=A0=C2=A0=C2=A0 -> declt=
ype(std::forward<C>(c).<wbr>begin())<br>{ return std::forward<C>=
;(c).begin(); }<br><br>The following restriction will apply:<br>1) Function=
with expression-body cannot be forward declared.<br>2) Explicit inline<br>=
4) Can have only auto introducer<br><br>As this will use decltype(expr) ded=
uction (not decltype(auto)) it will make the function SFINAE'able on th=
e function body, and will basically resolve problems listed in <a href=3D"h=
ttp://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0238r0.html" rel=3D=
"nofollow" target=3D"_blank" onmousedown=3D"this.href=3D'http://www.goo=
gle.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%=
2Fpapers%2F2016%2Fp0238r0.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHR2O=
2WpZ1MMv9CQLLWTb-Lc143Ow';return true;" onclick=3D"this.href=3D'htt=
p://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fw=
g21%2Fdocs%2Fpapers%2F2016%2Fp0238r0.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3=
dAFQjCNHR2O2WpZ1MMv9CQLLWTb-Lc143Ow';return true;">http://www.open-std.=
org/jtc1/<wbr>sc22/wg21/docs/papers/2016/<wbr>p0238r0.html</a> paper.<br></=
div></blockquote><div><br>But returning `decltype(expr)` is (SFINAE-aside) =
equivalent to `auto`. Which means that it will <i>always</i> return by valu=
e. So if `expr` results in a reference... too bad; it's returning a val=
ue now.<br></div></div></blockquote><div><br>No, it does not. decltype(auto=
) and decltype(expr) are equivalent if the function return statement is ret=
urn expr, and the only situation when it returns by value, is when expr is =
actually an prvalue, in which case returnning by value is only way to avoid=
dangling references.<br><br>And live example:<br><a href=3D"http://melpon.=
org/wandbox/permlink/u3oE3UCBrVHivK12#" target=3D"_blank" rel=3D"nofollow" =
onmousedown=3D"this.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2=
Fmelpon.org%2Fwandbox%2Fpermlink%2Fu3oE3UCBrVHivK12%23\x26sa\x3dD\x26sntz\x=
3d1\x26usg\x3dAFQjCNFRyXOr4uX16dfDrCVEsp3tZwDd-A';return true;" onclick=
=3D"this.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fmelpon.org=
%2Fwandbox%2Fpermlink%2Fu3oE3UCBrVHivK12%23\x26sa\x3dD\x26sntz\x3d1\x26usg\=
x3dAFQjCNFRyXOr4uX16dfDrCVEsp3tZwDd-A';return true;">http://melpon.org/=
wandbox/<wbr>permlink/u3oE3UCBrVHivK12#</a></div></div></blockquote><div><b=
r>Correct link: http://melpon.org/wandbox/permlink/9XhOLN8S0rD7603x=C2=A0 <=
br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/17422161-fe6d-4949-9e9e-381bc4fcd417%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/17422161-fe6d-4949-9e9e-381bc4fcd417=
%40isocpp.org</a>.<br />
------=_Part_1465_1038310150.1476250049537--
------=_Part_1464_2054429466.1476250049537--
.
Author: Zhihao Yuan <zy@miator.net>
Date: Wed, 12 Oct 2016 00:47:17 -0500
Raw View
On Wed, Oct 12, 2016 at 12:24 AM, Tomasz <tomaszkam@gmail.com> wrote:
>> But returning `decltype(expr)` is (SFINAE-aside) equivalent to `auto`.
>> Which means that it will always return by value. So if `expr` results in a
>> reference... too bad; it's returning a value now.
>
>
> No, it does not. decltype(auto) and decltype(expr) are equivalent if the
> function return statement is return expr, and the only situation when it
> returns by value, is when expr is actually an prvalue
My concern is the reversed: user might really want to return
a prvalue using `auto` rules rather than "accidentally" returning
a reference. By default, lambda uses `auto` rules, so making
the abbrev form using `decltype(expr)` changes the intuition.
So here is my suggestion made to applying this change to
normal function definitions by examples:
1. auto f(/* ... */) = return expr;
is equivalent to
auto f(/* ... */) noexcept(expr) -> std::decay_t<decltype(expr)>
{ return expr; }
2. decltype(auto) f(/* ... */) = return expr;
is equivalent to
auto f(/* ... */) noexcept(expr) -> decltype(expr)
{ return expr; }
3. R f(/* ... */) = return expr;
is equivalent to
R f(/* ... */) noexcept(expr)
{ return expr; }
If we follow these conventions as well in abbrev lambdas,
we could optionally let the abbrev form accept a return
type in syntax:
a -> auto = return expr;
a -> decltype(auto) = return expr;
a -> R = return expr;
and
a = return expr;
would yield the first one.
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://blog.miator.net/
--
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/CAGsORuAah%3De4y1ewPDo7MzJHcKr-F0jCS%2BGM%2BHtoZguiYaW5Fw%40mail.gmail.com.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 11 Oct 2016 23:06:48 -0700 (PDT)
Raw View
------=_Part_1853_663232747.1476252409046
Content-Type: multipart/alternative;
boundary="----=_Part_1854_1518512718.1476252409046"
------=_Part_1854_1518512718.1476252409046
Content-Type: text/plain; charset=UTF-8
On Wednesday, October 12, 2016 at 1:47:19 AM UTC-4, Zhihao Yuan wrote:
>
> On Wed, Oct 12, 2016 at 12:24 AM, Tomasz <toma...@gmail.com <javascript:>>
> wrote:
> >> But returning `decltype(expr)` is (SFINAE-aside) equivalent to `auto`.
> >> Which means that it will always return by value. So if `expr` results
> in a
> >> reference... too bad; it's returning a value now.
> >
> >
> > No, it does not. decltype(auto) and decltype(expr) are equivalent if the
> > function return statement is return expr, and the only situation when it
> > returns by value, is when expr is actually an prvalue
>
> My concern is the reversed: user might really want to return
> a prvalue using `auto` rules rather than "accidentally" returning
> a reference. By default, lambda uses `auto` rules, so making
> the abbrev form using `decltype(expr)` changes the intuition.
>
> So here is my suggestion made to applying this change to
> normal function definitions by examples:
>
> 1. auto f(/* ... */) = return expr;
>
> is equivalent to
>
> auto f(/* ... */) noexcept(expr) -> std::decay_t<decltype(expr)>
> { return expr; }
>
> 2. decltype(auto) f(/* ... */) = return expr;
>
> is equivalent to
>
> auto f(/* ... */) noexcept(expr) -> decltype(expr)
> { return expr; }
>
> 3. R f(/* ... */) = return expr;
>
> is equivalent to
>
> R f(/* ... */) noexcept(expr)
> { return expr; }
>
> If we follow these conventions as well in abbrev lambdas,
> we could optionally let the abbrev form accept a return
> type in syntax:
>
> a -> auto = return expr;
> a -> decltype(auto) = return expr;
> a -> R = return expr;
>
> and
>
> a = return expr;
>
> would yield the first one.
>
But what of lambdas? By default, they use `auto` return mechanics, so
`[](...) = return expr` would use the default. But most of the time for
such functions, you want decltype(expr) mechanics. That forces you to do
`[](...) -> decltype(auto) = return expr`
The point of the feature (as it relates to lambdas) is to make the common
case less verbose. Sticking that `decltype(auto)` in there isn't that. Nor
is having to use `return` explicitly.
How about this. We use the suggested `=> expr` syntax. By default, it will
use `decltype(expr)`. However, we can force `std::decay_t<decltype(expr)>`
by saying `=> auto expr`.
The syntax could cause problems if your expression declares a variable. But
we could require that `expr` not declare variables (after all, it wouldn't
be very useful).
It would be a bit inconsistent, since lambdas normally default to `auto`
rather than `decltype(auto)`. But considering that we're using different
syntax, it would probably work out OK.
--
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/416e803c-bacb-4a94-bfd1-12a22f15c1f5%40isocpp.org.
------=_Part_1854_1518512718.1476252409046
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Wednesday, October 12, 2016 at 1:47:19 AM UTC-4=
, Zhihao Yuan wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Wed, Oc=
t 12, 2016 at 12:24 AM, Tomasz <<a href=3D"javascript:" target=3D"_blank=
" gdf-obfuscated-mailto=3D"_NUTeu9GAQAJ" rel=3D"nofollow" onmousedown=3D"th=
is.href=3D'javascript:';return true;" onclick=3D"this.href=3D'j=
avascript:';return true;">toma...@gmail.com</a>> wrote:
<br>>> But returning `decltype(expr)` is (SFINAE-aside) equivalent to=
`auto`.
<br>>> Which means that it will always return by value. So if `expr` =
results in a
<br>>> reference... too bad; it's returning a value now.
<br>>
<br>>
<br>> No, it does not. decltype(auto) and decltype(expr) are equivalent =
if the
<br>> function return statement is return expr, and the only situation w=
hen it
<br>> returns by value, is when expr is actually an prvalue
<br>
<br>My concern is the reversed: user might really want to return
<br>a prvalue using `auto` rules rather than "accidentally" retur=
ning
<br>a reference. =C2=A0By default, lambda uses `auto` rules, so making
<br>the abbrev form using `decltype(expr)` changes the intuition.
<br>
<br>So here is my suggestion made to applying this change to
<br>normal function definitions by examples:
<br>
<br>1. =C2=A0auto f(/* ... */) =3D return expr;
<br>
<br>is equivalent to
<br>
<br>=C2=A0 auto f(/* ... */) noexcept(expr) -> std::decay_t<decltype(=
expr)>
<br>=C2=A0 { return expr; }
<br>
<br>2. =C2=A0decltype(auto) f(/* ... */) =3D return expr;
<br>
<br>is equivalent to
<br>
<br>=C2=A0 auto f(/* ... */) noexcept(expr) -> decltype(expr)
<br>=C2=A0 { return expr; }
<br>
<br>3. R f(/* ... */) =3D return expr;
<br>
<br>is equivalent to
<br>
<br>=C2=A0 R f(/* ... */) noexcept(expr)
<br>=C2=A0 { return expr; }
<br>
<br>If we follow these conventions as well in abbrev lambdas,
<br>we could optionally let the abbrev form accept a return
<br>type in syntax:
<br>
<br>=C2=A0 a -> auto =3D return expr;
<br>=C2=A0 a -> decltype(auto) =3D return expr;
<br>=C2=A0 a -> R =3D return expr;
<br>
<br>and
<br>
<br>=C2=A0 a =3D return expr;
<br>
<br>would yield the first one.<br></blockquote><div><br>But what of lambdas=
? By default, they use `auto` return mechanics, so `[](...) =3D return expr=
` would use the default. But most of the time for such functions, you want =
decltype(expr) mechanics. That forces you to do `[](...) -> decltype(aut=
o) =3D return expr`<br><br>The point of the feature (as it relates to lambd=
as) is to make the common case less verbose. Sticking that `decltype(auto)`=
in there isn't that. Nor is having to use `return` explicitly.<br><br>=
How about this. We use the suggested `=3D> expr` syntax. By default, it =
will use `decltype(expr)`. However, we can force `std::decay_t<decltype(=
expr)>` by saying `=3D> auto expr`.<br><br>The syntax could cause pro=
blems if your expression declares a variable. But we could require that `ex=
pr` not declare variables (after all, it wouldn't be very useful).<br><=
br>It would be a bit inconsistent, since lambdas normally default to `auto`=
rather than `decltype(auto)`. But considering that we're using differe=
nt syntax, it would probably work out OK.<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/416e803c-bacb-4a94-bfd1-12a22f15c1f5%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/416e803c-bacb-4a94-bfd1-12a22f15c1f5=
%40isocpp.org</a>.<br />
------=_Part_1854_1518512718.1476252409046--
------=_Part_1853_663232747.1476252409046--
.
Author: Zhihao Yuan <zy@miator.net>
Date: Wed, 12 Oct 2016 02:40:01 -0500
Raw View
On Wed, Oct 12, 2016 at 1:06 AM, Nicol Bolas <jmckesson@gmail.com> wrote:
> But most of the time for such functions, you want decltype(expr) mechanics.
For non-capturing cases, maybe. But in general, I can't say
much without data.
> We use the suggested `=> expr` syntax.
Some little research shows that:
Languages using => in lambdas:
JavaScript
C#
D
Dart
Standard ML
Perl 6
Scala
Languages using -> in lambdas:
Erlang
Haskell
OCaml
Java
Julia
F#
Elixir
Swift
I'm glad to see that F# and OCaml "fixed" Standard ML's syntax
here :)
I have a whole bag of reasons about not to use "=>" in
lambdas if we have only bikeshedding left.
> By default, it will
> use `decltype(expr)`. However, we can force `std::decay_t<decltype(expr)>`
> by saying `=> auto expr`.
>
> [...]
>
> It would be a bit inconsistent, since lambdas normally default to `auto`
> rather than `decltype(auto)`. But considering that we're using different
> syntax, it would probably work out OK.
You may have noticed that in terms of teachability (yes, it
should be a word if there is a "C++ discussion mode" in
email clients), you are adding complexity on top of
inconsistency, doubling the work plus fearing people
away...
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://blog.miator.net/
--
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/CAGsORuCoS_bnHRaZjQWUTwtXJb2mnaLUf9oS86ad56A5LNdWpQ%40mail.gmail.com.
.
Author: szollosi.lorand@gmail.com
Date: Wed, 12 Oct 2016 00:52:44 -0700 (PDT)
Raw View
------=_Part_366_2004715426.1476258764506
Content-Type: multipart/alternative;
boundary="----=_Part_367_1320189960.1476258764507"
------=_Part_367_1320189960.1476258764507
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Hi,
Can't we just divert `:` for this? I know that '?:' is an operator in=20
itself, but what it tries to be is a definition of two nullary functions=20
and a choice operator (that is *not* simply choosing between the two, think=
=20
of a? b? x : y : z and a? x : b? y : z). As a mind game, we could have:
binary a : b equivalent to make_function_pair( () =3D> a>>, () =3D> b>> );
unary a : (or :a, but then take care about the gcc a ?: b) equivalent to ()=
=20
=3D> a>>.
unary (auto&& i) a + i : equivalent to (i) =3D> a>> + i>>.
and the corresponding binary version. If you don't like typing `(auto&&=20
i)`, we could have `(@i)`, with the special case `@i` for a single=20
parameter. `@` is not yet used in C++ and it's widely available due to=20
email addresses. For those who don't have it, one might introduce a digraph=
=20
like %<.
Note that bindings are mutable and the pairs can be heterogeneous. It's the=
=20
? sequence that makes them homogeneous.
Thanks,
-lorro
2016. okt=C3=B3ber 12., szerda 8:06:49 UTC+2 id=C5=91pontban Nicol Bolas a =
k=C3=B6vetkez=C5=91t=20
=C3=ADrta:
>
>
>
> On Wednesday, October 12, 2016 at 1:47:19 AM UTC-4, Zhihao Yuan wrote:
>>
>> On Wed, Oct 12, 2016 at 12:24 AM, Tomasz <toma...@gmail.com> wrote:=20
>> >> But returning `decltype(expr)` is (SFINAE-aside) equivalent to `auto`=
..=20
>> >> Which means that it will always return by value. So if `expr` results=
=20
>> in a=20
>> >> reference... too bad; it's returning a value now.=20
>> >=20
>> >=20
>> > No, it does not. decltype(auto) and decltype(expr) are equivalent if=
=20
>> the=20
>> > function return statement is return expr, and the only situation when=
=20
>> it=20
>> > returns by value, is when expr is actually an prvalue=20
>>
>> My concern is the reversed: user might really want to return=20
>> a prvalue using `auto` rules rather than "accidentally" returning=20
>> a reference. By default, lambda uses `auto` rules, so making=20
>> the abbrev form using `decltype(expr)` changes the intuition.=20
>>
>> So here is my suggestion made to applying this change to=20
>> normal function definitions by examples:=20
>>
>> 1. auto f(/* ... */) =3D return expr;=20
>>
>> is equivalent to=20
>>
>> auto f(/* ... */) noexcept(expr) -> std::decay_t<decltype(expr)>=20
>> { return expr; }=20
>>
>> 2. decltype(auto) f(/* ... */) =3D return expr;=20
>>
>> is equivalent to=20
>>
>> auto f(/* ... */) noexcept(expr) -> decltype(expr)=20
>> { return expr; }=20
>>
>> 3. R f(/* ... */) =3D return expr;=20
>>
>> is equivalent to=20
>>
>> R f(/* ... */) noexcept(expr)=20
>> { return expr; }=20
>>
>> If we follow these conventions as well in abbrev lambdas,=20
>> we could optionally let the abbrev form accept a return=20
>> type in syntax:=20
>>
>> a -> auto =3D return expr;=20
>> a -> decltype(auto) =3D return expr;=20
>> a -> R =3D return expr;=20
>>
>> and=20
>>
>> a =3D return expr;=20
>>
>> would yield the first one.
>>
>
> But what of lambdas? By default, they use `auto` return mechanics, so=20
> `[](...) =3D return expr` would use the default. But most of the time for=
=20
> such functions, you want decltype(expr) mechanics. That forces you to do=
=20
> `[](...) -> decltype(auto) =3D return expr`
>
> The point of the feature (as it relates to lambdas) is to make the common=
=20
> case less verbose. Sticking that `decltype(auto)` in there isn't that. No=
r=20
> is having to use `return` explicitly.
>
> How about this. We use the suggested `=3D> expr` syntax. By default, it w=
ill=20
> use `decltype(expr)`. However, we can force `std::decay_t<decltype(expr)>=
`=20
> by saying `=3D> auto expr`.
>
> The syntax could cause problems if your expression declares a variable.=
=20
> But we could require that `expr` not declare variables (after all, it=20
> wouldn't be very useful).
>
> It would be a bit inconsistent, since lambdas normally default to `auto`=
=20
> rather than `decltype(auto)`. But considering that we're using different=
=20
> syntax, it would probably work out OK.
>
--=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/3a8120c7-53a3-4fd0-9ada-489fbce2877e%40isocpp.or=
g.
------=_Part_367_1320189960.1476258764507
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi,<br><br>Can't we just divert `:` for this? I know t=
hat '?:' is an operator in itself, but what it tries to be is a def=
inition of two nullary functions and a choice operator (that is <i>not</i> =
simply choosing between the two, think of a? b? x : y : z and a? x : b? y :=
z). As a mind game, we could have:<br>binary a : b equivalent to make_func=
tion_pair( () =3D> a>>, () =3D> b>> );<br>unary a : (or :=
a, but then take care about the gcc a ?: b) equivalent to () =3D> a>&=
gt;.<br>unary (auto&& i) a + i : equivalent to (i) =3D> a>>=
; + i>>.<br>and the corresponding binary version. If you don't li=
ke typing `(auto&& i)`, we could have `(@i)`, with the special case=
`@i` for a single parameter. `@` is not yet used in C++ and it's widel=
y available due to email addresses. For those who don't have it, one mi=
ght introduce a digraph like %<.<br><br>Note that bindings are mutable a=
nd the pairs can be heterogeneous. It's the ? sequence that makes them =
homogeneous.<br><br>Thanks,<br>-lorro<br><br><br>2016. okt=C3=B3ber 12., sz=
erda 8:06:49 UTC+2 id=C5=91pontban Nicol Bolas a k=C3=B6vetkez=C5=91t =C3=
=ADrta:<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"><br><b=
r>On Wednesday, October 12, 2016 at 1:47:19 AM UTC-4, Zhihao Yuan wrote:<bl=
ockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-l=
eft:1px #ccc solid;padding-left:1ex">On Wed, Oct 12, 2016 at 12:24 AM, Toma=
sz <<a rel=3D"nofollow">toma...@gmail.com</a>> wrote:
<br>>> But returning `decltype(expr)` is (SFINAE-aside) equivalent to=
`auto`.
<br>>> Which means that it will always return by value. So if `expr` =
results in a
<br>>> reference... too bad; it's returning a value now.
<br>>
<br>>
<br>> No, it does not. decltype(auto) and decltype(expr) are equivalent =
if the
<br>> function return statement is return expr, and the only situation w=
hen it
<br>> returns by value, is when expr is actually an prvalue
<br>
<br>My concern is the reversed: user might really want to return
<br>a prvalue using `auto` rules rather than "accidentally" retur=
ning
<br>a reference. =C2=A0By default, lambda uses `auto` rules, so making
<br>the abbrev form using `decltype(expr)` changes the intuition.
<br>
<br>So here is my suggestion made to applying this change to
<br>normal function definitions by examples:
<br>
<br>1. =C2=A0auto f(/* ... */) =3D return expr;
<br>
<br>is equivalent to
<br>
<br>=C2=A0 auto f(/* ... */) noexcept(expr) -> std::decay_t<decltype(=
expr)>
<br>=C2=A0 { return expr; }
<br>
<br>2. =C2=A0decltype(auto) f(/* ... */) =3D return expr;
<br>
<br>is equivalent to
<br>
<br>=C2=A0 auto f(/* ... */) noexcept(expr) -> decltype(expr)
<br>=C2=A0 { return expr; }
<br>
<br>3. R f(/* ... */) =3D return expr;
<br>
<br>is equivalent to
<br>
<br>=C2=A0 R f(/* ... */) noexcept(expr)
<br>=C2=A0 { return expr; }
<br>
<br>If we follow these conventions as well in abbrev lambdas,
<br>we could optionally let the abbrev form accept a return
<br>type in syntax:
<br>
<br>=C2=A0 a -> auto =3D return expr;
<br>=C2=A0 a -> decltype(auto) =3D return expr;
<br>=C2=A0 a -> R =3D return expr;
<br>
<br>and
<br>
<br>=C2=A0 a =3D return expr;
<br>
<br>would yield the first one.<br></blockquote><div><br>But what of lambdas=
? By default, they use `auto` return mechanics, so `[](...) =3D return expr=
` would use the default. But most of the time for such functions, you want =
decltype(expr) mechanics. That forces you to do `[](...) -> decltype(aut=
o) =3D return expr`<br><br>The point of the feature (as it relates to lambd=
as) is to make the common case less verbose. Sticking that `decltype(auto)`=
in there isn't that. Nor is having to use `return` explicitly.<br><br>=
How about this. We use the suggested `=3D> expr` syntax. By default, it =
will use `decltype(expr)`. However, we can force `std::decay_t<decltype(=
expr)>` by saying `=3D> auto expr`.<br><br>The syntax could cause pro=
blems if your expression declares a variable. But we could require that `ex=
pr` not declare variables (after all, it wouldn't be very useful).<br><=
br>It would be a bit inconsistent, since lambdas normally default to `auto`=
rather than `decltype(auto)`. But considering that we're using differe=
nt syntax, it would probably work out OK.<br></div></div></blockquote></div=
>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/3a8120c7-53a3-4fd0-9ada-489fbce2877e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/3a8120c7-53a3-4fd0-9ada-489fbce2877e=
%40isocpp.org</a>.<br />
------=_Part_367_1320189960.1476258764507--
------=_Part_366_2004715426.1476258764506--
.
Author: Zhihao Yuan <zy@miator.net>
Date: Wed, 12 Oct 2016 03:25:40 -0500
Raw View
On Wed, Oct 12, 2016 at 2:40 AM, Zhihao Yuan <zy@miator.net> wrote:
>
> I have a whole bag of reasons about not to use "=>" in
> lambdas if we have only bikeshedding left.
>
>> By default, it will
>> use `decltype(expr)`. However, we can force `std::decay_t<decltype(expr)>`
>> by saying `=> auto expr`.
>>
>> [...]
>>
>> It would be a bit inconsistent, since lambdas normally default to `auto`
>> rather than `decltype(auto)`. But considering that we're using different
>> syntax, it would probably work out OK.
>
> You may have noticed that in terms of teachability (yes, it
> should be a word if there is a "C++ discussion mode" in
> email clients), you are adding complexity on top of
> inconsistency, doubling the work plus fearing people
> away...
And here are my constructive notes:
1. If people insist that we must not expand an abbrev
syntax to allow specifying an optional return type,
we have to choose from one deduction rule from the
two, and letting the other one suffers for their own
reasons. Because if we don't want to allow tweaking
a well-known thing, following the same logic we should
not allow tweaking a less well-known thing for a
feature striving for simplicity.
2. If people don't like 'return', here is another syntax
I can think of:
[] -> expr
[] a -> expr
[&cap] a, b -> expr
Can someone tell me that whether it's parseable? I can
read code like this though.
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://blog.miator.net/
--
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/CAGsORuA9%3DqufbkV%3D4xqCbsZs%2BT_-xpmUBx611SDyWM%3DQTEA_RQ%40mail.gmail.com.
.
Author: Victor Dyachenko <victor.dyachenko@gmail.com>
Date: Wed, 12 Oct 2016 02:35:31 -0700 (PDT)
Raw View
------=_Part_2958_1102057378.1476264931651
Content-Type: multipart/alternative;
boundary="----=_Part_2959_917582748.1476264931651"
------=_Part_2959_917582748.1476264931651
Content-Type: text/plain; charset=UTF-8
On Wednesday, October 12, 2016 at 12:53:55 AM UTC+3, Richard Smith wrote:
>
>
> This will be difficult to parse. Requiring lookahead past the ) whenever
> we see a ( is likely not going to be acceptable. Handling
> "(identifier-list) =>" would already be a rather special case, but is
> probably manageable because you can defer handling the identifier-list part
> until after you reach the ")" and see whether there's a "=>" next. But
> once you add in default arguments / assignment-expressions (where the rules
> for valid expressions are subtly different, especially since earlier
> parameter names are in scope in the default arguments of later parameters),
> you can't use that same strategy.
>
I think anything that creates parsing issues just has to be just
disallowed. Particularly hardly ever people need default arguments in this
terse syntax. Who needs advanced features always can use "good old" 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/7a2bcfbd-9e09-4af0-945f-db375d2fd988%40isocpp.org.
------=_Part_2959_917582748.1476264931651
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wednesday, October 12, 2016 at 12:53:55 AM UTC+3, Richa=
rd Smith 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=
"><div><div class=3D"gmail_quote"><br><div>This will be difficult to parse.=
Requiring lookahead past the ) whenever we see a ( is likely not going to =
be acceptable. Handling "(identifier-list) =3D>" would already=
be a rather special case, but is probably manageable because you can defer=
handling the identifier-list part until after you reach the ")" =
and see whether there's a "=3D>" next.=C2=A0 But once you =
add in default arguments / assignment-expressions (where the rules for vali=
d expressions are subtly different, especially since earlier parameter name=
s are in scope in the default arguments of later parameters), you can't=
use that same strategy.</div></div></div></div></blockquote><div>I think a=
nything that creates parsing issues just has to be just disallowed. Particu=
larly hardly ever people need default arguments in this terse syntax. Who n=
eeds advanced features always can use "good old" 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" 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/7a2bcfbd-9e09-4af0-945f-db375d2fd988%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/7a2bcfbd-9e09-4af0-945f-db375d2fd988=
%40isocpp.org</a>.<br />
------=_Part_2959_917582748.1476264931651--
------=_Part_2958_1102057378.1476264931651--
.
Author: TONGARI J <tongari95@gmail.com>
Date: Wed, 12 Oct 2016 07:00:57 -0700 (PDT)
Raw View
------=_Part_4790_245267564.1476280857836
Content-Type: multipart/alternative;
boundary="----=_Part_4791_804861090.1476280857836"
------=_Part_4791_804861090.1476280857836
Content-Type: text/plain; charset=UTF-8
On Wednesday, October 12, 2016 at 1:47:19 PM UTC+8, Zhihao Yuan wrote:
>
> On Wed, Oct 12, 2016 at 12:24 AM, Tomasz <toma...@gmail.com <javascript:>>
> wrote:
> >> But returning `decltype(expr)` is (SFINAE-aside) equivalent to `auto`.
> >> Which means that it will always return by value. So if `expr` results
> in a
> >> reference... too bad; it's returning a value now.
> >
> >
> > No, it does not. decltype(auto) and decltype(expr) are equivalent if the
> > function return statement is return expr, and the only situation when it
> > returns by value, is when expr is actually an prvalue
>
> My concern is the reversed: user might really want to return
> a prvalue using `auto` rules rather than "accidentally" returning
> a reference. By default, lambda uses `auto` rules, so making
> the abbrev form using `decltype(expr)` changes the intuition.
>
> So here is my suggestion made to applying this change to
> normal function definitions by examples:
>
> 1. auto f(/* ... */) = return expr;
>
> is equivalent to
>
> auto f(/* ... */) noexcept(expr) -> std::decay_t<decltype(expr)>
> { return expr; }
>
> 2. decltype(auto) f(/* ... */) = return expr;
>
> is equivalent to
>
> auto f(/* ... */) noexcept(expr) -> decltype(expr)
> { return expr; }
>
> 3. R f(/* ... */) = return expr;
>
> is equivalent to
>
> R f(/* ... */) noexcept(expr)
> { return expr; }
>
> If we follow these conventions as well in abbrev lambdas,
> we could optionally let the abbrev form accept a return
> type in syntax:
>
> a -> auto = return expr;
> a -> decltype(auto) = return expr;
> a -> R = return expr;
>
> and
>
> a = return expr;
>
> would yield the first one.
>
If we need the "return" keyword, it's not that terse, you know...
I'd be much happier if we could have the syntax as:
auto f(/* ... */) = expr;
However, one thing that prevents us from pursuing such syntax for normal
functions is pure virtual function...
--
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/8a2b7820-fa68-4dcb-8824-5fbfc133fe2c%40isocpp.org.
------=_Part_4791_804861090.1476280857836
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wednesday, October 12, 2016 at 1:47:19 PM UTC+8, Zhihao=
Yuan wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Wed, Oct 12, 20=
16 at 12:24 AM, Tomasz <<a href=3D"javascript:" target=3D"_blank" gdf-ob=
fuscated-mailto=3D"_NUTeu9GAQAJ" rel=3D"nofollow" onmousedown=3D"this.href=
=3D'javascript:';return true;" onclick=3D"this.href=3D'javascri=
pt:';return true;">toma...@gmail.com</a>> wrote:
<br>>> But returning `decltype(expr)` is (SFINAE-aside) equivalent to=
`auto`.
<br>>> Which means that it will always return by value. So if `expr` =
results in a
<br>>> reference... too bad; it's returning a value now.
<br>>
<br>>
<br>> No, it does not. decltype(auto) and decltype(expr) are equivalent =
if the
<br>> function return statement is return expr, and the only situation w=
hen it
<br>> returns by value, is when expr is actually an prvalue
<br>
<br>My concern is the reversed: user might really want to return
<br>a prvalue using `auto` rules rather than "accidentally" retur=
ning
<br>a reference. =C2=A0By default, lambda uses `auto` rules, so making
<br>the abbrev form using `decltype(expr)` changes the intuition.
<br>
<br>So here is my suggestion made to applying this change to
<br>normal function definitions by examples:
<br>
<br>1. =C2=A0auto f(/* ... */) =3D return expr;
<br>
<br>is equivalent to
<br>
<br>=C2=A0 auto f(/* ... */) noexcept(expr) -> std::decay_t<decltype(=
expr)>
<br>=C2=A0 { return expr; }
<br>
<br>2. =C2=A0decltype(auto) f(/* ... */) =3D return expr;
<br>
<br>is equivalent to
<br>
<br>=C2=A0 auto f(/* ... */) noexcept(expr) -> decltype(expr)
<br>=C2=A0 { return expr; }
<br>
<br>3. R f(/* ... */) =3D return expr;
<br>
<br>is equivalent to
<br>
<br>=C2=A0 R f(/* ... */) noexcept(expr)
<br>=C2=A0 { return expr; }
<br>
<br>If we follow these conventions as well in abbrev lambdas,
<br>we could optionally let the abbrev form accept a return
<br>type in syntax:
<br>
<br>=C2=A0 a -> auto =3D return expr;
<br>=C2=A0 a -> decltype(auto) =3D return expr;
<br>=C2=A0 a -> R =3D return expr;
<br>
<br>and
<br>
<br>=C2=A0 a =3D return expr;
<br>
<br>would yield the first one.
<br></blockquote><div><br></div><div>If we need the "return" keyw=
ord, it's not that terse, you know...</div><div style=3D"font-family: a=
rial, sans-serif; font-size: small;">I'd be much happier if we could ha=
ve the syntax as:</div><div><div class=3D"prettyprint" style=3D"background-=
color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: =
solid; border-width: 1px; word-wrap: break-word;"><code class=3D"prettyprin=
t"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styl=
ed-by-prettify">auto</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> f</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">(</span><span style=3D"color: #800;" class=3D"styled-by-prettify">/* ... =
*/</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> expr</span><span style=3D"color:=
#660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> </span></div></code></div><br></div><div>Howev=
er, one thing that prevents us from pursuing such syntax for normal functio=
ns is pure virtual function...</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/8a2b7820-fa68-4dcb-8824-5fbfc133fe2c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/8a2b7820-fa68-4dcb-8824-5fbfc133fe2c=
%40isocpp.org</a>.<br />
------=_Part_4791_804861090.1476280857836--
------=_Part_4790_245267564.1476280857836--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Wed, 12 Oct 2016 07:04:14 -0700 (PDT)
Raw View
------=_Part_202_640625207.1476281054993
Content-Type: multipart/alternative;
boundary="----=_Part_203_175467725.1476281054993"
------=_Part_203_175467725.1476281054993
Content-Type: text/plain; charset=UTF-8
On Wednesday, October 12, 2016 at 3:40:04 AM UTC-4, Zhihao Yuan wrote:
>
> On Wed, Oct 12, 2016 at 1:06 AM, Nicol Bolas <jmck...@gmail.com
> <javascript:>> wrote:
> > But most of the time for such functions, you want decltype(expr)
> mechanics.
>
> For non-capturing cases, maybe. But in general, I can't say
> much without data.
>
The cases which motivate the initial proposal need to use the
`decltype(expr)` mechanics. Indeed, as outlined by the OP, that's a good
50% of the point of asking for the functionality.
The goal of the syntax is to make it possible to write trivial forwarding
functions and expression functions. Using `auto` return deduction works
against that, since it doesn't forward return values exactly as if you had
written the expression locally.
> By default, it will
> > use `decltype(expr)`. However, we can force
> `std::decay_t<decltype(expr)>`
> > by saying `=> auto expr`.
> >
> > [...]
> >
> > It would be a bit inconsistent, since lambdas normally default to `auto`
> > rather than `decltype(auto)`. But considering that we're using different
> > syntax, it would probably work out OK.
>
> You may have noticed that in terms of teachability (yes, it
> should be a word if there is a "C++ discussion mode" in
> email clients), you are adding complexity on top of
> inconsistency, doubling the work plus fearing people
> away...
>
It's only difficult to teach if people need to use the `auto` return type
deduction rules.
--
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/6664aa86-bf5d-4692-8459-f3b36cadb13c%40isocpp.org.
------=_Part_203_175467725.1476281054993
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wednesday, October 12, 2016 at 3:40:04 AM UTC-4, Zhihao=
Yuan wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Wed, Oct 12, 20=
16 at 1:06 AM, Nicol Bolas <<a href=3D"javascript:" target=3D"_blank" gd=
f-obfuscated-mailto=3D"N91MaRZNAQAJ" rel=3D"nofollow" onmousedown=3D"this.h=
ref=3D'javascript:';return true;" onclick=3D"this.href=3D'javas=
cript:';return true;">jmck...@gmail.com</a>> wrote:
<br>> But most of the time for such functions, you want decltype(expr) m=
echanics.
<br>
<br>For non-capturing cases, maybe. =C2=A0But in general, I can't say
<br>much without data.<br></blockquote><div><br>The cases which motivate th=
e initial proposal need to use the `decltype(expr)` mechanics. Indeed, as o=
utlined by the OP, that's a good 50% of the point of asking for the fun=
ctionality.<br><br>The goal of the syntax is to make it possible to write t=
rivial forwarding functions and expression functions. Using `auto` return d=
eduction works against that, since it doesn't forward return values exa=
ctly as if you had written the expression locally.<br><br></div><blockquote=
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1=
px #ccc solid;padding-left: 1ex;">
> By default, it will
<br>> use `decltype(expr)`. However, we can force `std::decay_t<declt=
ype(expr)>`
<br>> by saying `=3D> auto expr`.
<br>>
<br>> [...]
<br>>
<br>> It would be a bit inconsistent, since lambdas normally default to =
`auto`
<br>> rather than `decltype(auto)`. But considering that we're using=
different
<br>> syntax, it would probably work out OK.
<br>
<br>You may have noticed that in terms of teachability (yes, it
<br>should be a word if there is a "C++ discussion mode" in
<br>email clients), you are adding complexity on top of
<br>inconsistency, doubling the work plus fearing people
<br>away...
<br></blockquote><div><br>It's only difficult to teach if people need t=
o use the `auto` return type deduction rules.<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/6664aa86-bf5d-4692-8459-f3b36cadb13c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/6664aa86-bf5d-4692-8459-f3b36cadb13c=
%40isocpp.org</a>.<br />
------=_Part_203_175467725.1476281054993--
------=_Part_202_640625207.1476281054993--
.
Author: Domen Vrankar <domen.vrankar@gmail.com>
Date: Wed, 12 Oct 2016 21:29:42 +0200
Raw View
--001a1144844a386e74053eb00670
Content-Type: text/plain; charset=UTF-8
2016-10-11 23:56 GMT+02:00 Andrey Semashev <andrey.semashev@gmail.com>:
> On 10/11/16 20:32, Barry Revzin wrote:
>
>> Here is a contrasting proposal for how to handle overload sets as
>> function arguments. While a lot more verbose in the simple case of just
>> naming a function (where instead of just naming the function you have to
>> actually enumerate the arguments list twice), I think it offers more
>> flexibility in writing short lambdas. There are some motivating examples
>> in the proposal. It's also getting pretty verbose to write correct
>> generic functions with regards to SFINAE and noexcept, so this attempts
>> to make it a little bit easier - at least in the easy case.
>>
>> Also I'm proposing a shorter syntax for forwarding arguments. I picked
>> unary>> because it looks like moving something forward but really
>> anything shorter would be nice. std::forward<Arg>(arg) is particularly
>> verbose, especially in a generic lambda where you have to write
>> std::forward<decltype(arg)>(arg), where the actual forwarding just
>> dominates the code itself.
>>
>
> IMHO, this new syntax makes the code more obscure. The proposed
> abbreviated lambdas no longer have any resemblence with functions and blend
> in the surrounding code too much (yes, this is a bad thing).
>
+1
While I would like a more compact syntax for lambdas my eyes seem to be
really adjusted to brackets so I would prefer such syntax:
(x) => {i < 1000}
So mandatory parentheses around parameters even if there is only a single
one and mandatory curly braces around function body even though it is a one
liner. Don't care too much about return statement, semicolon or [ ]
brackets in this case - in fact I even prefer them gone.
I believe that this would make it far more readable with not too much extra
noise with more resemblance with functions and lambdas. (I hope that it
doesn't add issues with initializer lists or something like that...)
Regards,
Domen
--
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/CAKgx6BJ-Y18Lp-O0g5Askeyx9roC4Z3%2BeiChXSzv99WkYpF08A%40mail.gmail.com.
--001a1144844a386e74053eb00670
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">2016-10-11 23:56 GMT+02:00 Andrey Semashev <span dir=3D"lt=
r"><<a target=3D"_blank" href=3D"mailto:andrey.semashev@gmail.com">andre=
y.semashev@gmail.com</a>></span>:<br><div class=3D"gmail_extra"><div cla=
ss=3D"gmail_quote"><blockquote style=3D"margin:0px 0px 0px 0.8ex;border-lef=
t:1px solid rgb(204,204,204);padding-left:1ex" class=3D"gmail_quote"><span =
class=3D"gmail-">On 10/11/16 20:32, Barry Revzin wrote:<br>
<blockquote style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204=
,204,204);padding-left:1ex" class=3D"gmail_quote">
Here is a contrasting proposal for how to handle overload sets as<br>
function arguments. While a lot more verbose in the simple case of just<br>
naming a function (where instead of just naming the function you have to<br=
>
actually enumerate the arguments list twice), I think it offers more<br>
flexibility in writing short lambdas. There are some motivating examples<br=
>
in the proposal. It's also getting pretty verbose to write correct<br>
generic functions with regards to SFINAE and noexcept, so this attempts<br>
to make it a little bit easier - at least in the easy case.<br>
<br>
Also I'm proposing a shorter syntax for forwarding arguments. I picked<=
br>
unary>> because it looks like moving something forward but really<br>
anything shorter would be nice. std::forward<Arg>(arg) is particularl=
y<br>
verbose, especially in a generic lambda where you have to write<br>
std::forward<decltype(arg)>(ar<wbr>g), where the actual forwarding ju=
st<br>
dominates the code itself.<br>
</blockquote>
<br></span>
IMHO, this new syntax makes the code more obscure. The proposed abbreviated=
lambdas no longer have any resemblence with functions and blend in the sur=
rounding code too much (yes, this is a bad thing).<span class=3D"gmail-"><b=
r></span></blockquote><div><br>+1<br><br></div><div>While I would like=C2=
=A0 a more compact syntax for lambdas my eyes seem to be really adjusted to=
brackets so I would prefer such syntax:<br><br></div><div>(x) =3D> {i &=
lt; 1000}<br></div><div><br></div><div>So mandatory parentheses around para=
meters even if there is only a single one and mandatory curly braces around=
function body even though it is a one liner. Don't care too much about=
return statement,=C2=A0 semicolon or [ ] brackets in this case - in fact I=
even prefer them gone.<br><br></div><div>I believe that this would make it=
far more readable with not too much extra noise with more resemblance with=
functions and lambdas. (I hope that it doesn't add issues with initial=
izer lists or something like that...)<br><br></div><div>Regards,<br></div><=
div>Domen<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" 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/CAKgx6BJ-Y18Lp-O0g5Askeyx9roC4Z3%2Bei=
ChXSzv99WkYpF08A%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKgx6BJ-Y18Lp-=
O0g5Askeyx9roC4Z3%2BeiChXSzv99WkYpF08A%40mail.gmail.com</a>.<br />
--001a1144844a386e74053eb00670--
.
Author: Zhihao Yuan <zy@miator.net>
Date: Wed, 12 Oct 2016 14:36:20 -0500
Raw View
On Wed, Oct 12, 2016 at 2:29 PM, Domen Vrankar <domen.vrankar@gmail.com> wr=
ote:
>
> (x) =3D> {i < 1000}
>
> So mandatory parentheses around parameters even if there is only a single
> one and mandatory curly braces around function body even though it is a o=
ne
> liner. Don't care too much about return statement, semicolon or [ ]
> brackets in this case - in fact I even prefer them gone.
Read [] as the introductory =CE=BB notation:
[] x -> x < 1000
Totally reassembles the Haskell style
\x -> x < 1000
or the F# and OCaml one
fun x -> x < 1000
--=20
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://blog.miator.net/
--=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/CAGsORuAEWp%2BwsUvEZqR%2BTm-LtTKBR-9o5npd1eoZE6d=
WmD4kMg%40mail.gmail.com.
.
Author: Tomasz <tomaszkam@gmail.com>
Date: Wed, 12 Oct 2016 12:38:48 -0700 (PDT)
Raw View
------=_Part_4246_2049806823.1476301128778
Content-Type: multipart/alternative;
boundary="----=_Part_4247_831809286.1476301128779"
------=_Part_4247_831809286.1476301128779
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
And having [] is the only way to specify capture for the shorter lambda,=20
like:
[x] y =3D> y + x;
W dniu =C5=9Broda, 12 pa=C5=BAdziernika 2016 21:36:23 UTC+2 u=C5=BCytkownik=
Zhihao Yuan=20
napisa=C5=82:
>
> On Wed, Oct 12, 2016 at 2:29 PM, Domen Vrankar <domen....@gmail.com=20
> <javascript:>> wrote:=20
> >=20
> > (x) =3D> {i < 1000}=20
> >=20
> > So mandatory parentheses around parameters even if there is only a=20
> single=20
> > one and mandatory curly braces around function body even though it is a=
=20
> one=20
> > liner. Don't care too much about return statement, semicolon or [ ]=20
> > brackets in this case - in fact I even prefer them gone.=20
>
> Read [] as the introductory =CE=BB notation:=20
>
> [] x -> x < 1000=20
>
> Totally reassembles the Haskell style=20
>
> \x -> x < 1000=20
>
> or the F# and OCaml one=20
>
> fun x -> x < 1000=20
>
> --=20
> Zhihao Yuan, ID lichray=20
> The best way to predict the future is to invent it.=20
> ___________________________________________________=20
> 4BSD -- http://blog.miator.net/=20
>
--=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/59e65655-e9ce-4efa-814c-21a72bfe866f%40isocpp.or=
g.
------=_Part_4247_831809286.1476301128779
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">And having [] is the only way to specify capture for the s=
horter lambda, like:<br>[x] y =3D> y + x;<br><br>W dniu =C5=9Broda, 12 p=
a=C5=BAdziernika 2016 21:36:23 UTC+2 u=C5=BCytkownik Zhihao Yuan napisa=C5=
=82:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;">On Wed, Oct 12, 2016 at 2:=
29 PM, Domen Vrankar <<a href=3D"javascript:" target=3D"_blank" gdf-obfu=
scated-mailto=3D"ianMSy10AQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D=
'javascript:';return true;" onclick=3D"this.href=3D'javascript:=
';return true;">domen....@gmail.com</a>> wrote:
<br>>
<br>> (x) =3D> {i < 1000}
<br>>
<br>> So mandatory parentheses around parameters even if there is only a=
single
<br>> one and mandatory curly braces around function body even though it=
is a one
<br>> liner. Don't care too much about return statement, =C2=A0semic=
olon or [ ]
<br>> brackets in this case - in fact I even prefer them gone.
<br>
<br>Read [] as the introductory =CE=BB notation:
<br>
<br>=C2=A0 [] x -> x < 1000
<br>
<br>Totally reassembles the Haskell style
<br>
<br>=C2=A0 \x -> x < 1000
<br>
<br>or the F# and OCaml one
<br>
<br>=C2=A0 fun x -> x < 1000
<br>
<br>--=20
<br>Zhihao Yuan, ID lichray
<br>The best way to predict the future is to invent it.
<br>______________________________<wbr>_____________________
<br>4BSD -- <a href=3D"http://blog.miator.net/" target=3D"_blank" rel=3D"no=
follow" onmousedown=3D"this.href=3D'http://www.google.com/url?q\x3dhttp=
%3A%2F%2Fblog.miator.net%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHmWTsHV=
Z1D7s1tahvZikRjgaSh7g';return true;" onclick=3D"this.href=3D'http:/=
/www.google.com/url?q\x3dhttp%3A%2F%2Fblog.miator.net%2F\x26sa\x3dD\x26sntz=
\x3d1\x26usg\x3dAFQjCNHmWTsHVZ1D7s1tahvZikRjgaSh7g';return true;">http:=
//blog.miator.net/</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" 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/59e65655-e9ce-4efa-814c-21a72bfe866f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/59e65655-e9ce-4efa-814c-21a72bfe866f=
%40isocpp.org</a>.<br />
------=_Part_4247_831809286.1476301128779--
------=_Part_4246_2049806823.1476301128778--
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Wed, 12 Oct 2016 12:39:12 -0700
Raw View
--001a113ee190d52ce6053eb0251b
Content-Type: text/plain; charset=UTF-8
On Wed, Oct 12, 2016 at 1:25 AM, Zhihao Yuan <zy@miator.net> wrote:
> On Wed, Oct 12, 2016 at 2:40 AM, Zhihao Yuan <zy@miator.net> wrote:
> >
> > I have a whole bag of reasons about not to use "=>" in
> > lambdas if we have only bikeshedding left.
> >
> >> By default, it will
> >> use `decltype(expr)`. However, we can force
> `std::decay_t<decltype(expr)>`
> >> by saying `=> auto expr`.
> >>
> >> [...]
> >>
> >> It would be a bit inconsistent, since lambdas normally default to `auto`
> >> rather than `decltype(auto)`. But considering that we're using different
> >> syntax, it would probably work out OK.
> >
> > You may have noticed that in terms of teachability (yes, it
> > should be a word if there is a "C++ discussion mode" in
> > email clients), you are adding complexity on top of
> > inconsistency, doubling the work plus fearing people
> > away...
>
> And here are my constructive notes:
>
> 1. If people insist that we must not expand an abbrev
> syntax to allow specifying an optional return type,
> we have to choose from one deduction rule from the
> two, and letting the other one suffers for their own
> reasons. Because if we don't want to allow tweaking
> a well-known thing, following the same logic we should
> not allow tweaking a less well-known thing for a
> feature striving for simplicity.
>
> 2. If people don't like 'return', here is another syntax
> I can think of:
>
> [] -> expr
> [] a -> expr
> [&cap] a, b -> expr
>
> Can someone tell me that whether it's parseable? I can
> read code like this though.
I think it's a big mistake to use -> as both a specifier for a return type
and for a produced value. People write
[] -> T { ... }
(missing out the "()") often enough that several implementations have
dedicated custom errors to catch this, and there was a proposal to allow 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/CAOfiQqn8sWFJanfc1bUUoRDW1PjPf8g4o7cy41MAdTpfBw1R-Q%40mail.gmail.com.
--001a113ee190d52ce6053eb0251b
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, Oct 12, 2016 at 1:25 AM, Zhihao Yuan <span dir=3D"ltr"><<a href=3D"m=
ailto:zy@miator.net" target=3D"_blank">zy@miator.net</a>></span> wrote:<=
br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex"><span class=3D"">On Wed, Oct 12, 2016 at =
2:40 AM, Zhihao Yuan <<a href=3D"mailto:zy@miator.net">zy@miator.net</a>=
> wrote:<br>
><br>
> I have a whole bag of reasons about not to use "=3D>" in<=
br>
> lambdas if we have only bikeshedding left.<br>
><br>
>> By default, it will<br>
>> use `decltype(expr)`. However, we can force `std::decay_t<declt=
ype(expr)>`<br>
>> by saying `=3D> auto expr`.<br>
>><br>
>> [...]<br>
>><br>
>> It would be a bit inconsistent, since lambdas normally default to =
`auto`<br>
>> rather than `decltype(auto)`. But considering that we're using=
different<br>
>> syntax, it would probably work out OK.<br>
><br>
> You may have noticed that in terms of teachability (yes, it<br>
> should be a word if there is a "C++ discussion mode" in<br>
> email clients), you are adding complexity on top of<br>
> inconsistency, doubling the work plus fearing people<br>
> away...<br>
<br>
</span>And here are my constructive notes:<br>
<br>
1. If people insist that we must not expand an abbrev<br>
=C2=A0 syntax to allow specifying an optional return type,<br>
=C2=A0 we have to choose from one deduction rule from the<br>
=C2=A0 two, and letting the other one suffers for their own<br>
=C2=A0 reasons.=C2=A0 Because if we don't want to allow tweaking<br>
=C2=A0 a well-known thing, following the same logic we should<br>
=C2=A0 not allow tweaking a less well-known thing for a<br>
=C2=A0 feature striving for simplicity.<br>
<br>
2. If people don't like 'return', here is another syntax<br>
=C2=A0 I can think of:<br>
<br>
=C2=A0 [] -> expr<br>
=C2=A0 [] a -> expr<br>
=C2=A0 [&cap] a, b -> expr<br>
<br>
=C2=A0 Can someone tell me that whether it's parseable?=C2=A0 I can<br>
=C2=A0 read code like this though.</blockquote><div><br></div><div>I think =
it's a big mistake to use -> as both a specifier for a return type a=
nd for a produced value. People write</div><div><br></div><div>=C2=A0 [] -&=
gt; T { ... }</div><div><br></div><div>(missing out the "()") oft=
en enough that several implementations have dedicated custom errors to catc=
h this, and there was a proposal to allow it.</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" 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/CAOfiQqn8sWFJanfc1bUUoRDW1PjPf8g4o7cy=
41MAdTpfBw1R-Q%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQqn8sWFJanfc=
1bUUoRDW1PjPf8g4o7cy41MAdTpfBw1R-Q%40mail.gmail.com</a>.<br />
--001a113ee190d52ce6053eb0251b--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Wed, 12 Oct 2016 16:10:48 -0400
Raw View
Nothing (exaggeration) else about C++ resembles Haskell, why start now?
I'd prefer it to resemble C++.
Sent=C2=A0from=C2=A0my=C2=A0BlackBerry=C2=A0portable=C2=A0Babbage=C2=A0Devi=
ce
=C2=A0 Original Message =C2=A0
From: Zhihao Yuan
Sent: Wednesday, October 12, 2016 3:36 PM
To: std-proposals@isocpp.org
Reply To: std-proposals@isocpp.org
Subject: Re: [std-proposals] An abbreviated lambda syntax
On Wed, Oct 12, 2016 at 2:29 PM, Domen Vrankar <domen.vrankar@gmail.com> wr=
ote:
>
> (x) =3D> {i < 1000}
>
> So mandatory parentheses around parameters even if there is only a single
> one and mandatory curly braces around function body even though it is a o=
ne
> liner. Don't care too much about return statement, semicolon or [ ]
> brackets in this case - in fact I even prefer them gone.
Read [] as the introductory =CE=BB notation:
[] x -> x < 1000
Totally reassembles the Haskell style
\x -> x < 1000
or the F# and OCaml one
fun x -> x < 1000
--=20
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://blog.miator.net/
--=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/CAGsORuAEWp%2BwsUvEZqR%2BTm-LtTKBR-9o5npd1eoZE6d=
WmD4kMg%40mail.gmail.com.
--=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/20161012201048.4882513.25468.18326%40gmail.com.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Wed, 12 Oct 2016 13:28:01 -0700 (PDT)
Raw View
------=_Part_4354_1691808007.1476304082011
Content-Type: multipart/alternative;
boundary="----=_Part_4355_1061898774.1476304082011"
------=_Part_4355_1061898774.1476304082011
Content-Type: text/plain; charset=UTF-8
On Wednesday, October 12, 2016 at 3:30:24 PM UTC-4, Domen Vrankar wrote:
>
> 2016-10-11 23:56 GMT+02:00 Andrey Semashev <andrey....@gmail.com
> <javascript:>>:
>
>> On 10/11/16 20:32, Barry Revzin wrote:
>>
>>> Here is a contrasting proposal for how to handle overload sets as
>>> function arguments. While a lot more verbose in the simple case of just
>>> naming a function (where instead of just naming the function you have to
>>> actually enumerate the arguments list twice), I think it offers more
>>> flexibility in writing short lambdas. There are some motivating examples
>>> in the proposal. It's also getting pretty verbose to write correct
>>> generic functions with regards to SFINAE and noexcept, so this attempts
>>> to make it a little bit easier - at least in the easy case.
>>>
>>> Also I'm proposing a shorter syntax for forwarding arguments. I picked
>>> unary>> because it looks like moving something forward but really
>>> anything shorter would be nice. std::forward<Arg>(arg) is particularly
>>> verbose, especially in a generic lambda where you have to write
>>> std::forward<decltype(arg)>(arg), where the actual forwarding just
>>> dominates the code itself.
>>>
>>
>> IMHO, this new syntax makes the code more obscure. The proposed
>> abbreviated lambdas no longer have any resemblence with functions and blend
>> in the surrounding code too much (yes, this is a bad thing).
>>
>
> +1
>
> While I would like a more compact syntax for lambdas my eyes seem to be
> really adjusted to brackets so I would prefer such syntax:
>
> (x) => {i < 1000}
>
Hey; that sounds really close to something good. I would still require the
lambda inducer `[]` syntax, but this even permits us to declare what kind
of return type deduction it is:
[](...) => auto {expr};
[](...) => {expr}; //uses `decltype(auto)`.
--
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/beb60984-696c-4b28-a03d-0d10c866bcee%40isocpp.org.
------=_Part_4355_1061898774.1476304082011
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Wednesday, October 12, 2016 at 3:30:24 PM UTC-4=
, Domen Vrankar 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">2016-10-11 23:56 GMT+02:00 Andrey Semashev <span dir=3D"ltr"><<=
a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"eYuz1tlzA=
QAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';retu=
rn true;" onclick=3D"this.href=3D'javascript:';return true;">andrey=
.....@gmail.com</a>></span>:<br><div><div class=3D"gmail_quote"><blockquo=
te style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204)=
;padding-left:1ex" class=3D"gmail_quote"><span>On 10/11/16 20:32, Barry Rev=
zin wrote:<br>
<blockquote style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204=
,204,204);padding-left:1ex" class=3D"gmail_quote">
Here is a contrasting proposal for how to handle overload sets as<br>
function arguments. While a lot more verbose in the simple case of just<br>
naming a function (where instead of just naming the function you have to<br=
>
actually enumerate the arguments list twice), I think it offers more<br>
flexibility in writing short lambdas. There are some motivating examples<br=
>
in the proposal. It's also getting pretty verbose to write correct<br>
generic functions with regards to SFINAE and noexcept, so this attempts<br>
to make it a little bit easier - at least in the easy case.<br>
<br>
Also I'm proposing a shorter syntax for forwarding arguments. I picked<=
br>
unary>> because it looks like moving something forward but really<br>
anything shorter would be nice. std::forward<Arg>(arg) is particularl=
y<br>
verbose, especially in a generic lambda where you have to write<br>
std::forward<decltype(arg)>(<wbr>arg), where the actual forwarding ju=
st<br>
dominates the code itself.<br>
</blockquote>
<br></span>
IMHO, this new syntax makes the code more obscure. The proposed abbreviated=
lambdas no longer have any resemblence with functions and blend in the sur=
rounding code too much (yes, this is a bad thing).<span><br></span></blockq=
uote><div><br>+1<br><br></div><div>While I would like=C2=A0 a more compact =
syntax for lambdas my eyes seem to be really adjusted to brackets so I woul=
d prefer such syntax:<br><br></div><div>(x) =3D> {i < 1000}<br></div>=
</div></div></div></blockquote><div><br>Hey; that sounds really close to so=
mething good. I would still require the lambda inducer `[]` syntax, but thi=
s even permits us to declare what kind of return type deduction it is:<br><=
br>[](...) =3D> auto {expr};<br><br>[](...) =3D> {expr}; //uses `decl=
type(auto)`.<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/beb60984-696c-4b28-a03d-0d10c866bcee%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/beb60984-696c-4b28-a03d-0d10c866bcee=
%40isocpp.org</a>.<br />
------=_Part_4355_1061898774.1476304082011--
------=_Part_4354_1691808007.1476304082011--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Wed, 12 Oct 2016 13:29:59 -0700 (PDT)
Raw View
------=_Part_754_268040761.1476304199256
Content-Type: multipart/alternative;
boundary="----=_Part_755_599019806.1476304199256"
------=_Part_755_599019806.1476304199256
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Wednesday, October 12, 2016 at 3:36:23 PM UTC-4, Zhihao Yuan wrote:
>
> On Wed, Oct 12, 2016 at 2:29 PM, Domen Vrankar <domen....@gmail.com=20
> <javascript:>> wrote:=20
> >=20
> > (x) =3D> {i < 1000}=20
> >=20
> > So mandatory parentheses around parameters even if there is only a=20
> single=20
> > one and mandatory curly braces around function body even though it is a=
=20
> one=20
> > liner. Don't care too much about return statement, semicolon or [ ]=20
> > brackets in this case - in fact I even prefer them gone.=20
>
> Read [] as the introductory =CE=BB notation:=20
>
> [] x -> x < 1000=20
>
That imposes a parsing issue.
Whether we have this short lambda syntax or not, we will still need=20
`[]funcname` to be a lambda which calls a function overload set. So the=20
abbreviated lambda syntax should not interfere with that. Without the=20
parenthesis, it's difficult to tell whether `[]x` is supposed to be an=20
overload set or a lambda with one `auto&&` variable.
--=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/cff50466-113c-42db-9880-3cc0f9dd4b1b%40isocpp.or=
g.
------=_Part_755_599019806.1476304199256
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Wednesday, October 12, 2016 at 3:36:23 PM UTC-4=
, Zhihao Yuan wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Wed, Oc=
t 12, 2016 at 2:29 PM, Domen Vrankar <<a href=3D"javascript:" target=3D"=
_blank" gdf-obfuscated-mailto=3D"ianMSy10AQAJ" rel=3D"nofollow" onmousedown=
=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D=
'javascript:';return true;">domen....@gmail.com</a>> wrote:
<br>>
<br>> (x) =3D> {i < 1000}
<br>>
<br>> So mandatory parentheses around parameters even if there is only a=
single
<br>> one and mandatory curly braces around function body even though it=
is a one
<br>> liner. Don't care too much about return statement, =C2=A0semic=
olon or [ ]
<br>> brackets in this case - in fact I even prefer them gone.
<br>
<br>Read [] as the introductory =CE=BB notation:
<br>
<br>=C2=A0 [] x -> x < 1000
<br></blockquote><div><br>That imposes a parsing issue.<br><br>Whether we h=
ave this short lambda syntax or not, we will still need `[]funcname` to be =
a lambda which calls a function overload set. So the abbreviated lambda syn=
tax should not interfere with that. Without the parenthesis, it's diffi=
cult to tell whether `[]x` is supposed to be an overload set or a lambda wi=
th one `auto&&` variable.</div><br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/cff50466-113c-42db-9880-3cc0f9dd4b1b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/cff50466-113c-42db-9880-3cc0f9dd4b1b=
%40isocpp.org</a>.<br />
------=_Part_755_599019806.1476304199256--
------=_Part_754_268040761.1476304199256--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Thu, 13 Oct 2016 03:25:58 -0400
Raw View
<html><head></head><body lang=3D"en-US" style=3D"background-color: rgb(255,=
255, 255); line-height: initial;"> =
<div style=3D"width: 100%; fo=
nt-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif=
; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, =
255, 255);">Is [](funcname) about to be valid syntax?</div><div style=3D"wi=
dth: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-seri=
f, sans-serif; color: rgb(31, 73, 125); text-align: initial; background-col=
or: rgb(255, 255, 255);"><br></div><div style=3D"width: 100%; font-size: in=
itial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rg=
b(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);"=
>It would be odd to have a place where extraneous () around an identifier a=
re _not_ allowed. </div> =
=
<div style=3D"width: 100%; font-size: initial; font-family: Calibri,=
'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: =
initial; background-color: rgb(255, 255, 255);"><br style=3D"display:initia=
l"></div> =
=
<div style=3D"font-si=
ze: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; col=
or: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, =
255);">Sent from my BlackBerry portable Babbage&nb=
sp;Device</div> =
=
<table width=3D"100%" style=3D"b=
ackground-color:white;border-spacing:0px;"> <tbody><tr><td colspan=3D"2" st=
yle=3D"font-size: initial; text-align: initial; background-color: rgb(255, =
255, 255);"> <div style=3D"border-style: solid no=
ne none; border-top-color: rgb(181, 196, 223); border-top-width: 1pt; paddi=
ng: 3pt 0in 0in; font-family: Tahoma, 'BB Alpha Sans', 'Slate Pro'; font-si=
ze: 10pt;"> <div><b>From: </b>Nicol Bolas</div><div><b>Sent: </b>Wednesday=
, October 12, 2016 4:30 PM</div><div><b>To: </b>ISO C++ Standard - Future P=
roposals</div><div><b>Reply To: </b>std-proposals@isocpp.org</div><div><b>S=
ubject: </b>Re: [std-proposals] An abbreviated lambda syntax</div></div></t=
d></tr></tbody></table><div style=3D"border-style: solid none none; border-=
top-color: rgb(186, 188, 209); border-top-width: 1pt; font-size: initial; t=
ext-align: initial; background-color: rgb(255, 255, 255);"></div><br><div i=
d=3D"_originalContent" style=3D""><div dir=3D"ltr"><br><br>On Wednesday, Oc=
tober 12, 2016 at 3:36:23 PM UTC-4, Zhihao Yuan wrote:<blockquote class=3D"=
gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc so=
lid;padding-left: 1ex;">On Wed, Oct 12, 2016 at 2:29 PM, Domen Vrankar <=
<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"ianMSy10=
AQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';return true=
;" onclick=3D"this.href=3D'javascript:';return true;">domen....@gmail.com</=
a>> wrote:
<br>>
<br>> (x) =3D> {i < 1000}
<br>>
<br>> So mandatory parentheses around parameters even if there is only a=
single
<br>> one and mandatory curly braces around function body even though it=
is a one
<br>> liner. Don't care too much about return statement, semicolon=
or [ ]
<br>> brackets in this case - in fact I even prefer them gone.
<br>
<br>Read [] as the introductory =CE=BB notation:
<br>
<br> [] x -> x < 1000
<br></blockquote><div><br>That imposes a parsing issue.<br><br>Whether we h=
ave this short lambda syntax or not, we will still need `[]funcname` to be =
a lambda which calls a function overload set. So the abbreviated lambda syn=
tax should not interfere with that. Without the parenthesis, it's difficult=
to tell whether `[]x` is supposed to be an overload set or a lambda with o=
ne `auto&&` variable.</div><br></div>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" 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/cff50466-113c-42db-9880-3cc0f9dd4b1b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.goo=
gle.com/a/isocpp.org/d/msgid/std-proposals/cff50466-113c-42db-9880-3cc0f9dd=
4b1b%40isocpp.org</a>.<br>
<br><!--end of _originalContent --></div></body></html>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/20161013072558.4882513.95761.18366%40=
gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com=
/a/isocpp.org/d/msgid/std-proposals/20161013072558.4882513.95761.18366%40gm=
ail.com</a>.<br />
.
Author: szollosi.lorand@gmail.com
Date: Thu, 13 Oct 2016 00:42:23 -0700 (PDT)
Raw View
------=_Part_123_1343300771.1476344543853
Content-Type: multipart/alternative;
boundary="----=_Part_124_310556677.1476344543854"
------=_Part_124_310556677.1476344543854
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Hi,
Note that `x` and `(x)` already has very different meanings when it comes=
=20
to ADL, referenceness, to name a few.
Thanks,
-lorro
2016. okt=C3=B3ber 13., cs=C3=BCt=C3=B6rt=C3=B6k 9:26:06 UTC+2 id=C5=91pont=
ban Tony V E a k=C3=B6vetkez=C5=91t=20
=C3=ADrta:
>
> Is [](funcname) about to be valid syntax?
>
> It would be odd to have a place where extraneous () around an identifier=
=20
> are _not_ allowed.=20
>
> Sent from my BlackBerry portable Babbage Device
> *From: *Nicol Bolas
> *Sent: *Wednesday, October 12, 2016 4:30 PM
> *To: *ISO C++ Standard - Future Proposals
> *Reply To: *std-pr...@isocpp.org <javascript:>
> *Subject: *Re: [std-proposals] An abbreviated lambda syntax
>
>
>
> On Wednesday, October 12, 2016 at 3:36:23 PM UTC-4, Zhihao Yuan wrote:
>>
>> On Wed, Oct 12, 2016 at 2:29 PM, Domen Vrankar <domen....@gmail.com>=20
>> wrote:=20
>> >=20
>> > (x) =3D> {i < 1000}=20
>> >=20
>> > So mandatory parentheses around parameters even if there is only a=20
>> single=20
>> > one and mandatory curly braces around function body even though it is =
a=20
>> one=20
>> > liner. Don't care too much about return statement, semicolon or [ ]=
=20
>> > brackets in this case - in fact I even prefer them gone.=20
>>
>> Read [] as the introductory =CE=BB notation:=20
>>
>> [] x -> x < 1000=20
>>
>
> That imposes a parsing issue.
>
> Whether we have this short lambda syntax or not, we will still need=20
> `[]funcname` to be a lambda which calls a function overload set. So the=
=20
> abbreviated lambda syntax should not interfere with that. Without the=20
> parenthesis, it's difficult to tell whether `[]x` is supposed to be an=20
> overload set or a lambda with one `auto&&` variable.
>
> --=20
> You received this message because you are subscribed to the Google Groups=
=20
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an=
=20
> email to std-proposal...@isocpp.org <javascript:>.
> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
> To view this discussion on the web visit=20
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/cff50466-113=
c-42db-9880-3cc0f9dd4b1b%40isocpp.org=20
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/cff50466-11=
3c-42db-9880-3cc0f9dd4b1b%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>
>
--=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/4c5e7a77-e3fb-4c38-9eba-4db847dc2a7f%40isocpp.or=
g.
------=_Part_124_310556677.1476344543854
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi,<br><br>Note that `x` and `(x)` already has very differ=
ent meanings when it comes to ADL, referenceness, to name a few.<br><br>Tha=
nks,<br>-lorro<br><br>2016. okt=C3=B3ber 13., cs=C3=BCt=C3=B6rt=C3=B6k 9:26=
:06 UTC+2 id=C5=91pontban Tony V E a k=C3=B6vetkez=C5=91t =C3=ADrta:<blockq=
uote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-lef=
t: 1px #ccc solid;padding-left: 1ex;"><div style=3D"background-color:rgb(25=
5,255,255);line-height:initial" lang=3D"en-US"> =
<div style=3D"wid=
th:100%;font-size:initial;font-family:Calibri,'Slate Pro',sans-seri=
f,sans-serif;color:rgb(31,73,125);text-align:initial;background-color:rgb(2=
55,255,255)">Is [](funcname) about to be valid syntax?</div><div style=3D"w=
idth:100%;font-size:initial;font-family:Calibri,'Slate Pro',sans-se=
rif,sans-serif;color:rgb(31,73,125);text-align:initial;background-color:rgb=
(255,255,255)"><br></div><div style=3D"width:100%;font-size:initial;font-fa=
mily:Calibri,'Slate Pro',sans-serif,sans-serif;color:rgb(31,73,125)=
;text-align:initial;background-color:rgb(255,255,255)">It would be odd to h=
ave a place where extraneous () around an identifier are _not_ allowed. </d=
iv> =
<div style=3D"=
width:100%;font-size:initial;font-family:Calibri,'Slate Pro',sans-s=
erif,sans-serif;color:rgb(31,73,125);text-align:initial;background-color:rg=
b(255,255,255)"><br style=3D"display:initial"></div> =
=
=
<div style=3D"font-size:initial;font-family:Calibri,&=
#39;Slate Pro',sans-serif,sans-serif;color:rgb(31,73,125);text-align:in=
itial;background-color:rgb(255,255,255)">Sent=C2=A0from=C2=A0my=C2=A0BlackB=
erry=C2=A0<wbr>portable=C2=A0Babbage=C2=A0Device</div> =
=
=
<table style=3D"background-color:white;border-spacing:0px" width=3D"=
100%"> <tbody><tr><td colspan=3D"2" style=3D"font-size:initial;text-align:i=
nitial;background-color:rgb(255,255,255)"> <div s=
tyle=3D"border-style:solid none none;border-top-color:rgb(181,196,223);bord=
er-top-width:1pt;padding:3pt 0in 0in;font-family:Tahoma,'BB Alpha Sans&=
#39;,'Slate Pro';font-size:10pt"> <div><b>From: </b>Nicol Bolas</d=
iv><div><b>Sent: </b>Wednesday, October 12, 2016 4:30 PM</div><div><b>To: <=
/b>ISO C++ Standard - Future Proposals</div><div><b>Reply To: </b><a href=
=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"PHlAS-iaAQAJ" r=
el=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';return tru=
e;" onclick=3D"this.href=3D'javascript:';return true;">std-pr...@is=
ocpp.org</a></div><div><b>Subject: </b>Re: [std-proposals] An abbreviated l=
ambda syntax</div></div></td></tr></tbody></table><div style=3D"border-styl=
e:solid none none;border-top-color:rgb(186,188,209);border-top-width:1pt;fo=
nt-size:initial;text-align:initial;background-color:rgb(255,255,255)"></div=
><br><div><div dir=3D"ltr"><br><br>On Wednesday, October 12, 2016 at 3:36:2=
3 PM UTC-4, Zhihao Yuan wrote:<blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">On We=
d, Oct 12, 2016 at 2:29 PM, Domen Vrankar <<a rel=3D"nofollow">domen....=
@gmail.com</a>> wrote:
<br>>
<br>> (x) =3D> {i < 1000}
<br>>
<br>> So mandatory parentheses around parameters even if there is only a=
single
<br>> one and mandatory curly braces around function body even though it=
is a one
<br>> liner. Don't care too much about return statement, =C2=A0semic=
olon or [ ]
<br>> brackets in this case - in fact I even prefer them gone.
<br>
<br>Read [] as the introductory =CE=BB notation:
<br>
<br>=C2=A0 [] x -> x < 1000
<br></blockquote><div><br>That imposes a parsing issue.<br><br>Whether we h=
ave this short lambda syntax or not, we will still need `[]funcname` to be =
a lambda which calls a function overload set. So the abbreviated lambda syn=
tax should not interfere with that. Without the parenthesis, it's diffi=
cult to tell whether `[]x` is supposed to be an overload set or a lambda wi=
th one `auto&&` variable.</div><br></div>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
PHlAS-iaAQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:&=
#39;;return true;" onclick=3D"this.href=3D'javascript:';return true=
;">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"PHlAS-iaAQAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'=
;javascript:';return true;">std-pr...@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/cff50466-113c-42db-9880-3cc0f9dd4b1b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank" =
rel=3D"nofollow" onmousedown=3D"this.href=3D'https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/cff50466-113c-42db-9880-3cc0f9dd4b1b%40i=
socpp.org?utm_medium\x3demail\x26utm_source\x3dfooter';return true;" on=
click=3D"this.href=3D'https://groups.google.com/a/isocpp.org/d/msgid/st=
d-proposals/cff50466-113c-42db-9880-3cc0f9dd4b1b%40isocpp.org?utm_medium\x3=
demail\x26utm_source\x3dfooter';return true;">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/cff50466-113c-42db-<wbr>9880-=
3cc0f9dd4b1b%40isocpp.org</a><wbr>.<br>
<br></div></div>
</blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/4c5e7a77-e3fb-4c38-9eba-4db847dc2a7f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/4c5e7a77-e3fb-4c38-9eba-4db847dc2a7f=
%40isocpp.org</a>.<br />
------=_Part_124_310556677.1476344543854--
------=_Part_123_1343300771.1476344543853--
.
Author: Giovanni Piero Deretta <gpderetta@gmail.com>
Date: Thu, 13 Oct 2016 02:13:29 -0700 (PDT)
Raw View
------=_Part_186_162609674.1476350009232
Content-Type: multipart/alternative;
boundary="----=_Part_187_2067631484.1476350009232"
------=_Part_187_2067631484.1476350009232
Content-Type: text/plain; charset=UTF-8
On Wednesday, October 12, 2016 at 8:30:24 PM UTC+1, Domen Vrankar wrote:
>
> 2016-10-11 23:56 GMT+02:00 Andrey Semashev <andrey....@gmail.com
> <javascript:>>:
>
>> On 10/11/16 20:32, Barry Revzin wrote:
>>
>>> Here is a contrasting proposal for how to handle overload sets as
>>> function arguments. While a lot more verbose in the simple case of just
>>> naming a function (where instead of just naming the function you have to
>>> actually enumerate the arguments list twice), I think it offers more
>>> flexibility in writing short lambdas. There are some motivating examples
>>> in the proposal. It's also getting pretty verbose to write correct
>>> generic functions with regards to SFINAE and noexcept, so this attempts
>>> to make it a little bit easier - at least in the easy case.
>>>
>>> Also I'm proposing a shorter syntax for forwarding arguments. I picked
>>> unary>> because it looks like moving something forward but really
>>> anything shorter would be nice. std::forward<Arg>(arg) is particularly
>>> verbose, especially in a generic lambda where you have to write
>>> std::forward<decltype(arg)>(arg), where the actual forwarding just
>>> dominates the code itself.
>>>
>>
>> IMHO, this new syntax makes the code more obscure. The proposed
>> abbreviated lambdas no longer have any resemblence with functions and blend
>> in the surrounding code too much (yes, this is a bad thing).
>>
>
> +1
>
>
-1 . I think that the syntax as suggested by the OP is quote good.
<rant> Terser syntaxes keep getting rejected from C++ because it might be
initially confusing, but then we will be stuck for the next 20 years with
the verbose syntax (I can't be the only one that is tired of typing
template<typename> over and over), which is a greater impediment to
readability as the signal is lost in the noise. Many languages have
significantly terser syntax than C++ with no issues. </rant>
--
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/3a5ffefb-930d-42c0-bb6f-c0697e764d61%40isocpp.org.
------=_Part_187_2067631484.1476350009232
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wednesday, October 12, 2016 at 8:30:24 PM UTC+1, Domen =
Vrankar wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
>2016-10-11 23:56 GMT+02:00 Andrey Semashev <span dir=3D"ltr"><<a href=
=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"eYuz1tlzAQAJ" r=
el=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';return tru=
e;" onclick=3D"this.href=3D'javascript:';return true;">andrey....@g=
mail.com</a>></span>:<br><div><div class=3D"gmail_quote"><blockquote sty=
le=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddi=
ng-left:1ex" class=3D"gmail_quote"><span>On 10/11/16 20:32, Barry Revzin wr=
ote:<br>
<blockquote style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204=
,204,204);padding-left:1ex" class=3D"gmail_quote">
Here is a contrasting proposal for how to handle overload sets as<br>
function arguments. While a lot more verbose in the simple case of just<br>
naming a function (where instead of just naming the function you have to<br=
>
actually enumerate the arguments list twice), I think it offers more<br>
flexibility in writing short lambdas. There are some motivating examples<br=
>
in the proposal. It's also getting pretty verbose to write correct<br>
generic functions with regards to SFINAE and noexcept, so this attempts<br>
to make it a little bit easier - at least in the easy case.<br>
<br>
Also I'm proposing a shorter syntax for forwarding arguments. I picked<=
br>
unary>> because it looks like moving something forward but really<br>
anything shorter would be nice. std::forward<Arg>(arg) is particularl=
y<br>
verbose, especially in a generic lambda where you have to write<br>
std::forward<decltype(arg)>(<wbr>arg), where the actual forwarding ju=
st<br>
dominates the code itself.<br>
</blockquote>
<br></span>
IMHO, this new syntax makes the code more obscure. The proposed abbreviated=
lambdas no longer have any resemblence with functions and blend in the sur=
rounding code too much (yes, this is a bad thing).<span><br></span></blockq=
uote><div><br>+1<br><br></div></div></div></div></blockquote><div><br>-1 . =
I think that the syntax as suggested by the OP is quote good. <br><br><r=
ant> Terser syntaxes keep getting rejected from C++ because it might be =
initially confusing, but then we will be stuck for the next 20 years with t=
he verbose syntax (I can't be the only one that is tired of typing temp=
late<typename> over and over), which is a greater impediment to reada=
bility as the signal is lost in the noise. Many languages have significantl=
y terser syntax than C++ with no issues. </rant><br></div><br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/3a5ffefb-930d-42c0-bb6f-c0697e764d61%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/3a5ffefb-930d-42c0-bb6f-c0697e764d61=
%40isocpp.org</a>.<br />
------=_Part_187_2067631484.1476350009232--
------=_Part_186_162609674.1476350009232--
.
Author: Andrey Semashev <andrey.semashev@gmail.com>
Date: Thu, 13 Oct 2016 12:22:51 +0300
Raw View
On 10/13/16 12:13, Giovanni Piero Deretta wrote:
>
> <rant> Terser syntaxes keep getting rejected from C++ because it might
> be initially confusing, but then we will be stuck for the next 20 years
> with the verbose syntax (I can't be the only one that is tired of typing
> template<typename> over and over), which is a greater impediment to
> readability as the signal is lost in the noise. Many languages have
> significantly terser syntax than C++ with no issues. </rant>
As I wrote in my (cut away) reply, I'm all for shorter syntax but only
when it's descriptive. Replacing everything with random tokens doesn't
help descriptiveness although it requires less typing.
BTW, I have no problem with template<typename> at all. Just use a better
editor.
--
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/baebb942-7d31-3ba7-1358-1b310553dfc8%40gmail.com.
.
Author: Domen Vrankar <domen.vrankar@gmail.com>
Date: Thu, 13 Oct 2016 11:55:29 +0200
Raw View
--001a11421bae811438053ebc1ec8
Content-Type: text/plain; charset=UTF-8
2016-10-13 11:13 GMT+02:00 Giovanni Piero Deretta <gpderetta@gmail.com>:
On Wednesday, October 12, 2016 at 8:30:24 PM UTC+1, Domen Vrankar wrote:
>>
>> 2016-10-11 23:56 GMT+02:00 Andrey Semashev <andrey....@gmail.com>:
>>
>>> On 10/11/16 20:32, Barry Revzin wrote:
>>>
>>>> Here is a contrasting proposal for how to handle overload sets as
>>>> function arguments. While a lot more verbose in the simple case of just
>>>> naming a function (where instead of just naming the function you have to
>>>> actually enumerate the arguments list twice), I think it offers more
>>>> flexibility in writing short lambdas. There are some motivating examples
>>>> in the proposal. It's also getting pretty verbose to write correct
>>>> generic functions with regards to SFINAE and noexcept, so this attempts
>>>> to make it a little bit easier - at least in the easy case.
>>>>
>>>> Also I'm proposing a shorter syntax for forwarding arguments. I picked
>>>> unary>> because it looks like moving something forward but really
>>>> anything shorter would be nice. std::forward<Arg>(arg) is particularly
>>>> verbose, especially in a generic lambda where you have to write
>>>> std::forward<decltype(arg)>(arg), where the actual forwarding just
>>>> dominates the code itself.
>>>>
>>>
>>> IMHO, this new syntax makes the code more obscure. The proposed
>>> abbreviated lambdas no longer have any resemblence with functions and blend
>>> in the surrounding code too much (yes, this is a bad thing).
>>>
>>
>> +1
>>
>>
> -1 . I think that the syntax as suggested by the OP is quote good.
>
> <rant> Terser syntaxes keep getting rejected from C++ because it might be
> initially confusing, but then we will be stuck for the next 20 years with
> the verbose syntax (I can't be the only one that is tired of typing
> template<typename> over and over), which is a greater impediment to
> readability as the signal is lost in the noise. Many languages have
> significantly terser syntax than C++ with no issues. </rant>
>
I also have a problem with verbose lambda syntax when providing more than
one lambda function as a parameter but would still like to easily
distinguish a function mutation from other parts of the code. One of the
reasons why I dislike allot of other languages is exactly because they
quite often trade too much readability for less key strokes and
unfortunately I fix/extent/reuse old code authored by me or often other
people far more often than write new code... There is always a trade off
between terse syntax and readability and I doubt that 4 additional brackets
make a difference in the terse department - from where I stand the biggest
verbosity with my lambda functions comes from "auto" or explicit types in
parameter list and not from braces.
Regards,
Domen
--
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/CAKgx6BL3VgcVe2Q%3DGu_pYiyjzYwoDuEOrj9MGWjZ4c7wgBuP2g%40mail.gmail.com.
--001a11421bae811438053ebc1ec8
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">2016=
-10-13 11:13 GMT+02:00 Giovanni Piero Deretta <span dir=3D"ltr"><<a href=
=3D"mailto:gpderetta@gmail.com" target=3D"_blank">gpderetta@gmail.com</a>&g=
t;</span>:<br><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">On Wednes=
day, October 12, 2016 at 8:30:24 PM UTC+1, Domen Vrankar wrote:<span class=
=3D""><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">2016-10-11 2=
3:56 GMT+02:00 Andrey Semashev <span dir=3D"ltr"><<a rel=3D"nofollow">an=
drey....@gmail.com</a>></span>:<br><div><div class=3D"gmail_quote"><bloc=
kquote style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,=
204);padding-left:1ex" class=3D"gmail_quote"><span>On 10/11/16 20:32, Barry=
Revzin wrote:<br>
<blockquote style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204=
,204,204);padding-left:1ex" class=3D"gmail_quote">
Here is a contrasting proposal for how to handle overload sets as<br>
function arguments. While a lot more verbose in the simple case of just<br>
naming a function (where instead of just naming the function you have to<br=
>
actually enumerate the arguments list twice), I think it offers more<br>
flexibility in writing short lambdas. There are some motivating examples<br=
>
in the proposal. It's also getting pretty verbose to write correct<br>
generic functions with regards to SFINAE and noexcept, so this attempts<br>
to make it a little bit easier - at least in the easy case.<br>
<br>
Also I'm proposing a shorter syntax for forwarding arguments. I picked<=
br>
unary>> because it looks like moving something forward but really<br>
anything shorter would be nice. std::forward<Arg>(arg) is particularl=
y<br>
verbose, especially in a generic lambda where you have to write<br>
std::forward<decltype(arg)>(ar<wbr>g), where the actual forwarding ju=
st<br>
dominates the code itself.<br>
</blockquote>
<br></span>
IMHO, this new syntax makes the code more obscure. The proposed abbreviated=
lambdas no longer have any resemblence with functions and blend in the sur=
rounding code too much (yes, this is a bad thing).<span><br></span></blockq=
uote><div><br>+1<br><br></div></div></div></div></blockquote></span><div><b=
r>-1 . I think that the syntax as suggested by the OP is quote good. <br><b=
r><rant> Terser syntaxes keep getting rejected from C++ because it mi=
ght be initially confusing, but then we will be stuck for the next 20 years=
with the verbose syntax (I can't be the only one that is tired of typi=
ng template<typename> over and over), which is a greater impediment t=
o readability as the signal is lost in the noise. Many languages have signi=
ficantly terser syntax than C++ with no issues. </rant><br></div></di=
v></blockquote><div><br></div><div>I also have a problem with verbose lambd=
a syntax when providing more than one lambda function as a parameter but wo=
uld still like to easily distinguish a function mutation from other parts o=
f the code. One of the reasons why I dislike allot of other languages is ex=
actly because they quite often trade too much readability for less key stro=
kes and unfortunately I fix/extent/reuse old code authored by me or often o=
ther people far more often than write new code... There is always a trade o=
ff between terse syntax and readability and I doubt that 4 additional brack=
ets make a difference in the terse department - from where I stand the bigg=
est verbosity with my lambda functions comes from "auto" or expli=
cit types in parameter list and not from braces.<br><br></div><div>Regards,=
<br></div><div>Domen<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" 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/CAKgx6BL3VgcVe2Q%3DGu_pYiyjzYwoDuEOrj=
9MGWjZ4c7wgBuP2g%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKgx6BL3VgcVe2=
Q%3DGu_pYiyjzYwoDuEOrj9MGWjZ4c7wgBuP2g%40mail.gmail.com</a>.<br />
--001a11421bae811438053ebc1ec8--
.
Author: Victor Dyachenko <victor.dyachenko@gmail.com>
Date: Thu, 13 Oct 2016 03:14:18 -0700 (PDT)
Raw View
------=_Part_198_1765412670.1476353658534
Content-Type: multipart/alternative;
boundary="----=_Part_199_2098899142.1476353658534"
------=_Part_199_2098899142.1476353658534
Content-Type: text/plain; charset=UTF-8
There is more general issue in the modern C++:
inline void f()
{
...
}
is actually
inline void f() noexcept(false)
{
...
}
Why it is forbidden to compiler deduce noexcept-ness even for inline
functions? It is nonsense and confusing.
--
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/f5fe2995-856b-4bc6-91fa-c25cceaa426c%40isocpp.org.
------=_Part_199_2098899142.1476353658534
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">There is more general issue in the modern C++:<br><br><div=
class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); borde=
r-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-w=
rap: break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"=
><span style=3D"color: #008;" class=3D"styled-by-prettify">inline</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">void</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> f</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">()</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" class=3D"s=
tyled-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"st=
yled-by-prettify">...</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">}</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
</span></div></code></div><br>is actually<br><br><div class=3D"prettyprint"=
style=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187,=
187); border-style: solid; border-width: 1px; word-wrap: break-word;"><cod=
e class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color:=
#008;" class=3D"styled-by-prettify">inline</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">void</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> f</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">()</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> noexcept</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>(</span><span style=3D"color: #008;" class=3D"styled-by-prettify">false</s=
pan><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>=C2=A0 =C2=A0 </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">...</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">}</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"><br></span></div></code></div><br>Why it is forbid=
den to compiler deduce noexcept-ness even for inline functions? It is nonse=
nse and confusing.<br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/f5fe2995-856b-4bc6-91fa-c25cceaa426c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f5fe2995-856b-4bc6-91fa-c25cceaa426c=
%40isocpp.org</a>.<br />
------=_Part_199_2098899142.1476353658534--
------=_Part_198_1765412670.1476353658534--
.
Author: Domen Vrankar <domen.vrankar@gmail.com>
Date: Thu, 13 Oct 2016 12:15:29 +0200
Raw View
--001a113f267606dbf8053ebc66b6
Content-Type: text/plain; charset=UTF-8
2016-10-13 11:55 GMT+02:00 Domen Vrankar <domen.vrankar@gmail.com>:
> 2016-10-13 11:13 GMT+02:00 Giovanni Piero Deretta <gpderetta@gmail.com>:
>
> On Wednesday, October 12, 2016 at 8:30:24 PM UTC+1, Domen Vrankar wrote:
>>>
>>> 2016-10-11 23:56 GMT+02:00 Andrey Semashev <andrey....@gmail.com>:
>>>
>>>> On 10/11/16 20:32, Barry Revzin wrote:
>>>>
>>>>> Here is a contrasting proposal for how to handle overload sets as
>>>>> function arguments. While a lot more verbose in the simple case of just
>>>>> naming a function (where instead of just naming the function you have
>>>>> to
>>>>> actually enumerate the arguments list twice), I think it offers more
>>>>> flexibility in writing short lambdas. There are some motivating
>>>>> examples
>>>>> in the proposal. It's also getting pretty verbose to write correct
>>>>> generic functions with regards to SFINAE and noexcept, so this attempts
>>>>> to make it a little bit easier - at least in the easy case.
>>>>>
>>>>> Also I'm proposing a shorter syntax for forwarding arguments. I picked
>>>>> unary>> because it looks like moving something forward but really
>>>>> anything shorter would be nice. std::forward<Arg>(arg) is particularly
>>>>> verbose, especially in a generic lambda where you have to write
>>>>> std::forward<decltype(arg)>(arg), where the actual forwarding just
>>>>> dominates the code itself.
>>>>>
>>>>
>>>> IMHO, this new syntax makes the code more obscure. The proposed
>>>> abbreviated lambdas no longer have any resemblence with functions and blend
>>>> in the surrounding code too much (yes, this is a bad thing).
>>>>
>>>
>>> +1
>>>
>>>
>> -1 . I think that the syntax as suggested by the OP is quote good.
>>
>> <rant> Terser syntaxes keep getting rejected from C++ because it might be
>> initially confusing, but then we will be stuck for the next 20 years with
>> the verbose syntax (I can't be the only one that is tired of typing
>> template<typename> over and over), which is a greater impediment to
>> readability as the signal is lost in the noise. Many languages have
>> significantly terser syntax than C++ with no issues. </rant>
>>
>
> I also have a problem with verbose lambda syntax when providing more than
> one lambda function as a parameter but would still like to easily
> distinguish a function mutation from other parts of the code. One of the
> reasons why I dislike allot of other languages is exactly because they
> quite often trade too much readability for less key strokes and
> unfortunately I fix/extent/reuse old code authored by me or often other
> people far more often than write new code... There is always a trade off
> between terse syntax and readability and I doubt that 4 additional brackets
> make a difference in the terse department - from where I stand the biggest
> verbosity with my lambda functions comes from "auto" or explicit types in
> parameter list and not from braces.
>
Even with the long example from the proposal that is using noexcepti with
only one parameter with auto&& removing brackets would not make much
difference while on the other hand preseving brackets and removing the rest
makes a huge difference:
// OK: calls #1 *invoke*([](auto&& *x*)
noexcept(noexcept(test(std::forward<decltype(x)>(x))))
-> decltype(test(std::forward<decltype(x)>(x))) { return *test*(std::
*forward*<decltype(x)>(*x*)); });
invoke(x => test(forward(x)));
or
invoke([](x) => {test(forward(x))});
Is not that different and I see the later as a good compromise between the
two.
Terser syntax yes, removing everything so that it blurs with the
surrounding not so much.
Regards,
Domen
--
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/CAKgx6BJOQkjR_yaMBy8onJnsPFsv2Yb%2BB0vUwsN8fa3m6xjirg%40mail.gmail.com.
--001a113f267606dbf8053ebc66b6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">2016-10-13 11:55 GMT+02:00 Domen Vrankar <span dir=3D"ltr"=
><<a target=3D"_blank" href=3D"mailto:domen.vrankar@gmail.com">domen.vra=
nkar@gmail.com</a>></span>:<br><div class=3D"gmail_extra"><div class=3D"=
gmail_quote"><blockquote style=3D"margin:0px 0px 0px 0.8ex;border-left:1px =
solid rgb(204,204,204);padding-left:1ex" class=3D"gmail_quote"><div dir=3D"=
ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><span class=3D"g=
mail-">2016-10-13 11:13 GMT+02:00 Giovanni Piero Deretta <span dir=3D"ltr">=
<<a target=3D"_blank" href=3D"mailto:gpderetta@gmail.com">gpderetta@gmai=
l.com</a>></span>:<br><br><blockquote style=3D"margin:0px 0px 0px 0.8ex;=
border-left:1px solid rgb(204,204,204);padding-left:1ex" class=3D"gmail_quo=
te"><div dir=3D"ltr">On Wednesday, October 12, 2016 at 8:30:24 PM UTC+1, Do=
men Vrankar wrote:<span><blockquote style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left:1px solid rgb(204,204,204);padding-left:1ex" class=3D"gmail_quote"><=
div dir=3D"ltr">2016-10-11 23:56 GMT+02:00 Andrey Semashev <span dir=3D"ltr=
"><<a rel=3D"nofollow">andrey....@gmail.com</a>></span>:<br><div><div=
class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><s=
pan>On 10/11/16 20:32, Barry Revzin wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex">
Here is a contrasting proposal for how to handle overload sets as<br>
function arguments. While a lot more verbose in the simple case of just<br>
naming a function (where instead of just naming the function you have to<br=
>
actually enumerate the arguments list twice), I think it offers more<br>
flexibility in writing short lambdas. There are some motivating examples<br=
>
in the proposal. It's also getting pretty verbose to write correct<br>
generic functions with regards to SFINAE and noexcept, so this attempts<br>
to make it a little bit easier - at least in the easy case.<br>
<br>
Also I'm proposing a shorter syntax for forwarding arguments. I picked<=
br>
unary>> because it looks like moving something forward but really<br>
anything shorter would be nice. std::forward<Arg>(arg) is particularl=
y<br>
verbose, especially in a generic lambda where you have to write<br>
std::forward<decltype(arg)>(ar<wbr>g), where the actual forwarding ju=
st<br>
dominates the code itself.<br>
</blockquote>
<br></span>
IMHO, this new syntax makes the code more obscure. The proposed abbreviated=
lambdas no longer have any resemblence with functions and blend in the sur=
rounding code too much (yes, this is a bad thing).<span><br></span></blockq=
uote><div><br>+1<br><br></div></div></div></div></blockquote></span><div><b=
r>-1 . I think that the syntax as suggested by the OP is quote good. <br><b=
r><rant> Terser syntaxes keep getting rejected from C++ because it mi=
ght be initially confusing, but then we will be stuck for the next 20 years=
with the verbose syntax (I can't be the only one that is tired of typi=
ng template<typename> over and over), which is a greater impediment t=
o readability as the signal is lost in the noise. Many languages have signi=
ficantly terser syntax than C++ with no issues. </rant><br></div></di=
v></blockquote><div><br></div></span><div>I also have a problem with verbos=
e lambda syntax when providing more than one lambda function as a parameter=
but would still like to easily distinguish a function mutation from other =
parts of the code. One of the reasons why I dislike allot of other language=
s is exactly because they quite often trade too much readability for less k=
ey strokes and unfortunately I fix/extent/reuse old code authored by me or =
often other people far more often than write new code... There is always a =
trade off between terse syntax and readability and I doubt that 4 additiona=
l brackets make a difference in the terse department - from where I stand t=
he biggest verbosity with my lambda functions comes from "auto" o=
r explicit types in parameter list and not from braces.<br></div></div></di=
v></div></blockquote><div><br>Even with the long example from the proposal =
that is using noexcepti with only one parameter with auto&& removin=
g brackets would not make much difference while on the other hand preseving=
brackets and removing the rest makes a huge difference:<br><br><code>// OK=
: calls #1
<font color=3D"blue"><b>invoke</b></font>([](auto&& <font color=3D"=
blue"><b>x</b></font>) noexcept(noexcept(test(std::<wbr>forward<decltype=
(x)>(x))))
-> decltype(test(std::forward<<wbr>decltype(x)>(x)))
{
return <font color=3D"blue"><b>test</b></font>(std::<font color=3D"blue"><=
b>forward</b></font><decltype(x)><wbr>(<font color=3D"blue"><b>x</b><=
/font>));
});=C2=A0
<br><br></code></div><div><code>invoke(x =3D> test(forward(x)));<br></co=
de></div><div><code>or<br></code></div><div><code>invoke([](x) =3D> {tes=
t(forward(x))});<br></code></div><div><code><br></code></div><div><code>Is =
not that different and I see the later as a good compromise between the two=
..<br></code></div><div><code><br>Terser syntax yes, removing everything so =
that it blurs with the surrounding not so much.<br></code></div><div><code>=
<br></code></div><div><code>Regards,<br></code></div><div><code>Domen<br></=
code></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" 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/CAKgx6BJOQkjR_yaMBy8onJnsPFsv2Yb%2BB0=
vUwsN8fa3m6xjirg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKgx6BJOQkjR_y=
aMBy8onJnsPFsv2Yb%2BB0vUwsN8fa3m6xjirg%40mail.gmail.com</a>.<br />
--001a113f267606dbf8053ebc66b6--
.
Author: Andrey Semashev <andrey.semashev@gmail.com>
Date: Thu, 13 Oct 2016 13:37:06 +0300
Raw View
On 10/13/16 13:15, Domen Vrankar wrote:
> 2016-10-13 11:55 GMT+02:00 Domen Vrankar <domen.vrankar@gmail.com
> <mailto:domen.vrankar@gmail.com>>:
>
> Even with the long example from the proposal that is using noexcepti
> with only one parameter with auto&& removing brackets would not make
> much difference while on the other hand preseving brackets and removing
> the rest makes a huge difference:
>
> |// OK: calls #1 *invoke*([](auto&& *x*)
> noexcept(noexcept(test(std::forward<decltype(x)>(x)))) ->
> decltype(test(std::forward<decltype(x)>(x))) { return
> *test*(std::*forward*<decltype(x)>(*x*)); });
>
> |
> |invoke(x => test(forward(x)));
> |
> |or
> |
> |invoke([](x) => {test(forward(x))});
> |
> |
> |
> |Is not that different and I see the later as a good compromise between
> the two.
> |
> |
> Terser syntax yes, removing everything so that it blurs with the
> surrounding not so much.
I think the original problem should be decomposed into several smaller
ones, which can be dealt with separately.
For instance, I would be interested in a proposal that makes the
explicit template argument to std::forward unnecessary. Regardless
lambdas, this alone would be helpful in general.
Another step is to enable compilers deduce noexcept automatically when
possible (which lambdas surely qualify). Again, this would be a
generally useful addition.
Having done just those two you shorten your lambda by more than half:
invoke([](auto&& x) -> decltype(auto)
{ return test(std::forward(x)); });
Further improvements like making auto&& in the lambda argument list
optional are also possible, but more targeted to this particular
problem. They can be made evolutionary.
--
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/dbf7215b-b9fc-dcd2-f8ee-96f5439ed417%40gmail.com.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Thu, 13 Oct 2016 08:17:14 -0700 (PDT)
Raw View
------=_Part_434_498071099.1476371834632
Content-Type: multipart/alternative;
boundary="----=_Part_435_181968216.1476371834632"
------=_Part_435_181968216.1476371834632
Content-Type: text/plain; charset=UTF-8
On Thursday, October 13, 2016 at 3:26:06 AM UTC-4, Tony V E wrote:
>
> Is [](funcname) about to be valid syntax?
>
That all depends on the eventual wording from new versions of the feature.
But I would say that it shouldn't. It would create an ambiguity between an
overload set and a lambda with members. Even without terse lambda
declarations, users can accidentally use the wrong typename something.
That's a useful compile error to get.
--
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/f27402ea-eaa4-419c-9d2b-423ff2543c40%40isocpp.org.
------=_Part_435_181968216.1476371834632
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thursday, October 13, 2016 at 3:26:06 AM UTC-4, Tony V =
E wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"backgrou=
nd-color:rgb(255,255,255);line-height:initial" lang=3D"en-US"> =
<d=
iv style=3D"width:100%;font-size:initial;font-family:Calibri,'Slate Pro=
',sans-serif,sans-serif;color:rgb(31,73,125);text-align:initial;backgro=
und-color:rgb(255,255,255)">Is [](funcname) about to be valid syntax?</div>=
</div></blockquote><div><br>That all depends on the eventual wording from n=
ew versions of the feature. But I would say that it shouldn't. It would=
create an ambiguity between an overload set and a lambda with members. Eve=
n without terse lambda declarations, users can accidentally use the wrong t=
ypename something. That's a useful compile error to get.</div><br></div=
>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/f27402ea-eaa4-419c-9d2b-423ff2543c40%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f27402ea-eaa4-419c-9d2b-423ff2543c40=
%40isocpp.org</a>.<br />
------=_Part_435_181968216.1476371834632--
------=_Part_434_498071099.1476371834632--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Thu, 13 Oct 2016 09:16:11 -0700 (PDT)
Raw View
------=_Part_467_1227628225.1476375371427
Content-Type: multipart/alternative;
boundary="----=_Part_468_1721101189.1476375371427"
------=_Part_468_1721101189.1476375371427
Content-Type: text/plain; charset=UTF-8
On Thursday, October 13, 2016 at 6:37:10 AM UTC-4, Andrey Semashev wrote:
>
> On 10/13/16 13:15, Domen Vrankar wrote:
> > 2016-10-13 11:55 GMT+02:00 Domen Vrankar <domen....@gmail.com
> <javascript:>
> > <mailto:domen....@gmail.com <javascript:>>>:
> >
> > Even with the long example from the proposal that is using noexcepti
> > with only one parameter with auto&& removing brackets would not make
> > much difference while on the other hand preseving brackets and removing
> > the rest makes a huge difference:
> >
> > |// OK: calls #1 *invoke*([](auto&& *x*)
> > noexcept(noexcept(test(std::forward<decltype(x)>(x)))) ->
> > decltype(test(std::forward<decltype(x)>(x))) { return
> > *test*(std::*forward*<decltype(x)>(*x*)); });
> >
> > |
> > |invoke(x => test(forward(x)));
> > |
> > |or
> > |
> > |invoke([](x) => {test(forward(x))});
> > |
> > |
> > |
> > |Is not that different and I see the later as a good compromise between
> > the two.
> > |
> > |
> > Terser syntax yes, removing everything so that it blurs with the
> > surrounding not so much.
>
> I think the original problem should be decomposed into several smaller
> ones, which can be dealt with separately.
>
For instance, I would be interested in a proposal that makes the
> explicit template argument to std::forward unnecessary. Regardless
> lambdas, this alone would be helpful in general.
>
I don't think there is a way to do that. And even if there was, you still
have the noise of `std::forward` cluttering up the function.
The last 5-6 years of C++11 have taught us that, in template code, you're
going to be forwarding *a lot*. Given that common pattern, having explicit
syntax for doing so is not unreasonable. Granted, I don't like the OP's
particular operator suggestion, but I do believe that we need *something*.
Another step is to enable compilers deduce noexcept automatically when
> possible (which lambdas surely qualify). Again, this would be a
> generally useful addition.
>
I don't agree with this.
Noexcept deduction, if we allow it, *must be* something we ask for on
regular function declarations. Why? Because it becomes part of the
interface of an API. And yet, it's not actually part of the function's
interface. It's something that changes based on the implementation, since
it is deduced *from* the implementation.
Users can detect if an API of yours is noexcept. And if it is, then they
can write code that requires this. If it were automatically deduced, then
users would have to maintain it even if they didn't intend for the function
to be noexcept.
Lambdas are not used as the interface in an API, so allowing them to deduce
noexcept may be OK. But this is not something that should generally be
imposed on a function.
Having done just those two you shorten your lambda by more than half:
>
> invoke([](auto&& x) -> decltype(auto)
> { return test(std::forward(x)); });
>
The problem I have with decomposing the problem the way you do is this.
We have a problem with what should be short, trivial lambdas having a lot
of noise. That noise comes from a lot of places. However, unless you
eliminate *all of them*, the result, while smaller, will still be too noisy.
Your above code is certainly an improvement (even though the forward trick
can't work). But it's still *way* too big; the problem is still there.
Also, your code doesn't handle SFINAE, since you're using `decltype(auto)`
which doesn't do SFINAE on the return expression. That's very important.
The usefulenss of the `=>` syntax is that it solves about 60% of the
problem. It solves multiple problems all at once. You can only get such a
solution by focusing on the lambda problem itself. If you decompose the
problems, you'll get decomposed solutions with them. These may make the
syntax shorter, but they won't necessarily fix the problem.
I'm not against decomposition per-se. But any such decomposition needs to
remain focused on the specific problems.
1: Parameter declarations in lambdas. Having to specify a type rather than
getting `auto&&`.
2: Specifying return types and noexcept explicitly in order to properly
return an expression, with SFINAE intact.
3: Specifying std::forward<...> for the use of forwarding reference
parameters.
It seems to me that, in terms of code burden, #2 is the one that takes up
the most room, followed by #3. #1, while not unimportant, is not as
gigantic as the others.
Solving #2 is essentially about having a function whose entire body is
"return <expr>;". The `=> expr` syntax discussed in this thread seems like
a good fit here, especially since it could also be applied to regular
function declarations.
Solving #3... is very tricky without having to introduce a new
keyword/operator.
--
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/d959a5cd-0c22-461f-8acf-4a14dd9a1f30%40isocpp.org.
------=_Part_468_1721101189.1476375371427
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thursday, October 13, 2016 at 6:37:10 AM UTC-4, Andrey =
Semashev wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 10/13/16 13:=
15, Domen Vrankar wrote:
<br>> 2016-10-13 11:55 GMT+02:00 Domen Vrankar <<a href=3D"javascript=
:" target=3D"_blank" gdf-obfuscated-mailto=3D"1xmlMlWlAQAJ" rel=3D"nofollow=
" onmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D=
"this.href=3D'javascript:';return true;">domen....@gmail.com</a>
<br>> <mailto:<a href=3D"javascript:" target=3D"_blank" gdf-obfuscate=
d-mailto=3D"1xmlMlWlAQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'=
javascript:';return true;" onclick=3D"this.href=3D'javascript:'=
;return true;">domen....@gmail.<wbr>com</a>>>:
<br>>
<br>> Even with the long example from the proposal that is using noexcep=
ti
<br>> with only one parameter with auto&& removing brackets woul=
d not make
<br>> much difference while on the other hand preseving brackets and rem=
oving
<br>> the rest makes a huge difference:
<br>>
<br>> |// OK: calls #1 *invoke*([](auto&& *x*)
<br>> noexcept(noexcept(test(std::<wbr>forward<decltype(x)>(x)))) =
->
<br>> decltype(test(std::forward<<wbr>decltype(x)>(x))) { return
<br>> *test*(std::*forward*<<wbr>decltype(x)>(*x*)); });
<br>>
<br>> |
<br>> |invoke(x =3D> test(forward(x)));
<br>> |
<br>> |or
<br>> |
<br>> |invoke([](x) =3D> {test(forward(x))});
<br>> |
<br>> |
<br>> |
<br>> |Is not that different and I see the later as a good compromise be=
tween
<br>> the two.
<br>> |
<br>> |
<br>> Terser syntax yes, removing everything so that it blurs with the
<br>> surrounding not so much.
<br>
<br>I think the original problem should be decomposed into several smaller=
=20
<br>ones, which can be dealt with separately.=C2=A0</blockquote><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>=C2=A0</div></blockquot=
e><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;">
For instance, I would be interested in a proposal that makes the=20
<br>explicit template argument to std::forward unnecessary. Regardless=20
<br>lambdas, this alone would be helpful in general.<br></blockquote><div><=
br>I don't think there is a way to do that. And even if there was, you =
still have the noise of `std::forward` cluttering up the function.<br><br>T=
he last 5-6 years of C++11 have taught us that, in template code, you'r=
e going to be forwarding <i>a lot</i>. Given that common pattern, having ex=
plicit syntax for doing so is not unreasonable. Granted, I don't like t=
he OP's particular operator suggestion, but I do believe that we need <=
i>something</i>.<br><br></div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
Another step is to enable compilers deduce noexcept automatically when=20
<br>possible (which lambdas surely qualify). Again, this would be a=20
<br>generally useful addition.<br></blockquote><div><br>I don't agree w=
ith this.<br><br>Noexcept deduction, if we allow it, <i>must be</i> somethi=
ng we ask for on regular function declarations. Why? Because it becomes par=
t of the interface of an API. And yet, it's not actually part of the fu=
nction's interface. It's something that changes based on the implem=
entation, since it is deduced <i>from</i> the implementation.<br><br>Users =
can detect if an API of yours is noexcept. And if it is, then they can writ=
e code that requires this. If it were automatically deduced, then users wou=
ld have to maintain it even if they didn't intend for the function to b=
e noexcept.<br><br>Lambdas are not used as the interface in an API, so allo=
wing them to deduce noexcept may be OK. But this is not something that shou=
ld generally be imposed on a function.<br><br></div><blockquote class=3D"gm=
ail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc soli=
d;padding-left: 1ex;">
Having done just those two you shorten your lambda by more than half:
<br>
<br>=C2=A0 =C2=A0invoke([](auto&& x) -> decltype(auto)
<br>=C2=A0 =C2=A0 =C2=A0{ return test(std::forward(x)); });<br></blockquote=
><div><br>The problem I have with decomposing the problem the way you do is=
this.<br><br>We have a problem with what should be short, trivial lambdas =
having a lot of noise. That noise comes from a lot of places. However, unle=
ss you eliminate <i>all of them</i>, the result, while smaller, will still =
be too noisy.<br><br>Your above code is certainly an improvement (even thou=
gh the forward trick can't work). But it's still <i>way</i> too big=
; the problem is still there. Also, your code doesn't handle SFINAE, si=
nce you're using `decltype(auto)` which doesn't do SFINAE on the re=
turn expression. That's very important.<br><br>The usefulenss of the `=
=3D>` syntax is that it solves about 60% of the problem. It solves multi=
ple problems all at once. You can only get such a solution by focusing on t=
he lambda problem itself. If you decompose the problems, you'll get dec=
omposed solutions with them. These may make the syntax shorter, but they wo=
n't necessarily fix the problem.<br><br>I'm not against decompositi=
on per-se. But any such decomposition needs to remain focused on the specif=
ic problems.<br><br>1: Parameter declarations in lambdas. Having to specify=
a type rather than getting `auto&&`.<br><br>2: Specifying return t=
ypes and noexcept explicitly in order to properly return an expression, wit=
h SFINAE intact.<br><br>3: Specifying std::forward<...> for the use o=
f forwarding reference parameters.<br><br>It seems to me that, in terms of =
code burden, #2 is the one that takes up the most room, followed by #3. #1,=
while not unimportant, is not as gigantic as the others.<br></div><br>Solv=
ing #2 is essentially about having a function whose entire body is "re=
turn <expr>;". The `=3D> expr` syntax discussed in this threa=
d seems like a good fit here, especially since it could also be applied to =
regular function declarations.<br><br>Solving #3... is very tricky without =
having to introduce a new keyword/operator.<br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/d959a5cd-0c22-461f-8acf-4a14dd9a1f30%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d959a5cd-0c22-461f-8acf-4a14dd9a1f30=
%40isocpp.org</a>.<br />
------=_Part_468_1721101189.1476375371427--
------=_Part_467_1227628225.1476375371427--
.
Author: Andrey Semashev <andrey.semashev@gmail.com>
Date: Thu, 13 Oct 2016 20:45:14 +0300
Raw View
On 10/13/16 19:16, Nicol Bolas wrote:
> On Thursday, October 13, 2016 at 6:37:10 AM UTC-4, Andrey Semashev wrote:
>
> For instance, I would be interested in a proposal that makes the
> explicit template argument to std::forward unnecessary. Regardless
> lambdas, this alone would be helpful in general.
>
>
> I don't think there is a way to do that.
Not without some sort of compiler magic or a new language feature. But
I'm ok if magic is involved.
> And even if there was, you
> still have the noise of `std::forward` cluttering up the function.
And I like that it's there. It makes the intention more obvious, same as
when you use std::move or std::ref.
> Another step is to enable compilers deduce noexcept automatically when
> possible (which lambdas surely qualify). Again, this would be a
> generally useful addition.
>
>
> I don't agree with this.
>
> Noexcept deduction, if we allow it, /must be/ something we ask for on
> regular function declarations. Why? Because it becomes part of the
> interface of an API. And yet, it's not actually part of the function's
> interface. It's something that changes based on the implementation,
> since it is deduced /from/ the implementation.
>
> Users can detect if an API of yours is noexcept. And if it is, then they
> can write code that requires this. If it were automatically deduced,
> then users would have to maintain it even if they didn't intend for the
> function to be noexcept.
While I agree with the argument that noexcept is part of the interface,
it is too often I just want it to propagate throughout the code. Writing
generic functions and classes, it is indeed too tedious to spell the
correct noexcept condition and keep it in sync with the actual code as
it changes - so tedious that you either give up on noexcept or just
force it and say that otherwise is not supported by your
no-longer-generic code. If it has to be requested explicitly then it
should be something short and simple, like this:
void foo() noexcept(auto)
{
// ...
}
> Lambdas are not used as the interface in an API, so allowing them to
> deduce noexcept may be OK. But this is not something that should
> generally be imposed on a function.
Ok, so we make noexcept(auto) the implicit default for lambdas but not
other functions. I'm ok with that.
> Having done just those two you shorten your lambda by more than half:
>
> invoke([](auto&& x) -> decltype(auto)
> { return test(std::forward(x)); });
>
>
> The problem I have with decomposing the problem the way you do is this.
>
> We have a problem with what should be short, trivial lambdas having a
> lot of noise. That noise comes from a lot of places. However, unless you
> eliminate /all of them/, the result, while smaller, will still be too noisy.
>
> Your above code is certainly an improvement (even though the forward
> trick can't work). But it's still /way/ too big; the problem is still
> there. Also, your code doesn't handle SFINAE, since you're using
> `decltype(auto)` which doesn't do SFINAE on the return expression.
> That's very important.
I just suggested two decoupled changes that would significantly reduce
the noise and would otherwise be useful in other contexts. Note that the
lambda function is still very recognizable and no special syntax is
required. Further improvements are possible, but I'm sure they can also
be applied iteratively and also be useful elsewhere.
> The usefulenss of the `=>` syntax is that it solves about 60% of the
> problem. It solves multiple problems all at once. You can only get such
> a solution by focusing on the lambda problem itself. If you decompose
> the problems, you'll get decomposed solutions with them. These may make
> the syntax shorter, but they won't necessarily fix the problem.
But when you introduce the new syntax you only solving the problem for
lambdas (as I opined earlier, in a not good way) leaving other parts of
the language disconnected.
> I'm not against decomposition per-se. But any such decomposition needs
> to remain focused on the specific problems.
>
> 1: Parameter declarations in lambdas. Having to specify a type rather
> than getting `auto&&`.
>
> 2: Specifying return types and noexcept explicitly in order to properly
> return an expression, with SFINAE intact.
>
> 3: Specifying std::forward<...> for the use of forwarding reference
> parameters.
>
> It seems to me that, in terms of code burden, #2 is the one that takes
> up the most room, followed by #3. #1, while not unimportant, is not as
> gigantic as the others.
>
> Solving #2 is essentially about having a function whose entire body is
> "return <expr>;". The `=> expr` syntax discussed in this thread seems
> like a good fit here, especially since it could also be applied to
> regular function declarations.
I disagree. I mean, you are correct if all you want to do is optimize
the very specific case - a lambda with a single return statement. But my
point is that we should not be optimizing that one single case, when the
same problems exist in other cases as well. Noexcept specifications are
yet more verbose for functions that are more complex than a lazy return.
Callability forwarding (i.e. SFINAE-friendliness) is yet more difficult.
These problems need solving in general, and by induction in lambda
functions.
I don't mind if there are lambda-specific improvements along the road,
just don't invent yet another syntax for a function just for one
specific case. Keep the language consistent.
--
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/1311711e-67fc-32b8-ef50-af5d45ff5eae%40gmail.com.
.
Author: Victor Dyachenko <victor.dyachenko@gmail.com>
Date: Thu, 13 Oct 2016 11:06:53 -0700 (PDT)
Raw View
------=_Part_507_153204334.1476382014004
Content-Type: multipart/alternative;
boundary="----=_Part_508_1418650485.1476382014004"
------=_Part_508_1418650485.1476382014004
Content-Type: text/plain; charset=UTF-8
On Thursday, October 13, 2016 at 7:16:11 PM UTC+3, Nicol Bolas wrote:
>
> Noexcept deduction, if we allow it, *must be* something we ask for on
> regular function declarations. Why? Because it becomes part of the
> interface of an API. And yet, it's not actually part of the function's
> interface. It's something that changes based on the implementation, since
> it is deduced *from* the implementation.
>
> Users can detect if an API of yours is noexcept. And if it is, then they
> can write code that requires this. If it were automatically deduced, then
> users would have to maintain it even if they didn't intend for the function
> to be noexcept.
>
> Lambdas are not used as the interface in an API, so allowing them to
> deduce noexcept may be OK. But this is not something that should generally
> be imposed on a function.
>
How inline functions are different in this sense? How
template<class Func>
inline decltype(auto) wrapper(Func &&f) noexcept(noexcept(std::forward<Func
>(f)()))
{
std::forward<Func>(f)();
}
is "API-stable"? Why do wee need this crap with noexcept(noexcept(...)) in
such cases? Especially with inline move-operations, where noexceptness is
critical for performance and exception safety
--
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/8d41bf4b-f4a6-489a-8461-d325e167e714%40isocpp.org.
------=_Part_508_1418650485.1476382014004
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thursday, October 13, 2016 at 7:16:11 PM UTC+3, Nicol B=
olas 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">No=
except deduction, if we allow it, <i>must be</i> something we ask for on re=
gular function declarations. Why? Because it becomes part of the interface =
of an API. And yet, it's not actually part of the function's interf=
ace. It's something that changes based on the implementation, since it =
is deduced <i>from</i> the implementation.<br><div><br>Users can detect if =
an API of yours is noexcept. And if it is, then they can write code that re=
quires this. If it were automatically deduced, then users would have to mai=
ntain it even if they didn't intend for the function to be noexcept.<br=
><br>Lambdas are not used as the interface in an API, so allowing them to d=
educe noexcept may be OK. But this is not something that should generally b=
e imposed on a function.<br></div></div></blockquote><div>How inline functi=
ons are different in this sense? How <br><br><div class=3D"prettyprint" sty=
le=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187=
); border-style: solid; border-width: 1px; word-wrap: break-word;"><code cl=
ass=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">template</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify"><</span><span style=3D"color: #008;" clas=
s=3D"styled-by-prettify">class</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"styled-by=
-prettify">Func</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">></span><span style=3D"color: #000;" class=3D"styled-by-prettify"><=
br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">inline<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">decltype</span><span=
style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D=
"color: #008;" class=3D"styled-by-prettify">auto</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">)</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> wrapper</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">(</span><span style=3D"color: #606;" class=3D"st=
yled-by-prettify">Func</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">&&</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y">f</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> noexcept</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify">noexcept</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify">std</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">forward</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify"><</span><span style=3D"color: #606;" class=3D"style=
d-by-prettify">Func</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">>(</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy">f</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 st=
yle=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 std</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify">forward</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify"><</span><span style=3D=
"color: #606;" class=3D"styled-by-prettify">Func</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">>(</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify">f</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">)();</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">}</span></div></code></div><br>is "API-stable"? Why d=
o wee need this crap with noexcept(noexcept(...)) in such cases? Especially=
with inline move-operations, where noexceptness is critical for performanc=
e and exception safety<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/8d41bf4b-f4a6-489a-8461-d325e167e714%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/8d41bf4b-f4a6-489a-8461-d325e167e714=
%40isocpp.org</a>.<br />
------=_Part_508_1418650485.1476382014004--
------=_Part_507_153204334.1476382014004--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Thu, 13 Oct 2016 22:28:09 -0700 (PDT)
Raw View
------=_Part_89_52120452.1476422889840
Content-Type: multipart/alternative;
boundary="----=_Part_90_1671252048.1476422889840"
------=_Part_90_1671252048.1476422889840
Content-Type: text/plain; charset=UTF-8
On Thursday, October 13, 2016 at 2:06:54 PM UTC-4, Victor Dyachenko wrote:
>
> On Thursday, October 13, 2016 at 7:16:11 PM UTC+3, Nicol Bolas wrote:
>>
>> Noexcept deduction, if we allow it, *must be* something we ask for on
>> regular function declarations. Why? Because it becomes part of the
>> interface of an API. And yet, it's not actually part of the function's
>> interface. It's something that changes based on the implementation, since
>> it is deduced *from* the implementation.
>>
>> Users can detect if an API of yours is noexcept. And if it is, then they
>> can write code that requires this. If it were automatically deduced, then
>> users would have to maintain it even if they didn't intend for the function
>> to be noexcept.
>>
>> Lambdas are not used as the interface in an API, so allowing them to
>> deduce noexcept may be OK. But this is not something that should generally
>> be imposed on a function.
>>
> How inline functions are different in this sense? How
>
> template<class Func>
> inline decltype(auto) wrapper(Func &&f) noexcept(noexcept(std::forward<
> Func>(f)()))
> {
> std::forward<Func>(f)();
> }
>
> is "API-stable"?
>
It's perfectly stable. The function does exactly what it says it does, and
has the noexcept statement it says it has.
My problem is that changing the implementation changes the *interface*,
without that interface being apparent to anyone reading the code. I can
have an API function that is automatically `noexcept` simply because I
never called a non-`noexcept` function. But if I suddenly feel the need to
call a library function that isn't `noexcept`, my code stops being
`noexcept`. And I've broken my API.
An API that I *did not ask for*. Remember: I was talking about a suggestion
for *implicit* deduction of `noexcept`.
Though I'm not exactly a fan of explicit deduction of `noexcept` for
anything more complex than an expression...
--
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/e60112f0-4763-4c0b-8c50-953d5358b028%40isocpp.org.
------=_Part_90_1671252048.1476422889840
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thursday, October 13, 2016 at 2:06:54 PM UTC-4, Victor =
Dyachenko 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"lt=
r">On Thursday, October 13, 2016 at 7:16:11 PM UTC+3, Nicol Bolas wrote:<bl=
ockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Noexcept deduction, i=
f we allow it, <i>must be</i> something we ask for on regular function decl=
arations. Why? Because it becomes part of the interface of an API. And yet,=
it's not actually part of the function's interface. It's somet=
hing that changes based on the implementation, since it is deduced <i>from<=
/i> the implementation.<br><div><br>Users can detect if an API of yours is =
noexcept. And if it is, then they can write code that requires this. If it =
were automatically deduced, then users would have to maintain it even if th=
ey didn't intend for the function to be noexcept.<br><br>Lambdas are no=
t used as the interface in an API, so allowing them to deduce noexcept may =
be OK. But this is not something that should generally be imposed on a func=
tion.<br></div></div></blockquote><div>How inline functions are different i=
n this sense? How <br><br><div style=3D"background-color:rgb(250,250,250);b=
order-color:rgb(187,187,187);border-style:solid;border-width:1px;word-wrap:=
break-word"><code><div><span style=3D"color:#008">template</span><span styl=
e=3D"color:#660"><</span><span style=3D"color:#008">class</span><span st=
yle=3D"color:#000"> </span><span style=3D"color:#606">Func</span><span styl=
e=3D"color:#660">></span><span style=3D"color:#000"><br></span><span sty=
le=3D"color:#008">inline</span><span style=3D"color:#000"> </span><span sty=
le=3D"color:#008">decltype</span><span style=3D"color:#660">(</span><span s=
tyle=3D"color:#008">auto</span><span style=3D"color:#660">)</span><span sty=
le=3D"color:#000"> wrapper</span><span style=3D"color:#660">(</span><span s=
tyle=3D"color:#606">Func</span><span style=3D"color:#000"> </span><span sty=
le=3D"color:#660">&&</span><span style=3D"color:#000">f</span><span=
style=3D"color:#660">)</span><span style=3D"color:#000"> noexcept</span><s=
pan style=3D"color:#660">(</span><span style=3D"color:#000">noexcept</span>=
<span style=3D"color:#660">(</span><span style=3D"color:#000">std</span><sp=
an style=3D"color:#660">::</span><span style=3D"color:#000">forward</span><=
span style=3D"color:#660"><wbr><</span><span style=3D"color:#606">Func</=
span><span style=3D"color:#660">>(</span><span style=3D"color:#000">f</s=
pan><span style=3D"color:#660">)()))</span><span style=3D"color:#000"><br><=
/span><span style=3D"color:#660">{</span><span style=3D"color:#000"><br>=C2=
=A0 =C2=A0 std</span><span style=3D"color:#660">::</span><span style=3D"col=
or:#000">forward</span><span style=3D"color:#660"><</span><span style=3D=
"color:#606">Func</span><span style=3D"color:#660">>(</span><span style=
=3D"color:#000">f</span><span style=3D"color:#660">)();</span><span style=
=3D"color:#000"><br></span><span style=3D"color:#660">}</span></div></code>=
</div><br>is "API-stable"?</div></div></blockquote><div><br>It=
9;s perfectly stable. The function does exactly what it says it does, and h=
as the noexcept statement it says it has.<br><br>My problem is that changin=
g the implementation changes the <i>interface</i>, without that interface b=
eing apparent to anyone reading the code. I can have an API function that i=
s automatically `noexcept` simply because I never called a non-`noexcept` f=
unction. But if I suddenly feel the need to call a library function that is=
n't `noexcept`, my code stops being `noexcept`. And I've broken my =
API.<br><br>An API that I <i>did not ask for</i>. Remember: I was talking a=
bout a suggestion for <i>implicit</i> deduction of `noexcept`.<br><br>Thoug=
h I'm not exactly a fan of explicit deduction of `noexcept` for anythin=
g more complex than an expression...<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/e60112f0-4763-4c0b-8c50-953d5358b028%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e60112f0-4763-4c0b-8c50-953d5358b028=
%40isocpp.org</a>.<br />
------=_Part_90_1671252048.1476422889840--
------=_Part_89_52120452.1476422889840--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Thu, 13 Oct 2016 23:45:10 -0700 (PDT)
Raw View
------=_Part_657_1001314069.1476427511005
Content-Type: multipart/alternative;
boundary="----=_Part_658_2117772285.1476427511006"
------=_Part_658_2117772285.1476427511006
Content-Type: text/plain; charset=UTF-8
On Thursday, October 13, 2016 at 1:45:18 PM UTC-4, Andrey Semashev wrote:
>
> On 10/13/16 19:16, Nicol Bolas wrote:
> > On Thursday, October 13, 2016 at 6:37:10 AM UTC-4, Andrey Semashev
> wrote:
> >
> > For instance, I would be interested in a proposal that makes the
> > explicit template argument to std::forward unnecessary. Regardless
> > lambdas, this alone would be helpful in general.
> >
> >
> > I don't think there is a way to do that.
>
> Not without some sort of compiler magic or a new language feature. But
> I'm ok if magic is involved.
>
> > And even if there was, you
> > still have the noise of `std::forward` cluttering up the function.
>
> And I like that it's there. It makes the intention more obvious, same as
> when you use std::move or std::ref.
>
And this is part of my point: by breaking the problem down into such small,
disparate pieces, you have effectively designed yourself into a position
where you don't actually solve the original problem anymore.
We need to spell out `std::move` and `std::ref` because, in many cases,
it's not at all clear when you intend to do that operation. With
`std::forward`, there's always a good indicator that you want to use it.
Namely, the fact that you're using a forwarding reference. Most of the
time, when you use those, you should be using `std::forward` with them.
While it is true that sometimes you don't want to, there are times when you
are essentially guaranteed to want to forward. In those cases, it's *completely
obvious* to the reader what you're doing, such that having `std::forward`
there is pointless noise that detracts from the code you're trying to
write. `std::forward()` is 14 keystrokes that don't need to be there, in an
environment where every keystroke matters.
By focusing only on the general cases, you miss the details that make for a
good solution to the specific one.
> If it has to be requested explicitly then it
> should be something short and simple, like this:
>
> void foo() noexcept(auto)
> {
> // ...
> }
>
> > Lambdas are not used as the interface in an API, so allowing them to
> > deduce noexcept may be OK. But this is not something that should
> > generally be imposed on a function.
>
> Ok, so we make noexcept(auto) the implicit default for lambdas but not
> other functions. I'm ok with that.
>
Since that might potentially break existing code (my suggestion would only
apply to the new `=>` syntax, not to already-written lambdas), I can't say
I'm OK with that.
> The usefulenss of the `=>` syntax is that it solves about 60% of the
> > problem. It solves multiple problems all at once. You can only get such
> > a solution by focusing on the lambda problem itself. If you decompose
> > the problems, you'll get decomposed solutions with them. These may make
> > the syntax shorter, but they won't necessarily fix the problem.
>
> But when you introduce the new syntax you only solving the problem for
> lambdas (as I opined earlier, in a not good way) leaving other parts of
> the language disconnected.
>
There is no reason why `=>` syntax, along with its noexcept and return type
deduction syntax, could not be applied to named functions. This was
discussed earlier in the thread.
So if you have a single-expression function, you can express it like this:
template<typename ...Ts> auto something(Ts &&...ts) => {some_func(ts...)};
Sure, that's not like a huge thing. But it's hardly trivial. And it buys
you all of the features of the lambda version.
> I'm not against decomposition per-se. But any such decomposition needs
> > to remain focused on the specific problems.
> >
> > 1: Parameter declarations in lambdas. Having to specify a type rather
> > than getting `auto&&`.
> >
> > 2: Specifying return types and noexcept explicitly in order to properly
> > return an expression, with SFINAE intact.
> >
> > 3: Specifying std::forward<...> for the use of forwarding reference
> > parameters.
> >
> > It seems to me that, in terms of code burden, #2 is the one that takes
> > up the most room, followed by #3. #1, while not unimportant, is not as
> > gigantic as the others.
> >
> > Solving #2 is essentially about having a function whose entire body is
> > "return <expr>;". The `=> expr` syntax discussed in this thread seems
> > like a good fit here, especially since it could also be applied to
> > regular function declarations.
>
> I disagree. I mean, you are correct if all you want to do is optimize
> the very specific case - a lambda with a single return statement. But my
> point is that we should not be optimizing that one single case, when the
> same problems exist in other cases as well.
But they don't exist in other cases. Or rather, not in the same way.
The verbosity of reading a function declaration is certainly a real thing.
But lambdas are frequently written in-situ, in the middle of expressions.
The problem is more important there, and the shorter the lambda's body
conceptually could be, the lower the tolerance for noise. If all you're
doing is returning `a + 1`, every keystroke beyond that has to be
meaningful, a legitimate choice that you pick or don't pick based on need.
So while other cases may be verbose, in the case of the lambda, it is
especially pernicious.
> Noexcept specifications are
> yet more verbose for functions that are more complex than a lazy return.
> Callability forwarding (i.e. SFINAE-friendliness) is yet more difficult.
> These problems need solving in general, and by induction in lambda
> functions.
>
That leads to trickle-down terseness.
Consider what we discussed with automatic noexcept generation. It is
unworkable to suddenly change the unspecified noexcept declaration of
millions of lambda functions to be automatically deduced. Therefore, the
only way that lambdas could get in on that is to specify `noexcept(auto)`.
While this would be functional, it would hardly be called "terse". Same
goes for `std::forward`: you get a solution that removes some cruft, but
that's all.
And in that way, the user never quite gets the lambda terseness they want.
--
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/3d54d3df-1cac-4623-a28d-e2d16d25ef0e%40isocpp.org.
------=_Part_658_2117772285.1476427511006
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thursday, October 13, 2016 at 1:45:18 PM UTC-4, Andrey =
Semashev wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 10/13/16 19:=
16, Nicol Bolas wrote:
<br>> On Thursday, October 13, 2016 at 6:37:10 AM UTC-4, Andrey Semashev=
wrote:
<br>>
<br>> =C2=A0 =C2=A0 For instance, I would be interested in a proposal th=
at makes the
<br>> =C2=A0 =C2=A0 explicit template argument to std::forward unnecessa=
ry. Regardless
<br>> =C2=A0 =C2=A0 lambdas, this alone would be helpful in general.
<br>>
<br>>
<br>> I don't think there is a way to do that.
<br>
<br>Not without some sort of compiler magic or a new language feature. But=
=20
<br>I'm ok if magic is involved.
<br>
<br>> And even if there was, you
<br>> still have the noise of `std::forward` cluttering up the function.
<br>
<br>And I like that it's there. It makes the intention more obvious, sa=
me as=20
<br>when you use std::move or std::ref.<br></blockquote><div><br>And this i=
s part of my point: by breaking the problem down into such small, disparate=
pieces, you have effectively designed yourself into a position where you d=
on't actually solve the original problem anymore.<br><br>We need to spe=
ll out `std::move` and `std::ref` because, in many cases, it's not at a=
ll clear when you intend to do that operation. With `std::forward`, there&#=
39;s always a good indicator that you want to use it. Namely, the fact that=
you're using a forwarding reference. Most of the time, when you use th=
ose, you should be using `std::forward` with them.<br><br>While it is true =
that sometimes you don't want to, there are times when you are essentia=
lly guaranteed to want to forward. In those cases, it's <i>completely o=
bvious</i> to the reader what you're doing, such that having `std::forw=
ard` there is pointless noise that detracts from the code you're trying=
to write. `std::forward()` is 14 keystrokes that don't need to be ther=
e, in an environment where every keystroke matters.<br><br>By focusing only=
on the general cases, you miss the details that make for a good solution t=
o the specific one.<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;">If it has to be requested explicitly then it=20
<br>should be something short and simple, like this:
<br>
<br>=C2=A0 =C2=A0void foo() noexcept(auto)
<br>=C2=A0 =C2=A0{
<br>=C2=A0 =C2=A0 =C2=A0// ...
<br>=C2=A0 =C2=A0}
<br>
<br>> Lambdas are not used as the interface in an API, so allowing them =
to
<br>> deduce noexcept may be OK. But this is not something that should
<br>> generally be imposed on a function.
<br>
<br>Ok, so we make noexcept(auto) the implicit default for lambdas but not=
=20
<br>other functions. I'm ok with that.<br></blockquote><div><br>Since t=
hat might potentially break existing code (my suggestion would only apply t=
o the new `=3D>` syntax, not to already-written lambdas), I can't sa=
y I'm OK with that.<br><br></div><div></div><blockquote class=3D"gmail_=
quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pa=
dding-left: 1ex;">> The usefulenss of the `=3D>` syntax is that it so=
lves about 60% of the
<br>> problem. It solves multiple problems all at once. You can only get=
such
<br>> a solution by focusing on the lambda problem itself. If you decomp=
ose
<br>> the problems, you'll get decomposed solutions with them. These=
may make
<br>> the syntax shorter, but they won't necessarily fix the problem=
..
<br>
<br>But when you introduce the new syntax you only solving the problem for=
=20
<br>lambdas (as I opined earlier, in a not good way) leaving other parts of=
=20
<br>the language disconnected.<br></blockquote><div><br>There is no reason =
why `=3D>` syntax, along with its noexcept and return type deduction syn=
tax, could not be applied to named functions. This was discussed earlier in=
the thread.<br><br>So if you have a single-expression function, you can ex=
press it like this:<br><br><div style=3D"background-color: rgb(250, 250, 25=
0); border-color: rgb(187, 187, 187); border-style: solid; border-width: 1p=
x; overflow-wrap: break-word;" class=3D"prettyprint"><code class=3D"prettyp=
rint"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"s=
tyled-by-prettify">template</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify"><</span><span style=3D"color: #008;" class=3D"styled-by=
-prettify">typename</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
....</span><span style=3D"color: #606;" class=3D"styled-by-prettify">Ts</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">></span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> something</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #606=
;" class=3D"styled-by-prettify">Ts</span><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"st=
yled-by-prettify">ts</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D><=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">some_func</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify">ts</span><span style=3D"color: #660;"=
class=3D"styled-by-prettify">...)};</span></div></code></div><br>Sure, tha=
t's not like a huge thing. But it's hardly trivial. And it buys you=
all of the features of the lambda version.<br><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;">
> I'm not against decomposition per-se. But any such decomposition n=
eeds
<br>> to remain focused on the specific problems.
<br>>
<br>> 1: Parameter declarations in lambdas. Having to specify a type rat=
her
<br>> than getting `auto&&`.
<br>>
<br>> 2: Specifying return types and noexcept explicitly in order to pro=
perly
<br>> return an expression, with SFINAE intact.
<br>>
<br>> 3: Specifying std::forward<...> for the use of forwarding re=
ference
<br>> parameters.
<br>>
<br>> It seems to me that, in terms of code burden, #2 is the one that t=
akes
<br>> up the most room, followed by #3. #1, while not unimportant, is no=
t as
<br>> gigantic as the others.
<br>>
<br>> Solving #2 is essentially about having a function whose entire bod=
y is
<br>> "return <expr>;". The `=3D> expr` syntax discus=
sed in this thread seems
<br>> like a good fit here, especially since it could also be applied to
<br>> regular function declarations.
<br>
<br>I disagree. I mean, you are correct if all you want to do is optimize=
=20
<br>the very specific case - a lambda with a single return statement. But m=
y=20
<br>point is that we should not be optimizing that one single case, when th=
e=20
<br>same problems exist in other cases as well.</blockquote><div><br>But th=
ey don't exist in other cases. Or rather, not in the same way.<br><br>T=
he verbosity of reading a function declaration is certainly a real thing. B=
ut lambdas are frequently written in-situ, in the middle of expressions. Th=
e problem is more important there, and the shorter the lambda's body co=
nceptually could be, the lower the tolerance for noise. If all you're d=
oing is returning `a + 1`, every keystroke beyond that has to be meaningful=
, a legitimate choice that you pick or don't pick based on need.<br><br=
>So while other cases may be verbose, in the case of the lambda, it is espe=
cially pernicious.<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;">Noexcept specifications are=20
<br>yet more verbose for functions that are more complex than a lazy return=
..=20
<br>Callability forwarding (i.e. SFINAE-friendliness) is yet more difficult=
..=20
<br>These problems need solving in general, and by induction in lambda=20
<br>functions.<br></blockquote><div><br>That leads to trickle-down tersenes=
s.<br><br>Consider what we discussed with automatic noexcept generation. It=
is unworkable to suddenly change the unspecified noexcept declaration of m=
illions of lambda functions to be automatically deduced. Therefore, the onl=
y way that lambdas could get in on that is to specify `noexcept(auto)`. Whi=
le this would be functional, it would hardly be called "terse". S=
ame goes for `std::forward`: you get a solution that removes some cruft, bu=
t that's all.<br><br>And in that way, the user never quite gets the lam=
bda terseness they want.<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/3d54d3df-1cac-4623-a28d-e2d16d25ef0e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/3d54d3df-1cac-4623-a28d-e2d16d25ef0e=
%40isocpp.org</a>.<br />
------=_Part_658_2117772285.1476427511006--
------=_Part_657_1001314069.1476427511005--
.
Author: Victor Dyachenko <victor.dyachenko@gmail.com>
Date: Thu, 13 Oct 2016 23:47:59 -0700 (PDT)
Raw View
------=_Part_737_1621733307.1476427679439
Content-Type: multipart/alternative;
boundary="----=_Part_738_1162198477.1476427679439"
------=_Part_738_1162198477.1476427679439
Content-Type: text/plain; charset=UTF-8
Sadly, noexcept and constexpr quickly become an annoying noise in the
language, just like restrict in C99. Not every function is part of "API"!
In 90%+ of cases I prefer transparent noexcept-ness without explicit
stating this.
What is the problem with noexcept-transparency for inline functions? The
whole idea of inline functions is that replacing the expression with inline
function doesn't impact generated code - you finally get the same result.
It's zero-cost abstractions which C++ is famous for.
--
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/71e33c56-90d1-41c1-98f5-d569a6df32f7%40isocpp.org.
------=_Part_738_1162198477.1476427679439
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Sadly, <span style=3D"font-family: courier new,monospace;"=
>noexcept</span> and <span style=3D"font-family: courier new,monospace;">co=
nstexpr</span> quickly become an annoying noise in the language, just like =
<span style=3D"font-family: courier new,monospace;">restrict</span> in C99.=
Not every function is part of "API"! In 90%+ of cases I prefer t=
ransparent noexcept-ness without explicit stating this.<br><br>What is the =
problem with noexcept-transparency for inline functions? The whole idea of =
inline functions is that replacing the expression with inline function does=
n't impact generated code - you finally get the same result. It's z=
ero-cost abstractions which C++ is famous for.<br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/71e33c56-90d1-41c1-98f5-d569a6df32f7%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/71e33c56-90d1-41c1-98f5-d569a6df32f7=
%40isocpp.org</a>.<br />
------=_Part_738_1162198477.1476427679439--
------=_Part_737_1621733307.1476427679439--
.
Author: Andrey Semashev <andrey.semashev@gmail.com>
Date: Fri, 14 Oct 2016 13:15:45 +0300
Raw View
On 10/14/16 09:45, Nicol Bolas wrote:
> On Thursday, October 13, 2016 at 1:45:18 PM UTC-4, Andrey Semashev wrote:
>
> > And even if there was, you
> > still have the noise of `std::forward` cluttering up the function.
>
> And I like that it's there. It makes the intention more obvious,
> same as
> when you use std::move or std::ref.
>
> And this is part of my point: by breaking the problem down into such
> small, disparate pieces, you have effectively designed yourself into a
> position where you don't actually solve the original problem anymore.
>
> We need to spell out `std::move` and `std::ref` because, in many cases,
> it's not at all clear when you intend to do that operation. With
> `std::forward`, there's always a good indicator that you want to use it.
> Namely, the fact that you're using a forwarding reference. Most of the
> time, when you use those, you should be using `std::forward` with them.
>
> While it is true that sometimes you don't want to, there are times when
> you are essentially guaranteed to want to forward. In those cases, it's
> /completely obvious/ to the reader what you're doing, such that having
> `std::forward` there is pointless noise that detracts from the code
> you're trying to write. `std::forward()` is 14 keystrokes that don't
> need to be there, in an environment where every keystroke matters.
I wouldn't say my typical code base is swarmed with forwarding
functions. I'd say, situations when you obviously do want to
std::forward are equally frequent to those when you don't. At least, I
can't say I write or read code with one preference significantly more
often than the other. So I would rather have std::forward spelled out
explicitly every single time when it's intended rather than having to
guess. Of course, it all depends on the kind of code we write, so our
experiences differ.
Consider also that the function call syntax currently is self-sufficient
in a way that you know which arguments you are discarding (i.e. moving
or forwarding) and which you do not. With the new syntax this is no
longer the case since it changes the way function arguments are
interpreted (i.e. implicit forward). I know you're saying that's the
whole point of the change, but think how it will play in functions more
complex than an immediate forward to another function. I don't think
that would improve readability.
> > I'm not against decomposition per-se. But any such decomposition
> needs
> > to remain focused on the specific problems.
> >
> > 1: Parameter declarations in lambdas. Having to specify a type rather
> > than getting `auto&&`.
> >
> > 2: Specifying return types and noexcept explicitly in order to
> properly
> > return an expression, with SFINAE intact.
> >
> > 3: Specifying std::forward<...> for the use of forwarding reference
> > parameters.
> >
> > It seems to me that, in terms of code burden, #2 is the one that
> takes
> > up the most room, followed by #3. #1, while not unimportant, is
> not as
> > gigantic as the others.
> >
> > Solving #2 is essentially about having a function whose entire
> body is
> > "return <expr>;". The `=> expr` syntax discussed in this thread seems
> > like a good fit here, especially since it could also be applied to
> > regular function declarations.
>
> I disagree. I mean, you are correct if all you want to do is optimize
> the very specific case - a lambda with a single return statement.
> But my
> point is that we should not be optimizing that one single case, when
> the
> same problems exist in other cases as well.
>
>
> But they don't exist in other cases. Or rather, not in the same way.
>
> The verbosity of reading a function declaration is certainly a real
> thing. But lambdas are frequently written in-situ, in the middle of
> expressions. The problem is more important there, and the shorter the
> lambda's body conceptually could be, the lower the tolerance for noise.
> If all you're doing is returning `a + 1`, every keystroke beyond that
> has to be meaningful, a legitimate choice that you pick or don't pick
> based on need.
>
> So while other cases may be verbose, in the case of the lambda, it is
> especially pernicious.
>
>
> Noexcept specifications are
> yet more verbose for functions that are more complex than a lazy
> return.
> Callability forwarding (i.e. SFINAE-friendliness) is yet more
> difficult.
> These problems need solving in general, and by induction in lambda
> functions.
>
>
> That leads to trickle-down terseness.
>
> Consider what we discussed with automatic noexcept generation. It is
> unworkable to suddenly change the unspecified noexcept declaration of
> millions of lambda functions to be automatically deduced. Therefore, the
> only way that lambdas could get in on that is to specify
> `noexcept(auto)`. While this would be functional, it would hardly be
> called "terse". Same goes for `std::forward`: you get a solution that
> removes some cruft, but that's all.
>
> And in that way, the user never quite gets the lambda terseness they want.
Well, let's just say I don't want to trade terseness at the expense of
readability or expressiveness of the code.
--
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/d07400c0-ca17-0a52-807d-ef2ade686ad4%40gmail.com.
.
Author: Barry Revzin <barry.revzin@gmail.com>
Date: Fri, 14 Oct 2016 06:59:39 -0700 (PDT)
Raw View
------=_Part_1273_356441538.1476453579308
Content-Type: multipart/alternative;
boundary="----=_Part_1274_515262586.1476453579309"
------=_Part_1274_515262586.1476453579309
Content-Type: text/plain; charset=UTF-8
>
>
> Consider also that the function call syntax currently is self-sufficient
> in a way that you know which arguments you are discarding (i.e. moving
> or forwarding) and which you do not. With the new syntax this is no
> longer the case since it changes the way function arguments are
> interpreted (i.e. implicit forward).
>
I'll post an updated proposal later, but just want to chime here - there is
no implicit forwarding here. The function arguments are interpreted the
same way, I just want to allow for omission of the parameter types, the
trailing decltype, and the return keyword:
// none of these do any forwarding
[](auto&& x) -> decltype(twice(x)) { return twice(x); }
[](auto&& x) => twice(x);
[](x) => twice(x);
// all of these do forwarding
[](auto&& x) -> decltype(twice(std::forward<decltype(x)>(x))) { return twice
(std::forward<decltype(x)>(x)); }
[](auto&& x) => twice(std::forward<decltype(x)>(x));
[](x) => twice(std::forward<decltype(x)>(x));
[](x) => twice(>>x);
You still have to mark the argument as being forwarded.
--
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/e5826e0c-4cb8-441d-aa55-21bb1e6aecab%40isocpp.org.
------=_Part_1274_515262586.1476453579309
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br>Consider =
also that the function call syntax currently is self-sufficient=20
<br>in a way that you know which arguments you are discarding (i.e. moving=
=20
<br>or forwarding) and which you do not. With the new syntax this is no=20
<br>longer the case since it changes the way function arguments are=20
<br>interpreted (i.e. implicit forward).=C2=A0<br></blockquote><div><br></d=
iv><div>I'll post an updated proposal later, but just want to chime her=
e - there is no implicit forwarding here. The function arguments are interp=
reted the same way, I just want to allow for omission of the parameter type=
s, the trailing decltype, and the return keyword:</div><div><br></div><div>=
<div class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); b=
order-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; wo=
rd-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subprettypr=
int"><span style=3D"color: #800;" class=3D"styled-by-prettify">// none of t=
hese do any forwarding</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">[](</span><span style=3D"color: #008;" class=3D"styled-by-prettify">a=
uto</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&&a=
mp;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> x</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">-></span><span style=3D"color:=
#000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" c=
lass=3D"styled-by-prettify">decltype</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify">twice</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y">x</span><span style=3D"color: #660;" class=3D"styled-by-prettify">))</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #0=
08;" class=3D"styled-by-prettify">return</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify"> twice</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify">x</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">);</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">[](</span><span style=3D=
"color: #008;" class=3D"styled-by-prettify">auto</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;"=
class=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">=3D></span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> twice</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">x</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span><fon=
t color=3D"#880000"><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"><br></span><span style=3D"color: #660;" class=3D"styled-by-prettify">[](=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify">x</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">=3D></span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> twice</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;" class=3D"style=
d-by-prettify">);</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"><br><br></span><span style=3D"color: #800;" class=3D"styled-by-prett=
ify">// all of these do forwarding</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span></font><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">[](</span><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">auto</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">&&</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> x</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">-></span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">decltype</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify">twice</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">std</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify">forward</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify"><</span><span style=3D"color: #008;" class=3D"styled-by-prettify">=
decltype</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify">x</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">)>(</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify">x</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">)))</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-pr=
ettify">return</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> twice</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">std</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify">forward</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify"><</span><span style=3D"c=
olor: #008;" class=3D"styled-by-prettify">decltype</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">(</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">x</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">));</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">[](</span><span styl=
e=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">&&</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> x</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">)</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">=3D></span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> twice</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">(</span><font color=3D"#000000"><span style=3D"color: #000;" class=
=3D"styled-by-prettify">std</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify">forward</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify"><</span><span style=3D"color: #008;" class=3D"styled-by-prettify">=
decltype</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify">x</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">)>(</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify">x</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">)</span></font><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">);</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">[](</span><span style=3D"color: #000;" class=3D"s=
tyled-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"=
> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D><=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> twice</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><font c=
olor=3D"#000000"><span style=3D"color: #000;" class=3D"styled-by-prettify">=
std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify">forward</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify"><</span><span s=
tyle=3D"color: #008;" class=3D"styled-by-prettify">decltype</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify">x</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">)>(</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify">x</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">)</span></font><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">);</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">[](</span><span style=3D"color: #000;" class=3D"styled-by-prettify">x</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">=3D></span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> twice</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;" cla=
ss=3D"styled-by-prettify">);</span></div></code></div><div><br></div>You st=
ill have to mark the argument as being forwarded.<br>=C2=A0</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/e5826e0c-4cb8-441d-aa55-21bb1e6aecab%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e5826e0c-4cb8-441d-aa55-21bb1e6aecab=
%40isocpp.org</a>.<br />
------=_Part_1274_515262586.1476453579309--
------=_Part_1273_356441538.1476453579308--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Fri, 14 Oct 2016 07:53:45 -0700 (PDT)
Raw View
------=_Part_1002_1390261349.1476456825611
Content-Type: multipart/alternative;
boundary="----=_Part_1003_140424073.1476456825612"
------=_Part_1003_140424073.1476456825612
Content-Type: text/plain; charset=UTF-8
On Friday, October 14, 2016 at 9:59:39 AM UTC-4, Barry Revzin wrote:
>
>
>> Consider also that the function call syntax currently is self-sufficient
>> in a way that you know which arguments you are discarding (i.e. moving
>> or forwarding) and which you do not. With the new syntax this is no
>> longer the case since it changes the way function arguments are
>> interpreted (i.e. implicit forward).
>>
>
> I'll post an updated proposal later, but just want to chime here - there
> is no implicit forwarding here. The function arguments are interpreted the
> same way, I just want to allow for omission of the parameter types, the
> trailing decltype, and the return keyword:
>
> // none of these do any forwarding
> [](auto&& x) -> decltype(twice(x)) { return twice(x); }
> [](auto&& x) => twice(x);
> [](x) => twice(x);
>
> // all of these do forwarding
> [](auto&& x) -> decltype(twice(std::forward<decltype(x)>(x))) { return
> twice(std::forward<decltype(x)>(x)); }
> [](auto&& x) => twice(std::forward<decltype(x)>(x));
> [](x) => twice(std::forward<decltype(x)>(x));
> [](x) => twice(>>x);
>
> You still have to mark the argument as being forwarded.
>
>
Fair enough, but I still hate using `>>` for that ;)
Granted, I don't have a better alternative at the moment...
--
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/28f5a88b-6e0c-4ffa-a7f2-33a406ed703b%40isocpp.org.
------=_Part_1003_140424073.1476456825612
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Friday, October 14, 2016 at 9:59:39 AM UTC-4, Barry Rev=
zin 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"><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><br>Consider also that the function ca=
ll syntax currently is self-sufficient=20
<br>in a way that you know which arguments you are discarding (i.e. moving=
=20
<br>or forwarding) and which you do not. With the new syntax this is no=20
<br>longer the case since it changes the way function arguments are=20
<br>interpreted (i.e. implicit forward).=C2=A0<br></blockquote><div><br></d=
iv><div>I'll post an updated proposal later, but just want to chime her=
e - there is no implicit forwarding here. The function arguments are interp=
reted the same way, I just want to allow for omission of the parameter type=
s, the trailing decltype, and the return keyword:</div><div><br></div><div>=
<div style=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,18=
7);border-style:solid;border-width:1px;word-wrap:break-word"><code><div><sp=
an style=3D"color:#800">// none of these do any forwarding</span><span styl=
e=3D"color:#000"><br></span><span style=3D"color:#660">[](</span><span styl=
e=3D"color:#008">auto</span><span style=3D"color:#660">&&</span><sp=
an style=3D"color:#000"> x</span><span style=3D"color:#660">)</span><span s=
tyle=3D"color:#000"> </span><span style=3D"color:#660">-></span><span st=
yle=3D"color:#000"> </span><span style=3D"color:#008">decltype</span><span =
style=3D"color:#660">(</span><span style=3D"color:#000">twice</span><span s=
tyle=3D"color:#660">(</span><span style=3D"color:#000">x</span><span style=
=3D"color:#660">))</span><span style=3D"color:#000"> </span><span style=3D"=
color:#660">{</span><span style=3D"color:#000"> </span><span style=3D"color=
:#008">return</span><span style=3D"color:#000"> twice</span><span style=3D"=
color:#660">(</span><span style=3D"color:#000">x</span><span style=3D"color=
:#660">);</span><span style=3D"color:#000"> </span><span style=3D"color:#66=
0">}</span><span style=3D"color:#000"><br></span><span style=3D"color:#660"=
>[](</span><span style=3D"color:#008">auto</span><span style=3D"color:#660"=
>&&</span><span style=3D"color:#000"> x</span><span style=3D"color:=
#660">)</span><span style=3D"color:#000"> </span><span style=3D"color:#660"=
>=3D></span><span style=3D"color:#000"> twice</span><span style=3D"color=
:#660">(</span><span style=3D"color:#000">x</span><span style=3D"color:#660=
">);</span><font color=3D"#880000"><span style=3D"color:#000"><br></span><s=
pan style=3D"color:#660">[](</span><span style=3D"color:#000">x</span><span=
style=3D"color:#660">)</span><span style=3D"color:#000"> </span><span styl=
e=3D"color:#660">=3D></span><span style=3D"color:#000"> twice</span><spa=
n style=3D"color:#660">(</span><span style=3D"color:#000">x</span><span sty=
le=3D"color:#660">);</span><span style=3D"color:#000"><br><br></span><span =
style=3D"color:#800">// all of these do forwarding</span><span style=3D"col=
or:#000"><br></span></font><span style=3D"color:#660">[](</span><span style=
=3D"color:#008">auto</span><span style=3D"color:#660">&&</span><spa=
n style=3D"color:#000"> x</span><span style=3D"color:#660">)</span><span st=
yle=3D"color:#000"> </span><span style=3D"color:#660">-></span><span sty=
le=3D"color:#000"> </span><span style=3D"color:#008">decltype</span><span s=
tyle=3D"color:#660">(</span><span style=3D"color:#000">twice</span><span st=
yle=3D"color:#660">(</span><span style=3D"color:#000">std</span><span style=
=3D"color:#660">::</span><span style=3D"color:#000">forward</span><span sty=
le=3D"color:#660"><</span><span style=3D"color:#008">de<wbr>cltype</span=
><span style=3D"color:#660">(</span><span style=3D"color:#000">x</span><spa=
n style=3D"color:#660">)>(</span><span style=3D"color:#000">x</span><spa=
n style=3D"color:#660">)))</span><span style=3D"color:#000"> </span><span s=
tyle=3D"color:#660">{</span><span style=3D"color:#000"> </span><span style=
=3D"color:#008">return</span><span style=3D"color:#000"> twice</span><span =
style=3D"color:#660">(</span><span style=3D"color:#000">std</span><span sty=
le=3D"color:#660">::</span><span style=3D"color:#000">forward</span><span s=
tyle=3D"color:#660"><</span><span style=3D"color:#008">decltype</span><s=
pan style=3D"color:#660">(</span><span style=3D"color:#000">x</span><span s=
tyle=3D"color:#660">)<wbr>>(</span><span style=3D"color:#000">x</span><s=
pan style=3D"color:#660">));</span><span style=3D"color:#000"> </span><span=
style=3D"color:#660">}</span><span style=3D"color:#000"><br></span><span s=
tyle=3D"color:#660">[](</span><span style=3D"color:#008">auto</span><span s=
tyle=3D"color:#660">&&</span><span style=3D"color:#000"> x</span><s=
pan style=3D"color:#660">)</span><span style=3D"color:#000"> </span><span s=
tyle=3D"color:#660">=3D></span><span style=3D"color:#000"> twice</span><=
span style=3D"color:#660">(</span><font color=3D"#000000"><span style=3D"co=
lor:#000">std</span><span style=3D"color:#660">::</span><span style=3D"colo=
r:#000">forward</span><span style=3D"color:#660"><</span><span style=3D"=
color:#008">decltype</span><span style=3D"color:#660">(</span><span style=
=3D"color:#000">x</span><span style=3D"color:#660">)<wbr>>(</span><span =
style=3D"color:#000">x</span><span style=3D"color:#660">)</span></font><spa=
n style=3D"color:#660">);</span><span style=3D"color:#000"><br></span><span=
style=3D"color:#660">[](</span><span style=3D"color:#000">x</span><span st=
yle=3D"color:#660">)</span><span style=3D"color:#000"> </span><span style=
=3D"color:#660">=3D></span><span style=3D"color:#000"> twice</span><span=
style=3D"color:#660">(</span><font color=3D"#000000"><span style=3D"color:=
#000">std</span><span style=3D"color:#660">::</span><span style=3D"color:#0=
00">forward</span><span style=3D"color:#660"><</span><span style=3D"colo=
r:#008">decltype</span><span style=3D"color:#660">(</span><span style=3D"co=
lor:#000">x</span><span style=3D"color:#660">)<wbr>>(</span><span style=
=3D"color:#000">x</span><span style=3D"color:#660">)</span></font><span sty=
le=3D"color:#660">);</span><span style=3D"color:#000"><br></span><span styl=
e=3D"color:#660">[](</span><span style=3D"color:#000">x</span><span style=
=3D"color:#660">)</span><span style=3D"color:#000"> </span><span style=3D"c=
olor:#660">=3D></span><span style=3D"color:#000"> twice</span><span styl=
e=3D"color:#660">(>></span><span style=3D"color:#000">x</span><span s=
tyle=3D"color:#660">);</span></div></code></div><div><br></div>You still ha=
ve to mark the argument as being forwarded.<br>=C2=A0</div></div></blockquo=
te><div><br>Fair enough, but I still hate using `>>` for that ;)<br><=
br>Granted, I don't have a better alternative at the moment...<br></div=
></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/28f5a88b-6e0c-4ffa-a7f2-33a406ed703b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/28f5a88b-6e0c-4ffa-a7f2-33a406ed703b=
%40isocpp.org</a>.<br />
------=_Part_1003_140424073.1476456825612--
------=_Part_1002_1390261349.1476456825611--
.
Author: Barry Revzin <barry.revzin@gmail.com>
Date: Fri, 14 Oct 2016 18:33:02 -0700 (PDT)
Raw View
------=_Part_1349_1997677589.1476495182352
Content-Type: multipart/alternative;
boundary="----=_Part_1350_1313457140.1476495182352"
------=_Part_1350_1313457140.1476495182352
Content-Type: text/plain; charset=UTF-8
On Tuesday, October 11, 2016 at 12:32:57 PM UTC-5, Barry Revzin wrote:
>
> Here is a contrasting proposal for how to handle overload sets as function
> arguments. While a lot more verbose in the simple case of just naming a
> function (where instead of just naming the function you have to actually
> enumerate the arguments list twice), I think it offers more flexibility in
> writing short lambdas. There are some motivating examples in the proposal.
> It's also getting pretty verbose to write correct generic functions with
> regards to SFINAE and noexcept, so this attempts to make it a little bit
> easier - at least in the easy case.
>
> Also I'm proposing a shorter syntax for forwarding arguments. I picked
> unary>> because it looks like moving something forward but really anything
> shorter would be nice. std::forward<Arg>(arg) is particularly verbose,
> especially in a generic lambda where you have to write
> std::forward<decltype(arg)>(arg), where the actual forwarding just
> dominates the code itself.
>
>
Here's an updated draft. I've dropped the version of the syntax that allows
for the omission of [] and (). At best, that saved four characters for
single-argument no-capture lambdas, which is a small amount of the overall
character savings, and seems hardly worth the added complexity in parsing.
I actually defined >>expr (which had not been the case before) and extend
the proposal to apply the same idea for function templates.
--
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/6341edd7-7e49-43e2-af64-3ac04d3a6696%40isocpp.org.
------=_Part_1350_1313457140.1476495182352
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Tuesday, October 11, 2016 at 12:32:57 PM UTC-5,=
Barry Revzin wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr">Here is a contrasting proposal for how to handle overload sets as =
function arguments. While a lot more verbose in the simple case of just nam=
ing a function (where instead of just naming the function you have to actua=
lly enumerate the arguments list twice), I think it offers more flexibility=
in writing short lambdas. There are some motivating examples in the propos=
al. It's also getting pretty verbose to write correct generic functions=
with regards to SFINAE and noexcept, so this attempts to make it a little =
bit easier - at least in the easy case.=C2=A0<div><div><br></div><div>Also =
I'm proposing a shorter syntax for forwarding arguments. I picked unary=
>> because it looks like moving something forward but really anything=
shorter would be nice. <font face=3D"courier new, monospace">std::forward&=
lt;Arg>(arg)</font> is particularly verbose, especially in a generic lam=
bda where you have to write <font face=3D"courier new, monospace">std::forw=
ard<decltype(arg)>(<wbr>arg)</font><font face=3D"arial, sans-serif">,=
where the actual forwarding just dominates the code itself.=C2=A0</font></=
div><div><br></div></div></div></blockquote><div><br></div><div>Here's =
an updated draft. I've dropped the version of the syntax that allows fo=
r the omission of [] and (). At best, that saved four characters for single=
-argument no-capture lambdas, which is a small amount of the overall charac=
ter savings, and seems hardly worth the added complexity in parsing. I actu=
ally defined >>expr (which had not been the case before) and extend t=
he proposal to apply the same idea for function templates.=C2=A0</div></div=
>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/6341edd7-7e49-43e2-af64-3ac04d3a6696%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/6341edd7-7e49-43e2-af64-3ac04d3a6696=
%40isocpp.org</a>.<br />
------=_Part_1350_1313457140.1476495182352--
------=_Part_1349_1997677589.1476495182352
Content-Type: text/html; charset=US-ASCII; name=abbrev_lambda.html
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename=abbrev_lambda.html
X-Attachment-Id: b2dcc052-8afc-4c75-bdfc-807b719e69e9
Content-ID: <b2dcc052-8afc-4c75-bdfc-807b719e69e9>
<html>
<head>
<title>abbreviated lambdas</title>
<style>
p {text-align:justify}
li {text-align:justify}
blockquote.note
{
background-color:#E0E0E0;
padding-left: 15px;
padding-right: 15px;
padding-top: 1px;
padding-bottom: 1px;
}
ins {color:#00A000}
del {color:#A00000}
code {white-space:pre;}
</style>
</head>
<body>
<address align=right>
Document number: DxxxxR0<br>
<br/>
<a href="mailto:barry.revzin@gmail.com">Barry Revzin</a><br/>
2016-10-10<br/>
</address>
<hr/>
<h1 align=center>Abbreviated Lambdas for fun and profit</h1>
<h2>Contents</h2>
<ul>
<li><a href="#Motivation">Motivation</a></li>
<li><a href="#Proposal">Proposal</a></li>
<li><a href="#Examples">Examples</a></li>
<li><a href="#Funcs">Abbreviated Function Syntax</a></li>
<li><a href="#Effects">Effects on Existing Code</a></li>
<li><a href="#Priors">Prior Work</a></li>
<li><a href="#Acks">Acknowledgements and References</a></li>
</ul>
<a name="Motivation"></a><h2>Motivation</h2>
<p>There are two, somewhat related motivations for an abbreviated lambda syntax. The first is to address the problem of trying to pass in overload sets as function arguments [1]:
<blockquote><pre>
template <class T>
T twice(T x) { return x + x; }
template <class I>
void f(I first, I last) {
transform(first, last, twice); // error
}
</pre></blockquote>
C++14 generic lambdas allow us a way to solve this problem by just wrapping the overloaded name in a lambda:
<blockquote><pre>
transform(first, last, [](auto&& x) {
return twice(std::forward<decltype(x)>(x));
});
</pre></blockquote>
<p>But that isn't actually correct, although it's the "obvious" code that most people would produce. It's not SFINAE-friendly and it's not <code>noexcept</code>-correct. Which could lead to avoidable errors:
<blockquote><pre>
struct Widget;
bool test(int );
bool test(Widget );
void invoke(std::function<bool(int)> ); // #1
void invoke(std::function<bool(std::string)> ); // #2
// error: unresolved overloaded function type
invoke(test);
// still error: no known conversion from std::string to int or Widget
invoke([](auto&& x) {
return test(std::forward<decltype(x)>(x));
});
</pre></blockquote>
You'd really have to write:
<blockquote><code>// OK: calls #1
<font color="blue"><b>invoke</b></font>([](auto&& <font color="blue"><b>x</b></font>) noexcept(noexcept(test(std::forward<decltype(x)>(x))))
-> decltype(test(std::forward<decltype(x)>(x)))
{
return <font color="blue"><b>test</b></font>(std::<font color="blue"><b>forward</b></font><decltype(x)>(<font color="blue"><b>x</b></font>));
});
</code></blockquote>
<p>And that's a lot to have to type. Which brings me to the second motivation: not having to write that. For simple lambdas, those lambdas whose entire body is <code>return expr;</code>, the noisy stuff you have to write to get it correct where you need to use it just drowns out the signal of what it was you wanted your lambda to do in the first place. That is assuming that I succeed in writing the same code in all three places without accidentally introducing subtle differences.
<p>Arguably the only important code in the above block is that which has been marked in <font color="blue"><b>blue</b></font>. All I want to do is <code>test(x)</code>, why so much boilerplate?
<a name="Proposal"></a><h2>Proposal</h2>
<p>This paper proposes the creation of a new lambda introducer, <code>=></code>, which allows for a single expression in the body that will be its return. This will synthesize a SFINAE-friendly, <code>noexcept</code>-correct lambda by doing the code triplication for you.
<p>At its simplest:
<blockquote><pre>
[](auto&& x) => test(x)
</pre></blockquote>
shall be exactly equivalent to the lambda:
<blockquote><pre>
[](auto&& x) noexcept(noexcept(test(x))) -> decltype(test(x)) {
return test(x);
}
</pre></blockquote>
But since <code>auto&&</code> has become such a regular choice of argument for lambdas, that too can become optional. An omitted type would be assumed as <code>auto&&</code>. That is:
<blockquote><pre>
[](x) => test(x) // equivalent to the above
</pre></blockquote>
<p>One of the last sources of boilerplate is <code>std::forward</code>. In a lot of generic code, the uses of <code>forward</code> overwhelm all the rest of the code, to the point where many talks and examples just omit references entirely to save space. I'm occasionally tempted to introduce a macro (<code>#define FWD(x) decltype(x)(x)</code>) which is just wrong. Unlike <code>std::move</code> and <code>std::ref</code>, which are used to do non-typical things and deserve to be visible markers for code readability, <code>std::forward</code> is very typically used in the context of using forwarding references. It does not have as clear a need to be a signpost.
<p>This paper would like to see a shorter way to forward arguments and proposes non-overloadable unary <code>operator >></code>, where <code>>>expr</code> shall be equivalent to <code>static_cast<decltype(expr)&&>(expr)</code>.
<p>Putting it all together we get:
<blockquote><pre>
// old way
transform(first, last, [](auto&& x) noexcept(noexcept(test(std::forward<decltype(x)>(x))))
-> decltype(test(std::forward<decltype(x)>(x)))
{
return test(std::forward<decltype(x)>(x));
});
// proposed new way
transform(first, last, [](x) => twice(>>x));
</pre></blockquote>
Abbreviated lambdas will not allow for default arguments.
<a name="Examples"></a><h2>Examples</h2>
<p>Other examples of improved usage as compared to C++14 best practices.
<p>Sorting in decreasing order: roughly comparable typing, but arguably clearer:
<blockquote><pre>
std::sort(begin(v), end(v), std::greater<>{}); // C++14
std::sort(begin(v), end(v), [](x,y) => x > y); // this proposal
</pre></blockquote>
<p>Sorting in decreasing order by ID
<blockquote><pre>
std::sort(begin(v), end(v), [](auto&& x, auto&& y) { return x.id > y.id; }); // C++14
std::sort(begin(v), end(v), std::greater<>{}, &Object::id); // ranges with projections
std::sort(begin(v), end(v), [](x,y) => x.id > y.id); // this proposal
</pre></blockquote>
<p>Calling an overload where SFINAE matters and getting it wrong is a mess:
<blockquote><pre>
bool invoke(std::function<bool(int)> f); // #1
bool invoke(std::function<bool(std::string)> f); // #2
invoke([](auto x) { return x == 2; }); // error! (283 lines of diagnostic on gcc)
invoke([](auto x) -> decltype(x == 2) { return x == 2; }); // OK C++14: calls #1
invoke([](x) => x == 2); // OK this proposal: calls #1
</pre></blockquote>
<p>Binding an overloaded member function that takes arbitrarily many arguments to an instance, even without <code>noexcept</code>-correctness:
<blockquote><pre>
// C++14
[&obj](auto&&... args) -> decltype(obj.func(std::forward<decltype(args)>(args)...) {
return obj.func(std::forward<decltype(args)>(args));
};
// this proposal
[&obj](... args) => obj.func(>>args...)
</pre></blockquote>
<p>Chaining lots of functions together from range-v3: summing the squares under 1000:
<blockquote><pre>
// C++14
int sum = accumulate(ints(1)
| transform([](int i){ return i*i; })
| take_while([](int i){ return i < 1000; }));
// this proposal
int sum = accumulate(ints(1) | transform([](i) => i*i) | take_while([](i) => i < 1000));
</pre></blockquote>
<a name="Funcs"></a><h2>Abbreviated Function Syntax</h2>
While this paper is motivated primarily by abbreviating lambdas - whose brevity directly affects readability - the same concepts can apply to function templates as well. Consider the implementation of <code>std::begin</code>:
<blockquote><pre>
template <typename C>
constexpr auto begin(C& cont)
-> decltype(cont.begin())
{
return cont.begin();
}
</pre></blockquote>
This is the same idea - we're duplicating the body to get SFINAE-correctness. This could just as easily become:
<blockquote><pre>
template <typename C>
constexpr auto begin(C& cont) => cont.begin();
</pre></blockquote>
This becomes far more dramatic for examples like the overloads of <code>std::not_fn</code>, which has four overloads of <code>operator()</code> that all look like this:
<blockquote><pre>
template <class... Args>
auto operator()(Args&&... args)
noexcept(noexcept(!std::invoke(f, std::forward<Args>(args)...)))
-> decltype(!std::invoke(f, std::forward<Args>(args)...)) {
return !std::invoke(f, std::forward<Args>(args)...);
}
</pre></blockquote>
In order to get SFINAE- and <code>noexcept</code>-correctness, we need to triple the body, which makes the whole function basically illegible at best and error-prone at worst. With the abbreviated syntax, this function can be implemented correctly as:
<blockquote><pre>
template <class... Args>
auto operator()(Args&&... args)
=> !std::invoke(f, >>args...);
</pre></blockquote>
<a name="Effects"></a><h2>Effects on Existing Code</h2>
The token <code>=></code> can appear in code in rare cases, such as in the context of passing a the address of the assignment operator as a template non-template parameter, as in <code>X<Y::operator=></code>. However, such usage is incredibly rare, so this proposal would have very limited effect on existing code. Thanks to Richard Smith for doing a search.
<p>Unary <code>operator>></code> cannot appear in legal code today, so that is a pure language extension.
<a name="Priors"></a><h2>Prior Work</h2>
The original paper introducing what are now generic lambdas [2] also proposed extensions for omitting the <i>type-specifier</i> and dropping the body of a lambda if it's a single expression. This paper provides a different path towards those that same goal.
<p>The usage of <code>=></code> (or the similar <code>-></code>) in the context of lambdas appears in many, many programming languages of all varieties. A non-exhaustive sampling: C#, D, Erlang, F#, Haskell, Java, JavaScript, ML, OCaml, Swift. The widespread use is strongly suggestive that the syntax is easy to read and quite useful.
<a name="Acks"></a><h2>Acknowledgements and References</h2>
Thanks to Andrew Sutton and Tomasz Kaminski for considering and rejecting several bad iterations of this proposal. Thanks to Richard Smith for looking into the practicality of this design.
<p> [1] <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0119r2.pdf">Overload sets as function arguments</a>
<p> [2] <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3418.pdf">Proposal for Generic (Polymorphic) Lambda Expressions</a>
</body>
</html>
------=_Part_1349_1997677589.1476495182352--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Fri, 14 Oct 2016 18:51:21 -0700 (PDT)
Raw View
------=_Part_1069_1568816021.1476496281807
Content-Type: multipart/alternative;
boundary="----=_Part_1070_1170980344.1476496281808"
------=_Part_1070_1170980344.1476496281808
Content-Type: text/plain; charset=UTF-8
On Friday, October 14, 2016 at 9:33:02 PM UTC-4, Barry Revzin wrote:
>
> On Tuesday, October 11, 2016 at 12:32:57 PM UTC-5, Barry Revzin wrote:
>>
>> Here is a contrasting proposal for how to handle overload sets as
>> function arguments. While a lot more verbose in the simple case of just
>> naming a function (where instead of just naming the function you have to
>> actually enumerate the arguments list twice), I think it offers more
>> flexibility in writing short lambdas. There are some motivating examples in
>> the proposal. It's also getting pretty verbose to write correct generic
>> functions with regards to SFINAE and noexcept, so this attempts to make it
>> a little bit easier - at least in the easy case.
>>
>> Also I'm proposing a shorter syntax for forwarding arguments. I picked
>> unary>> because it looks like moving something forward but really anything
>> shorter would be nice. std::forward<Arg>(arg) is particularly verbose,
>> especially in a generic lambda where you have to write
>> std::forward<decltype(arg)>(arg), where the actual forwarding just
>> dominates the code itself.
>>
>>
> Here's an updated draft. I've dropped the version of the syntax that
> allows for the omission of [] and (). At best, that saved four characters
> for single-argument no-capture lambdas, which is a small amount of the
> overall character savings, and seems hardly worth the added complexity in
> parsing. I actually defined >>expr (which had not been the case before) and
> extend the proposal to apply the same idea for function templates.
>
Since you're creating a new operator, I would like to have some explanation
of the precedence of this operator. I imagine that it would be at
precedence level 3
<http://en.cppreference.com/w/cpp/language/operator_precedence>, along with
the other prefix operators.
You also don't make it clear if the new abbreviated lambda parameter
declaration requires the use of `=>` or not. That is, is it legal to do
`[](x) {foo(x + 1);}`? Similarly, it isn't completely clear that `>>` can
be used outside of the context of terse lambda expressions.
Basically, I think you should make it more clear that there are 3
independent features in one proposal, which all leads to shorter and
cleaner code.
--
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/5ddff9cb-b562-4848-9f8b-db390c70883c%40isocpp.org.
------=_Part_1070_1170980344.1476496281808
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Friday, October 14, 2016 at 9:33:02 PM UTC-4, Barry Rev=
zin 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">On =
Tuesday, October 11, 2016 at 12:32:57 PM UTC-5, Barry Revzin wrote:<blockqu=
ote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Here is a contrasting prop=
osal for how to handle overload sets as function arguments. While a lot mor=
e verbose in the simple case of just naming a function (where instead of ju=
st naming the function you have to actually enumerate the arguments list tw=
ice), I think it offers more flexibility in writing short lambdas. There ar=
e some motivating examples in the proposal. It's also getting pretty ve=
rbose to write correct generic functions with regards to SFINAE and noexcep=
t, so this attempts to make it a little bit easier - at least in the easy c=
ase.=C2=A0<div><div><br></div><div>Also I'm proposing a shorter syntax =
for forwarding arguments. I picked unary>> because it looks like movi=
ng something forward but really anything shorter would be nice. <font face=
=3D"courier new, monospace">std::forward<Arg>(arg)</font> is particul=
arly verbose, especially in a generic lambda where you have to write <font =
face=3D"courier new, monospace">std::forward<decltype(arg)>(<wbr>arg)=
</font><font face=3D"arial, sans-serif">, where the actual forwarding just =
dominates the code itself.=C2=A0</font></div><div><br></div></div></div></b=
lockquote><div><br></div><div>Here's an updated draft. I've dropped=
the version of the syntax that allows for the omission of [] and (). At be=
st, that saved four characters for single-argument no-capture lambdas, whic=
h is a small amount of the overall character savings, and seems hardly wort=
h the added complexity in parsing. I actually defined >>expr (which h=
ad not been the case before) and extend the proposal to apply the same idea=
for function templates.=C2=A0</div></div></blockquote><div><br>Since you&#=
39;re creating a new operator, I would like to have some explanation of the=
precedence of this operator. I imagine that it would be <a href=3D"http://=
en.cppreference.com/w/cpp/language/operator_precedence">at precedence level=
3</a>, along with the other prefix operators.<br><br>You also don't ma=
ke it clear if the new abbreviated lambda parameter declaration requires th=
e use of `=3D>` or not. That is, is it legal to do `[](x) {foo(x + 1);}`=
? Similarly, it isn't completely clear that `>>` can be used outs=
ide of the context of terse lambda expressions.<br><br>Basically, I think y=
ou should make it more clear that there are 3 independent features in one p=
roposal, which all leads to shorter and cleaner code.<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/5ddff9cb-b562-4848-9f8b-db390c70883c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5ddff9cb-b562-4848-9f8b-db390c70883c=
%40isocpp.org</a>.<br />
------=_Part_1070_1170980344.1476496281808--
------=_Part_1069_1568816021.1476496281807--
.
Author: szollosi.lorand@gmail.com
Date: Sat, 15 Oct 2016 00:36:23 -0700 (PDT)
Raw View
------=_Part_425_1836527761.1476516983568
Content-Type: multipart/alternative;
boundary="----=_Part_426_1295283847.1476516983568"
------=_Part_426_1295283847.1476516983568
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Hi,
We actually do have a syntax for forwarding and delay: it's operator : .=20
But to understand this, we have to start a little further, break down and=
=20
build up delayed execution to pieces.
First, we (re)define the following constructs:
- : expr means a lambda expression that captures (by mutable reference)=
=20
everything in expr and returns expr (forwarded when that makes sense). I=
t's=20
either prefix or infix, the latter captures a pair of lambdas. Thus : a =
: b=20
equals : ( a : b).
- R(Ti ai, ...) or R(T... args) or (Ti ai, ...) -> R or (T... args) -> R=
=20
mean that a stack frame is allocated[1]. Usually this means function=20
definition; for lambda, one might omit R. Note that the human eye parses=
=20
this, i.e. 'two things separated by space, which might become a list and=
is=20
in parentheses; it'd be counter-intuitive skipping this, especially sinc=
e=20
one might `#define A auto&&`.. [3]
- [...] means a type is being defined which can manually alter what's to=
=20
capture. [2]
=20
Then we define a ? b as a binary operator (thus we got rid of the ternary)=
=20
as b().first() or b().second() depending on a. Note that b is also delayed,=
=20
this is essential for nested ?:. Same logic applies for &&, ||.
Finally, we could allow stack frame[1] definition inside : expr, that is,=
=20
:(auto&& x) ++i, x; for a lambda takes an x, returns (forwards) it and=20
counts the number of times it was called.
One final step remains. What if you didn't want to forward? Gcc has=20
statement expressions which don't need a return statement but instead=20
return the last expr in body. We might borrow this idea (while still=20
allowing for explicit return). In fact, most of the missing return errors=
=20
that occur in a function just expect this, so we generalize to sg that was=
=20
an error before with the intention of the code that resulted in error.
This means, [](auto&& x){ ++i, x; } is allowed and does not forward, while=
=20
:(auto&& x) ++i, x; does forward.
/* one might even try to remove {} from the first */=20
What do you think?
Thanks,
-lorro
[1] Technically, we don't necessarily have stack, so it's=20
parameter/argument list on one side and automatic storage duration=20
variables received on the other side.
[2] One should discuss mutable here.
[3] If that's still not enough, one might allow (&& x) for (auto&& x) and=
=20
(& x) for (auto& x).
2016. okt=C3=B3ber 14., p=C3=A9ntek 16:53:45 UTC+2 id=C5=91pontban Nicol Bo=
las a=20
k=C3=B6vetkez=C5=91t =C3=ADrta:
>
> On Friday, October 14, 2016 at 9:59:39 AM UTC-4, Barry Revzin wrote:
>>
>>
>>> Consider also that the function call syntax currently is self-sufficien=
t=20
>>> in a way that you know which arguments you are discarding (i.e. moving=
=20
>>> or forwarding) and which you do not. With the new syntax this is no=20
>>> longer the case since it changes the way function arguments are=20
>>> interpreted (i.e. implicit forward).=20
>>>
>>
>> I'll post an updated proposal later, but just want to chime here - there=
=20
>> is no implicit forwarding here. The function arguments are interpreted t=
he=20
>> same way, I just want to allow for omission of the parameter types, the=
=20
>> trailing decltype, and the return keyword:
>>
>> // none of these do any forwarding
>> [](auto&& x) -> decltype(twice(x)) { return twice(x); }
>> [](auto&& x) =3D> twice(x);
>> [](x) =3D> twice(x);
>>
>> // all of these do forwarding
>> [](auto&& x) -> decltype(twice(std::forward<decltype(x)>(x))) { return=
=20
>> twice(std::forward<decltype(x)>(x)); }
>> [](auto&& x) =3D> twice(std::forward<decltype(x)>(x));
>> [](x) =3D> twice(std::forward<decltype(x)>(x));
>> [](x) =3D> twice(>>x);
>>
>> You still have to mark the argument as being forwarded.
>> =20
>>
>
> Fair enough, but I still hate using `>>` for that ;)
>
> Granted, I don't have a better alternative at the moment...
>
--=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/dfe4984d-c953-4cc2-b439-2c6351c56221%40isocpp.or=
g.
------=_Part_426_1295283847.1476516983568
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi,<br><br>We actually do have a syntax for forwarding and=
delay: it's operator : . But to understand this, we have to start a li=
ttle further, break down and build up delayed execution to pieces.<br>First=
, we (re)define the following constructs:<br><ul><li>: expr means a lambda =
expression that captures (by mutable reference) everything in expr and retu=
rns expr (forwarded when that makes sense). It's either prefix or infix=
, the latter captures a pair of lambdas. Thus : a : b equals : ( a : b).<br=
></li><li>R(Ti ai, ...) or R(T... args) or (Ti ai, ...) -> R or (T... ar=
gs) -> R mean that a stack frame is allocated[1]. Usually this means fun=
ction definition; for lambda, one might omit R. Note that the human eye par=
ses this, i.e. 'two things separated by space, which might become a lis=
t and is in parentheses; it'd be counter-intuitive skipping this, espec=
ially since one might `#define A auto&&`.. [3]<br></li><li>[...] me=
ans a type is being defined which can manually alter what's to capture.=
[2]<br></li></ul>Then we define a ? b as a binary operator (thus we got ri=
d of the ternary) as b().first() or b().second() depending on a. Note that =
b is also delayed, this is essential for nested ?:. Same logic applies for =
&&, ||.<br><br>Finally, we could allow stack frame[1] definition in=
side : expr, that is, :(auto&& x) ++i, x; for a lambda takes an x, =
returns (forwards) it and counts the number of times it was called.<br><br>=
One final step remains. What if you didn't want to forward? Gcc has sta=
tement expressions which don't need a return statement but instead retu=
rn the last expr in body. We might borrow this idea (while still allowing f=
or explicit return). In fact, most of the missing return errors that occur =
in a function just expect this, so we generalize to sg that was an error be=
fore with the intention of the code that resulted in error.<br>This means, =
[](auto&& x){ ++i, x; } is allowed and does not forward, while :(au=
to&& x) ++i, x; does forward.<br>/* one might even try to remove {}=
from the first */ <br><br>What do you think?<br><br>Thanks,<br>-lorro<br><=
br>[1] Technically, we don't necessarily have stack, so it's parame=
ter/argument list on one side and automatic storage duration variables rece=
ived on the other side.<br>[2] One should discuss mutable here.<br>[3] If t=
hat's still not enough, one might allow (&& x) for (auto&&a=
mp; x) and (& x) for (auto& x).<br><br>2016. okt=C3=B3ber 14., p=C3=
=A9ntek 16:53:45 UTC+2 id=C5=91pontban Nicol Bolas a k=C3=B6vetkez=C5=91t =
=C3=ADrta:<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">On =
Friday, October 14, 2016 at 9:59:39 AM UTC-4, Barry Revzin wrote:<blockquot=
e class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px=
#ccc solid;padding-left:1ex"><div dir=3D"ltr"><blockquote class=3D"gmail_q=
uote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddin=
g-left:1ex"><br>Consider also that the function call syntax currently is se=
lf-sufficient=20
<br>in a way that you know which arguments you are discarding (i.e. moving=
=20
<br>or forwarding) and which you do not. With the new syntax this is no=20
<br>longer the case since it changes the way function arguments are=20
<br>interpreted (i.e. implicit forward).=C2=A0<br></blockquote><div><br></d=
iv><div>I'll post an updated proposal later, but just want to chime her=
e - there is no implicit forwarding here. The function arguments are interp=
reted the same way, I just want to allow for omission of the parameter type=
s, the trailing decltype, and the return keyword:</div><div><br></div><div>=
<div style=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,18=
7);border-style:solid;border-width:1px;word-wrap:break-word"><code><div><sp=
an style=3D"color:#800">// none of these do any forwarding</span><span styl=
e=3D"color:#000"><br></span><span style=3D"color:#660">[](</span><span styl=
e=3D"color:#008">auto</span><span style=3D"color:#660">&&</span><sp=
an style=3D"color:#000"> x</span><span style=3D"color:#660">)</span><span s=
tyle=3D"color:#000"> </span><span style=3D"color:#660">-></span><span st=
yle=3D"color:#000"> </span><span style=3D"color:#008">decltype</span><span =
style=3D"color:#660">(</span><span style=3D"color:#000">twice</span><span s=
tyle=3D"color:#660">(</span><span style=3D"color:#000">x</span><span style=
=3D"color:#660">))</span><span style=3D"color:#000"> </span><span style=3D"=
color:#660">{</span><span style=3D"color:#000"> </span><span style=3D"color=
:#008">return</span><span style=3D"color:#000"> twice</span><span style=3D"=
color:#660">(</span><span style=3D"color:#000">x</span><span style=3D"color=
:#660">);</span><span style=3D"color:#000"> </span><span style=3D"color:#66=
0">}</span><span style=3D"color:#000"><br></span><span style=3D"color:#660"=
>[](</span><span style=3D"color:#008">auto</span><span style=3D"color:#660"=
>&&</span><span style=3D"color:#000"> x</span><span style=3D"color:=
#660">)</span><span style=3D"color:#000"> </span><span style=3D"color:#660"=
>=3D></span><span style=3D"color:#000"> twice</span><span style=3D"color=
:#660">(</span><span style=3D"color:#000">x</span><span style=3D"color:#660=
">);</span><font color=3D"#880000"><span style=3D"color:#000"><br></span><s=
pan style=3D"color:#660">[](</span><span style=3D"color:#000">x</span><span=
style=3D"color:#660">)</span><span style=3D"color:#000"> </span><span styl=
e=3D"color:#660">=3D></span><span style=3D"color:#000"> twice</span><spa=
n style=3D"color:#660">(</span><span style=3D"color:#000">x</span><span sty=
le=3D"color:#660">);</span><span style=3D"color:#000"><br><br></span><span =
style=3D"color:#800">// all of these do forwarding</span><span style=3D"col=
or:#000"><br></span></font><span style=3D"color:#660">[](</span><span style=
=3D"color:#008">auto</span><span style=3D"color:#660">&&</span><spa=
n style=3D"color:#000"> x</span><span style=3D"color:#660">)</span><span st=
yle=3D"color:#000"> </span><span style=3D"color:#660">-></span><span sty=
le=3D"color:#000"> </span><span style=3D"color:#008">decltype</span><span s=
tyle=3D"color:#660">(</span><span style=3D"color:#000">twice</span><span st=
yle=3D"color:#660">(</span><span style=3D"color:#000">std</span><span style=
=3D"color:#660">::</span><span style=3D"color:#000">forward</span><span sty=
le=3D"color:#660"><</span><span style=3D"color:#008">de<wbr>cltype</span=
><span style=3D"color:#660">(</span><span style=3D"color:#000">x</span><spa=
n style=3D"color:#660">)>(</span><span style=3D"color:#000">x</span><spa=
n style=3D"color:#660">)))</span><span style=3D"color:#000"> </span><span s=
tyle=3D"color:#660">{</span><span style=3D"color:#000"> </span><span style=
=3D"color:#008">return</span><span style=3D"color:#000"> twice</span><span =
style=3D"color:#660">(</span><span style=3D"color:#000">std</span><span sty=
le=3D"color:#660">::</span><span style=3D"color:#000">forward</span><span s=
tyle=3D"color:#660"><</span><span style=3D"color:#008">decltype</span><s=
pan style=3D"color:#660">(</span><span style=3D"color:#000">x</span><span s=
tyle=3D"color:#660">)<wbr>>(</span><span style=3D"color:#000">x</span><s=
pan style=3D"color:#660">));</span><span style=3D"color:#000"> </span><span=
style=3D"color:#660">}</span><span style=3D"color:#000"><br></span><span s=
tyle=3D"color:#660">[](</span><span style=3D"color:#008">auto</span><span s=
tyle=3D"color:#660">&&</span><span style=3D"color:#000"> x</span><s=
pan style=3D"color:#660">)</span><span style=3D"color:#000"> </span><span s=
tyle=3D"color:#660">=3D></span><span style=3D"color:#000"> twice</span><=
span style=3D"color:#660">(</span><font color=3D"#000000"><span style=3D"co=
lor:#000">std</span><span style=3D"color:#660">::</span><span style=3D"colo=
r:#000">forward</span><span style=3D"color:#660"><</span><span style=3D"=
color:#008">decltype</span><span style=3D"color:#660">(</span><span style=
=3D"color:#000">x</span><span style=3D"color:#660">)<wbr>>(</span><span =
style=3D"color:#000">x</span><span style=3D"color:#660">)</span></font><spa=
n style=3D"color:#660">);</span><span style=3D"color:#000"><br></span><span=
style=3D"color:#660">[](</span><span style=3D"color:#000">x</span><span st=
yle=3D"color:#660">)</span><span style=3D"color:#000"> </span><span style=
=3D"color:#660">=3D></span><span style=3D"color:#000"> twice</span><span=
style=3D"color:#660">(</span><font color=3D"#000000"><span style=3D"color:=
#000">std</span><span style=3D"color:#660">::</span><span style=3D"color:#0=
00">forward</span><span style=3D"color:#660"><</span><span style=3D"colo=
r:#008">decltype</span><span style=3D"color:#660">(</span><span style=3D"co=
lor:#000">x</span><span style=3D"color:#660">)<wbr>>(</span><span style=
=3D"color:#000">x</span><span style=3D"color:#660">)</span></font><span sty=
le=3D"color:#660">);</span><span style=3D"color:#000"><br></span><span styl=
e=3D"color:#660">[](</span><span style=3D"color:#000">x</span><span style=
=3D"color:#660">)</span><span style=3D"color:#000"> </span><span style=3D"c=
olor:#660">=3D></span><span style=3D"color:#000"> twice</span><span styl=
e=3D"color:#660">(>></span><span style=3D"color:#000">x</span><span s=
tyle=3D"color:#660">);</span></div></code></div><div><br></div>You still ha=
ve to mark the argument as being forwarded.<br>=C2=A0</div></div></blockquo=
te><div><br>Fair enough, but I still hate using `>>` for that ;)<br><=
br>Granted, I don't have a better alternative at the moment...<br></div=
></div></blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/dfe4984d-c953-4cc2-b439-2c6351c56221%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/dfe4984d-c953-4cc2-b439-2c6351c56221=
%40isocpp.org</a>.<br />
------=_Part_426_1295283847.1476516983568--
------=_Part_425_1836527761.1476516983568--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Sat, 15 Oct 2016 11:46:54 -0400
Raw View
<html><head></head><body lang=3D"en-US" style=3D"background-color: rgb(255,=
255, 255); line-height: initial;"> =
<div style=3D"width: 100%; fo=
nt-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif=
; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, =
255, 255);">I keep thinking something like back-tick would be useful in thi=
s discussion. </div><div style=3D"width: 100%; font-size: initial; fon=
t-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, =
125); text-align: initial; background-color: rgb(255, 255, 255);"><br></div=
><div style=3D"width: 100%; font-size: initial; font-family: Calibri, 'Slat=
e Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initia=
l; background-color: rgb(255, 255, 255);">Like `x + 1` is a 'lifted' or to-=
be-inlined expression, a lambda where x is auto-forwarded because =E2=80=8E=
you don't get a new type at all, just a direct substitution of x. </d=
iv><div style=3D"width: 100%; font-size: initial; font-family: Calibri, 'Sl=
ate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: init=
ial; background-color: rgb(255, 255, 255);"><br></div><div style=3D"width: =
100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sa=
ns-serif; color: rgb(31, 73, 125); text-align: initial; background-color: r=
gb(255, 255, 255);">Or maybe `x` means forward x. </div><div style=3D"=
width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-se=
rif, sans-serif; color: rgb(31, 73, 125); text-align: initial; background-c=
olor: rgb(255, 255, 255);"><br></div><div style=3D"width: 100%; font-size: =
initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: =
rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255)=
;">(yes, I know, back-tick isn't part of the character set)</div><div style=
=3D"width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', san=
s-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; backgrou=
nd-color: rgb(255, 255, 255);"><br></div> =
=
<div style=3D"width: 100%; font-size: initial; font=
-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 1=
25); text-align: initial; background-color: rgb(255, 255, 255);"><br style=
=3D"display:initial"></div> =
=
<di=
v style=3D"font-size: initial; font-family: Calibri, 'Slate Pro', sans-seri=
f, sans-serif; color: rgb(31, 73, 125); text-align: initial; background-col=
or: rgb(255, 255, 255);">Sent from my BlackBerry portab=
le Babbage Device</div> =
=
<table width=
=3D"100%" style=3D"background-color:white;border-spacing:0px;"> <tbody><tr>=
<td colspan=3D"2" style=3D"font-size: initial; text-align: initial; backgro=
und-color: rgb(255, 255, 255);"> <div style=3D"bo=
rder-style: solid none none; border-top-color: rgb(181, 196, 223); border-t=
op-width: 1pt; padding: 3pt 0in 0in; font-family: Tahoma, 'BB Alpha Sans', =
'Slate Pro'; font-size: 10pt;"> <div><b>From: </b>szollosi.lorand@gmail.co=
m</div><div><b>Sent: </b>Saturday, October 15, 2016 3:36 AM</div><div><b>To=
: </b>ISO C++ Standard - Future Proposals</div><div><b>Reply To: </b>std-pr=
oposals@isocpp.org</div><div><b>Subject: </b>Re: [std-proposals] An abbrevi=
ated lambda syntax</div></div></td></tr></tbody></table><div style=3D"borde=
r-style: solid none none; border-top-color: rgb(186, 188, 209); border-top-=
width: 1pt; font-size: initial; text-align: initial; background-color: rgb(=
255, 255, 255);"></div><br><div id=3D"_originalContent" style=3D""><div dir=
=3D"ltr">Hi,<br><br>We actually do have a syntax for forwarding and delay: =
it's operator : . But to understand this, we have to start a little further=
, break down and build up delayed execution to pieces.<br>First, we (re)def=
ine the following constructs:<br><ul><li>: expr means a lambda expression t=
hat captures (by mutable reference) everything in expr and returns expr (fo=
rwarded when that makes sense). It's either prefix or infix, the latter cap=
tures a pair of lambdas. Thus : a : b equals : ( a : b).<br></li><li>R(Ti a=
i, ...) or R(T... args) or (Ti ai, ...) -> R or (T... args) -> R mean=
that a stack frame is allocated[1]. Usually this means function definition=
; for lambda, one might omit R. Note that the human eye parses this, i.e. '=
two things separated by space, which might become a list and is in parenthe=
ses; it'd be counter-intuitive skipping this, especially since one might `#=
define A auto&&`.. [3]<br></li><li>[...] means a type is being defi=
ned which can manually alter what's to capture. [2]<br></li></ul>Then we de=
fine a ? b as a binary operator (thus we got rid of the ternary) as b().fir=
st() or b().second() depending on a. Note that b is also delayed, this is e=
ssential for nested ?:. Same logic applies for &&, ||.<br><br>Final=
ly, we could allow stack frame[1] definition inside : expr, that is, :(auto=
&& x) ++i, x; for a lambda takes an x, returns (forwards) it and co=
unts the number of times it was called.<br><br>One final step remains. What=
if you didn't want to forward? Gcc has statement expressions which don't n=
eed a return statement but instead return the last expr in body. We might b=
orrow this idea (while still allowing for explicit return). In fact, most o=
f the missing return errors that occur in a function just expect this, so w=
e generalize to sg that was an error before with the intention of the code =
that resulted in error.<br>This means, [](auto&& x){ ++i, x; } is a=
llowed and does not forward, while :(auto&& x) ++i, x; does forward=
..<br>/* one might even try to remove {} from the first */ <br><br>What do y=
ou think?<br><br>Thanks,<br>-lorro<br><br>[1] Technically, we don't necessa=
rily have stack, so it's parameter/argument list on one side and automatic =
storage duration variables received on the other side.<br>[2] One should di=
scuss mutable here.<br>[3] If that's still not enough, one might allow (&am=
p;& x) for (auto&& x) and (& x) for (auto& x).<br><br>2=
016. okt=C3=B3ber 14., p=C3=A9ntek 16:53:45 UTC+2 id=C5=91pontban Nicol Bol=
as a k=C3=B6vetkez=C5=91t =C3=ADrta:<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">On Friday, October 14, 2016 at 9:59:39 AM UTC-4, Bar=
ry Revzin 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"><b=
lockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-=
left:1px #ccc solid;padding-left:1ex"><br>Consider also that the function c=
all syntax currently is self-sufficient=20
<br>in a way that you know which arguments you are discarding (i.e. moving=
=20
<br>or forwarding) and which you do not. With the new syntax this is no=20
<br>longer the case since it changes the way function arguments are=20
<br>interpreted (i.e. implicit forward). <br></blockquote><div><br></d=
iv><div>I'll post an updated proposal later, but just want to chime here - =
there is no implicit forwarding here. The function arguments are interprete=
d the same way, I just want to allow for omission of the parameter types, t=
he trailing decltype, and the return keyword:</div><div><br></div><div><div=
style=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187);b=
order-style:solid;border-width:1px;word-wrap:break-word"><code><div><span s=
tyle=3D"color:#800">// none of these do any forwarding</span><span style=3D=
"color:#000"><br></span><span style=3D"color:#660">[](</span><span style=3D=
"color:#008">auto</span><span style=3D"color:#660">&&</span><span s=
tyle=3D"color:#000"> x</span><span style=3D"color:#660">)</span><span style=
=3D"color:#000"> </span><span style=3D"color:#660">-></span><span style=
=3D"color:#000"> </span><span style=3D"color:#008">decltype</span><span sty=
le=3D"color:#660">(</span><span style=3D"color:#000">twice</span><span styl=
e=3D"color:#660">(</span><span style=3D"color:#000">x</span><span style=3D"=
color:#660">))</span><span style=3D"color:#000"> </span><span style=3D"colo=
r:#660">{</span><span style=3D"color:#000"> </span><span style=3D"color:#00=
8">return</span><span style=3D"color:#000"> twice</span><span style=3D"colo=
r:#660">(</span><span style=3D"color:#000">x</span><span style=3D"color:#66=
0">);</span><span style=3D"color:#000"> </span><span style=3D"color:#660">}=
</span><span style=3D"color:#000"><br></span><span style=3D"color:#660">[](=
</span><span style=3D"color:#008">auto</span><span style=3D"color:#660">&am=
p;&</span><span style=3D"color:#000"> x</span><span style=3D"color:#660=
">)</span><span style=3D"color:#000"> </span><span style=3D"color:#660">=3D=
></span><span style=3D"color:#000"> twice</span><span style=3D"color:#66=
0">(</span><span style=3D"color:#000">x</span><span style=3D"color:#660">);=
</span><font color=3D"#880000"><span style=3D"color:#000"><br></span><span =
style=3D"color:#660">[](</span><span style=3D"color:#000">x</span><span sty=
le=3D"color:#660">)</span><span style=3D"color:#000"> </span><span style=3D=
"color:#660">=3D></span><span style=3D"color:#000"> twice</span><span st=
yle=3D"color:#660">(</span><span style=3D"color:#000">x</span><span style=
=3D"color:#660">);</span><span style=3D"color:#000"><br><br></span><span st=
yle=3D"color:#800">// all of these do forwarding</span><span style=3D"color=
:#000"><br></span></font><span style=3D"color:#660">[](</span><span style=
=3D"color:#008">auto</span><span style=3D"color:#660">&&</span><spa=
n style=3D"color:#000"> x</span><span style=3D"color:#660">)</span><span st=
yle=3D"color:#000"> </span><span style=3D"color:#660">-></span><span sty=
le=3D"color:#000"> </span><span style=3D"color:#008">decltype</span><span s=
tyle=3D"color:#660">(</span><span style=3D"color:#000">twice</span><span st=
yle=3D"color:#660">(</span><span style=3D"color:#000">std</span><span style=
=3D"color:#660">::</span><span style=3D"color:#000">forward</span><span sty=
le=3D"color:#660"><</span><span style=3D"color:#008">de<wbr>cltype</span=
><span style=3D"color:#660">(</span><span style=3D"color:#000">x</span><spa=
n style=3D"color:#660">)>(</span><span style=3D"color:#000">x</span><spa=
n style=3D"color:#660">)))</span><span style=3D"color:#000"> </span><span s=
tyle=3D"color:#660">{</span><span style=3D"color:#000"> </span><span style=
=3D"color:#008">return</span><span style=3D"color:#000"> twice</span><span =
style=3D"color:#660">(</span><span style=3D"color:#000">std</span><span sty=
le=3D"color:#660">::</span><span style=3D"color:#000">forward</span><span s=
tyle=3D"color:#660"><</span><span style=3D"color:#008">decltype</span><s=
pan style=3D"color:#660">(</span><span style=3D"color:#000">x</span><span s=
tyle=3D"color:#660">)<wbr>>(</span><span style=3D"color:#000">x</span><s=
pan style=3D"color:#660">));</span><span style=3D"color:#000"> </span><span=
style=3D"color:#660">}</span><span style=3D"color:#000"><br></span><span s=
tyle=3D"color:#660">[](</span><span style=3D"color:#008">auto</span><span s=
tyle=3D"color:#660">&&</span><span style=3D"color:#000"> x</span><s=
pan style=3D"color:#660">)</span><span style=3D"color:#000"> </span><span s=
tyle=3D"color:#660">=3D></span><span style=3D"color:#000"> twice</span><=
span style=3D"color:#660">(</span><font color=3D"#000000"><span style=3D"co=
lor:#000">std</span><span style=3D"color:#660">::</span><span style=3D"colo=
r:#000">forward</span><span style=3D"color:#660"><</span><span style=3D"=
color:#008">decltype</span><span style=3D"color:#660">(</span><span style=
=3D"color:#000">x</span><span style=3D"color:#660">)<wbr>>(</span><span =
style=3D"color:#000">x</span><span style=3D"color:#660">)</span></font><spa=
n style=3D"color:#660">);</span><span style=3D"color:#000"><br></span><span=
style=3D"color:#660">[](</span><span style=3D"color:#000">x</span><span st=
yle=3D"color:#660">)</span><span style=3D"color:#000"> </span><span style=
=3D"color:#660">=3D></span><span style=3D"color:#000"> twice</span><span=
style=3D"color:#660">(</span><font color=3D"#000000"><span style=3D"color:=
#000">std</span><span style=3D"color:#660">::</span><span style=3D"color:#0=
00">forward</span><span style=3D"color:#660"><</span><span style=3D"colo=
r:#008">decltype</span><span style=3D"color:#660">(</span><span style=3D"co=
lor:#000">x</span><span style=3D"color:#660">)<wbr>>(</span><span style=
=3D"color:#000">x</span><span style=3D"color:#660">)</span></font><span sty=
le=3D"color:#660">);</span><span style=3D"color:#000"><br></span><span styl=
e=3D"color:#660">[](</span><span style=3D"color:#000">x</span><span style=
=3D"color:#660">)</span><span style=3D"color:#000"> </span><span style=3D"c=
olor:#660">=3D></span><span style=3D"color:#000"> twice</span><span styl=
e=3D"color:#660">(>></span><span style=3D"color:#000">x</span><span s=
tyle=3D"color:#660">);</span></div></code></div><div><br></div>You still ha=
ve to mark the argument as being forwarded.<br> </div></div></blockquo=
te><div><br>Fair enough, but I still hate using `>>` for that ;)<br><=
br>Granted, I don't have a better alternative at the moment...<br></div></d=
iv></blockquote></div>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" 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/dfe4984d-c953-4cc2-b439-2c6351c56221%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.goo=
gle.com/a/isocpp.org/d/msgid/std-proposals/dfe4984d-c953-4cc2-b439-2c6351c5=
6221%40isocpp.org</a>.<br>
<br><!--end of _originalContent --></div></body></html>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/20161015154654.4907089.73110.18538%40=
gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com=
/a/isocpp.org/d/msgid/std-proposals/20161015154654.4907089.73110.18538%40gm=
ail.com</a>.<br />
.
Author: szollosi.lorand@gmail.com
Date: Sat, 15 Oct 2016 10:19:01 -0700 (PDT)
Raw View
------=_Part_1370_469888223.1476551941749
Content-Type: multipart/alternative;
boundary="----=_Part_1371_1602982379.1476551941750"
------=_Part_1371_1602982379.1476551941750
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Hi,
Sounds very promising.. would you perhaps allow statements as well? That'd=
=20
fix my other proposal, capturing return / break / continue: you could say=
=20
f(i, `return false;`) or f(i, `break;`).
Adding a digraph is no problem :).
Thanks,
-lorro
2016. okt=C3=B3ber 15., szombat 17:47:01 UTC+2 id=C5=91pontban Tony V E a k=
=C3=B6vetkez=C5=91t=20
=C3=ADrta:
>
> I keep thinking something like back-tick would be useful in this=20
> discussion.=20
>
> Like `x + 1` is a 'lifted' or to-be-inlined expression, a lambda where x=
=20
> is auto-forwarded because =E2=80=8Eyou don't get a new type at all, just =
a direct=20
> substitution of x. =20
>
> Or maybe `x` means forward x.=20
>
> (yes, I know, back-tick isn't part of the character set)
>
>
> Sent from my BlackBerry portable Babbage Device
> *From: *szollos...@gmail.com <javascript:>
> *Sent: *Saturday, October 15, 2016 3:36 AM
> *To: *ISO C++ Standard - Future Proposals
> *Reply To: *std-pr...@isocpp.org <javascript:>
> *Subject: *Re: [std-proposals] An abbreviated lambda syntax
>
> Hi,
>
> We actually do have a syntax for forwarding and delay: it's operator : .=
=20
> But to understand this, we have to start a little further, break down and=
=20
> build up delayed execution to pieces.
> First, we (re)define the following constructs:
>
> - : expr means a lambda expression that captures (by mutable=20
> reference) everything in expr and returns expr (forwarded when that ma=
kes=20
> sense). It's either prefix or infix, the latter captures a pair of lam=
bdas.=20
> Thus : a : b equals : ( a : b).
> - R(Ti ai, ...) or R(T... args) or (Ti ai, ...) -> R or (T... args) ->=
=20
> R mean that a stack frame is allocated[1]. Usually this means function=
=20
> definition; for lambda, one might omit R. Note that the human eye pars=
es=20
> this, i.e. 'two things separated by space, which might become a list a=
nd is=20
> in parentheses; it'd be counter-intuitive skipping this, especially si=
nce=20
> one might `#define A auto&&`.. [3]
> - [...] means a type is being defined which can manually alter what's=
=20
> to capture. [2]
> =20
> Then we define a ? b as a binary operator (thus we got rid of the ternary=
)=20
> as b().first() or b().second() depending on a. Note that b is also delaye=
d,=20
> this is essential for nested ?:. Same logic applies for &&, ||.
>
> Finally, we could allow stack frame[1] definition inside : expr, that is,=
=20
> :(auto&& x) ++i, x; for a lambda takes an x, returns (forwards) it and=20
> counts the number of times it was called.
>
> One final step remains. What if you didn't want to forward? Gcc has=20
> statement expressions which don't need a return statement but instead=20
> return the last expr in body. We might borrow this idea (while still=20
> allowing for explicit return). In fact, most of the missing return errors=
=20
> that occur in a function just expect this, so we generalize to sg that wa=
s=20
> an error before with the intention of the code that resulted in error.
> This means, [](auto&& x){ ++i, x; } is allowed and does not forward, whil=
e=20
> :(auto&& x) ++i, x; does forward.
> /* one might even try to remove {} from the first */=20
>
> What do you think?
>
> Thanks,
> -lorro
>
> [1] Technically, we don't necessarily have stack, so it's=20
> parameter/argument list on one side and automatic storage duration=20
> variables received on the other side.
> [2] One should discuss mutable here.
> [3] If that's still not enough, one might allow (&& x) for (auto&& x) and=
=20
> (& x) for (auto& x).
>
> 2016. okt=C3=B3ber 14., p=C3=A9ntek 16:53:45 UTC+2 id=C5=91pontban Nicol =
Bolas a=20
> k=C3=B6vetkez=C5=91t =C3=ADrta:
>>
>> On Friday, October 14, 2016 at 9:59:39 AM UTC-4, Barry Revzin wrote:
>>>
>>>
>>>> Consider also that the function call syntax currently is=20
>>>> self-sufficient=20
>>>> in a way that you know which arguments you are discarding (i.e. moving=
=20
>>>> or forwarding) and which you do not. With the new syntax this is no=20
>>>> longer the case since it changes the way function arguments are=20
>>>> interpreted (i.e. implicit forward).=20
>>>>
>>>
>>> I'll post an updated proposal later, but just want to chime here - ther=
e=20
>>> is no implicit forwarding here. The function arguments are interpreted =
the=20
>>> same way, I just want to allow for omission of the parameter types, the=
=20
>>> trailing decltype, and the return keyword:
>>>
>>> // none of these do any forwarding
>>> [](auto&& x) -> decltype(twice(x)) { return twice(x); }
>>> [](auto&& x) =3D> twice(x);
>>> [](x) =3D> twice(x);
>>>
>>> // all of these do forwarding
>>> [](auto&& x) -> decltype(twice(std::forward<decltype(x)>(x))) { return=
=20
>>> twice(std::forward<decltype(x)>(x)); }
>>> [](auto&& x) =3D> twice(std::forward<decltype(x)>(x));
>>> [](x) =3D> twice(std::forward<decltype(x)>(x));
>>> [](x) =3D> twice(>>x);
>>>
>>> You still have to mark the argument as being forwarded.
>>> =20
>>>
>>
>> Fair enough, but I still hate using `>>` for that ;)
>>
>> Granted, I don't have a better alternative at the moment...
>>
> --=20
> You received this message because you are subscribed to the Google Groups=
=20
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an=
=20
> email to std-proposal...@isocpp.org <javascript:>.
> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
> To view this discussion on the web visit=20
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/dfe4984d-c95=
3-4cc2-b439-2c6351c56221%40isocpp.org=20
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/dfe4984d-c9=
53-4cc2-b439-2c6351c56221%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>
>
--=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/09675607-2ece-4afb-ab60-c1f80fbb7050%40isocpp.or=
g.
------=_Part_1371_1602982379.1476551941750
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi,<br><br>Sounds very promising.. would you perhaps allow=
statements as well? That'd fix my other proposal, capturing return / b=
reak / continue: you could say f(i, `return false;`) or f(i, `break;`).<br>=
Adding a digraph is no problem :).<br><br>Thanks,<br>-lorro<br><br>2016. ok=
t=C3=B3ber 15., szombat 17:47:01 UTC+2 id=C5=91pontban Tony V E a k=C3=B6ve=
tkez=C5=91t =C3=ADrta:<blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div sty=
le=3D"background-color:rgb(255,255,255);line-height:initial" lang=3D"en-US"=
> =
<div style=3D"width:100%;font-size:initial;font-family:Calibri,=
'Slate Pro',sans-serif,sans-serif;color:rgb(31,73,125);text-align:i=
nitial;background-color:rgb(255,255,255)">I keep thinking something like ba=
ck-tick would be useful in this discussion.=C2=A0</div><div style=3D"width:=
100%;font-size:initial;font-family:Calibri,'Slate Pro',sans-serif,s=
ans-serif;color:rgb(31,73,125);text-align:initial;background-color:rgb(255,=
255,255)"><br></div><div style=3D"width:100%;font-size:initial;font-family:=
Calibri,'Slate Pro',sans-serif,sans-serif;color:rgb(31,73,125);text=
-align:initial;background-color:rgb(255,255,255)">Like `x + 1` is a 'li=
fted' or to-be-inlined expression, a lambda where x is auto-forwarded b=
ecause =E2=80=8Eyou don't get a new type at all, just a direct substitu=
tion of x. =C2=A0</div><div style=3D"width:100%;font-size:initial;font-fami=
ly:Calibri,'Slate Pro',sans-serif,sans-serif;color:rgb(31,73,125);t=
ext-align:initial;background-color:rgb(255,255,255)"><br></div><div style=
=3D"width:100%;font-size:initial;font-family:Calibri,'Slate Pro',sa=
ns-serif,sans-serif;color:rgb(31,73,125);text-align:initial;background-colo=
r:rgb(255,255,255)">Or maybe `x` means forward x.=C2=A0</div><div style=3D"=
width:100%;font-size:initial;font-family:Calibri,'Slate Pro',sans-s=
erif,sans-serif;color:rgb(31,73,125);text-align:initial;background-color:rg=
b(255,255,255)"><br></div><div style=3D"width:100%;font-size:initial;font-f=
amily:Calibri,'Slate Pro',sans-serif,sans-serif;color:rgb(31,73,125=
);text-align:initial;background-color:rgb(255,255,255)">(yes, I know, back-=
tick isn't part of the character set)</div><div style=3D"width:100%;fon=
t-size:initial;font-family:Calibri,'Slate Pro',sans-serif,sans-seri=
f;color:rgb(31,73,125);text-align:initial;background-color:rgb(255,255,255)=
"><br></div> =
<div =
style=3D"width:100%;font-size:initial;font-family:Calibri,'Slate Pro=
9;,sans-serif,sans-serif;color:rgb(31,73,125);text-align:initial;background=
-color:rgb(255,255,255)"><br style=3D"display:initial"></div> =
=
=
<div style=3D"font-size:initial;font-family:=
Calibri,'Slate Pro',sans-serif,sans-serif;color:rgb(31,73,125);text=
-align:initial;background-color:rgb(255,255,255)">Sent=C2=A0from=C2=A0my=C2=
=A0BlackBerry=C2=A0<wbr>portable=C2=A0Babbage=C2=A0Device</div> =
=
=
<table style=3D"background-color:white;border-spacing:0px" =
width=3D"100%"> <tbody><tr><td colspan=3D"2" style=3D"font-size:initial;tex=
t-align:initial;background-color:rgb(255,255,255)"> =
<div style=3D"border-style:solid none none;border-top-color:rgb(181,196,=
223);border-top-width:1pt;padding:3pt 0in 0in;font-family:Tahoma,'BB Al=
pha Sans','Slate Pro';font-size:10pt"> <div><b>From: </b><a hr=
ef=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"nBmFwWZTAgAJ"=
rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';return t=
rue;" onclick=3D"this.href=3D'javascript:';return true;">szollos...=
@gmail.com</a></div><div><b>Sent: </b>Saturday, October 15, 2016 3:36 AM</d=
iv><div><b>To: </b>ISO C++ Standard - Future Proposals</div><div><b>Reply T=
o: </b><a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"n=
BmFwWZTAgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:&#=
39;;return true;" onclick=3D"this.href=3D'javascript:';return true;=
">std-pr...@isocpp.org</a></div><div><b>Subject: </b>Re: [std-proposals] An=
abbreviated lambda syntax</div></div></td></tr></tbody></table><div style=
=3D"border-style:solid none none;border-top-color:rgb(186,188,209);border-t=
op-width:1pt;font-size:initial;text-align:initial;background-color:rgb(255,=
255,255)"></div><br><div><div dir=3D"ltr">Hi,<br><br>We actually do have a =
syntax for forwarding and delay: it's operator : . But to understand th=
is, we have to start a little further, break down and build up delayed exec=
ution to pieces.<br>First, we (re)define the following constructs:<br><ul><=
li>: expr means a lambda expression that captures (by mutable reference) ev=
erything in expr and returns expr (forwarded when that makes sense). It'=
;s either prefix or infix, the latter captures a pair of lambdas. Thus : a =
: b equals : ( a : b).<br></li><li>R(Ti ai, ...) or R(T... args) or (Ti ai,=
...) -> R or (T... args) -> R mean that a stack frame is allocated[1=
]. Usually this means function definition; for lambda, one might omit R. No=
te that the human eye parses this, i.e. 'two things separated by space,=
which might become a list and is in parentheses; it'd be counter-intui=
tive skipping this, especially since one might `#define A auto&&`..=
[3]<br></li><li>[...] means a type is being defined which can manually alt=
er what's to capture. [2]<br></li></ul>Then we define a ? b as a binary=
operator (thus we got rid of the ternary) as b().first() or b().second() d=
epending on a. Note that b is also delayed, this is essential for nested ?:=
.. Same logic applies for &&, ||.<br><br>Finally, we could allow sta=
ck frame[1] definition inside : expr, that is, :(auto&& x) ++i, x; =
for a lambda takes an x, returns (forwards) it and counts the number of tim=
es it was called.<br><br>One final step remains. What if you didn't wan=
t to forward? Gcc has statement expressions which don't need a return s=
tatement but instead return the last expr in body. We might borrow this ide=
a (while still allowing for explicit return). In fact, most of the missing =
return errors that occur in a function just expect this, so we generalize t=
o sg that was an error before with the intention of the code that resulted =
in error.<br>This means, [](auto&& x){ ++i, x; } is allowed and doe=
s not forward, while :(auto&& x) ++i, x; does forward.<br>/* one mi=
ght even try to remove {} from the first */ <br><br>What do you think?<br><=
br>Thanks,<br>-lorro<br><br>[1] Technically, we don't necessarily have =
stack, so it's parameter/argument list on one side and automatic storag=
e duration variables received on the other side.<br>[2] One should discuss =
mutable here.<br>[3] If that's still not enough, one might allow (&=
& x) for (auto&& x) and (& x) for (auto& x).<br><br>201=
6. okt=C3=B3ber 14., p=C3=A9ntek 16:53:45 UTC+2 id=C5=91pontban Nicol Bolas=
a k=C3=B6vetkez=C5=91t =C3=ADrta:<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">On Friday, October 14, 2016 at 9:59:39 AM UTC-4, Barry Re=
vzin 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"><blockq=
uote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:=
1px #ccc solid;padding-left:1ex"><br>Consider also that the function call s=
yntax currently is self-sufficient=20
<br>in a way that you know which arguments you are discarding (i.e. moving=
=20
<br>or forwarding) and which you do not. With the new syntax this is no=20
<br>longer the case since it changes the way function arguments are=20
<br>interpreted (i.e. implicit forward).=C2=A0<br></blockquote><div><br></d=
iv><div>I'll post an updated proposal later, but just want to chime her=
e - there is no implicit forwarding here. The function arguments are interp=
reted the same way, I just want to allow for omission of the parameter type=
s, the trailing decltype, and the return keyword:</div><div><br></div><div>=
<div style=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,18=
7);border-style:solid;border-width:1px;word-wrap:break-word"><code><div><sp=
an style=3D"color:#800">// none of these do any forwarding</span><span styl=
e=3D"color:#000"><br></span><span style=3D"color:#660">[](</span><span styl=
e=3D"color:#008">auto</span><span style=3D"color:#660">&&</span><sp=
an style=3D"color:#000"> x</span><span style=3D"color:#660">)</span><span s=
tyle=3D"color:#000"> </span><span style=3D"color:#660">-></span><span st=
yle=3D"color:#000"> </span><span style=3D"color:#008">decltype</span><span =
style=3D"color:#660">(</span><span style=3D"color:#000">twice</span><span s=
tyle=3D"color:#660">(</span><span style=3D"color:#000">x</span><span style=
=3D"color:#660">))</span><span style=3D"color:#000"> </span><span style=3D"=
color:#660">{</span><span style=3D"color:#000"> </span><span style=3D"color=
:#008">return</span><span style=3D"color:#000"> twice</span><span style=3D"=
color:#660">(</span><span style=3D"color:#000">x</span><span style=3D"color=
:#660">);</span><span style=3D"color:#000"> </span><span style=3D"color:#66=
0">}</span><span style=3D"color:#000"><br></span><span style=3D"color:#660"=
>[](</span><span style=3D"color:#008">auto</span><span style=3D"color:#660"=
>&&</span><span style=3D"color:#000"> x</span><span style=3D"color:=
#660">)</span><span style=3D"color:#000"> </span><span style=3D"color:#660"=
>=3D></span><span style=3D"color:#000"> twice</span><span style=3D"color=
:#660">(</span><span style=3D"color:#000">x</span><span style=3D"color:#660=
">);</span><font color=3D"#880000"><span style=3D"color:#000"><br></span><s=
pan style=3D"color:#660">[](</span><span style=3D"color:#000">x</span><span=
style=3D"color:#660">)</span><span style=3D"color:#000"> </span><span styl=
e=3D"color:#660">=3D></span><span style=3D"color:#000"> twice</span><spa=
n style=3D"color:#660">(</span><span style=3D"color:#000">x</span><span sty=
le=3D"color:#660">);</span><span style=3D"color:#000"><br><br></span><span =
style=3D"color:#800">// all of these do forwarding</span><span style=3D"col=
or:#000"><br></span></font><span style=3D"color:#660">[](</span><span style=
=3D"color:#008">auto</span><span style=3D"color:#660">&&</span><spa=
n style=3D"color:#000"> x</span><span style=3D"color:#660">)</span><span st=
yle=3D"color:#000"> </span><span style=3D"color:#660">-></span><span sty=
le=3D"color:#000"> </span><span style=3D"color:#008">decltype</span><span s=
tyle=3D"color:#660">(</span><span style=3D"color:#000">twice</span><span st=
yle=3D"color:#660">(</span><span style=3D"color:#000">std</span><span style=
=3D"color:#660">::</span><span style=3D"color:#000">forward</span><span sty=
le=3D"color:#660"><</span><span style=3D"color:#008">de<wbr>cltype</span=
><span style=3D"color:#660">(</span><span style=3D"color:#000">x</span><spa=
n style=3D"color:#660">)>(</span><span style=3D"color:#000">x</span><spa=
n style=3D"color:#660">)))</span><span style=3D"color:#000"> </span><span s=
tyle=3D"color:#660">{</span><span style=3D"color:#000"> </span><span style=
=3D"color:#008">return</span><span style=3D"color:#000"> twice</span><span =
style=3D"color:#660">(</span><span style=3D"color:#000">std</span><span sty=
le=3D"color:#660">::</span><span style=3D"color:#000">forward</span><span s=
tyle=3D"color:#660"><</span><span style=3D"color:#008">decltype</span><s=
pan style=3D"color:#660">(</span><span style=3D"color:#000">x</span><span s=
tyle=3D"color:#660">)<wbr>>(</span><span style=3D"color:#000">x</span><s=
pan style=3D"color:#660">));</span><span style=3D"color:#000"> </span><span=
style=3D"color:#660">}</span><span style=3D"color:#000"><br></span><span s=
tyle=3D"color:#660">[](</span><span style=3D"color:#008">auto</span><span s=
tyle=3D"color:#660">&&</span><span style=3D"color:#000"> x</span><s=
pan style=3D"color:#660">)</span><span style=3D"color:#000"> </span><span s=
tyle=3D"color:#660">=3D></span><span style=3D"color:#000"> twice</span><=
span style=3D"color:#660">(</span><font color=3D"#000000"><span style=3D"co=
lor:#000">std</span><span style=3D"color:#660">::</span><span style=3D"colo=
r:#000">forward</span><span style=3D"color:#660"><</span><span style=3D"=
color:#008">decltype</span><span style=3D"color:#660">(</span><span style=
=3D"color:#000">x</span><span style=3D"color:#660">)<wbr>>(</span><span =
style=3D"color:#000">x</span><span style=3D"color:#660">)</span></font><spa=
n style=3D"color:#660">);</span><span style=3D"color:#000"><br></span><span=
style=3D"color:#660">[](</span><span style=3D"color:#000">x</span><span st=
yle=3D"color:#660">)</span><span style=3D"color:#000"> </span><span style=
=3D"color:#660">=3D></span><span style=3D"color:#000"> twice</span><span=
style=3D"color:#660">(</span><font color=3D"#000000"><span style=3D"color:=
#000">std</span><span style=3D"color:#660">::</span><span style=3D"color:#0=
00">forward</span><span style=3D"color:#660"><</span><span style=3D"colo=
r:#008">decltype</span><span style=3D"color:#660">(</span><span style=3D"co=
lor:#000">x</span><span style=3D"color:#660">)<wbr>>(</span><span style=
=3D"color:#000">x</span><span style=3D"color:#660">)</span></font><span sty=
le=3D"color:#660">);</span><span style=3D"color:#000"><br></span><span styl=
e=3D"color:#660">[](</span><span style=3D"color:#000">x</span><span style=
=3D"color:#660">)</span><span style=3D"color:#000"> </span><span style=3D"c=
olor:#660">=3D></span><span style=3D"color:#000"> twice</span><span styl=
e=3D"color:#660">(>></span><span style=3D"color:#000">x</span><span s=
tyle=3D"color:#660">);</span></div></code></div><div><br></div>You still ha=
ve to mark the argument as being forwarded.<br>=C2=A0</div></div></blockquo=
te><div><br>Fair enough, but I still hate using `>>` for that ;)<br><=
br>Granted, I don't have a better alternative at the moment...<br></div=
></div></blockquote></div>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
nBmFwWZTAgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:&=
#39;;return true;" onclick=3D"this.href=3D'javascript:';return true=
;">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"nBmFwWZTAgAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'=
;javascript:';return true;">std-pr...@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/dfe4984d-c953-4cc2-b439-2c6351c56221%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank" =
rel=3D"nofollow" onmousedown=3D"this.href=3D'https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/dfe4984d-c953-4cc2-b439-2c6351c56221%40i=
socpp.org?utm_medium\x3demail\x26utm_source\x3dfooter';return true;" on=
click=3D"this.href=3D'https://groups.google.com/a/isocpp.org/d/msgid/st=
d-proposals/dfe4984d-c953-4cc2-b439-2c6351c56221%40isocpp.org?utm_medium\x3=
demail\x26utm_source\x3dfooter';return true;">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/dfe4984d-c953-4cc2-<wbr>b439-=
2c6351c56221%40isocpp.org</a><wbr>.<br>
<br></div></div>
</blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/09675607-2ece-4afb-ab60-c1f80fbb7050%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/09675607-2ece-4afb-ab60-c1f80fbb7050=
%40isocpp.org</a>.<br />
------=_Part_1371_1602982379.1476551941750--
------=_Part_1370_469888223.1476551941749--
.
Author: Barry Revzin <barry.revzin@gmail.com>
Date: Sat, 15 Oct 2016 10:47:32 -0700 (PDT)
Raw View
------=_Part_1469_1365567190.1476553652138
Content-Type: multipart/alternative;
boundary="----=_Part_1470_1476797185.1476553652138"
------=_Part_1470_1476797185.1476553652138
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Going to reply to a bunch of people in one go:
=20
Nicol:
> Since you're creating a new operator, I would like to have some=20
> explanation of the precedence of this operator. I imagine that it would b=
e at=20
> precedence level 3=20
> <http://www.google.com/url?q=3Dhttp%3A%2F%2Fen.cppreference.com%2Fw%2Fcpp=
%2Flanguage%2Foperator_precedence&sa=3DD&sntz=3D1&usg=3DAFQjCNGEhknTTxNLIac=
H6QNBGSQLRFvw7A>,=20
> along with the other prefix operators.
>
> Yes, that would seem about right. And >> would be usable anywhere.=20
=20
Nicol:
> You also don't make it clear if the new abbreviated lambda parameter=20
> declaration requires the use of `=3D>` or not. That is, is it legal to do=
=20
> `[](x) {foo(x + 1);}`? Similarly, it isn't completely clear that `>>` can=
=20
> be used outside of the context of terse lambda expressions.
>
One problem that comes up with allowing for omitting the type (and this is=
=20
as true for the =3D> notation as it is for the normal lambda notation) is a=
=20
potential ambiguity:
[](arg ) { return sizeof(arg); }
is this a lambda taking a single unnamed variable of type arg and returning=
=20
that size, or is it a lambda taking a forwarding reference named arg and=20
returning the size of the type it refers to? To allow the terse naming for=
=20
normal lambdas, it would have to be the latter - but there are undoubtedly=
=20
lambdas in existence that take unnamed arguments. And this could break code=
=20
if that code relies on side effects of constructing those arguments. Or at=
=20
the very least will suddenly start having warnings about unused variables.=
=20
I would like for the terse syntax to be used anywhere, but this case=20
concerns me.=20
=20
Lorro:
> What do you think?
I do not understand your use of : and what it means in the context of=20
lambdas, sorry.
Tony:
> Like `x + 1` is a 'lifted' or to-be-inlined expression, a lambda where x=
=20
> is auto-forwarded because =E2=80=8Eyou don't get a new type at all, just =
a direct=20
> substitution of x. Or maybe `x` means forward x.=20
This reminds me a bit of how Scala allows you to do lambdas with _. There=
=20
you can write:
transform(first, last, _ + 1);
sort(first, last, _ > _);
to mean:
transform(first, last, [&](auto&& x) { return x+1; });
sort(first, last, [&](auto&& a, auto&& b) { return a > b; });
I may be wrong about the implicit capture by reference, but at least=20
something to that effect.=20
It's easy to come up with examples where this syntax is pretty awesome. But=
=20
once you get passed exceedingly simple, there are a lot of questions that=
=20
come up. How do you take one argument and pass it twice to a different=20
function (which means you can't forward it twice)? How do you invert the=20
input arguments? How do you deal with captures of expressions? My version=
=20
0.1 of this proposal was based on the _ syntax, but it got buried pretty=20
quickly under a pile of unanswerable questions.=20
--=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/32bc0deb-687f-4288-9edc-52ecfcb7f719%40isocpp.or=
g.
------=_Part_1470_1476797185.1476553652138
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Going to reply to a bunch of people in one go:</div><=
div><br></div><div>=C2=A0</div><div>Nicol:</div><blockquote class=3D"gmail_=
quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pa=
dding-left: 1ex;"><div lang=3D"en-US" style=3D"background-color:rgb(255,255=
,255);line-height:initial"><div>Since you're creating a new operator, I=
would like to have some explanation of the precedence of this operator. I =
imagine that it would be=C2=A0<a href=3D"http://www.google.com/url?q=3Dhttp=
%3A%2F%2Fen.cppreference.com%2Fw%2Fcpp%2Flanguage%2Foperator_precedence&=
;sa=3DD&sntz=3D1&usg=3DAFQjCNGEhknTTxNLIacH6QNBGSQLRFvw7A" target=
=3D"_blank" rel=3D"nofollow" style=3D"cursor: pointer;">at precedence level=
3</a>, along with the other prefix operators.<br><br></div></div></blockqu=
ote><div>Yes, that would seem about right. =C2=A0And >> would be usab=
le anywhere.=C2=A0</div><div><br></div><div>=C2=A0</div><div>Nicol:</div><b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;"><div lang=3D"en-US" style=3D"bac=
kground-color:rgb(255,255,255);line-height:initial"><div>You also don't=
make it clear if the new abbreviated lambda parameter declaration requires=
the use of `=3D>` or not. That is, is it legal to do `[](x) {foo(x + 1)=
;}`? Similarly, it isn't completely clear that `>>` can be used o=
utside of the context of terse lambda expressions.<br></div></div></blockqu=
ote><div><br></div><div>One problem that comes up with allowing for omittin=
g the type (and this is as true for the =3D> notation as it is for the n=
ormal lambda notation) is a potential ambiguity:</div><div><br></div><div><=
div class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); bo=
rder-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; wor=
d-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subprettypri=
nt"><span style=3D"color: #660;" class=3D"styled-by-prettify">[](</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify">arg </span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">)</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> </span><font color=3D"#666600"><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">return</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" clas=
s=3D"styled-by-prettify">sizeof</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify">arg</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">);</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span></fo=
nt></div></code></div><div><br></div>is this a lambda taking a single unnam=
ed variable of type <font face=3D"courier new, monospace">arg </font>and re=
turning that size, or is it a lambda taking a forwarding reference named <f=
ont face=3D"courier new, monospace">arg </font>and returning the size of th=
e type it refers to? To allow the terse naming for normal lambdas, it would=
have to be the latter - but there are undoubtedly lambdas in existence tha=
t take unnamed arguments. And this could break code if that code relies on =
side effects of constructing those arguments. Or at the very least will sud=
denly start having warnings about unused variables.=C2=A0</div><div><br></d=
iv><div>I would like for the terse syntax to be used anywhere, but this cas=
e concerns me.=C2=A0<br>=C2=A0</div><div>Lorro:</div><blockquote class=3D"g=
mail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(=
204, 204, 204); padding-left: 1ex;">What do you think?</blockquote><div><br=
></div><div>I do not understand your use of : and what it means in the cont=
ext of lambdas, sorry.</div><div><br></div><div>Tony:</div><blockquote clas=
s=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px soli=
d rgb(204, 204, 204); padding-left: 1ex;"> Like `x + 1` is a 'lifted=
9; or to-be-inlined expression, a lambda where x is auto-forwarded because =
=E2=80=8Eyou don't get a new type at all, just a direct substitution of=
x. Or maybe `x` means forward x. </blockquote><div><br></div><div>This re=
minds me a bit of how Scala allows you to do lambdas with _. There you can =
write:</div><div><br></div><div><div class=3D"prettyprint" style=3D"backgro=
und-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-sty=
le: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"pretty=
print"><div class=3D"subprettyprint"><span style=3D"color: #000;" class=3D"=
styled-by-prettify">transform</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify">first</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </s=
pan><span style=3D"color: #008;" class=3D"styled-by-prettify">last</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> _ </span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">+</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> </span><span style=3D"color: #066;" class=
=3D"styled-by-prettify">1</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">);</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"><br>sort</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">firs=
t</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span styl=
e=3D"color: #008;" class=3D"styled-by-prettify">last</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">,</span><font color=3D"#000000"><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> _ </span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">></span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> _</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">);</span></font></div></code></div><div=
><br></div>to mean:</div><div><br></div><div><div class=3D"prettyprint" sty=
le=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187=
); border-style: solid; border-width: 1px; word-wrap: break-word;"><code cl=
ass=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #00=
0;" class=3D"styled-by-prettify">transform</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">first</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify"=
>last</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">[&](</span><span st=
yle=3D"color: #008;" class=3D"styled-by-prettify">auto</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;" class=3D"styled-by-prettify">)</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">=
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><spa=
n style=3D"color: #066;" class=3D"styled-by-prettify">1</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">});</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br>sort</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify">first</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">last</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">[&](</span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">auto</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">&&</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> a</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: #008;" class=3D"styled-by-p=
rettify">auto</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">&&</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> b</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #0=
08;" class=3D"styled-by-prettify">return</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify"> a</span><font color=3D"#666600"><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"> b</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">});</span></font></div></code></div><br>I may be wrong about the impl=
icit capture by reference, but at least something to that effect.=C2=A0</di=
v><div><br></div><div>It's easy to come up with examples where this syn=
tax is pretty awesome. But once you get passed exceedingly simple, there ar=
e a lot of questions that come up. How do you take one argument and pass it=
twice to a different function (which means you can't forward it twice)=
? How do you invert the input arguments? How do you deal with captures of e=
xpressions? My version 0.1 of this proposal was based on the _ syntax, but =
it got buried pretty quickly under a pile of unanswerable questions.=C2=A0<=
/div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/32bc0deb-687f-4288-9edc-52ecfcb7f719%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/32bc0deb-687f-4288-9edc-52ecfcb7f719=
%40isocpp.org</a>.<br />
------=_Part_1470_1476797185.1476553652138--
------=_Part_1469_1365567190.1476553652138--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sat, 15 Oct 2016 11:15:57 -0700 (PDT)
Raw View
------=_Part_702_587574348.1476555357386
Content-Type: multipart/alternative;
boundary="----=_Part_703_1001324964.1476555357387"
------=_Part_703_1001324964.1476555357387
Content-Type: text/plain; charset=UTF-8
On Saturday, October 15, 2016 at 1:47:32 PM UTC-4, Barry Revzin wrote:
>
> Going to reply to a bunch of people in one go:
>
>
> Nicol:
>
>> Since you're creating a new operator, I would like to have some
>> explanation of the precedence of this operator. I imagine that it would be at
>> precedence level 3
>> <http://www.google.com/url?q=http%3A%2F%2Fen.cppreference.com%2Fw%2Fcpp%2Flanguage%2Foperator_precedence&sa=D&sntz=1&usg=AFQjCNGEhknTTxNLIacH6QNBGSQLRFvw7A>,
>> along with the other prefix operators.
>>
>> Yes, that would seem about right. And >> would be usable anywhere.
>
>
> Nicol:
>
>> You also don't make it clear if the new abbreviated lambda parameter
>> declaration requires the use of `=>` or not. That is, is it legal to do
>> `[](x) {foo(x + 1);}`? Similarly, it isn't completely clear that `>>` can
>> be used outside of the context of terse lambda expressions.
>>
>
> One problem that comes up with allowing for omitting the type (and this is
> as true for the => notation as it is for the normal lambda notation) is a
> potential ambiguity:
>
> [](arg ) { return sizeof(arg); }
>
> is this a lambda taking a single unnamed variable of type arg and
> returning that size, or is it a lambda taking a forwarding reference named arg
> and returning the size of the type it refers to? To allow the terse naming
> for normal lambdas, it would have to be the latter - but there are
> undoubtedly lambdas in existence that take unnamed arguments. And this
> could break code if that code relies on side effects of constructing those
> arguments. Or at the very least will suddenly start having warnings about
> unused variables.
>
> I would like for the terse syntax to be used anywhere, but this case
> concerns me.
>
What should concern you much more is that you can't really make this based
on =>. To do that would require lots and lots of look-ahead, and we don't
want parsers to have to do that. So whatever the solution will be, it must
be generic.
Worst-case scenario, if we can't make a naked identifier work, we can have
people use `&&` and `&` (or `const&`/`const&&`). If you want a value
parameter, you have to specify a type/`auto`. It's not as short as it could
be, but it's still shorter than having to type `auto&&`.
And of course, you can do `...&&args`.
--
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/c49bcef4-9e47-49a5-9517-ab584b535b63%40isocpp.org.
------=_Part_703_1001324964.1476555357387
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Saturday, October 15, 2016 at 1:47:32 PM UTC-4,=
Barry Revzin wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div>Going to reply to a bunch of people in one go:</div><div><br>=
</div><div>=C2=A0</div><div>Nicol:</div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:=
1ex"><div style=3D"background-color:rgb(255,255,255);line-height:initial" l=
ang=3D"en-US"><div>Since you're creating a new operator, I would like t=
o have some explanation of the precedence of this operator. I imagine that =
it would be=C2=A0<a href=3D"http://www.google.com/url?q=3Dhttp%3A%2F%2Fen.c=
ppreference.com%2Fw%2Fcpp%2Flanguage%2Foperator_precedence&sa=3DD&s=
ntz=3D1&usg=3DAFQjCNGEhknTTxNLIacH6QNBGSQLRFvw7A" rel=3D"nofollow" targ=
et=3D"_blank" onmousedown=3D"this.href=3D'http://www.google.com/url?q\x=
3dhttp%3A%2F%2Fen.cppreference.com%2Fw%2Fcpp%2Flanguage%2Foperator_preceden=
ce\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGEhknTTxNLIacH6QNBGSQLRFvw7A'=
;;return true;" onclick=3D"this.href=3D'http://www.google.com/url?q\x3d=
http%3A%2F%2Fen.cppreference.com%2Fw%2Fcpp%2Flanguage%2Foperator_precedence=
\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGEhknTTxNLIacH6QNBGSQLRFvw7A';=
return true;">at precedence level 3</a>, along with the other prefix operat=
ors.<br><br></div></div></blockquote><div>Yes, that would seem about right.=
=C2=A0And >> would be usable anywhere.=C2=A0</div><div><br></div><di=
v>=C2=A0</div><div>Nicol:</div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div=
style=3D"background-color:rgb(255,255,255);line-height:initial" lang=3D"en=
-US"><div>You also don't make it clear if the new abbreviated lambda pa=
rameter declaration requires the use of `=3D>` or not. That is, is it le=
gal to do `[](x) {foo(x + 1);}`? Similarly, it isn't completely clear t=
hat `>>` can be used outside of the context of terse lambda expressio=
ns.<br></div></div></blockquote><div><br></div><div>One problem that comes =
up with allowing for omitting the type (and this is as true for the =3D>=
notation as it is for the normal lambda notation) is a potential ambiguity=
:</div><div><br></div><div><div style=3D"background-color:rgb(250,250,250);=
border-color:rgb(187,187,187);border-style:solid;border-width:1px;word-wrap=
:break-word"><code><div><span style=3D"color:#660">[](</span><span style=3D=
"color:#000">arg </span><span style=3D"color:#660">)</span><span style=3D"c=
olor:#000"> </span><font color=3D"#666600"><span style=3D"color:#660">{</sp=
an><span style=3D"color:#000"> </span><span style=3D"color:#008">return</sp=
an><span style=3D"color:#000"> </span><span style=3D"color:#008">sizeof</sp=
an><span style=3D"color:#660">(</span><span style=3D"color:#000">arg</span>=
<span style=3D"color:#660">);</span><span style=3D"color:#000"> </span><spa=
n style=3D"color:#660">}</span></font></div></code></div><div><br></div>is =
this a lambda taking a single unnamed variable of type <font face=3D"courie=
r new, monospace">arg </font>and returning that size, or is it a lambda tak=
ing a forwarding reference named <font face=3D"courier new, monospace">arg =
</font>and returning the size of the type it refers to? To allow the terse =
naming for normal lambdas, it would have to be the latter - but there are u=
ndoubtedly lambdas in existence that take unnamed arguments. And this could=
break code if that code relies on side effects of constructing those argum=
ents. Or at the very least will suddenly start having warnings about unused=
variables.=C2=A0</div><div><br></div><div>I would like for the terse synta=
x to be used anywhere, but this case concerns me.<br></div></div></blockquo=
te><div><br>What should concern you much more is that you can't really =
make this based on =3D>. To do that would require lots and lots of look-=
ahead, and we don't want parsers to have to do that. So whatever the so=
lution will be, it must be generic.<br><br>Worst-case scenario, if we can&#=
39;t make a naked identifier work, we can have people use `&&` and =
`&` (or `const&`/`const&&`). If you want a value parameter,=
you have to specify a type/`auto`. It's not as short as it could be, b=
ut it's still shorter than having to type `auto&&`.<br><br>And =
of course, you can do `...&&args`.</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/c49bcef4-9e47-49a5-9517-ab584b535b63%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c49bcef4-9e47-49a5-9517-ab584b535b63=
%40isocpp.org</a>.<br />
------=_Part_703_1001324964.1476555357387--
------=_Part_702_587574348.1476555357386--
.
Author: szollosi.lorand@gmail.com
Date: Sat, 15 Oct 2016 12:43:26 -0700 (PDT)
Raw View
------=_Part_1524_19655479.1476560606620
Content-Type: multipart/alternative;
boundary="----=_Part_1525_895520703.1476560606620"
------=_Part_1525_895520703.1476560606620
Content-Type: text/plain; charset=UTF-8
Hi,
>
> This reminds me a bit of how Scala allows you to do lambdas with _. There
> you can write:
>
> transform(first, last, _ + 1);
> sort(first, last, _ > _);
>
> to mean:
>
> transform(first, last, [&](auto&& x) { return x+1; });
> sort(first, last, [&](auto&& a, auto&& b) { return a > b; });
>
> I may be wrong about the implicit capture by reference, but at least
> something to that effect.
>
We used to have this with std::placeholders::_1 , _2, .. & bind() and I'm
glad we can replace it. Naming your argument correctly means you're halfway
there. search(needle, haystack) looks way better than search(_1, _2).
(which is which?)
One thing you might do - and what a part of the community will continuously
oppose - is to simply *not* declare the arguments. Granted, this requires
passing arguments by name - something that's due for a long time now; but
then, any variable that's undefined (or, if you wish, any captured or
undefined variable) is automatically assumed to be auto&&. This requires
something like `expr` to differentiate from normal functions.
Thanks,
-lorro
--
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/5d40d6da-42bc-4de9-98bc-81bad2982070%40isocpp.org.
------=_Part_1525_895520703.1476560606620
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Hi,<br><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"><br><d=
iv>This reminds me a bit of how Scala allows you to do lambdas with _. Ther=
e you can write:</div><div><br></div><div><div style=3D"background-color:rg=
b(250,250,250);border-color:rgb(187,187,187);border-style:solid;border-widt=
h:1px;word-wrap:break-word"><code><div><span style=3D"color:#000">transform=
</span><span style=3D"color:#660">(</span><span style=3D"color:#000">first<=
/span><span style=3D"color:#660">,</span><span style=3D"color:#000"> </span=
><span style=3D"color:#008">last</span><span style=3D"color:#660">,</span><=
span style=3D"color:#000"> _ </span><span style=3D"color:#660">+</span><spa=
n style=3D"color:#000"> </span><span style=3D"color:#066">1</span><span sty=
le=3D"color:#660">);</span><span style=3D"color:#000"><br>sort</span><span =
style=3D"color:#660">(</span><span style=3D"color:#000">first</span><span s=
tyle=3D"color:#660">,</span><span style=3D"color:#000"> </span><span style=
=3D"color:#008">last</span><span style=3D"color:#660">,</span><font color=
=3D"#000000"><span style=3D"color:#000"> _ </span><span style=3D"color:#660=
">></span><span style=3D"color:#000"> _</span><span style=3D"color:#660"=
>);</span></font></div></code></div><div><br></div>to mean:</div><div><br><=
/div><div><div style=3D"background-color:rgb(250,250,250);border-color:rgb(=
187,187,187);border-style:solid;border-width:1px;word-wrap:break-word"><cod=
e><div><span style=3D"color:#000">transform</span><span style=3D"color:#660=
">(</span><span style=3D"color:#000">first</span><span style=3D"color:#660"=
>,</span><span style=3D"color:#000"> </span><span style=3D"color:#008">last=
</span><span style=3D"color:#660">,</span><span style=3D"color:#000"> </spa=
n><span style=3D"color:#660">[&](</span><span style=3D"color:#008">auto=
</span><span style=3D"color:#660">&&</span><span style=3D"color:#00=
0"> x</span><span style=3D"color:#660">)</span><span style=3D"color:#000"> =
</span><span style=3D"color:#660">{</span><span style=3D"color:#000"> </spa=
n><span style=3D"color:#008">return</span><span style=3D"color:#000"> x</sp=
an><span style=3D"color:#660">+</span><span style=3D"color:#066">1</span><s=
pan style=3D"color:#660">;</span><span style=3D"color:#000"> </span><span s=
tyle=3D"color:#660">});</span><span style=3D"color:#000"><br>sort</span><sp=
an style=3D"color:#660">(</span><span style=3D"color:#000">first</span><spa=
n style=3D"color:#660">,</span><span style=3D"color:#000"> </span><span sty=
le=3D"color:#008">last</span><span style=3D"color:#660">,</span><span style=
=3D"color:#000"> </span><span style=3D"color:#660">[&](</span><span sty=
le=3D"color:#008">auto</span><span style=3D"color:#660">&&</span><s=
pan style=3D"color:#000"> a</span><span style=3D"color:#660">,</span><span =
style=3D"color:#000"> </span><span style=3D"color:#008">auto</span><span st=
yle=3D"color:#660">&&</span><span style=3D"color:#000"> b</span><sp=
an style=3D"color:#660">)</span><span style=3D"color:#000"> </span><span st=
yle=3D"color:#660">{</span><span style=3D"color:#000"> </span><span style=
=3D"color:#008">return</span><span style=3D"color:#000"> a</span><font colo=
r=3D"#666600"><span style=3D"color:#000"> </span><span style=3D"color:#660"=
>></span><span style=3D"color:#000"> b</span><span style=3D"color:#660">=
;</span><span style=3D"color:#000"> </span><span style=3D"color:#660">});</=
span></font></div></code></div><br>I may be wrong about the implicit captur=
e by reference, but at least something to that effect. <br></div></div></bl=
ockquote><div><br>We used to have this with std::placeholders::_1 , _2, .. =
& bind() and I'm glad we can replace it. Naming your argument corre=
ctly means you're halfway there. search(needle, haystack) looks way bet=
ter than search(_1, _2). (which is which?)<br>One thing you might do - and =
what a part of the community will continuously oppose - is to simply <i>not=
</i> declare the arguments. Granted, this requires passing arguments by nam=
e - something that's due for a long time now; but then, any variable th=
at's undefined (or, if you wish, any captured or undefined variable) is=
automatically assumed to be auto&&. This requires something like `=
expr` to differentiate from normal functions.<br><br>Thanks,<br>-lorro<br><=
/div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/5d40d6da-42bc-4de9-98bc-81bad2982070%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5d40d6da-42bc-4de9-98bc-81bad2982070=
%40isocpp.org</a>.<br />
------=_Part_1525_895520703.1476560606620--
------=_Part_1524_19655479.1476560606620--
.
Author: szollosi.lorand@gmail.com
Date: Sat, 15 Oct 2016 14:40:56 -0700 (PDT)
Raw View
------=_Part_1362_561287952.1476567656854
Content-Type: multipart/alternative;
boundary="----=_Part_1363_1660002876.1476567656854"
------=_Part_1363_1660002876.1476567656854
Content-Type: text/plain; charset=UTF-8
Lorro:
>
> What do you think?
>
>
> I do not understand your use of : and what it means in the context of
> lambdas, sorry.
>
TL;DR version is, :x+1 equals [&]`x + 1`; furthermore, y+1 : x+1 equals z
such that z.first equals [&]`y+1` and z.second equals [&]`x+1`.
You can define ?:, &&, || in terms of the above; in fact, this is derived
from what ?: is. You might let :(auto&& x) x+1 into the syntax - or any of
the abbrev.s discussed.
You can't really get shorter than this, because this is just one character
expressing this all :). Furthermore, it's in line with what ?: is now.
Thanks,
-lorro
--
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/23ceccce-6f4c-4811-8ff6-4da12cd763fe%40isocpp.org.
------=_Part_1363_1660002876.1476567656854
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Lorro:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div di=
r=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8=
ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">What do you thi=
nk?</blockquote><div><br></div><div>I do not understand your use of : and w=
hat it means in the context of lambdas, sorry.</div></div></blockquote><div=
>TL;DR version is, :x+1 equals [&]`x + 1`; furthermore, y+1 : x+1 equal=
s z such that z.first equals [&]`y+1` and z.second equals [&]`x+1`.=
<br>You can define ?:, &&, || in terms of the above; in fact, this =
is derived from what ?: is. You might let :(auto&& x) x+1 into the =
syntax - or any of the abbrev.s discussed.<br>You can't really get shor=
ter than this, because this is just one character expressing this all :). F=
urthermore, it's in line with what ?: is now.<br><br>Thanks,<br>-lorro<=
br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/23ceccce-6f4c-4811-8ff6-4da12cd763fe%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/23ceccce-6f4c-4811-8ff6-4da12cd763fe=
%40isocpp.org</a>.<br />
------=_Part_1363_1660002876.1476567656854--
------=_Part_1362_561287952.1476567656854--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sat, 15 Oct 2016 15:28:07 -0700 (PDT)
Raw View
------=_Part_1317_26397106.1476570487567
Content-Type: multipart/alternative;
boundary="----=_Part_1318_356234000.1476570487567"
------=_Part_1318_356234000.1476570487567
Content-Type: text/plain; charset=UTF-8
On Saturday, October 15, 2016 at 5:40:57 PM UTC-4, szollos...@gmail.com
wrote:
>
> Lorro:
>>
>> What do you think?
>>
>>
>> I do not understand your use of : and what it means in the context of
>> lambdas, sorry.
>>
> TL;DR version is, :x+1 equals [&]`x + 1`; furthermore, y+1 : x+1 equals z
> such that z.first equals [&]`y+1` and z.second equals [&]`x+1`.
> You can define ?:, &&, || in terms of the above; in fact, this is derived
> from what ?: is. You might let :(auto&& x) x+1 into the syntax - or any of
> the abbrev.s discussed.
> You can't really get shorter than this, because this is just one character
> expressing this all :). Furthermore, it's in line with what ?: is now.
>
Except that's not what ?: does. If your back-tick things create lambdas,
then that's very different from how ?: works. And if your back-tick things
don't create lambdas, then it's not clear what's going on.
--
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/fdbaaed1-870e-41a1-bbe8-307da5d97b00%40isocpp.org.
------=_Part_1318_356234000.1476570487567
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Saturday, October 15, 2016 at 5:40:57 PM UTC-4,=
szollos...@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"marg=
in: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><d=
iv dir=3D"ltr">Lorro:<blockquote class=3D"gmail_quote" style=3D"margin:0;ma=
rgin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"lt=
r"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord=
er-left:1px solid rgb(204,204,204);padding-left:1ex">What do you think?</bl=
ockquote><div><br></div><div>I do not understand your use of : and what it =
means in the context of lambdas, sorry.</div></div></blockquote><div>TL;DR =
version is, :x+1 equals [&]`x + 1`; furthermore, y+1 : x+1 equals z suc=
h that z.first equals [&]`y+1` and z.second equals [&]`x+1`.<br>You=
can define ?:, &&, || in terms of the above; in fact, this is deri=
ved from what ?: is. You might let :(auto&& x) x+1 into the syntax =
- or any of the abbrev.s discussed.<br>You can't really get shorter tha=
n this, because this is just one character expressing this all :). Furtherm=
ore, it's in line with what ?: is now.<br></div></div></blockquote><div=
><br>Except that's not what ?: does. If your back-tick things create la=
mbdas, then that's very different from how ?: works. And if your back-t=
ick things don't create lambdas, then it's not clear what's goi=
ng on. <br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/fdbaaed1-870e-41a1-bbe8-307da5d97b00%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/fdbaaed1-870e-41a1-bbe8-307da5d97b00=
%40isocpp.org</a>.<br />
------=_Part_1318_356234000.1476570487567--
------=_Part_1317_26397106.1476570487567--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Sun, 16 Oct 2016 19:35:07 +0200
Raw View
This is a multi-part message in MIME format.
--------------82606F54529F4BD28AA95B18
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 15/10/2016 =C3=A0 03:33, Barry Revzin a =C3=A9crit :
>
>
> On Tuesday, October 11, 2016 at 12:32:57 PM UTC-5, Barry Revzin wrote:
>
> Here is a contrasting proposal for how to handle overload sets as
> function arguments. While a lot more verbose in the simple case of
> just naming a function (where instead of just naming the function
> you have to actually enumerate the arguments list twice), I think
> it offers more flexibility in writing short lambdas. There are
> some motivating examples in the proposal. It's also getting pretty
> verbose to write correct generic functions with regards to SFINAE
> and noexcept, so this attempts to make it a little bit easier - at
> least in the easy case.
>
> Also I'm proposing a shorter syntax for forwarding arguments. I
> picked unary>> because it looks like moving something forward but
> really anything shorter would be nice. std::forward<Arg>(arg) is
> particularly verbose, especially in a generic lambda where you
> have to write std::forward<decltype(arg)>(arg), where the actual
> forwarding just dominates the code itself.
>
>
> Here's an updated draft. I've dropped the version of the syntax that=20
> allows for the omission of [] and (). At best, that saved four=20
> characters for single-argument no-capture lambdas, which is a small=20
> amount of the overall character savings, and seems hardly worth the=20
> added complexity in parsing. I actually defined >>expr (which had not=20
> been the case before) and extend the proposal to apply the same idea=20
> for function templates.
Hi,
Have you considered the same thing for functions?
auto fct(auto&& x) =3D> test(x);
shall be exactly equivalent to the function:
auto fct(auto&& x) noexcept(noexcept(test(x))) -> decltype(test(x)) {
return test(x);
}
Vicente
--=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/d859833b-3acf-a2c3-d50f-a058417d1a90%40wanadoo.f=
r.
--------------82606F54529F4BD28AA95B18
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
<div class=3D"moz-cite-prefix">Le 15/10/2016 =C3=A0 03:33, Barry Revzin=
a
=C3=A9crit=C2=A0:<br>
</div>
<blockquote
cite=3D"mid:6341edd7-7e49-43e2-af64-3ac04d3a6696@isocpp.org"
type=3D"cite">
<div dir=3D"ltr"><br>
<br>
On Tuesday, October 11, 2016 at 12:32:57 PM UTC-5, Barry Revzin
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">Here is a contrasting proposal for how to
handle overload sets as function arguments. While a lot more
verbose in the simple case of just naming a function (where
instead of just naming the function you have to actually
enumerate the arguments list twice), I think it offers more
flexibility in writing short lambdas. There are some
motivating examples in the proposal. It's also getting
pretty verbose to write correct generic functions with
regards to SFINAE and noexcept, so this attempts to make it
a little bit easier - at least in the easy case.=C2=A0
<div>
<div><br>
</div>
<div>Also I'm proposing a shorter syntax for forwarding
arguments. I picked unary>> because it looks like
moving something forward but really anything shorter
would be nice. <font face=3D"courier new, monospace">std::f=
orward<Arg>(arg)</font>
is particularly verbose, especially in a generic lambda
where you have to write <font face=3D"courier new,
monospace">std::forward<decltype(arg)>(<wbr>arg)</f=
ont><font
face=3D"arial, sans-serif">, where the actual forwarding
just dominates the code itself.=C2=A0</font></div>
<div><br>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>Here's an updated draft. I've dropped the version of the
syntax that allows for the omission of [] and (). At best,
that saved four characters for single-argument no-capture
lambdas, which is a small amount of the overall character
savings, and seems hardly worth the added complexity in
parsing. I actually defined >>expr (which had not been
the case before) and extend the proposal to apply the same
idea for function templates.=C2=A0</div>
</div>
</blockquote>
<br>
Hi,<br>
<br>
Have you considered the same thing for functions?<br>
<br>
<meta http-equiv=3D"content-type" content=3D"text/html; charset=3Dutf-8=
">
<blockquote>
<pre>auto fct(auto&& x) =3D> test(x);
</pre>
</blockquote>
shall be exactly equivalent to the function:
<blockquote>
<pre>auto fct(auto&& x) noexcept(noexcept(test(x))) -> dec=
ltype(test(x)) {
return test(x);
}
</pre>
</blockquote>
Vicente<br>
</body>
</html>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/d859833b-3acf-a2c3-d50f-a058417d1a90%=
40wanadoo.fr?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d859833b-3acf-a2c3-d50f-a058417d1a90=
%40wanadoo.fr</a>.<br />
--------------82606F54529F4BD28AA95B18--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sun, 16 Oct 2016 11:56:19 -0700 (PDT)
Raw View
------=_Part_1550_285516074.1476644179448
Content-Type: multipart/alternative;
boundary="----=_Part_1551_191555886.1476644179448"
------=_Part_1551_191555886.1476644179448
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Sunday, October 16, 2016 at 1:35:10 PM UTC-4, Vicente J. Botet Escriba=
=20
wrote:
>
> Le 15/10/2016 =C3=A0 03:33, Barry Revzin a =C3=A9crit :
>
>
>
> On Tuesday, October 11, 2016 at 12:32:57 PM UTC-5, Barry Revzin wrote:=20
>>
>> Here is a contrasting proposal for how to handle overload sets as=20
>> function arguments. While a lot more verbose in the simple case of just=
=20
>> naming a function (where instead of just naming the function you have to=
=20
>> actually enumerate the arguments list twice), I think it offers more=20
>> flexibility in writing short lambdas. There are some motivating examples=
in=20
>> the proposal. It's also getting pretty verbose to write correct generic=
=20
>> functions with regards to SFINAE and noexcept, so this attempts to make =
it=20
>> a little bit easier - at least in the easy case. =20
>>
>> Also I'm proposing a shorter syntax for forwarding arguments. I picked=
=20
>> unary>> because it looks like moving something forward but really anythi=
ng=20
>> shorter would be nice. std::forward<Arg>(arg) is particularly verbose,=
=20
>> especially in a generic lambda where you have to write=20
>> std::forward<decltype(arg)>(arg), where the actual forwarding just=20
>> dominates the code itself.=20
>>
>>
> Here's an updated draft. I've dropped the version of the syntax that=20
> allows for the omission of [] and (). At best, that saved four characters=
=20
> for single-argument no-capture lambdas, which is a small amount of the=20
> overall character savings, and seems hardly worth the added complexity in=
=20
> parsing. I actually defined >>expr (which had not been the case before) a=
nd=20
> extend the proposal to apply the same idea for function templates.=20
>
>
> Hi,
>
> Have you considered the same thing for functions?
>
> auto fct(auto&& x) =3D> test(x);
>
> shall be exactly equivalent to the function:=20
>
> auto fct(auto&& x) noexcept(noexcept(test(x))) -> decltype(test(x)) {
> return test(x);
> }
>
> Vicente
>
Yes, he considered that. It's right there in the document he posted ;)=20
Search for "Abbreviated Function Syntax".=20
--=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/e026552b-a49d-47ce-8fcb-2c4e5adfca7c%40isocpp.or=
g.
------=_Part_1551_191555886.1476644179448
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Sunday, October 16, 2016 at 1:35:10 PM UTC-4, V=
icente J. Botet Escriba wrote:<blockquote class=3D"gmail_quote" style=3D"ma=
rgin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
=20
=20
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
<div>Le 15/10/2016 =C3=A0 03:33, Barry Revzin a
=C3=A9crit=C2=A0:<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr"><br>
<br>
On Tuesday, October 11, 2016 at 12:32:57 PM UTC-5, Barry Revzin
wrote:
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8=
ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr">Here is a contrasting proposal for how to
handle overload sets as function arguments. While a lot more
verbose in the simple case of just naming a function (where
instead of just naming the function you have to actually
enumerate the arguments list twice), I think it offers more
flexibility in writing short lambdas. There are some
motivating examples in the proposal. It's also getting
pretty verbose to write correct generic functions with
regards to SFINAE and noexcept, so this attempts to make it
a little bit easier - at least in the easy case.=C2=A0
<div>
<div><br>
</div>
<div>Also I'm proposing a shorter syntax for forwarding
arguments. I picked unary>> because it looks like
moving something forward but really anything shorter
would be nice. <font face=3D"courier new, monospace">std::f=
orward<Arg>(arg)</font>
is particularly verbose, especially in a generic lambda
where you have to write <font face=3D"courier new,
monospace">std::forward<decltype(arg)>(<wbr>arg)</f=
ont><font face=3D"arial, sans-serif">, where the actual forwarding
just dominates the code itself.=C2=A0</font></div>
<div><br>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>Here's an updated draft. I've dropped the version of t=
he
syntax that allows for the omission of [] and (). At best,
that saved four characters for single-argument no-capture
lambdas, which is a small amount of the overall character
savings, and seems hardly worth the added complexity in
parsing. I actually defined >>expr (which had not been
the case before) and extend the proposal to apply the same
idea for function templates.=C2=A0</div>
</div>
</blockquote>
<br>
Hi,<br>
<br>
Have you considered the same thing for functions?<br>
<br>
=20
<blockquote>
<pre>auto fct(auto&& x) =3D> test(x);
</pre>
</blockquote>
shall be exactly equivalent to the function:
<blockquote>
<pre>auto fct(auto&& x) noexcept(noexcept(test(x))) -> dec=
ltype(test(x)) {
return test(x);
}
</pre>
</blockquote>
Vicente<br></div></blockquote><div><br>Yes, he considered that. It'=
s right there in the document he posted ;) Search for "Abbreviated Fun=
ction 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" 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/e026552b-a49d-47ce-8fcb-2c4e5adfca7c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e026552b-a49d-47ce-8fcb-2c4e5adfca7c=
%40isocpp.org</a>.<br />
------=_Part_1551_191555886.1476644179448--
------=_Part_1550_285516074.1476644179448--
.
Author: Barry Revzin <barry.revzin@gmail.com>
Date: Sun, 16 Oct 2016 12:28:46 -0700 (PDT)
Raw View
------=_Part_1495_1160107626.1476646126796
Content-Type: multipart/alternative;
boundary="----=_Part_1496_1591085485.1476646126796"
------=_Part_1496_1591085485.1476646126796
Content-Type: text/plain; charset=UTF-8
>
>
>>
> Yes, he considered that. It's right there in the document he posted ;)
> Search for "Abbreviated Function Syntax".
>
Yep! Although here's a rewritten version where I'm clarifying that there
are three independent proposals here: => expr, unary>>, and omitting types
in lambdas. Hopefully this'll be clearer that the intent of => is to be
used in both lambdas and functions.
--
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/3151764f-a9e7-49c4-9f32-06ea85a41a20%40isocpp.org.
------=_Part_1496_1591085485.1476646126796
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><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"><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div bgcolor=3D"#FFFFFF" text=
=3D"#000000"><br></div></blockquote><div><br>Yes, he considered that. It=
9;s right there in the document he posted ;) Search for "Abbreviated F=
unction Syntax". <br></div></div></blockquote><div><br></div><div>Yep!=
Although here's a rewritten version where I'm clarifying that ther=
e are three independent proposals here: =3D> expr, unary>>, and om=
itting types in lambdas. Hopefully this'll be clearer that the intent o=
f =3D> is to be used in both lambdas and functions.=C2=A0</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/3151764f-a9e7-49c4-9f32-06ea85a41a20%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/3151764f-a9e7-49c4-9f32-06ea85a41a20=
%40isocpp.org</a>.<br />
------=_Part_1496_1591085485.1476646126796--
------=_Part_1495_1160107626.1476646126796
Content-Type: text/html; charset=US-ASCII; name=abbrev_lambda.html
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename=abbrev_lambda.html
X-Attachment-Id: ff814712-1e13-491e-a6da-887b402b6a83
Content-ID: <ff814712-1e13-491e-a6da-887b402b6a83>
<html>
<head>
<title>abbreviated lambdas</title>
<style>
p {text-align:justify}
li {text-align:justify}
blockquote.note
{
background-color:#E0E0E0;
padding-left: 15px;
padding-right: 15px;
padding-top: 1px;
padding-bottom: 1px;
}
ins {color:#00A000}
del {color:#A00000}
code {white-space:pre;}
</style>
</head>
<body>
<address align=right>
Document number: DxxxxR0<br>
<a href="mailto:barry.revzin@gmail.com">Barry Revzin</a><br/>
2016-10-16<br/>
</address>
<hr/>
<h1 align=center>Abbreviated Lambdas for Fun and Profit</h1>
<h2>Contents</h2>
<ul>
<li><a href="#Motivation">Motivation</a></li>
<li><a href="#Proposal">Proposal</a></li>
<ul>
<li><a href="#expr"><code>=> expr</code></a></li>
<li><a href="#omit">Omitting types</a></li>
<li><a href="#unary">Unary <code>operator>></code></a></li>
</ul>
<li><a href="#Examples">Examples</a></li>
<li><a href="#Effects">Effects on Existing Code</a></li>
<li><a href="#Priors">Prior Work</a></li>
<li><a href="#Acks">Acknowledgements and References</a></li>
</ul>
<a name="Motivation"></a><h2>Motivation</h2>
<p>There are two, somewhat related motivations for an abbreviated lambda syntax. The first is to address the problem of trying to pass in overload sets as function arguments [1]:
<blockquote><pre>
template <class T>
T twice(T x) { return x + x; }
template <class I>
void f(I first, I last) {
transform(first, last, twice); // error
}
</pre></blockquote>
C++14 generic lambdas allow us a way to solve this problem by just wrapping the overloaded name in a lambda:
<blockquote><pre>
transform(first, last, [](auto&& x) {
return twice(std::forward<decltype(x)>(x));
});
</pre></blockquote>
<p>But that isn't actually correct, although it's the "obvious" code that most people would produce. It's not SFINAE-friendly and it's not <code>noexcept</code>-correct. Which could lead to avoidable errors:
<blockquote><pre>
struct Widget;
bool test(int );
bool test(Widget );
void invoke(std::function<bool(int)> ); // #1
void invoke(std::function<bool(std::string)> ); // #2
// error: unresolved overloaded function type
invoke(test);
// still error: no known conversion from std::string to int or Widget
invoke([](auto&& x) {
return test(std::forward<decltype(x)>(x));
});
</pre></blockquote>
You'd really have to write:
<blockquote><code>// OK: calls #1
<font color="blue"><b>invoke</b></font>([](auto&& <font color="blue"><b>x</b></font>) noexcept(noexcept(test(std::forward<decltype(x)>(x))))
-> decltype(test(std::forward<decltype(x)>(x)))
{
return <font color="blue"><b>test</b></font>(std::<font color="blue"><b>forward</b></font><decltype(x)>(<font color="blue"><b>x</b></font>));
});
</code></blockquote>
<p>And that's a lot to have to type. Which brings me to the second motivation: not having to write that. For simple lambdas, those lambdas whose entire body is <code>return expr;</code>, the noisy stuff you have to write to get it correct where you need to use it just drowns out the signal of what it was you wanted your lambda to do in the first place. That is assuming that I succeed in writing the same code in all three places without accidentally introducing subtle differences.
<p>Arguably the only important code in the above block is that which has been marked in <font color="blue"><b>blue</b></font>. All I want to do is <code>test(x)</code>, why so much boilerplate?
<a name="Proposal"></a><h2>Proposal</h2>
<p>This paper proposes three language extensions. The extensions themselves are independent, but together combine to allow for terse, readable, correct lambdas and functions.
<a name="expr"/><h3><code>=> expr</code></h3>
<p>This paper proposes the creation of a new lambda introducer, <code>=></code>, which allows for a single expression in the body that will be its return statement. This will synthesize a SFINAE-friendly, <code>noexcept</code>-correct lambda by doing the code triplication for you.
<p>That is, the lambda:
<blockquote><pre>
[](auto&& x) => test(x)
</pre></blockquote>
shall be exactly equivalent to the lambda:
<blockquote><pre>
[](auto&& x) noexcept(noexcept(test(x))) -> decltype(test(x)) { return test(x); }
</pre></blockquote>
When SFINAE is important, the repetition of the function body makes the code difficult to read. At best. At worst, the code becomes error-prone when one changes the body of the function while forgetting to change the body of the trailing <code>decltype</code>. Even when SFINAE is not important, for the simplest lambdas, brevity is important for readability and omitting the <code>return</code> keyword would be helpful.
<p>The code duplication or triplication in short function bodies is also a common problem that wants for a solution [3]. Consider the overloads of <code>std::begin</code> and <code>std::not_fn</code>:
<blockquote><pre>
template <typename C>
constexpr auto begin(C& cont)
-> decltype(cont.begin())
{
return cont.begin();
}
template <class F>
struct not_fn {
F f;
template <class... Args>
auto operator()(Args&&... args)
noexcept(noexcept(!std::invoke(f, std::forward<Args>(args)...)))
-> decltype(!std::invoke(f, std::forward<Args>(args)...)) {
return !std::invoke(f, std::forward<Args>(args)...);
}
// + overloads for const, etc.
};
</pre></blockquote>
which would be able to be reduced, without loss of functionality, to:
<blockquote><pre>
template <typename C>
constexpr auto begin(C& cont)
=> cont.begin();
template <class F>
struct not_fn {
F f;
template <class... Args>
auto operator()(Args&&... args)
=> !std::invoke(f, std::forward<Args>(args)...);
// + overloads for const, etc.
};
</pre></blockquote>
These shorter implementations are easier to read, easier to write, and easier to maintain.
<a name="omit" /><h3>Omission of types in lambdas</h3>
One of the motivations of generic lambdas was to use <code>auto</code> as a substitute for long type names, which helps quite a bit. But since <code>auto&&</code> has become such a regular choice of argument for lambdas, and is rarely a wrong choice, it doesn't really bestow any information to the code. This paper proposes allowing for the type to be omitted, in which case it will be assumed to be <code>auto&&</code>. That is:
<blockquote><pre>
[](x) { return x+1; }
</pre></blockquote>
shall be exactly equivalent to the lambda:
<blockquote><pre>
[](auto&& x) { return x+1; }
</pre></blockquote>
Omitted arguments can be interspersed with provided arguments, and a leading <code>...</code> will indicate a parameter pack of forwarding references.
<blockquote><pre>
[](x, int y) { return x < y; }
[](...args) => test(std::forward<decltype(args)>(args)...)
</pre></blockquote>
shall be exactly equivalent to the lambdas
<blockquote><pre>
[](auto&& x, int y) { return x < y; }
[](auto&&... args) noexcept(noexcept(test(std::forward<decltype(args)>(args)...))) -> decltype(test(std::forward<decltype(args)>(args)...)) { return test(std::forward<decltype(args)>(args)...); }
</pre></blockquote>
No default arguments will be allowed in the case of type omission, due to potential ambiguities in parsing.
<a name="unary" /><h3>Unary <code>operator>></code></h3>
<p>One of the last sources of boilerplate is <code>std::forward</code>. In a lot of generic code, the uses of <code>forward</code> overwhelm all the rest of the code, to the point where many talks and examples just omit references entirely to save space. I'm occasionally tempted to introduce a macro (<code>#define FWD(x) decltype(x)(x)</code>) which is just wrong. Unlike <code>std::move</code> and <code>std::ref</code>, which are used to do non-typical things and deserve to be visible markers for code readability, <code>std::forward</code> is very typically used in the context of using forwarding references. It does not have as clear a need to be a signpost.
<p>This paper would like to see a shorter way to forward arguments and proposes non-overloadable unary <code>operator >></code>, where <code>>>expr</code> shall be defined as <code>static_cast<decltype(expr)&&>(expr)</code>, and not overloadable.
<p>This lambda:
<blockquote><pre>
[](auto&& x) { return test(>>x); }
</pre></blockquote>
is equivalent by definition to this one:
<blockquote><pre>
[](auto&& x) { return test(std::forward<decltype(x)>(x)); }
</pre></blockquote>
This operator will have equivalent precedence to the other prefix operators, like <code>operator!</code>. While this paper is primarily focused on abbreviated lambdas, unary <code>operator>></code> will not be limited in scope to just lambdas.
<a name="Examples"></a><h2>Examples</h2>
<p> Putting all three features together, binding an overload member function, <code>func</code>, to an instance, <code>obj</code>, as a function argument is reduced from:
<blockquote><pre>
[&obj](auto&&... args) noexcept(noexcept(obj.func(std::forward<decltype(args)>(args)...))) -> decltype(obj.func(std::forward<decltype(args)>(args)...)) { return obj.func(std::forward<decltype(args)>(args)...); }
</pre></blockquote>
to
<blockquote><pre>
[&obj](...args) => obj.func(>>args...)
</pre></blockquote>
<p>That is a reduction from 211 characters to 38.
<p>Here are other examples of improved usage as compared to C++14 best practices.
<p>Sorting in decreasing order: roughly comparable typing, but arguably clearer:
<blockquote><pre>
std::sort(begin(v), end(v), std::greater<>{}); // C++14
std::sort(begin(v), end(v), [](x,y) => x > y); // this proposal
</pre></blockquote>
<p>Sorting in decreasing order by ID
<blockquote><pre>
std::sort(begin(v), end(v), [](auto&& x, auto&& y) { return x.id > y.id; }); // C++14
std::sort(begin(v), end(v), std::greater<>{}, &Object::id); // ranges with projections
std::sort(begin(v), end(v), [](x,y) => x.id > y.id); // this proposal
</pre></blockquote>
<p>Calling an overload where SFINAE matters and getting it wrong is a mess:
<blockquote><pre>
bool invoke(std::function<bool(int)> f); // #1
bool invoke(std::function<bool(std::string)> f); // #2
invoke([](auto x) { return x == 2; }); // error! (283 lines of diagnostic on gcc)
invoke([](auto x) -> decltype(x == 2) { return x == 2; }); // OK C++14: calls #1
invoke([](x) => x == 2); // OK this proposal: calls #1
</pre></blockquote>
<p>Chaining lots of functions together from range-v3: summing the squares under 1000:
<blockquote><pre>
// C++14
int sum = accumulate(ints(1)
| transform([](int i){ return i*i; })
| take_while([](int i){ return i < 1000; }));
// this proposal
int sum = accumulate(ints(1) | transform([](i) => i*i) | take_while([](i) => i < 1000));
</pre></blockquote>
<a name="Effects"></a><h2>Effects on Existing Code</h2>
<p>The token <code>=></code> can appear in code in rare cases, such as in the context of passing a the address of the assignment operator as a template non-template parameter, as in <code>X<Y::operator=></code>. However, such usage is incredibly rare, so this proposal would have very limited effect on existing code. Thanks to Richard Smith for doing a search.
<p>Omitting a type in a lambda could change the meaning of code today. For example:
<blockquote><pre>
struct arg { arg(int ) { } };
auto lambda = [](arg ) { return sizeof(arg); }
int x = lambda(1);
</pre></blockquote>
In the language today, the lambda will be interpreted as taking a single unnamed argument of type <code>arg</code>, <code>x</code> will be <code>sizeof(arg)</code>, which is probably 1. With this proposal, the lambda will be reinterpreted as taking a single forwarding reference named <code>arg</code>, so <code>x</code> will be <code>sizeof(int)</code>. However, such code is rare - the lambda would have to not use the argument and either rely on the side effects of creating the parameter or other unevaluated expressions based on the parameter type name.
<p>Unary <code>operator>></code> cannot appear in legal code today, so that is a pure language extension.
<a name="Priors"></a><h2>Prior Work</h2>
The original paper introducing what are now generic lambdas [2] also proposed extensions for omitting the <i>type-specifier</i> and dropping the body of a lambda if it's a single expression. This paper provides a different path towards those that same goal.
<p>The usage of <code>=></code> (or the similar <code>-></code>) in the context of lambdas appears in many, many programming languages of all varieties. A non-exhaustive sampling: C#, D, Erlang, F#, Haskell, Java, JavaScript, ML, OCaml, Swift. The widespread use is strongly suggestive that the syntax is easy to read and quite useful.
<a name="Acks"></a><h2>Acknowledgements and References</h2>
Thanks to Andrew Sutton and Tomasz Kaminski for considering and rejecting several bad iterations of this proposal. Thanks to Richard Smith for looking into the practicality of this design. Thanks to Nicol Bolas for refocusing the paper as three independent language extensions.
<p> [1] <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0119r2.pdf">Overload sets as function arguments</a>
<p> [2] <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3418.pdf">Proposal for Generic (Polymorphic) Lambda Expressions</a>
<p> [3] <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0238r0.html">Return type deduction and SFINAE</a>
</body>
</html>
------=_Part_1495_1160107626.1476646126796--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Sun, 16 Oct 2016 22:43:00 +0300
Raw View
On 16 October 2016 at 22:28, Barry Revzin <barry.revzin@gmail.com> wrote:
>>>
>>
>> Yes, he considered that. It's right there in the document he posted ;)
>> Search for "Abbreviated Function Syntax".
>
>
> Yep! Although here's a rewritten version where I'm clarifying that there are
> three independent proposals here: => expr, unary>>, and omitting types in
> lambdas. Hopefully this'll be clearer that the intent of => is to be used in
> both lambdas and functions.
Except for unary>>, these features were proposed and rejected in
Portland. I don't see much in this
proposal that would make the objections made at that time moot.
--
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/CAFk2RUYZL-juqx_BBw7YJcW6Q4A4R%3DP5MPgRAnh7yFzOxrypvA%40mail.gmail.com.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sun, 16 Oct 2016 12:48:12 -0700 (PDT)
Raw View
------=_Part_1481_177146925.1476647292212
Content-Type: multipart/alternative;
boundary="----=_Part_1482_1128506679.1476647292212"
------=_Part_1482_1128506679.1476647292212
Content-Type: text/plain; charset=UTF-8
On Sunday, October 16, 2016 at 3:43:03 PM UTC-4, Ville Voutilainen wrote:
>
> On 16 October 2016 at 22:28, Barry Revzin <barry....@gmail.com
> <javascript:>> wrote:
> >>>
> >>
> >> Yes, he considered that. It's right there in the document he posted ;)
> >> Search for "Abbreviated Function Syntax".
> >
> >
> > Yep! Although here's a rewritten version where I'm clarifying that there
> are
> > three independent proposals here: => expr, unary>>, and omitting types
> in
> > lambdas. Hopefully this'll be clearer that the intent of => is to be
> used in
> > both lambdas and functions.
>
>
> Except for unary>>, these features were proposed and rejected in
> Portland. I don't see much in this
> proposal that would make the objections made at that time moot.
>
Could you provide some information on what those proposals were and what
the objections were?
--
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/eaafe844-907d-41fd-a7a6-ecd99c6ea7f4%40isocpp.org.
------=_Part_1482_1128506679.1476647292212
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Sunday, October 16, 2016 at 3:43:03 PM UTC-4, V=
ille Voutilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 16 O=
ctober 2016 at 22:28, Barry Revzin <<a href=3D"javascript:" target=3D"_b=
lank" gdf-obfuscated-mailto=3D"raqkwNyuAgAJ" rel=3D"nofollow" onmousedown=
=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D=
'javascript:';return true;">barry....@gmail.com</a>> wrote:
<br>>>>
<br>>>
<br>>> Yes, he considered that. It's right there in the document =
he posted ;)
<br>>> Search for "Abbreviated Function Syntax".
<br>>
<br>>
<br>> Yep! Although here's a rewritten version where I'm clarify=
ing that there are
<br>> three independent proposals here: =3D> expr, unary>>, and=
omitting types in
<br>> lambdas. Hopefully this'll be clearer that the intent of =3D&g=
t; is to be used in
<br>> both lambdas and functions.
<br>
<br>
<br>Except for unary>>, these features were proposed and rejected in
<br>Portland. I don't see much in this
<br>proposal that would make the objections made at that time moot.<br></bl=
ockquote><div><br>Could you provide some information on what those proposal=
s were and what the objections were?<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/eaafe844-907d-41fd-a7a6-ecd99c6ea7f4%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/eaafe844-907d-41fd-a7a6-ecd99c6ea7f4=
%40isocpp.org</a>.<br />
------=_Part_1482_1128506679.1476647292212--
------=_Part_1481_177146925.1476647292212--
.
Author: Tomasz <tomaszkam@gmail.com>
Date: Sun, 16 Oct 2016 12:53:18 -0700 (PDT)
Raw View
------=_Part_1615_2023003224.1476647598992
Content-Type: multipart/alternative;
boundary="----=_Part_1616_456731974.1476647598992"
------=_Part_1616_456731974.1476647598992
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
W dniu niedziela, 16 pa=C5=BAdziernika 2016 21:43:03 UTC+2 u=C5=BCytkownik =
Ville=20
Voutilainen napisa=C5=82:
>
>
> Except for unary>>, these features were proposed and rejected in=20
> Portland. I don't see much in this=20
> proposal that would make the objections made at that time moot.=20
>
For =3D> expr, I belive you are reffering to section 2.3 of =20
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3418.pdf. However,=
=20
the proposal there, was to allow
[] () expr=20
With semantics equivalent to:
[] () { return expr; }
Notice that it still use auto return type deduction (no SFINAE) and returns=
=20
by value.
The =3D> expr is generalized to be expression body syntax, that will be=20
available for all functions (including lambda) and will be equivalent to:
noexcept(noexcept(expr))
-> decltype(expr)
{ return expr; }
This basically resolve the problem of uncessary repetition and also=20
partially resolves problem with return type deduction and SFINAE=20
(http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0238r0.html)=20
without requiring speculative compliation. That gives a lot more=20
motivation, that was in the paper, I belive it should be treated as totally=
=20
new feature.
--=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/4a5caf85-ce97-44d3-b702-7252ebd65004%40isocpp.or=
g.
------=_Part_1616_456731974.1476647598992
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">W dniu niedziela, 16 pa=C5=BAdziernika 2016 21:43:03 UTC+2=
u=C5=BCytkownik Ville Voutilainen napisa=C5=82:<blockquote class=3D"gmail_=
quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pa=
dding-left: 1ex;">
<br>Except for unary>>, these features were proposed and rejected in
<br>Portland. I don't see much in this
<br>proposal that would make the objections made at that time moot.
<br></blockquote><div><br>For =3D> expr, I belive you are reffering to s=
ection 2.3 of=C2=A0 http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012=
/n3418.pdf. However, the proposal there, was to allow<br>[] () expr <br>Wit=
h semantics equivalent to:<br>[] () { return expr; }<br>Notice that it stil=
l use auto return type deduction (no SFINAE) and returns by value.<br><br>T=
he =3D> expr is generalized to be expression body syntax, that will be a=
vailable for all functions (including lambda) and will be equivalent to:<br=
>noexcept(noexcept(expr))<br>=C2=A0 -> decltype(expr)<br>{ return expr; =
}<br><br>This basically resolve the problem of uncessary repetition and als=
o partially resolves problem with return type deduction and SFINAE (http://=
www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0238r0.html) without requ=
iring speculative compliation. That gives a lot more motivation, that was i=
n the paper, I belive it should be treated as totally new feature.<br><br><=
br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/4a5caf85-ce97-44d3-b702-7252ebd65004%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/4a5caf85-ce97-44d3-b702-7252ebd65004=
%40isocpp.org</a>.<br />
------=_Part_1616_456731974.1476647598992--
------=_Part_1615_2023003224.1476647598992--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Sun, 16 Oct 2016 22:57:44 +0300
Raw View
On 16 October 2016 at 22:48, Nicol Bolas <jmckesson@gmail.com> wrote:
>
>
> On Sunday, October 16, 2016 at 3:43:03 PM UTC-4, Ville Voutilainen wrote:
>>
>> On 16 October 2016 at 22:28, Barry Revzin <barry....@gmail.com> wrote:
>> >>>
>> >>
>> >> Yes, he considered that. It's right there in the document he posted ;)
>> >> Search for "Abbreviated Function Syntax".
>> >
>> >
>> > Yep! Although here's a rewritten version where I'm clarifying that there
>> > are
>> > three independent proposals here: => expr, unary>>, and omitting types
>> > in
>> > lambdas. Hopefully this'll be clearer that the intent of => is to be
>> > used in
>> > both lambdas and functions.
>>
>>
>> Except for unary>>, these features were proposed and rejected in
>> Portland. I don't see much in this
>> proposal that would make the objections made at that time moot.
>
>
> Could you provide some information on what those proposals were and what the
> objections were?
That would be http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3418.pdf.
The problem with an untyped argument is that it's ambiguous - does it
mean an unnamed parameter of a certain
type, or a parameter of a deduced type? The former is already used by
existing code, so this is a breaking change.
The problem with a single expression that is not inside braces is that
use cases where the lambda would be immediately
called instead of passed as an argument are unattainable, whereas such
problems don't arise with traditional lambdas.
There are also readability concerns with lambdas where the body is not braced.
The issues with terse lambda bodies can perhaps be overcome. The
requirement to have a type for a parameter can't, that
horse is out of the barn. I doubt a completely new lambda syntax that
makes the polar opposite decision for that issue can
survive, it will be murdered at the altar of consistency.
--
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/CAFk2RUbLLSBSkRZLSd9AmTd29pz%3DMwm%3DgV8XzuRDg6K57ZGODQ%40mail.gmail.com.
.
Author: Barry Revzin <barry.revzin@gmail.com>
Date: Sun, 16 Oct 2016 13:15:50 -0700 (PDT)
Raw View
------=_Part_1634_1574354550.1476648950513
Content-Type: multipart/alternative;
boundary="----=_Part_1635_793415805.1476648950513"
------=_Part_1635_793415805.1476648950513
Content-Type: text/plain; charset=UTF-8
>
>
>
> The problem with a single expression that is not inside braces is that
> use cases where the lambda would be immediately
> called instead of passed as an argument are unattainable, whereas such
> problems don't arise with traditional lambdas.
> There are also readability concerns with lambdas where the body is not
> braced.
>
>
But those cases have no need for SFINAE-friendliness or
noexcept-correctness since they're never passed to anything. Also most of
the time I'm created a lambda to be immediately called is for conditionally
initializing something - which wouldn't be a single expression anyway. And
if it were a single expression, why would I need a lambda anyway?
--
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/20b2b23a-4f37-4375-9333-7608f5b31ff9%40isocpp.org.
------=_Part_1635_793415805.1476648950513
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br>
<br>The problem with a single expression that is not inside braces is that
<br>use cases where the lambda would be immediately
<br>called instead of passed as an argument are unattainable, whereas such
<br>problems don't arise with traditional lambdas.
<br>There are also readability concerns with lambdas where the body is not =
braced.
<br><br></blockquote><div><br></div><div>But those cases have no need for S=
FINAE-friendliness or noexcept-correctness since they're never passed t=
o anything. Also most of the time I'm created a lambda to be immediatel=
y called is for conditionally initializing something - which wouldn't b=
e a single expression anyway. And if it were a single expression, why would=
I need a lambda anyway?=C2=A0</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/20b2b23a-4f37-4375-9333-7608f5b31ff9%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/20b2b23a-4f37-4375-9333-7608f5b31ff9=
%40isocpp.org</a>.<br />
------=_Part_1635_793415805.1476648950513--
------=_Part_1634_1574354550.1476648950513--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Sun, 16 Oct 2016 23:26:30 +0300
Raw View
On 16 October 2016 at 23:15, Barry Revzin <barry.revzin@gmail.com> wrote:
>>
>>
>> The problem with a single expression that is not inside braces is that
>> use cases where the lambda would be immediately
>> called instead of passed as an argument are unattainable, whereas such
>> problems don't arise with traditional lambdas.
>> There are also readability concerns with lambdas where the body is not
>> braced.
>>
>
> But those cases have no need for SFINAE-friendliness or noexcept-correctness
> since they're never passed to anything. Also most of the time I'm created a
> lambda to be immediately called is for conditionally initializing something
> - which wouldn't be a single expression anyway. And if it were a single
> expression, why would I need a lambda anyway?
Well, if you can convince EWG that single-expression cases are that
important, and there's
never a need to put another statement into that lambda, you may have a
case. The paper should
perhaps explain why noexcept-correctness is of such importance, and it
should explain why
SFINAE-friendliness is of such importance, and to whom, and writing what.
--
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/CAFk2RUZNy%3DsYC6OMNvd4j868fdBkCk1BDHqO5p4nnnL1qHuZ2A%40mail.gmail.com.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sun, 16 Oct 2016 14:42:20 -0700 (PDT)
Raw View
------=_Part_1571_120560724.1476654140364
Content-Type: multipart/alternative;
boundary="----=_Part_1572_740801928.1476654140365"
------=_Part_1572_740801928.1476654140365
Content-Type: text/plain; charset=UTF-8
On Sunday, October 16, 2016 at 3:57:48 PM UTC-4, Ville Voutilainen wrote:
>
> On 16 October 2016 at 22:48, Nicol Bolas <jmck...@gmail.com <javascript:>>
> wrote:
> >
> >
> > On Sunday, October 16, 2016 at 3:43:03 PM UTC-4, Ville Voutilainen
> wrote:
> >>
> >> On 16 October 2016 at 22:28, Barry Revzin <barry....@gmail.com> wrote:
> >> >>>
> >> >>
> >> >> Yes, he considered that. It's right there in the document he posted
> ;)
> >> >> Search for "Abbreviated Function Syntax".
> >> >
> >> >
> >> > Yep! Although here's a rewritten version where I'm clarifying that
> there
> >> > are
> >> > three independent proposals here: => expr, unary>>, and omitting
> types
> >> > in
> >> > lambdas. Hopefully this'll be clearer that the intent of => is to be
> >> > used in
> >> > both lambdas and functions.
> >>
> >>
> >> Except for unary>>, these features were proposed and rejected in
> >> Portland. I don't see much in this
> >> proposal that would make the objections made at that time moot.
> >
> >
> > Could you provide some information on what those proposals were and what
> the
> > objections were?
>
>
> That would be
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3418.pdf.
>
> The problem with an untyped argument is that it's ambiguous - does it
> mean an unnamed parameter of a certain
> type, or a parameter of a deduced type? The former is already used by
> existing code, so this is a breaking change.
>
So what about having untyped arguments, so long as it isn't ambiguous? That
is, `&&name`, `const &name`, `*name`, etc.
> The problem with a single expression that is not inside braces is that
> use cases where the lambda would be immediately
> called instead of passed as an argument are unattainable, whereas such
> problems don't arise with traditional lambdas.
> There are also readability concerns with lambdas where the body is not
> braced.
>
The use of => syntax should help with readability (though personally, I
wouldn't be averse to requiring {}). And it is possible to call such a
lambda; you just need partheses around the lambda itself: `([]() =>
expr)()`.
>
> The issues with terse lambda bodies can perhaps be overcome. The
> requirement to have a type for a parameter can't, that
> horse is out of the barn. I doubt a completely new lambda syntax that
> makes the polar opposite decision for that issue can
> survive, it will be murdered at the altar of consistency.
>
--
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/483e02c2-5cf2-4a75-b962-88c7ce382090%40isocpp.org.
------=_Part_1572_740801928.1476654140365
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Sunday, October 16, 2016 at 3:57:48 PM UTC-4, V=
ille Voutilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 16 O=
ctober 2016 at 22:48, Nicol Bolas <<a href=3D"javascript:" target=3D"_bl=
ank" gdf-obfuscated-mailto=3D"UOSV26qvAgAJ" rel=3D"nofollow" onmousedown=3D=
"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D=
9;javascript:';return true;">jmck...@gmail.com</a>> wrote:
<br>>
<br>>
<br>> On Sunday, October 16, 2016 at 3:43:03 PM UTC-4, Ville Voutilainen=
wrote:
<br>>>
<br>>> On 16 October 2016 at 22:28, Barry Revzin <<a>barry....@gma=
il.com</a>> wrote:
<br>>> >>>
<br>>> >>
<br>>> >> Yes, he considered that. It's right there in the =
document he posted ;)
<br>>> >> Search for "Abbreviated Function Syntax".
<br>>> >
<br>>> >
<br>>> > Yep! Although here's a rewritten version where I'=
m clarifying that there
<br>>> > are
<br>>> > three independent proposals here: =3D> expr, unary>=
>, and omitting types
<br>>> > in
<br>>> > lambdas. Hopefully this'll be clearer that the intent=
of =3D> is to be
<br>>> > used in
<br>>> > both lambdas and functions.
<br>>>
<br>>>
<br>>> Except for unary>>, these features were proposed and rej=
ected in
<br>>> Portland. I don't see much in this
<br>>> proposal that would make the objections made at that time moot=
..
<br>>
<br>>
<br>> Could you provide some information on what those proposals were an=
d what the
<br>> objections were?
<br>
<br>
<br>That would be <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/pa=
pers/2012/n3418.pdf" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this=
..href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2=
Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2012%2Fn3418.pdf\x26sa\x3dD\x26sntz\x=
3d1\x26usg\x3dAFQjCNFOviG5A2DE-CYn41vAT6qvA0yJMw';return true;" onclick=
=3D"this.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-s=
td.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2012%2Fn3418.pdf\x26sa\x3dD\x=
26sntz\x3d1\x26usg\x3dAFQjCNFOviG5A2DE-CYn41vAT6qvA0yJMw';return true;"=
>http://www.open-std.org/jtc1/<wbr>sc22/wg21/docs/papers/2012/<wbr>n3418.pd=
f</a>.
<br>
<br>The problem with an untyped argument is that it's ambiguous - does =
it
<br>mean an unnamed parameter of a certain
<br>type, or a parameter of a deduced type? The former is already used by
<br>existing code, so this is a breaking change.<br></blockquote><div><br>S=
o what about having untyped arguments, so long as it isn't ambiguous? T=
hat is, `&&name`, `const &name`, `*name`, etc.<br></div><div>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">The problem with a=
single expression that is not inside braces is that
<br>use cases where the lambda would be immediately
<br>called instead of passed as an argument are unattainable, whereas such
<br>problems don't arise with traditional lambdas.
<br>There are also readability concerns with lambdas where the body is not =
braced.
<br></blockquote><div><br>The use of =3D> syntax should help with readab=
ility (though personally, I wouldn't be averse to requiring {}). And it=
is possible to call such a lambda; you just need partheses around the lamb=
da itself: `([]() =3D> expr)()`.<br>=C2=A0</div><blockquote class=3D"gma=
il_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid=
;padding-left: 1ex;">
<br>The issues with terse lambda bodies can perhaps be overcome. The
<br>requirement to have a type for a parameter can't, that
<br>horse is out of the barn. I doubt a completely new lambda syntax that
<br>makes the polar opposite decision for that issue can
<br>survive, it will be murdered at the altar of consistency.
<br></blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/483e02c2-5cf2-4a75-b962-88c7ce382090%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/483e02c2-5cf2-4a75-b962-88c7ce382090=
%40isocpp.org</a>.<br />
------=_Part_1572_740801928.1476654140365--
------=_Part_1571_120560724.1476654140364--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Mon, 17 Oct 2016 01:11:33 +0300
Raw View
On 17 October 2016 at 00:42, Nicol Bolas <jmckesson@gmail.com> wrote:
> So what about having untyped arguments, so long as it isn't ambiguous? That
> is, `&&name`, `const &name`, `*name`, etc.
And how do you unambiguously have an unnamed by-value parameter?
> The use of => syntax should help with readability (though personally, I
> wouldn't be averse to requiring {}). And it is possible to call such a
> lambda; you just need partheses around the lambda itself: `([]() =>
> expr)()`.
Works for me.
--
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/CAFk2RUa%2BfwtoJ4%3DyJXQEUFQ0DVAbqfbpiMWpHtHJ9h1FdmGgGA%40mail.gmail.com.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sun, 16 Oct 2016 16:32:51 -0700 (PDT)
Raw View
------=_Part_1548_2076678247.1476660771900
Content-Type: multipart/alternative;
boundary="----=_Part_1549_1778320824.1476660771901"
------=_Part_1549_1778320824.1476660771901
Content-Type: text/plain; charset=UTF-8
On Sunday, October 16, 2016 at 6:11:40 PM UTC-4, Ville Voutilainen wrote:
>
> On 17 October 2016 at 00:42, Nicol Bolas <jmck...@gmail.com <javascript:>>
> wrote:
> > So what about having untyped arguments, so long as it isn't ambiguous?
> That
> > is, `&&name`, `const &name`, `*name`, etc.
>
> And how do you unambiguously have an unnamed by-value parameter?
>
You don't (or more accurately, you use `auto`, just like you used to).
While I appreciate the importance of by-value parameters, for lambdas, the
vast majority of cases will want to take parameters by some form of
reference. So if the syntax is sub-optimal for a more rare case, I think we
can live with 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/5c6a3a8d-dffa-4b68-b57f-6460df3b42b9%40isocpp.org.
------=_Part_1549_1778320824.1476660771901
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Sunday, October 16, 2016 at 6:11:40 PM UTC-4, Ville Vou=
tilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 17 October 2=
016 at 00:42, Nicol Bolas <<a href=3D"javascript:" target=3D"_blank" gdf=
-obfuscated-mailto=3D"2kL29fi2AgAJ" rel=3D"nofollow" onmousedown=3D"this.hr=
ef=3D'javascript:';return true;" onclick=3D"this.href=3D'javasc=
ript:';return true;">jmck...@gmail.com</a>> wrote:
<br>> So what about having untyped arguments, so long as it isn't am=
biguous? That
<br>> is, `&&name`, `const &name`, `*name`, etc.
<br>
<br>And how do you unambiguously have an unnamed by-value parameter?<br></b=
lockquote><div><br>You don't (or more accurately, you use `auto`, just =
like you used to). While I appreciate the importance of by-value parameters=
, for lambdas, the vast majority of cases will want to take parameters by s=
ome form of reference. So if the syntax is sub-optimal for a more rare case=
, I think we can live with it.<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/5c6a3a8d-dffa-4b68-b57f-6460df3b42b9%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5c6a3a8d-dffa-4b68-b57f-6460df3b42b9=
%40isocpp.org</a>.<br />
------=_Part_1549_1778320824.1476660771901--
------=_Part_1548_2076678247.1476660771900--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Mon, 17 Oct 2016 04:10:20 +0300
Raw View
On 17 October 2016 at 02:32, Nicol Bolas <jmckesson@gmail.com> wrote:
>> And how do you unambiguously have an unnamed by-value parameter?
>
>
> You don't (or more accurately, you use `auto`, just like you used to). While
> I appreciate the importance of by-value parameters, for lambdas, the vast
> majority of cases will want to take parameters by some form of reference. So
> if the syntax is sub-optimal for a more rare case, I think we can live with
> it.
Yet another rule in addition to usual parameter rules and capture
rules, something between them.
That'll get all 10 seconds of time in Evolution before the group
tosses the idea out.
--
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/CAFk2RUYHLgmKs-TicW-sgLwDLvnDNub6uhUGKd4qFHwDWukyZA%40mail.gmail.com.
.
Author: szollosi.lorand@gmail.com
Date: Mon, 17 Oct 2016 14:28:43 -0700 (PDT)
Raw View
------=_Part_1297_1085141974.1476739723178
Content-Type: multipart/alternative;
boundary="----=_Part_1298_856364098.1476739723179"
------=_Part_1298_856364098.1476739723179
Content-Type: text/plain; charset=UTF-8
> Except that's not what ?: does. If your back-tick things create lambdas,
> then that's very different from how ?: works. And if your back-tick things
> don't create lambdas, then it's not clear what's going on.
>
Can you please help me understand where I go wrong, I fail to see it..
Back-ticks should create lambdas and forward everything. I do intend to
redefine ? and : as separate operators, but the end result is (planned to
be) the same. ? should call one of the lambdas created.
Thanks,
-lorro
--
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/eed975e3-259a-4412-a445-032cb44e4563%40isocpp.org.
------=_Part_1298_856364098.1476739723179
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><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>Except that's not what ?: does. If your back-tick things =
create lambdas, then that's very different from how ?: works. And if yo=
ur back-tick things don't create lambdas, then it's not clear what&=
#39;s going on. <br></div></div></blockquote><div>Can you please help me un=
derstand where I go wrong, I fail to see it..<br>Back-ticks should create l=
ambdas and forward everything. I do intend to redefine ? and : as separate =
operators, but the end result is (planned to be) the same. ? should call on=
e of the lambdas created.<br><br>Thanks,<br>-lorro<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/eed975e3-259a-4412-a445-032cb44e4563%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/eed975e3-259a-4412-a445-032cb44e4563=
%40isocpp.org</a>.<br />
------=_Part_1298_856364098.1476739723179--
------=_Part_1297_1085141974.1476739723178--
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Tue, 25 Oct 2016 16:27:22 -0400
Raw View
On 2016-10-13 12:16, Nicol Bolas wrote:
> 2: Specifying return types and noexcept explicitly in order to properly
> return an expression, with SFINAE intact.
>
> Solving #2 is essentially about having a function whose entire body is
> "return <expr>;". The `=> expr` syntax discussed in this thread seems like
> a good fit here, especially since it could also be applied to regular
> function declarations.
Hmm...
class Foo
{
int m_bar;
public:
auto bar() const => m_bar;
};
WFM.
--
Matthew
--
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/nuof77%2425k%241%40blaine.gmane.org.
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Wed, 26 Oct 2016 11:30:53 -0400
Raw View
On 2016-10-16 15:57, Ville Voutilainen wrote:
> There are also readability concerns with lambdas where the body is
> not braced.
My impression (albeit granting that I did not read Barry's paper; this
is just going by the discussion) was that `=>` would be used when the
function/lambda body consists of a single expression with implied
return. I don't see this as being a serious readability issue.
As also noted by Tomaz, N3418 was proposing a different syntax, where
the syntax selected likely was largely responsible for the defeat of
that part of the proposal. Barry's proposal also has broader scope and
is thus useful in more contexts.
(Incidentally, I don't think `=>` should allow a braced expression; that
would give an entirely new and strange meaning to braces. *Parentheses*
on the other hand would make sense. Actually, I think `=>{expr}` should
be equivalent to `{ return {expr}; }`, which of course only makes sense
if the return type is specified.)
Personally, I'd be in favor of a proposal for `>>expr` and `func=>expr`.
--
Matthew
--
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/nuqi7b%24vmh%241%40blaine.gmane.org.
.
Author: Victor Dyachenko <victor.dyachenko@gmail.com>
Date: Tue, 1 Nov 2016 00:36:18 -0700 (PDT)
Raw View
------=_Part_1384_1321716210.1477985778507
Content-Type: multipart/alternative;
boundary="----=_Part_1385_148107838.1477985778507"
------=_Part_1385_148107838.1477985778507
Content-Type: text/plain; charset=UTF-8
On Monday, October 31, 2016 at 4:34:17 PM UTC+3, Matthew Woehlke wrote:
>
> (Incidentally, I don't think `=>` should allow a braced expression; that
> would give an entirely new and strange meaning to braces. *Parentheses*
> on the other hand would make sense. Actually, I think `=>{expr}` should
> be equivalent to `{ return {expr}; }`, which of course only makes sense
> if the return type is specified.)
>
+1. Braces don't add readability here. C# and Java are OK with => expr (->
expr in Java)
--
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/4aadc834-708f-4aa2-b5ac-d2126d49c5b3%40isocpp.org.
------=_Part_1385_148107838.1477985778507
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Monday, October 31, 2016 at 4:34:17 PM UTC+3, Matthew W=
oehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">(Incidentally, I =
don't think `=3D>` should allow a braced expression; that
<br>would give an entirely new and strange meaning to braces. *Parentheses*
<br>on the other hand would make sense. Actually, I think `=3D>{expr}` s=
hould
<br>be equivalent to `{ return {expr}; }`, which of course only makes sense
<br>if the return type is specified.)
<br></blockquote><div>+1. Braces don't add readability here. C# and Jav=
a are OK with =3D> expr (-> expr in Java)<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/4aadc834-708f-4aa2-b5ac-d2126d49c5b3%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/4aadc834-708f-4aa2-b5ac-d2126d49c5b3=
%40isocpp.org</a>.<br />
------=_Part_1385_148107838.1477985778507--
------=_Part_1384_1321716210.1477985778507--
.
Author: Barry Revzin <barry.revzin@gmail.com>
Date: Wed, 1 Feb 2017 15:51:57 -0800 (PST)
Raw View
------=_Part_20_957097330.1485993117392
Content-Type: multipart/alternative;
boundary="----=_Part_21_494922792.1485993117392"
------=_Part_21_494922792.1485993117392
Content-Type: text/plain; charset=UTF-8
I updated the proposal to expand on one of the ideas (using >> not only as
a substitute for std::forward, but also in lambda-capture to decay-copy,
adding the ability to capture parameter packs not only by value and
reference but also by decay-copy) and narrow another (omitting type-names
in lambdas only applies to those introduces with =>).
If this seems reasonable and agreeable, I'd like to add it to the next
mailing.
--
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/b6280220-06c4-4913-8f50-6a13297655ad%40isocpp.org.
------=_Part_21_494922792.1485993117392
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I updated the proposal to expand on one of the ideas (usin=
g >> not only as a substitute for std::forward, but also in lambda-ca=
pture to decay-copy, adding the ability to capture parameter packs not only=
by value and reference but also by decay-copy) and narrow another (omittin=
g type-names in lambdas only applies to those introduces with =3D>).=C2=
=A0<div><br></div><div>If this seems reasonable and agreeable, I'd like=
to add it to the next mailing.</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/b6280220-06c4-4913-8f50-6a13297655ad%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b6280220-06c4-4913-8f50-6a13297655ad=
%40isocpp.org</a>.<br />
------=_Part_21_494922792.1485993117392--
------=_Part_20_957097330.1485993117392
Content-Type: text/html; charset=US-ASCII; name=abbrev_lambda.html
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename=abbrev_lambda.html
X-Attachment-Id: 011d6f98-6119-4643-8bf7-6bcd3deb0657
Content-ID: <011d6f98-6119-4643-8bf7-6bcd3deb0657>
<html>
<head>
<title>abbreviated lambdas</title>
<style>
p {text-align:justify}
li {text-align:justify}
blockquote.note
{
background-color:#E0E0E0;
padding-left: 15px;
padding-right: 15px;
padding-top: 1px;
padding-bottom: 1px;
}
ins {color:#00A000}
del {color:#A00000}
code {white-space:pre;}
</style>
</head>
<body>
<address align=right>
Document number: DxxxxR0<br>
<a href="mailto:barry.revzin@gmail.com">Barry Revzin</a><br/>
2016-10-16<br/>
</address>
<hr/>
<h1 align=center>Abbreviated Lambdas for Fun and Profit</h1>
<h2>Contents</h2>
<ul>
<li><a href="#Motivation">Motivation</a></li>
<li><a href="#Proposal">Proposal</a></li>
<ul>
<li><a href="#expr"><code>=> expr</code></a></li>
<li><a href="#unary">Unary <code>operator>></code></a></li>
<li><a href="#omit">Omitting types</a></li>
</ul>
<li><a href="#Examples">Examples</a></li>
<li><a href="#Effects">Effects on Existing Code</a></li>
<li><a href="#Priors">Prior Work</a></li>
<li><a href="#Acks">Acknowledgements and References</a></li>
</ul>
<a name="Motivation"></a><h2>Motivation</h2>
<p>There are two, somewhat related motivations for an abbreviated lambda syntax. The first is to address the problem of trying to pass in overload sets as function arguments <a href="#ft1">[1]</a>:
<blockquote><pre>
template <class T>
T twice(T x) { return x + x; }
template <class I>
void f(I first, I last) {
transform(first, last, twice); // error
}
</pre></blockquote>
C++14 generic lambdas allow us a way to solve this problem by just wrapping the overloaded name in a lambda:
<blockquote><pre>
transform(first, last, [](auto&& x) {
return twice(std::forward<decltype(x)>(x));
});
</pre></blockquote>
<p>But that isn't actually correct, although it's the "obvious" code that most people would produce, and the problems are pretty subtle. The first problem is that it fails to return a reference where the function returned a reference, so there's an extra copy here in some cases (or just a hard error, if the type happens to be noncopyable). That's an easy fix though, just add the appropriate trailing return type:
<blockquote><pre>
transform(first, last, [](auto&& x) -> decltype(auto) {
return twice(std::forward<decltype(x)>(x));
});
</pre></blockquote>
Now we always have the right return type. But it's still not quite right: there's no condition checking on the argument, so the lambda isn't SFINAE-friendly. This could lead to hard errors where it's used in a situation where that matters, such as:
<blockquote><pre>
struct Widget;
bool test(int );
bool test(Widget );
void invoke(std::function<bool(int)> ); // #1
void invoke(std::function<bool(std::string)> ); // #2
// error: unresolved overloaded function type
invoke(test);
// error with a really long stack trace
invoke([](auto&& x) -> decltype(auto) {
return test(std::forward<decltype(x)>(x));
});
</pre></blockquote>
Situations like this come up from time to time, and will probably only become more common with the introduction of <code>std::variant</code> and the ability to easily use lambdas in <code>std::visit()</code> thanks to variadic <code>using</code> declarations <a href="#ft2">[2]</a>.
<p>The real, correct, way to lift an overloaded function into a function object would invole writing all of this (and even <i>this</i> version isn't <code>noexcept</code>-correct, which may matter in some cases!):
<blockquote><code>// finally OK: calls #1
<font color="blue"><b>invoke</b></font>([](auto&& <font color="blue"><b>x</b></font>)
-> decltype(test(std::forward<decltype(x)>(x)))
{
return <font color="blue"><b>test</b></font>(std::<font color="blue"><b>forward</b></font><decltype(x)>(<font color="blue"><b>x</b></font>));
});
</code></blockquote>
<p>That's <b>a lot</b> to have to type for what's conceptually a very simple thing: passing a function, that happens to be overloaded, to a function template. That lambda in of itself is 108 characters long, most of which is boilerplate that drowns out the important parts of the call (which I highlighted in <font color="blue"><b>blue</b></font>). That's far too long. Moreover, it's literally too long for many slides, so what you see at talks at conferences is typically people omit the perfect-forwarding for brevity's sake, and the forwarding syntax itself is so long that people just use macros:
<blockquote><code>#define FWD(x) static_cast<decltype(x)&&>(x)
[](auto&& x) -> decltype(test(FWD(x))) { return test(FWD(x)); }
</code></blockquote>
<p>Now we're down to just 64 characters. This is a good deal better, and we can even wrap the entire lifting process into a lambda to make it even shorter, but do we really want to be in a position where we're recommending the use of macros?
<p>Another place where this <code>FWD</code> macro comes especially handy is when we want to forward arguments <i>into</i> a lambda, just for normal purposes:
<blockquote><code>template <class T>
void foo(T&& arg) {
bar([arg=std::forward<T>(arg)]{ ... });
}
</code></blockquote>
<p>Again, that's so much to type. If I was copying <code>arg</code>, I could just type <code>arg</code> or <code>=</code>. If I was taking arg by reference, I could write <code>&arg</code> or <code>&</code>. But with forwarding, which is a fairly common operation, I need to write this 28-character beast (or, with macro, 13). But at least I <i>can</i> forward a single argument verbosely. With a parameter pack, I can capture the pack by copy or by reference, but to capture the whole thing by forward I would need to put it into a <code>std::tuple</code>. That seems very unsatisfying.
<p>These all seem like major annoyances in modern C++. Too much code to write simple things.
<a name="Proposal"></a><h2>Proposal</h2>
<p>This paper proposes three language extensions. The extensions themselves are independent, but together combine to allow for terse, readable, correct lambdas and functions.
<a name="expr"/><h3><code>=> expr</code></h3>
<p>This paper proposes the creation of a new lambda introducer, <code>=></code>, which allows for a single expression in the body that will be its return statement. This will synthesize a SFINAE-friendly, <code>noexcept</code>-correct lambda by doing the code triplication for you.
<p>That is, the lambda:
<blockquote><pre>
[](auto&& x) => test(x)
</pre></blockquote>
shall be exactly equivalent to the lambda:
<blockquote><pre>
[](auto&& x) noexcept(noexcept(test(x))) -> decltype(test(x)) { return test(x); }
</pre></blockquote>
When SFINAE is important, the repetition of the function body makes the code difficult to read. At best. At worst, the code becomes error-prone when one changes the body of the function while forgetting to change the body of the trailing <code>decltype</code>. Even when SFINAE is not important, for the simplest lambdas, brevity is important for readability and omitting the <code>return</code> keyword would be helpful.
<p>The code duplication or triplication in short function bodies is also a common problem that wants for a solution <a href="#ft3">[3]</a>, but this proposal is focused solely on lambda expressions.
<a name="unary" /><h3>Unary <code>operator>></code></h3>
<p>Another source of boilerplate is generic code is <code>std::forward</code>. When dealing with templates, the uses of <code>forward</code> can overwhelm all the rest of the code, to the point where many talks and examples just omit references entirely to save space and many programmers just give up trying to read it. Hence the viability of the <code>FWD()</code> macro presented earlier.
<p>Unlike <code>std::move</code> and <code>std::ref</code>, which are used to do non-typical things and deserve to be visible markers for code readability, <code>std::forward</code> is very typically used in the context of using forwarding references. It does not have as clear a need to be a signpost.
<p>This paper would like to see a shorter way to forward arguments and proposes non-overloadable unary <code>operator >></code>, where <code>>>expr</code> shall be defined as <code>static_cast<decltype(expr)&&>(expr)</code>, and shall not overloadable. Furthermore, the symbol <code>>></code> in the capture of a lambda expression can be used to "decay-copy" <a href="#ft4">[4]</a> the named variable or all variables.
<p>This lambda:
<blockquote><pre>
[](auto&& x) { return test(>>x); }
</pre></blockquote>
is equivalent by definition to this one:
<blockquote><pre>
[](auto&& x) { return test(std::forward<decltype(x)>(x)); }
</pre></blockquote>
<p>This function (a one-time delayed invoker):
<blockquote><pre>template <class F, class... Args>
auto delay_invoke(F&& f, Args&&... args) {
return [>>]() => std::invoke(>>f, >>args...);
}
</pre></blockquote>
is logically, though not strictly, equivalent to this one:
<blockquote><pre>template <class F, class... Args>
auto delay_invoke(F&& f, Args&&... args) {
return [f=std::forward<F>(f), tup=std::forward_as_tuple(std::forward<Args>(args)...)]() -> decltype(auto) {
return std::apply(std::forward<F>(f), std::move(tup));
};
}
</pre></blockquote>
<p>Using <code>>></code> to forward doesn't just make the code shorter. It makes it easier to read and easier to write. In the second example, it let's us naturally and directly invoke the function without having to do the indirection through a tuple (which is is neither easy to read nor write nor reason about). It's also probably easier for the compiler too.
<p>Unary <code>operator>></code> will have equivalent precedence to the other prefix operators, like <code>operator!</code>.
<a name="omit" /><h3>Omission of types in lambdas</h3>
One of the motivations of generic lambdas was to use <code>auto</code> as a substitute for long type names, which helps quite a bit. But since <code>auto&&</code> has become such a regular choice of argument for lambdas, and is rarely a wrong choice, it doesn't really bestow any information to the code. It would be great if we could allow the type to be omitted, in which case it will be assumed to be <code>auto&&</code>. That is, if:
<blockquote><pre>
[](x) { return x+1; }
</pre></blockquote>
could be exactly equivalent to the lambda:
<blockquote><pre>
[](auto&& x) { return x+1; }
</pre></blockquote>
However, this is impossible to do for all lambdas. The example:
<blockquote><pre>
struct arg { arg(int ) { } };
auto lambda = [](arg ) { return sizeof(arg); }
int x = lambda(1);
</pre></blockquote>
is well-formed today, yielding a value of (typically) 1 for <code>x</code>, and we can't just change that to yield (typically) 4. But while there's little we can do here, we can do something for precisely those simple lambdas that this proposal is focused on. The fragment <code>[](x) => expr</code> currently is ill-formed. So this paper proposes, for those abbreviated lambdas using the <code>=></code> syntax, to allow for the the omission of type names. Any standalone identifier shall be a parameter of type <code>auto&&</code>. Omitted type names can be interspersed with provided type names, and a trailing <code>...</code> will indicate a parameter pack of forwarding references. That is, the lambdas:
<blockquote><pre>[](x, int y) => x < y
[](args...) => test(>>args...)
</pre></blockquote>
shall be exactly equivalent to the C++14 lambdas
<blockquote><pre>
[](auto&& x, int y) noexcept(...) -> decltype(x < y) { return x < y; }
[](auto&&... args) noexcept(...) -> decltype(test(std::forward<decltype(args)>(args)...)) { return test(std::forward<decltype(args)>(args)...); }
</pre></blockquote>
No default arguments will be allowed in the case of type omission, due to potential ambiguities in parsing.
<a name="Examples"></a><h2>Examples</h2>
<p> Putting all three features together, binding an overload member function, <code>func</code>, to an instance, <code>obj</code>, as a function argument is reduced from:
<blockquote><pre>
[&obj](auto&&... args) noexcept(noexcept(obj.func(std::forward<decltype(args)>(args)...))) -> decltype(obj.func(std::forward<decltype(args)>(args)...)) { return obj.func(std::forward<decltype(args)>(args)...); }
</pre></blockquote>
to
<blockquote><pre>
[&obj](...args) => obj.func(>>args...)
</pre></blockquote>
<p>That is a reduction from 212 (144 if you don't care about <code>noexcept</code>) characters to 39.
<p>Here are other examples of improved usage as compared to C++14 best practices.
<p>Sorting in decreasing order: same typing, but arguably clearer:
<blockquote><code>std::sort(begin(v), end(v), [](auto&& x, auto&& y) { return x > y; }); // C++14
std::sort(begin(v), end(v), std::greater<>{}); // C++14 with function object
std::sort(begin(v), end(v), [](x,y) => x > y); // this proposal - don't need to know about std::greater
</code></blockquote>
<p>Sorting in decreasing order by ID:
<blockquote><code>std::sort(begin(v), end(v), [](auto&& x, auto&& y) { return x.id > y.id; }); // C++14
std::sort(begin(v), end(v), std::greater<>{}, &Object::id); // ranges with projections
std::sort(begin(v), end(v), [](x,y) => x.id > y.id); // this proposal
</code></blockquote>
<p>Finding an element based on a member function call, with and without additional arguments:
<blockquote><code>auto it = std::find_if(begin(v), end(v), [](auto&& e) { return e.isMatch(); }); // C++14 with lambda
auto it = std::find_if(begin(v), end(v), std::mem_fn(&Object::isMatch)); // C++11 with mem_fn
auto it = std::find_if(begin(v), end(v), [](e) => e.isMatch()); // this proposal
auto it = std::find_if(begin(v), end(v), std::bind(&Object::matches, _1, std::ref(target)));
auto it = std::find_if(begin(v), end(v), [&](auto&& e) { return e.matches(target); });
auto it = std::find_if(begin(v), end(v), [&](e) => e.matches(target));
</code></blockquote>
<p>Calling an overload where SFINAE matters and getting it wrong is a mess:
<blockquote><pre>
bool invoke(std::function<bool(int)> f); // #1
bool invoke(std::function<bool(std::string)> f); // #2
invoke([](auto x) { return x == 2; }); // error! (283 lines of diagnostic on gcc)
invoke([](auto x) -> decltype(x == 2) { return x == 2; }); // OK C++14: calls #1
invoke([](x) => x == 2); // OK this proposal: calls #1
</pre></blockquote>
<p>Implementing currying, in C++17. This is dramatically more concise than what you would otherwise have to do in C++17 <a href="#ft5">[5]</a>, thanks to being able to capture parameter packs by decay-copy and easily get the SFINAE right (here it is critical) without duplication.
<blockquote><code>template <class F>
auto curry(F&& f) {
return [>>](auto&&... args) -> decltype(auto) {
if constexpr (std::is_callable<F&(decltype(args)...)>::value) {
return std::invoke(f, >>args...);
}
else {
return curry([>>, f](auto&&... new_args) =>
std::invoke(f, args..., >>new_args...)
);
}
};
}
</code></blockquote>
<a name="Effects"></a><h2>Effects on Existing Code</h2>
<p>The token <code>=></code> can appear in code in rare cases, such as in the context of passing a the address of the assignment operator as a template non-template parameter, as in <code>X<Y::operator=></code>. However, such usage is incredibly rare, so this proposal would have very limited effect on existing code. Thanks to Richard Smith for doing a search.
<p>Unary <code>operator>></code> cannot appear in legal code today, or in this proposed context in a lambda-capture, so that is a pure language extension.
<a name="Priors"></a><h2>Prior Work</h2>
The original paper introducing what are now generic lambdas <a href="#ft6">[6]</a> also proposed extensions for omitting the <i>type-specifier</i> and dropping the body of a lambda if it's a single expression. This paper provides a different path towards those that same goal.
<p>The usage of <code>=></code> (or the similar <code>-></code>) in the context of lambdas appears in many, many programming languages of all varieties. A non-exhaustive sampling: C#, D, Erlang, F#, Haskell, Java, JavaScript, ML, OCaml, Swift. The widespread use is strongly suggestive that the syntax is easy to read and quite useful.
<p>There has also been an idea floating around, if not a specific proposal, to lift an overloaded function into a lambda with the syntax <code>[]f</code>. This is certainly far more concise than what is proposed as an alternative in this paper (<code>[](args...) => f(>>args...)</code>).
<a name="Acks"></a><h2>Acknowledgements and References</h2>
Thanks to Andrew Sutton and Tomasz Kaminski for considering and rejecting several bad iterations of this proposal. Thanks to Richard Smith for looking into the practicality of this design. Thanks to Nicol Bolas for refocusing the paper as three independent language extensions. Thanks to John Shaw for putting up with a torrent of bad ideas.
<p> <a name="ft1"/> [1] <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0119r2.pdf">Overload sets as function arguments</a>
<p> <a name="ft2"/> [2] <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0195r2.html">Pack expansions in using-declarations</a>
<p> <a name="ft3"/> [3] <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3418.pdf">Proposal for Generic (Polymorphic) Lambda Expressions</a>
<p> <a name="ft4"/> [4] <a href="http://eel.is/c++draft/thread.decaycopy">[thread.decaycopy]</a> defines this as <blockquote><code>template <class T>
decay_t<T> decay_copy(T&& v) {
return std::forward<T>(v);
}</code></blockquote>
<p> <a name="ft5"/> [5] <a href="https://vittorioromeo.info/index/blog/cpp17_curry.html">zero-overhead C++17 currying & partial application</a>, most of the implementation revolves around properly forward-capturing the parameter packs
<p> <a name="ft6"/> [6] <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0238r0.html">Return type deduction and SFINAE</a>
</body>
</html>
------=_Part_20_957097330.1485993117392--
.
Author: Ricardo Fabiano de Andrade <ricardofabianodeandrade@gmail.com>
Date: Wed, 1 Feb 2017 20:44:37 -0600
Raw View
--001a113aa4a07444e605478325a7
Content-Type: text/plain; charset=UTF-8
Nice idea, the forward operator is also a nice touch.
Maybe out of the scope, but I'm going to ask anyways: have you thought
about an equivalent move operator? "operator<<" maybe? :)
On Wed, Feb 1, 2017 at 5:51 PM, Barry Revzin <barry.revzin@gmail.com> wrote:
> I updated the proposal to expand on one of the ideas (using >> not only as
> a substitute for std::forward, but also in lambda-capture to decay-copy,
> adding the ability to capture parameter packs not only by value and
> reference but also by decay-copy) and narrow another (omitting type-names
> in lambdas only applies to those introduces with =>).
>
> If this seems reasonable and agreeable, I'd like to add it to the next
> mailing.
>
> --
> 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/b6280220-06c4-4913-
> 8f50-6a13297655ad%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b6280220-06c4-4913-8f50-6a13297655ad%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%2BfGSbNoG53yX%3D2%3DhM0i_pS6rbkSYhb7w60hLFKFe%2BeQUYY0Xw%40mail.gmail.com.
--001a113aa4a07444e605478325a7
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Nice idea, the forward operator is also a nice touch.<div>=
Maybe out of the scope, but I'm going to ask anyways: have you thought =
about an equivalent move operator? "operator<<" maybe? :)</=
div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Wed,=
Feb 1, 2017 at 5:51 PM, Barry Revzin <span dir=3D"ltr"><<a href=3D"mail=
to:barry.revzin@gmail.com" target=3D"_blank">barry.revzin@gmail.com</a>>=
</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">I updated=
the proposal to expand on one of the ideas (using >> not only as a s=
ubstitute for std::forward, but also in lambda-capture to decay-copy, addin=
g the ability to capture parameter packs not only by value and reference bu=
t also by decay-copy) and narrow another (omitting type-names in lambdas on=
ly applies to those introduces with =3D>).=C2=A0<div><br></div><div>If t=
his seems reasonable and agreeable, I'd like to add it to the next mail=
ing.</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" 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@<wbr>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/b6280220-06c4-4913-8f50-6a13297655ad%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/b628=
0220-06c4-4913-<wbr>8f50-6a13297655ad%40isocpp.org</a><wbr>.<br>
</font></span></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" 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%2BfGSbNoG53yX%3D2%3DhM0i_pS6rbkSYh=
b7w60hLFKFe%2BeQUYY0Xw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BfGSb=
NoG53yX%3D2%3DhM0i_pS6rbkSYhb7w60hLFKFe%2BeQUYY0Xw%40mail.gmail.com</a>.<br=
/>
--001a113aa4a07444e605478325a7--
.
Author: =?UTF-8?Q?P=C3=A9ter_Radics?= <mitchnull@gmail.com>
Date: Thu, 2 Feb 2017 01:05:42 -0800 (PST)
Raw View
------=_Part_106_115308593.1486026344066
Content-Type: multipart/alternative;
boundary="----=_Part_107_6629373.1486026344067"
------=_Part_107_6629373.1486026344067
Content-Type: text/plain; charset=UTF-8
Looks nice, although for me a the [](x, y) => x < y syntax looks a bit
"naked", I'd rather have something surrounding the expression, so I'd
prefer to write [](x, y) => { x < y }. Then this could also be generalized
to multi-statement lambdas, just with the new => syntax to help with your
other idea of omitting auto&&. Would that be viable? The {} could be
optional for single-expression body.
Also, I think you made a typo in the examples section:
[&obj](...args) => obj.func(>>args...)
should probably be
[&obj](args...) => obj.func(>>args...)
(at least according to the previous section of the proposal).
On Thursday, February 2, 2017 at 12:51:57 AM UTC+1, Barry Revzin wrote:
>
> I updated the proposal to expand on one of the ideas (using >> not only as
> a substitute for std::forward, but also in lambda-capture to decay-copy,
> adding the ability to capture parameter packs not only by value and
> reference but also by decay-copy) and narrow another (omitting type-names
> in lambdas only applies to those introduces with =>).
>
> If this seems reasonable and agreeable, I'd like to add it to the next
> mailing.
>
--
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/49130950-5e85-424f-bcda-8c5b0d5cef34%40isocpp.org.
------=_Part_107_6629373.1486026344067
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Looks nice, although for me a the [](x, y) =3D> x < =
y syntax looks a bit "naked", I'd rather have something surro=
unding the expression, so I'd prefer to write [](x, y) =3D> { x <=
y }. =C2=A0Then this could also be generalized to multi-statement lambdas,=
just with the new =3D> syntax to help with your other idea of omitting =
auto&&. =C2=A0Would that be viable? =C2=A0The {} could be optional =
for single-expression body.<div><br></div><div>Also, I think you made a typ=
o in the examples section:</div><div><br></div><div><pre style=3D"color: rg=
b(0, 0, 0);">[&obj](...args) =3D> obj.func(>>args...)</pre><pr=
e style=3D"color: rgb(0, 0, 0);"><br></pre><pre style=3D"color: rgb(0, 0, 0=
);"><br></pre>should probably be</div><div><br></div><div><pre style=3D"col=
or: rgb(0, 0, 0);">[&obj](args...) =3D> obj.func(>>args...)</p=
re></div><div><br></div><div>(at least according to the previous section of=
the proposal).</div><div><br></div><div><br>On Thursday, February 2, 2017 =
at 12:51:57 AM UTC+1, Barry Revzin wrote:<blockquote class=3D"gmail_quote" =
style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-l=
eft: 1ex;"><div dir=3D"ltr">I updated the proposal to expand on one of the =
ideas (using >> not only as a substitute for std::forward, but also i=
n lambda-capture to decay-copy, adding the ability to capture parameter pac=
ks not only by value and reference but also by decay-copy) and narrow anoth=
er (omitting type-names in lambdas only applies to those introduces with =
=3D>).=C2=A0<div><br></div><div>If this seems reasonable and agreeable, =
I'd like to add it to the next mailing.</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" 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/49130950-5e85-424f-bcda-8c5b0d5cef34%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/49130950-5e85-424f-bcda-8c5b0d5cef34=
%40isocpp.org</a>.<br />
------=_Part_107_6629373.1486026344067--
------=_Part_106_115308593.1486026344066--
.
Author: Jared Grubb <jared.grubb@gmail.com>
Date: Thu, 2 Feb 2017 09:24:47 -0800 (PST)
Raw View
------=_Part_961_1493520749.1486056287324
Content-Type: multipart/alternative;
boundary="----=_Part_962_954708668.1486056287324"
------=_Part_962_954708668.1486056287324
Content-Type: text/plain; charset=UTF-8
On Wednesday, February 1, 2017 at 3:51:57 PM UTC-8, Barry Revzin wrote:
>
> I updated the proposal to expand on one of the ideas (using >> not only as
> a substitute for std::forward, but also in lambda-capture to decay-copy,
> adding the ability to capture parameter packs not only by value and
> reference but also by decay-copy) and narrow another (omitting type-names
> in lambdas only applies to those introduces with =>).
>
> If this seems reasonable and agreeable, I'd like to add it to the next
> mailing.
>
I really like this a lot. Well argued and well written. Good luck!
--
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/a905a98d-30a1-4d91-a9f0-2be772519ddf%40isocpp.org.
------=_Part_962_954708668.1486056287324
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Wednesday, February 1, 2017 at 3:51:57 PM UTC-8=
, Barry Revzin wrote:<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">I updated the proposal to expand on one of the ideas (using >&g=
t; not only as a substitute for std::forward, but also in lambda-capture to=
decay-copy, adding the ability to capture parameter packs not only by valu=
e and reference but also by decay-copy) and narrow another (omitting type-n=
ames in lambdas only applies to those introduces with =3D>).=C2=A0<div><=
br></div><div>If this seems reasonable and agreeable, I'd like to add i=
t to the next mailing.</div></div></blockquote><div><br>I really like this =
a lot. Well argued and well written. Good luck! <br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/a905a98d-30a1-4d91-a9f0-2be772519ddf%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a905a98d-30a1-4d91-a9f0-2be772519ddf=
%40isocpp.org</a>.<br />
------=_Part_962_954708668.1486056287324--
------=_Part_961_1493520749.1486056287324--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Thu, 2 Feb 2017 14:22:31 -0800 (PST)
Raw View
------=_Part_367_1858683249.1486074151223
Content-Type: multipart/alternative;
boundary="----=_Part_368_1753425110.1486074151223"
------=_Part_368_1753425110.1486074151223
Content-Type: text/plain; charset=UTF-8
On Wednesday, February 1, 2017 at 6:51:57 PM UTC-5, Barry Revzin wrote:
>
> I updated the proposal to expand on one of the ideas (using >> not only as
> a substitute for std::forward, but also in lambda-capture to decay-copy,
> adding the ability to capture parameter packs not only by value and
> reference but also by decay-copy) and narrow another (omitting type-names
> in lambdas only applies to those introduces with =>).
>
> If this seems reasonable and agreeable, I'd like to add it to the next
> mailing.
>
Hmm. I really don't think the part about omitting the types is going to
fly, parsing wise. Basing it on the use of `=>` syntax requires look-ahead,
and that's an uphill battle. As a possible alternative, consider this:
[]:(x, ...y) {};
One advantage of this is that, like `=>` syntax, you could also
theoretically apply it to regular functions:
void func_name:(x, ...y) {}; //I'm a template!
The big downside is that with `:()` syntax, you now have to come up with
new parsing rules for function parameters. Also, :( looks like an emoji.
--
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/d0f841b7-60d3-4097-85f0-383711aeb401%40isocpp.org.
------=_Part_368_1753425110.1486074151223
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wednesday, February 1, 2017 at 6:51:57 PM UTC-5, Barry =
Revzin wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
I updated the proposal to expand on one of the ideas (using >> not on=
ly as a substitute for std::forward, but also in lambda-capture to decay-co=
py, adding the ability to capture parameter packs not only by value and ref=
erence but also by decay-copy) and narrow another (omitting type-names in l=
ambdas only applies to those introduces with =3D>).=C2=A0<div><br></div>=
<div>If this seems reasonable and agreeable, I'd like to add it to the =
next mailing.</div></div></blockquote><div><br>Hmm. I really don't thin=
k the part about omitting the types is going to fly, parsing wise. Basing i=
t on the use of `=3D>` syntax requires look-ahead, and that's an uph=
ill battle. As a possible alternative, consider this:<br><br><div style=3D"=
background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); bor=
der-style: solid; border-width: 1px; overflow-wrap: break-word;" class=3D"p=
rettyprint"><code class=3D"prettyprint"><div class=3D"subprettyprint"><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;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">...</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify">y</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">{};</span></di=
v></code></div><br>One advantage of this is that, like `=3D>` syntax, yo=
u could also theoretically apply it to regular functions:<br><br><div style=
=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187);=
border-style: solid; border-width: 1px; overflow-wrap: break-word;" class=
=3D"prettyprint"><code class=3D"prettyprint"><div class=3D"subprettyprint">=
<span style=3D"color: #008;" class=3D"styled-by-prettify">void</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> func_name</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;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">...</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify">y</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">{};</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"c=
olor: #800;" class=3D"styled-by-prettify">//I'm a template!</span></div=
></code></div><br>The big downside is that with `:()` syntax, you now have =
to come up with new parsing rules for function parameters. Also, :( looks l=
ike an emoji.<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/d0f841b7-60d3-4097-85f0-383711aeb401%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d0f841b7-60d3-4097-85f0-383711aeb401=
%40isocpp.org</a>.<br />
------=_Part_368_1753425110.1486074151223--
------=_Part_367_1858683249.1486074151223--
.
Author: Lorand Szollosi <szollosi.lorand@gmail.com>
Date: Fri, 3 Feb 2017 13:35:36 +0100
Raw View
--Apple-Mail-57E1E933-8D01-4AF5-BD36-ED046E015D6D
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Hi,
Like it, but miss some parens on the rhs of '=3D>', esp. because of precede=
nce.
Just an idea: gcc & clang & to some extend, intel cc already have ({ expr }=
} which 'has the value of' (definition on this differs per compiler) expr. =
If you said, [&](x, y) =3D> ({ x < y }) as the new syntax, you could:
- have a distinct paren type,
- make it look familiar to those used to statement expressions,
- solve most precedence issues,
- might optionally allow for ({ stmt; expr }) for some statement (perhaps s=
tep-by-step)
- might optionally allow for ({ return expr; }), which returns to the calle=
r of the context defining the lambda (think of e.g. accumulate() over range=
of ints via mul: you want to return early if you see a 0 in the input); UB=
if context is left,
- might optionally allow for break, continue or even throw, <cough>goto/swi=
tch in the defining context.
Thus you could capture continuation replacing statements. All the rest I'd =
keep the same in the proposal, I really like the idea of simplified lambdas=
..
Thanks,
-lorro
2017. febr. 2. d=C3=A1tummal, 0:51 id=C5=91pontban Barry Revzin <barry.revz=
in@gmail.com> =C3=ADrta:
> I updated the proposal to expand on one of the ideas (using >> not only a=
s a substitute for std::forward, but also in lambda-capture to decay-copy, =
adding the ability to capture parameter packs not only by value and referen=
ce but also by decay-copy) and narrow another (omitting type-names in lambd=
as only applies to those introduces with =3D>).=20
>=20
> If this seems reasonable and agreeable, I'd like to add it to the next ma=
iling.
> --=20
> You received this message because you are subscribed to a topic in the Go=
ogle Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.=
org/d/topic/std-proposals/uu7mRNXnf8Q/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to std-p=
roposals+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/isoc=
pp.org/d/msgid/std-proposals/b6280220-06c4-4913-8f50-6a13297655ad%40isocpp.=
org.
> <abbrev_lambda.html>
--=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/DA7EEC98-D410-4C92-9C13-0A9E0131A91A%40gmail.com=
..
--Apple-Mail-57E1E933-8D01-4AF5-BD36-ED046E015D6D
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=
=3Dutf-8"></head><body dir=3D"auto"><div>Hi,</div><div id=3D"AppleMailSigna=
ture"><br></div><div id=3D"AppleMailSignature">Like it, but miss some paren=
s on the rhs of '=3D>', esp. because of precedence.</div><div id=3D"Appl=
eMailSignature"><br></div><div id=3D"AppleMailSignature">Just an idea: gcc =
& clang & to some extend, intel cc already have ({ expr }} which 'h=
as the value of' (definition on this differs per compiler) expr. If you sai=
d, [&](x, y) =3D> ({ x < y }) as the new syntax, you could:</div>=
<div id=3D"AppleMailSignature">- have a distinct paren type,</div><div id=
=3D"AppleMailSignature">- make it look familiar to those used to statement =
expressions,</div><div id=3D"AppleMailSignature">- solve most precedence is=
sues,</div><div id=3D"AppleMailSignature">- might optionally allow for ({ s=
tmt; expr }) for some statement (perhaps step-by-step)</div><div id=3D"Appl=
eMailSignature">- might optionally allow for ({ return expr; }), which retu=
rns to the caller of the context defining the lambda (think of e.g. accumul=
ate() over range of ints via mul: you want to return early if you see a 0 i=
n the input); UB if context is left,</div><div id=3D"AppleMailSignature">- =
might optionally allow for break, continue or even throw, <cough>goto=
/switch in the defining context.</div><div id=3D"AppleMailSignature"><br></=
div><div id=3D"AppleMailSignature">Thus you could capture continuation repl=
acing statements. All the rest I'd keep the same in the proposal, I really =
like the idea of simplified lambdas.</div><div id=3D"AppleMailSignature"><b=
r></div><div id=3D"AppleMailSignature">Thanks,</div><div id=3D"AppleMailSig=
nature">-lorro</div><div><br>2017. febr. 2. d=C3=A1tummal, 0:51 id=C5=91pon=
tban Barry Revzin <<a href=3D"mailto:barry.revzin@gmail.com">barry.revzi=
n@gmail.com</a>> =C3=ADrta:<br><br></div><blockquote type=3D"cite"><div>=
<div dir=3D"ltr">I updated the proposal to expand on one of the ideas (usin=
g >> not only as a substitute for std::forward, but also in lambda-ca=
pture to decay-copy, adding the ability to capture parameter packs not only=
by value and reference but also by decay-copy) and narrow another (omittin=
g type-names in lambdas only applies to those introduces with =3D>).&nbs=
p;<div><br></div><div>If this seems reasonable and agreeable, I'd like to a=
dd it to the next mailing.</div></div>
<p></p>
-- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/uu7mRNXnf8Q/unsubscribe">https://groups.=
google.com/a/isocpp.org/d/topic/std-proposals/uu7mRNXnf8Q/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">std-proposals+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/b6280220-06c4-4913-8f50-6a13297655ad%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.goo=
gle.com/a/isocpp.org/d/msgid/std-proposals/b6280220-06c4-4913-8f50-6a132976=
55ad%40isocpp.org</a>.<br>
</div></blockquote><blockquote type=3D"cite"><div><abbrev_lambda.html>=
;</div></blockquote></body></html>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/DA7EEC98-D410-4C92-9C13-0A9E0131A91A%=
40gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/DA7EEC98-D410-4C92-9C13-0A9E0131A91A%=
40gmail.com</a>.<br />
--Apple-Mail-57E1E933-8D01-4AF5-BD36-ED046E015D6D--
.
Author: Viacheslav Usov <via.usov@gmail.com>
Date: Fri, 3 Feb 2017 16:09:40 +0100
Raw View
--001a11407132caded50547a1aba5
Content-Type: text/plain; charset=UTF-8
On Thu, Feb 2, 2017 at 11:22 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
> On Wednesday, February 1, 2017 at 6:51:57 PM UTC-5, Barry Revzin wrote:
>>
>> I updated the proposal to expand on one of the ideas (using >> not only
>> as a substitute for std::forward, but also in lambda-capture to decay-copy,
>> adding the ability to capture parameter packs not only by value and
>> reference but also by decay-copy) and narrow another (omitting type-names
>> in lambdas only applies to those introduces with =>).
>>
>> If this seems reasonable and agreeable, I'd like to add it to the next
>> mailing.
>>
>
> Hmm. I really don't think the part about omitting the types is going to
> fly, parsing wise. Basing it on the use of `=>` syntax requires look-ahead,
> and that's an uphill battle. As a possible alternative, consider this:
>
> []:(x, ...y) {};
>
> One advantage of this is that, like `=>` syntax, you could also
> theoretically apply it to regular functions:
>
> void func_name:(x, ...y) {}; //I'm a template!
>
> The big downside is that with `:()` syntax, you now have to come up with
> new parsing rules for function parameters. Also, :( looks like an emoji.
>
I think your idea can be stated more generally as a way to decorate the
*parameters-and-qualifiers* in some way that indicates the abbreviated
syntax shall be expected there.
Why can't we use the <> instead of () to that effect? E.g., []<a, b> => a
+ b.
This, in principle, makes the following => symbol redundant, so we can
abbreviate that further to []<a, b> a + b.
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/CAA7YVg1KD-yGuu8u1BKNRpxveJu-BkaeqWbFL790thRaH4cV6g%40mail.gmail.com.
--001a11407132caded50547a1aba5
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, Feb 2, 2017 at 11:22 PM, Nicol Bolas <span dir=3D"ltr"><<a href=3D"m=
ailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>></s=
pan> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=
=3D"ltr">On Wednesday, February 1, 2017 at 6:51:57 PM UTC-5, Barry Revzin w=
rote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo=
rder-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">I u=
pdated the proposal to expand on one of the ideas (using >> not only =
as a substitute for std::forward, but also in lambda-capture to decay-copy,=
adding the ability to capture parameter packs not only by value and refere=
nce but also by decay-copy) and narrow another (omitting type-names in lamb=
das only applies to those introduces with =3D>).=C2=A0<div><br></div><di=
v>If this seems reasonable and agreeable, I'd like to add it to the nex=
t mailing.</div></div></blockquote><div><br>Hmm. I really don't think t=
he part about omitting the types is going to fly, parsing wise. Basing it o=
n the use of `=3D>` syntax requires look-ahead, and that's an uphill=
battle. As a possible alternative, consider this:<br><br><div style=3D"bac=
kground-color:rgb(250,250,250);border-color:rgb(187,187,187);border-style:s=
olid;border-width:1px" class=3D"gmail-m_453050900183120300prettyprint"><cod=
e class=3D"gmail-m_453050900183120300prettyprint"><div class=3D"gmail-m_453=
050900183120300subprettyprint"><span style=3D"color:rgb(102,102,0)" class=
=3D"gmail-m_453050900183120300styled-by-prettify">[]:(</span><span style=3D=
"color:rgb(0,0,0)" class=3D"gmail-m_453050900183120300styled-by-prettify">x=
</span><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_45305090018312=
0300styled-by-prettify">,</span><span style=3D"color:rgb(0,0,0)" class=3D"g=
mail-m_453050900183120300styled-by-prettify"> </span><span style=3D"color:r=
gb(102,102,0)" class=3D"gmail-m_453050900183120300styled-by-prettify">...</=
span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_453050900183120300st=
yled-by-prettify">y</span><span style=3D"color:rgb(102,102,0)" class=3D"gma=
il-m_453050900183120300styled-by-prettify">)</span><span style=3D"color:rgb=
(0,0,0)" class=3D"gmail-m_453050900183120300styled-by-prettify"> </span><sp=
an style=3D"color:rgb(102,102,0)" class=3D"gmail-m_453050900183120300styled=
-by-prettify">{};</span></div></code></div><br>One advantage of this is tha=
t, like `=3D>` syntax, you could also theoretically apply it to regular =
functions:<br><br><div style=3D"background-color:rgb(250,250,250);border-co=
lor:rgb(187,187,187);border-style:solid;border-width:1px" class=3D"gmail-m_=
453050900183120300prettyprint"><code class=3D"gmail-m_453050900183120300pre=
ttyprint"><div class=3D"gmail-m_453050900183120300subprettyprint"><span sty=
le=3D"color:rgb(0,0,136)" class=3D"gmail-m_453050900183120300styled-by-pret=
tify">void</span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_45305090=
0183120300styled-by-prettify"> func_name</span><span style=3D"color:rgb(102=
,102,0)" class=3D"gmail-m_453050900183120300styled-by-prettify">:(</span><s=
pan style=3D"color:rgb(0,0,0)" class=3D"gmail-m_453050900183120300styled-by=
-prettify">x</span><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_45=
3050900183120300styled-by-prettify">,</span><span style=3D"color:rgb(0,0,0)=
" class=3D"gmail-m_453050900183120300styled-by-prettify"> </span><span styl=
e=3D"color:rgb(102,102,0)" class=3D"gmail-m_453050900183120300styled-by-pre=
ttify">...</span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_45305090=
0183120300styled-by-prettify">y</span><span style=3D"color:rgb(102,102,0)" =
class=3D"gmail-m_453050900183120300styled-by-prettify">)</span><span style=
=3D"color:rgb(0,0,0)" class=3D"gmail-m_453050900183120300styled-by-prettify=
"> </span><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_45305090018=
3120300styled-by-prettify">{};</span><span style=3D"color:rgb(0,0,0)" class=
=3D"gmail-m_453050900183120300styled-by-prettify"> </span><span style=3D"co=
lor:rgb(136,0,0)" class=3D"gmail-m_453050900183120300styled-by-prettify">//=
I'm a template!</span></div></code></div><br>The big downside is that w=
ith `:()` syntax, you now have to come up with new parsing rules for functi=
on parameters. Also, :( looks like an emoji.</div></div></blockquote><div><=
br></div><div>I think your idea can be stated more generally as a way to de=
corate the=C2=A0<i>parameters-and-qualifiers</i> in some way that indicates=
the abbreviated syntax shall be expected there.<br></div><div><br></div><d=
iv>Why can't we use the <> instead of () to that effect? E.g., []=
<a, b> =3D> =C2=A0a + b.</div><div><br></div><div>This, in princip=
le, makes the following =3D> symbol redundant, so we can abbreviate that=
further to []<a, b> a + b.</div><div><br></div><div>Cheers,</div><di=
v>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" 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/CAA7YVg1KD-yGuu8u1BKNRpxveJu-BkaeqWbF=
L790thRaH4cV6g%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg1KD-yGuu8u=
1BKNRpxveJu-BkaeqWbFL790thRaH4cV6g%40mail.gmail.com</a>.<br />
--001a11407132caded50547a1aba5--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Fri, 3 Feb 2017 07:13:42 -0800 (PST)
Raw View
------=_Part_636_1968795487.1486134822479
Content-Type: multipart/alternative;
boundary="----=_Part_637_1989600008.1486134822479"
------=_Part_637_1989600008.1486134822479
Content-Type: text/plain; charset=UTF-8
On Friday, February 3, 2017 at 7:35:40 AM UTC-5, Lorand Szollosi wrote:
>
> Hi,
>
> Like it, but miss some parens on the rhs of '=>', esp. because of
> precedence.
>
> Just an idea: gcc & clang & to some extend, intel cc already have ({ expr
> }} which 'has the value of' (definition on this differs per compiler) expr.
>
To me, that looks like someone is making a braced-init-list and putting it
inside (), which is ill-formed.
> If you said, [&](x, y) => ({ x < y }) as the new syntax, you could:
> - have a distinct paren type,
> - make it look familiar to those used to statement expressions,
>
Why not just standardize "statement expressions" as a separate proposal?
They have utility beyond just lambdas.
- solve most precedence issues,
>
Any precedence issues could be solved just as well with ().
- might optionally allow for ({ stmt; expr }) for some statement (perhaps
> step-by-step)
> - might optionally allow for ({ return expr; }), which returns to the
> caller of the context defining the lambda (think of e.g. accumulate() over
> range of ints via mul: you want to return early if you see a 0 in the
> input); UB if context is left,
>
No. That's too fragile.
- might optionally allow for break, continue or even throw,
> <cough>goto/switch in the defining context.
>
See above. Please don't try to make a different proposal conform to the
desires of your own pet feature.
--
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/72d31442-7f0e-4f66-9255-8c03a9625289%40isocpp.org.
------=_Part_637_1989600008.1486134822479
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Friday, February 3, 2017 at 7:35:40 AM UTC-5, Lorand Sz=
ollosi wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"auto"=
><div>Hi,</div><div><br></div><div>Like it, but miss some parens on the rhs=
of '=3D>', esp. because of precedence.</div><div><br></div><div=
>Just an idea: gcc & clang & to some extend, intel cc already have =
({ expr }} which 'has the value of' (definition on this differs per=
compiler) expr.</div></div></blockquote><div><br>To me, that looks like so=
meone is making a braced-init-list and putting it inside (), which is ill-f=
ormed.<br>=C2=A0</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"auto"><div>If you said, [&](x, y) =3D> ({ x < y }) as the new=
syntax, you could:</div><div>- have a distinct paren type,</div><div>- mak=
e it look familiar to those used to statement expressions,</div></div></blo=
ckquote><div><br>Why not just standardize "statement expressions"=
as a separate proposal? They have utility beyond just lambdas.<br><br></di=
v><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"auto"><div>- sol=
ve most precedence issues,</div></div></blockquote><div><br>Any precedence =
issues could be solved just as well with ().<br><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div dir=3D"auto"><div>- might optionally allow=
for ({ stmt; expr }) for some statement (perhaps step-by-step)</div><div>-=
might optionally allow for ({ return expr; }), which returns to the caller=
of the context defining the lambda (think of e.g. accumulate() over range =
of ints via mul: you want to return early if you see a 0 in the input); UB =
if context is left,</div></div></blockquote><div><br>No. That's too fra=
gile.<br><br></div><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=
"auto"><div>- might optionally allow for break, continue or even throw, <=
;cough>goto/switch in the defining context.</div></div></blockquote><div=
><br>See above. Please don't try to make a different proposal conform t=
o the desires of your own pet feature.</div><br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/72d31442-7f0e-4f66-9255-8c03a9625289%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/72d31442-7f0e-4f66-9255-8c03a9625289=
%40isocpp.org</a>.<br />
------=_Part_637_1989600008.1486134822479--
------=_Part_636_1968795487.1486134822479--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Fri, 3 Feb 2017 07:16:30 -0800 (PST)
Raw View
------=_Part_656_647760603.1486134990370
Content-Type: multipart/alternative;
boundary="----=_Part_657_1845304367.1486134990370"
------=_Part_657_1845304367.1486134990370
Content-Type: text/plain; charset=UTF-8
On Friday, February 3, 2017 at 10:09:43 AM UTC-5, Viacheslav Usov wrote:
>
> On Thu, Feb 2, 2017 at 11:22 PM, Nicol Bolas <jmck...@gmail.com
> <javascript:>> wrote:
>
>> On Wednesday, February 1, 2017 at 6:51:57 PM UTC-5, Barry Revzin wrote:
>>>
>>> I updated the proposal to expand on one of the ideas (using >> not only
>>> as a substitute for std::forward, but also in lambda-capture to decay-copy,
>>> adding the ability to capture parameter packs not only by value and
>>> reference but also by decay-copy) and narrow another (omitting type-names
>>> in lambdas only applies to those introduces with =>).
>>>
>>> If this seems reasonable and agreeable, I'd like to add it to the next
>>> mailing.
>>>
>>
>> Hmm. I really don't think the part about omitting the types is going to
>> fly, parsing wise. Basing it on the use of `=>` syntax requires look-ahead,
>> and that's an uphill battle. As a possible alternative, consider this:
>>
>> []:(x, ...y) {};
>>
>> One advantage of this is that, like `=>` syntax, you could also
>> theoretically apply it to regular functions:
>>
>> void func_name:(x, ...y) {}; //I'm a template!
>>
>> The big downside is that with `:()` syntax, you now have to come up with
>> new parsing rules for function parameters. Also, :( looks like an emoji.
>>
>
> I think your idea can be stated more generally as a way to decorate the
> *parameters-and-qualifiers* in some way that indicates the abbreviated
> syntax shall be expected there.
>
> Why can't we use the <> instead of () to that effect?
>
Because `<>` means "template parameters/arguments" not function
parameters/arguments.
--
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/a93ef297-6c36-456a-99f1-52982b8aa16d%40isocpp.org.
------=_Part_657_1845304367.1486134990370
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Friday, February 3, 2017 at 10:09:43 AM UTC-5, =
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"><div><div class=3D"gmail_quote">On Thu, Feb 2, 2017 at 11:22 PM, N=
icol Bolas <span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" =
gdf-obfuscated-mailto=3D"WZmLL-lzAQAJ" rel=3D"nofollow" onmousedown=3D"this=
..href=3D'javascript:';return true;" onclick=3D"this.href=3D'jav=
ascript:';return true;">jmck...@gmail.com</a>></span> wrote:<br><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">On Wednesday=
, February 1, 2017 at 6:51:57 PM UTC-5, Barry Revzin wrote:<blockquote clas=
s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid r=
gb(204,204,204);padding-left:1ex"><div dir=3D"ltr">I updated the proposal t=
o expand on one of the ideas (using >> not only as a substitute for s=
td::forward, but also in lambda-capture to decay-copy, adding the ability t=
o capture parameter packs not only by value and reference but also by decay=
-copy) and narrow another (omitting type-names in lambdas only applies to t=
hose introduces with =3D>).=C2=A0<div><br></div><div>If this seems reaso=
nable and agreeable, I'd like to add it to the next mailing.</div></div=
></blockquote><div><br>Hmm. I really don't think the part about omittin=
g the types is going to fly, parsing wise. Basing it on the use of `=3D>=
` syntax requires look-ahead, and that's an uphill battle. As a possibl=
e alternative, consider this:<br><br><div style=3D"background-color:rgb(250=
,250,250);border-color:rgb(187,187,187);border-style:solid;border-width:1px=
"><code><div><span style=3D"color:rgb(102,102,0)">[]:(</span><span style=3D=
"color:rgb(0,0,0)">x</span><span style=3D"color:rgb(102,102,0)">,</span><sp=
an style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(102,102,0)">=
....</span><span style=3D"color:rgb(0,0,0)">y</span><span style=3D"color:rgb=
(102,102,0)">)</span><span style=3D"color:rgb(0,0,0)"> </span><span style=
=3D"color:rgb(102,102,0)">{};</span></div></code></div><br>One advantage of=
this is that, like `=3D>` syntax, you could also theoretically apply it=
to regular functions:<br><br><div style=3D"background-color:rgb(250,250,25=
0);border-color:rgb(187,187,187);border-style:solid;border-width:1px"><code=
><div><span style=3D"color:rgb(0,0,136)">void</span><span style=3D"color:rg=
b(0,0,0)"> func_name</span><span style=3D"color:rgb(102,102,0)">:(</span><s=
pan style=3D"color:rgb(0,0,0)">x</span><span style=3D"color:rgb(102,102,0)"=
>,</span><span style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(=
102,102,0)">...</span><span style=3D"color:rgb(0,0,0)">y</span><span style=
=3D"color:rgb(102,102,0)">)</span><span style=3D"color:rgb(0,0,0)"> </span>=
<span style=3D"color:rgb(102,102,0)">{};</span><span style=3D"color:rgb(0,0=
,0)"> </span><span style=3D"color:rgb(136,0,0)">//I'm a template!</span=
></div></code></div><br>The big downside is that with `:()` syntax, you now=
have to come up with new parsing rules for function parameters. Also, :( l=
ooks like an emoji.</div></div></blockquote><div><br></div><div>I think you=
r idea can be stated more generally as a way to decorate the=C2=A0<i>parame=
ters-and-qualifiers</i> in some way that indicates the abbreviated syntax s=
hall be expected there.<br></div><div><br></div><div>Why can't we use t=
he <> instead of () to that effect?</div></div></div></div></blockquo=
te><div><br>Because `<>` means "template parameters/arguments&qu=
ot; not function parameters/arguments.</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/a93ef297-6c36-456a-99f1-52982b8aa16d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a93ef297-6c36-456a-99f1-52982b8aa16d=
%40isocpp.org</a>.<br />
------=_Part_657_1845304367.1486134990370--
------=_Part_656_647760603.1486134990370--
.
Author: Viacheslav Usov <via.usov@gmail.com>
Date: Fri, 3 Feb 2017 16:30:21 +0100
Raw View
--94eb2c0639e8cd1ee40547a1f5b3
Content-Type: text/plain; charset=UTF-8
On Fri, Feb 3, 2017 at 4:16 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
> Because `<>` means "template parameters/arguments" not function
parameters/arguments.
Not after a lambda introducer.
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/CAA7YVg1x6%2BtT8%3DcA%2BKV1m5Ob8CY%3DU%3D1MjkRBrBYKCjwbvyJVgw%40mail.gmail.com.
--94eb2c0639e8cd1ee40547a1f5b3
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, Feb 3, 2017 at 4:16 PM, Nicol Bolas <span dir=3D"ltr"><<a href=3D"ma=
ilto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>></sp=
an> wrote:<br><div><br></div><div>> Because `<>` means "templ=
ate parameters/arguments" not function parameters/arguments.</div><div=
><br></div><div>Not after a lambda introducer.</div><div><br></div><div>Che=
ers,</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" 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/CAA7YVg1x6%2BtT8%3DcA%2BKV1m5Ob8CY%3D=
U%3D1MjkRBrBYKCjwbvyJVgw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Df=
ooter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg=
1x6%2BtT8%3DcA%2BKV1m5Ob8CY%3DU%3D1MjkRBrBYKCjwbvyJVgw%40mail.gmail.com</a>=
..<br />
--94eb2c0639e8cd1ee40547a1f5b3--
.
Author: Barry Revzin <barry.revzin@gmail.com>
Date: Fri, 3 Feb 2017 07:51:41 -0800 (PST)
Raw View
------=_Part_2072_1633164953.1486137101281
Content-Type: multipart/alternative;
boundary="----=_Part_2073_2057835143.1486137101281"
------=_Part_2073_2057835143.1486137101281
Content-Type: text/plain; charset=UTF-8
>
>
> Hmm. I really don't think the part about omitting the types is going to
> fly, parsing wise. Basing it on the use of `=>` syntax requires look-ahead,
> and that's an uphill battle. As a possible alternative, consider this:
>
> []:(x, ...y) {};
>
>
Introducing identifiers with any type annotation is an uphill battle. The
lookahead parsing is maybe just a side-skirmish? There's a lot of different
directions we could take towards allowing the lack of type annotation:
[](x, y) => x > y // this proposal
[]@(x, y) => x > y // : or any other identifier before the parameter
list as a marking
// to indicate that there's no type on any of the
parameters
[](@x, @y) => x > y // some marking on the parameters themselves to
indicate that there's
// no type (like : or ^ or %, probably not & or *)
[](&&x, &&y) => x > y // this is actually in the original generic lambda
proposal: making
// the type-specifier optional.
All of those seem fine to me and I believe are better than having to write
out auto&& everywhere.
--
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/4f050b88-5176-4451-a77f-5cd8925c4f59%40isocpp.org.
------=_Part_2073_2057835143.1486137101281
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><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"><div><br>Hmm. I really don't think the part about omitting the type=
s is going to fly, parsing wise. Basing it on the use of `=3D>` syntax r=
equires look-ahead, and that's an uphill battle. As a possible alternat=
ive, consider this:<br><br><div style=3D"background-color:rgb(250,250,250);=
border-color:rgb(187,187,187);border-style:solid;border-width:1px"><code><d=
iv><span style=3D"color:#660">[]:(</span><span style=3D"color:#000">x</span=
><span style=3D"color:#660">,</span><span style=3D"color:#000"> </span><spa=
n style=3D"color:#660">...</span><span style=3D"color:#000">y</span><span s=
tyle=3D"color:#660">)</span><span style=3D"color:#000"> </span><span style=
=3D"color:#660">{};</span></div></code></div><br></div></div></blockquote><=
div><br></div><div>Introducing identifiers with any type annotation is an u=
phill battle. The lookahead parsing is maybe just a side-skirmish? There=
9;s a lot of different directions we could take towards allowing the lack o=
f type annotation:</div><div><br></div><div><div class=3D"prettyprint" styl=
e=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187)=
; border-style: solid; border-width: 1px; word-wrap: break-word;"><code cla=
ss=3D"prettyprint"><div class=3D"subprettyprint"><font color=3D"#000000"><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">[](</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify">x</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> y</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">=3D></span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> x </span><span style=3D"color: #660;" class=3D"styled-by-prettify">>=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> y =C2=A0 =
=C2=A0 </span><span style=3D"color: #800;" class=3D"styled-by-prettify">// =
this proposal</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"><br></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;" class=3D"styled-by-prettify">,</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> y</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">)</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">=3D></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-pr=
ettify"> y =C2=A0 =C2=A0</span><span style=3D"color: #800;" class=3D"styled=
-by-prettify">// : or any other identifier before the parameter list as a m=
arking</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 </span><span style=3D"color: #800;" class=3D"styled-by-prettify">// to =
indicate that there's no type on any of the parameters</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">[](</span><span style=3D"color: #=
066;" 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">@y</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">=3D></span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> x </span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">></span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> y =C2=A0 </span><span style=3D"c=
olor: #800;" class=3D"styled-by-prettify">// some marking on the parameters=
themselves to indicate that there's</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color: #800;" cla=
ss=3D"styled-by-prettify">// no type (like : or ^ or %, probably not & =
or *)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">[](&&am=
p;</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 sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">&&</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify">y</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">=3D></span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> x </span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">></span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
y </span><span style=3D"color: #800;" class=3D"styled-by-prettify">// this =
is actually in the original generic lambda proposal: making</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=
=3D"color: #800;" class=3D"styled-by-prettify">// the type-</span><span sty=
le=3D"color: #800;" class=3D"styled-by-prettify">specifier optional. </span=
></font></div></code></div><br>=C2=A0All of those seem fine to me and I bel=
ieve are better than having to write out auto&& everywhere.=C2=A0</=
div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/4f050b88-5176-4451-a77f-5cd8925c4f59%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/4f050b88-5176-4451-a77f-5cd8925c4f59=
%40isocpp.org</a>.<br />
------=_Part_2073_2057835143.1486137101281--
------=_Part_2072_1633164953.1486137101281--
.
Author: Barry Revzin <barry.revzin@gmail.com>
Date: Fri, 3 Feb 2017 07:55:28 -0800 (PST)
Raw View
------=_Part_2176_866378517.1486137328476
Content-Type: multipart/alternative;
boundary="----=_Part_2177_603469298.1486137328476"
------=_Part_2177_603469298.1486137328476
Content-Type: text/plain; charset=UTF-8
>
> Like it, but miss some parens on the rhs of '=>', esp. because of
> precedence.
>
You could always write them. I don't see the need for them though.
>
> Just an idea: gcc & clang & to some extend, intel cc already have ({ expr
> }} which 'has the value of' (definition on this differs per compiler) expr.
> If you said, [&](x, y) => ({ x < y }) as the new syntax, you could:
>
- have a distinct paren type,
> - make it look familiar to those used to statement expressions,
> - solve most precedence issues,
> - might optionally allow for ({ stmt; expr }) for some statement (perhaps
> step-by-step)
>
The problem is that without core language support, the
statement-expressions aren't super useful. There's no copy-elision there.
And statement-expressions would be a large language change that's worthy of
a large proposal.
> - might optionally allow for ({ return expr; }), which returns to the
> caller of the context defining the lambda (think of e.g. accumulate() over
> range of ints via mul: you want to return early if you see a 0 in the
> input); UB if context is left,
> - might optionally allow for break, continue or even throw,
> <cough>goto/switch in the defining context.
>
> Thus you could capture continuation replacing statements. All the rest I'd
> keep the same in the proposal, I really like the idea of simplified lambdas.
>
>
I still don't understand what any of this means, sorry.
--
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/dbd6261f-e61f-46fb-a345-9e89f81e0fa2%40isocpp.org.
------=_Part_2177_603469298.1486137328476
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><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"a=
uto"><div>Like it, but miss some parens on the rhs of '=3D>', es=
p. because of precedence.<br></div></div></blockquote><div><br></div><div>Y=
ou could always write them. I don't see the need for them though.</div>=
<div>=C2=A0</div><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"a=
uto"><div></div><div><br></div><div>Just an idea: gcc & clang & to =
some extend, intel cc already have ({ expr }} which 'has the value of&#=
39; (definition on this differs per compiler) expr. If you said, [&](x,=
y) =3D> ({ x < y }) as the new syntax, you could:</div></div></block=
quote><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"auto"><div>-=
have a distinct paren type,</div><div>- make it look familiar to those use=
d to statement expressions,</div><div>- solve most precedence issues,</div>=
<div>- might optionally allow for ({ stmt; expr }) for some statement (perh=
aps step-by-step)</div></div></blockquote><div><br></div><div>The problem i=
s that without core language support, the statement-expressions aren't =
super useful. There's no copy-elision there. And statement-expressions =
would be a large language change that's worthy of a large proposal.<br>=
</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div di=
r=3D"auto"><div>- might optionally allow for ({ return expr; }), which retu=
rns to the caller of the context defining the lambda (think of e.g. accumul=
ate() over range of ints via mul: you want to return early if you see a 0 i=
n the input); UB if context is left,</div><div>- might optionally allow for=
break, continue or even throw, <cough>goto/switch in the defining co=
ntext.</div><div><br></div><div>Thus you could capture continuation replaci=
ng statements. All the rest I'd keep the same in the proposal, I really=
like the idea of simplified lambdas.</div><div><br></div></div></blockquot=
e><div><br></div><div>I still don't understand what any of this means, =
sorry. =C2=A0</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/dbd6261f-e61f-46fb-a345-9e89f81e0fa2%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/dbd6261f-e61f-46fb-a345-9e89f81e0fa2=
%40isocpp.org</a>.<br />
------=_Part_2177_603469298.1486137328476--
------=_Part_2176_866378517.1486137328476--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Fri, 3 Feb 2017 08:50:17 -0800 (PST)
Raw View
------=_Part_2353_1539638202.1486140617640
Content-Type: multipart/alternative;
boundary="----=_Part_2354_676997018.1486140617641"
------=_Part_2354_676997018.1486140617641
Content-Type: text/plain; charset=UTF-8
On Friday, February 3, 2017 at 10:51:41 AM UTC-5, Barry Revzin wrote:
>
>
>> Hmm. I really don't think the part about omitting the types is going to
>> fly, parsing wise. Basing it on the use of `=>` syntax requires look-ahead,
>> and that's an uphill battle. As a possible alternative, consider this:
>>
>> []:(x, ...y) {};
>>
>>
> Introducing identifiers with any type annotation is an uphill battle. The
> lookahead parsing is maybe just a side-skirmish? There's a lot of different
> directions we could take towards allowing the lack of type annotation:
>
> [](x, y) => x > y // this proposal
> []@(x, y) => x > y // : or any other identifier before the parameter
> list as a marking
> // to indicate that there's no type on any of the
> parameters
> [](@x, @y) => x > y // some marking on the parameters themselves to
> indicate that there's
> // no type (like : or ^ or %, probably not & or *)
> [](&&x, &&y) => x > y // this is actually in the original generic lambda
> proposal: making
> // the type-specifier optional.
>
> All of those seem fine to me and I believe are better than having to
> write out auto&& everywhere.
>
Then your proposal should indicate that you're flexible with how this gets
handled. You should list out various alternatives, because I strongly
suspect that idea as is will be considered to require too much parsing work
to be allowed. It would be good to have a fallback should that happen.
--
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/5ee422d0-9c4f-4793-a1f4-1c4d728ec582%40isocpp.org.
------=_Part_2354_676997018.1486140617641
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Friday, February 3, 2017 at 10:51:41 AM UTC-5, Barry Re=
vzin 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"><b=
lockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-=
left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><br>Hmm. I real=
ly don't think the part about omitting the types is going to fly, parsi=
ng wise. Basing it on the use of `=3D>` syntax requires look-ahead, and =
that's an uphill battle. As a possible alternative, consider this:<br><=
br><div style=3D"background-color:rgb(250,250,250);border-color:rgb(187,187=
,187);border-style:solid;border-width:1px"><code><div><span style=3D"color:=
#660">[]:(</span><span style=3D"color:#000">x</span><span style=3D"color:#6=
60">,</span><span style=3D"color:#000"> </span><span style=3D"color:#660">.=
...</span><span style=3D"color:#000">y</span><span style=3D"color:#660">)</s=
pan><span style=3D"color:#000"> </span><span style=3D"color:#660">{};</span=
></div></code></div><br></div></div></blockquote><div><br></div><div>Introd=
ucing identifiers with any type annotation is an uphill battle. The lookahe=
ad parsing is maybe just a side-skirmish? There's a lot of different di=
rections we could take towards allowing the lack of type annotation:</div><=
div><br></div><div><div style=3D"background-color:rgb(250,250,250);border-c=
olor:rgb(187,187,187);border-style:solid;border-width:1px;word-wrap:break-w=
ord"><code><div><font color=3D"#000000"><span style=3D"color:#660">[](</spa=
n><span style=3D"color:#000">x</span><span style=3D"color:#660">,</span><sp=
an style=3D"color:#000"> y</span><span style=3D"color:#660">)</span><span s=
tyle=3D"color:#000"> </span><span style=3D"color:#660">=3D></span><span =
style=3D"color:#000"> x </span><span style=3D"color:#660">></span><span =
style=3D"color:#000"> y =C2=A0 =C2=A0 </span><span style=3D"color:#800">// =
this proposal</span><span style=3D"color:#000"><br></span><span style=3D"co=
lor:#660">[]@(</span><span style=3D"color:#000">x</span><span style=3D"colo=
r:#660">,</span><span style=3D"color:#000"> y</span><span style=3D"color:#6=
60">)</span><span style=3D"color:#000"> </span><span style=3D"color:#660">=
=3D></span><span style=3D"color:#000"> x </span><span style=3D"color:#66=
0">></span><span style=3D"color:#000"> y =C2=A0 =C2=A0</span><span style=
=3D"color:#800">// : or any other identifier before the parameter list as a=
marking</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"colo=
r:#800">// to indicate that there's no type on any of the parameters</s=
pan><span style=3D"color:#000"><br></span><span style=3D"color:#660">[](</s=
pan><span style=3D"color:#066">@x</span><span style=3D"color:#660">,</span>=
<span style=3D"color:#000"> </span><span style=3D"color:#066">@y</span><spa=
n style=3D"color:#660">)</span><span style=3D"color:#000"> </span><span sty=
le=3D"color:#660">=3D></span><span style=3D"color:#000"> x </span><span =
style=3D"color:#660">></span><span style=3D"color:#000"> y =C2=A0 </span=
><span style=3D"color:#800">// some marking on the parameters themselves to=
indicate that there's</span><span style=3D"color:#000"><br>=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><=
span style=3D"color:#800">// no type (like : or ^ or %, probably not & =
or *)</span><span style=3D"color:#000"><br></span><span style=3D"color:#660=
">[](&&</span><span style=3D"color:#000">x</span><span style=3D"col=
or:#660">,</span><span style=3D"color:#000"> </span><span style=3D"color:#6=
60">&&</span><span style=3D"color:#000">y</span><span style=3D"colo=
r:#660">)</span><span style=3D"color:#000"> </span><span style=3D"color:#66=
0">=3D></span><span style=3D"color:#000"> x </span><span style=3D"color:=
#660">></span><span style=3D"color:#000"> y </span><span style=3D"color:=
#800">// this is actually in the original generic lambda proposal: making</=
span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color:#800">//=
the type-</span><span style=3D"color:#800">specifier optional. </span></fo=
nt></div></code></div><br>=C2=A0All of those seem fine to me and I believe =
are better than having to write out auto&& everywhere.</div></div><=
/blockquote><div><br>Then your proposal should indicate that you're fle=
xible with how this gets handled. You should list out various alternatives,=
because I strongly suspect that idea as is will be considered to require t=
oo much parsing work to be allowed. It would be good to have a fallback sho=
uld that happen.<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/5ee422d0-9c4f-4793-a1f4-1c4d728ec582%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5ee422d0-9c4f-4793-a1f4-1c4d728ec582=
%40isocpp.org</a>.<br />
------=_Part_2354_676997018.1486140617641--
------=_Part_2353_1539638202.1486140617640--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Fri, 3 Feb 2017 08:53:39 -0800 (PST)
Raw View
------=_Part_2276_969732360.1486140819797
Content-Type: multipart/alternative;
boundary="----=_Part_2277_1494204082.1486140819798"
------=_Part_2277_1494204082.1486140819798
Content-Type: text/plain; charset=UTF-8
On Friday, February 3, 2017 at 10:30:24 AM UTC-5, Viacheslav Usov wrote:
>
> On Fri, Feb 3, 2017 at 4:16 PM, Nicol Bolas <jmck...@gmail.com
> <javascript:>> wrote:
>
> > Because `<>` means "template parameters/arguments" not function
> parameters/arguments.
>
> Not after a lambda introducer.
>
I'm not saying it poses a parsing problem. I'm saying it poses a human
recognition problem.
We shouldn't use something just because it's a syntax that works. It should
be a syntax that will not introduce confusion in users. Historically, <>
means template stuff. We should preserve that meaning.
This is also part of why I'm against template induction syntax from
Concepts TS: it makes {} mean template stuff too. It does so not because
it's a good, recognizable idea, but merely because it's a parse-able and
unambiguous 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/c279f22b-f4b7-41ea-9881-930be25b93f4%40isocpp.org.
------=_Part_2277_1494204082.1486140819798
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Friday, February 3, 2017 at 10:30:24 AM UTC-5, Viachesl=
av Usov wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
><div><div class=3D"gmail_quote">On Fri, Feb 3, 2017 at 4:16 PM, Nicol Bola=
s <span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-obfus=
cated-mailto=3D"EE9WJwp1AQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&=
#39;javascript:';return true;" onclick=3D"this.href=3D'javascript:&=
#39;;return true;">jmck...@gmail.com</a>></span> wrote:<br><div><br></di=
v><div>> Because `<>` means "template parameters/arguments&qu=
ot; not function parameters/arguments.</div><div><br></div><div>Not after a=
lambda introducer.</div></div></div></div></blockquote><div><br></div>I=
9;m not saying it poses a parsing problem. I'm saying it poses a human =
recognition problem.<br><br>We shouldn't use something just because it&=
#39;s a syntax that works. It should be a syntax that will not introduce co=
nfusion in users. Historically, <> means template stuff. We should pr=
eserve that meaning.<br><br>This is also part of why I'm against templa=
te induction syntax from Concepts TS: it makes {} mean template stuff too. =
It does so not because it's a good, recognizable idea, but merely becau=
se it's a parse-able and unambiguous syntax.<br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/c279f22b-f4b7-41ea-9881-930be25b93f4%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c279f22b-f4b7-41ea-9881-930be25b93f4=
%40isocpp.org</a>.<br />
------=_Part_2277_1494204082.1486140819798--
------=_Part_2276_969732360.1486140819797--
.
Author: Viacheslav Usov <via.usov@gmail.com>
Date: Fri, 3 Feb 2017 18:14:05 +0100
Raw View
--94eb2c0639e8c56a970547a36832
Content-Type: text/plain; charset=UTF-8
On Fri, Feb 3, 2017 at 5:53 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
> We shouldn't use something just because it's a syntax that works. It
should be a syntax that will not introduce confusion in users.
Historically, <> means template stuff. We should preserve that meaning.
Frankly, [] historically meant arrays, so the "historically means" argument
is pretty weak. Besides, <> means template stuff only when it follows some
name, and the stuff within <> would be made of pairs in that case, which
(to me) is very different from []<a, b>.
Then, those generic typeless arguments are related to templates. So there
is a connection. We can even call abbreviated lambdas "template
expressions" to make that connection stronger :)
Finally, the whole point of this thread is abbreviation. Decorating
*parameters-and-qualifiers* with additional symbols is kind of backward
here.
Using a different kind of lambda introducer might be a better way, but I
seem to remember that was discussed with an earlier version of the proposal.
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/CAA7YVg1v47naMGkkC%3D2ja63q8yaqYPfV1k64XRQOmozNd8JH6A%40mail.gmail.com.
--94eb2c0639e8c56a970547a36832
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, Feb 3, 2017 at 5:53 PM, Nicol Bolas <span dir=3D"ltr"><<a href=3D"ma=
ilto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>></sp=
an> wrote:<br><div><br></div><div>> We shouldn't use something just =
because it's a syntax that works. It should be a syntax that will not i=
ntroduce confusion in users. Historically, <> means template stuff. W=
e should preserve that meaning.</div><div><br></div><div><div>Frankly, [] h=
istorically meant arrays, so the "historically means" argument is=
pretty weak. Besides, <> means template stuff only when it follows s=
ome name, and the stuff within <> would be made of pairs in that case=
, which (to me) is very different from []<a, b>.</div><div><br></div>=
</div><div>Then, those generic typeless arguments are related to templates.=
So there is a connection. We can even call abbreviated lambdas "templ=
ate expressions" to make that connection stronger :)</div><div><br></d=
iv><div>Finally, the whole point of this thread is abbreviation. Decorating=
=C2=A0<i style=3D"font-size:12.8px">parameters-and-qualifiers</i>=C2=A0with=
additional symbols is kind of backward here.</div><div><br></div><div>Usin=
g a different kind of lambda introducer might be a better way, but I seem t=
o remember that was discussed with an earlier version of the proposal.</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" 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/CAA7YVg1v47naMGkkC%3D2ja63q8yaqYPfV1k=
64XRQOmozNd8JH6A%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg1v47naMG=
kkC%3D2ja63q8yaqYPfV1k64XRQOmozNd8JH6A%40mail.gmail.com</a>.<br />
--94eb2c0639e8c56a970547a36832--
.
Author: Barry Revzin <barry.revzin@gmail.com>
Date: Fri, 3 Feb 2017 09:22:19 -0800 (PST)
Raw View
------=_Part_2259_83515369.1486142539131
Content-Type: multipart/alternative;
boundary="----=_Part_2260_1836861222.1486142539131"
------=_Part_2260_1836861222.1486142539131
Content-Type: text/plain; charset=UTF-8
On Friday, February 3, 2017 at 9:30:24 AM UTC-6, Viacheslav Usov wrote:
>
> On Fri, Feb 3, 2017 at 4:16 PM, Nicol Bolas <jmck...@gmail.com
> <javascript:>> wrote:
>
> > Because `<>` means "template parameters/arguments" not function
> parameters/arguments.
>
> Not after a lambda introducer.
>
> Cheers,
> V.
>
There's also
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0428r0.pdf, which
I think was positively received in Issaquah.
--
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/e10e3f92-10da-44a7-a790-605fafa7a346%40isocpp.org.
------=_Part_2260_1836861222.1486142539131
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br>On Friday, February 3, 2017 at 9:30:24 AM UTC-6, Viach=
eslav Usov 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"><div><div class=3D"gmail_quote">On Fri, Feb 3, 2017 at 4:16 PM, Nicol B=
olas <span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-ob=
fuscated-mailto=3D"EE9WJwp1AQAJ" rel=3D"nofollow" onmousedown=3D"this.href=
=3D'javascript:';return true;" onclick=3D"this.href=3D'javascri=
pt:';return true;">jmck...@gmail.com</a>></span> wrote:<br><div><br>=
</div><div>> Because `<>` means "template parameters/argument=
s" not function parameters/arguments.</div><div><br></div><div>Not aft=
er a lambda introducer.</div><div><br></div><div>Cheers,</div><div>V.</div>=
</div></div></div></blockquote><div><br></div><div>There's also http://=
www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0428r0.pdf, which I think=
was positively received in Issaquah.=C2=A0</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/e10e3f92-10da-44a7-a790-605fafa7a346%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e10e3f92-10da-44a7-a790-605fafa7a346=
%40isocpp.org</a>.<br />
------=_Part_2260_1836861222.1486142539131--
------=_Part_2259_83515369.1486142539131--
.
Author: <via.usov@gmail.com>
Date: Fri, 3 Feb 2017 19:23:49 +0100
Raw View
--_4A4FFA7E-231E-4C43-B26A-4B75F0E52504_
Content-Type: text/plain; charset=UTF-8
Or we can just do away with the entire parenthetical block and specify abbreviated parameters in the square bracket block after some delimiter. For example:
[a, b : c, d] a + b + c + d
Here, a and b are captures, and c and d are arguments.
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/5894cae9.b296df0a.eab4e.2d22%40mx.google.com.
--_4A4FFA7E-231E-4C43-B26A-4B75F0E52504_
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" xmlns:w=3D"urn:sc=
hemas-microsoft-com:office:word" xmlns:m=3D"http://schemas.microsoft.com/of=
fice/2004/12/omml" xmlns=3D"http://www.w3.org/TR/REC-html40"><head><meta ht=
tp-equiv=3DContent-Type content=3D"text/html; charset=3Dutf-8"><meta name=
=3DGenerator 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:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
span.styled-by-prettify
{mso-style-name:styled-by-prettify;}
..MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style></head><body lang=3DEN-GB link=3Dblue vlink=3D"#954F72"><div cla=
ss=3DWordSection1><p class=3DMsoNormal><o:p> </o:p></p><div><div><p cl=
ass=3DMsoNormal>Or we can just do away with the entire parenthetical block =
and specify abbreviated parameters in the square bracket block after some d=
elimiter. For example:</p></div></div><p class=3DMsoNormal><o:p> </o:p=
></p><p class=3DMsoNormal>[a, b : c, d] a + b + c + d<o:p></o:p></p><p clas=
s=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>Here, a and b are c=
aptures, and c and d are arguments.<o:p></o:p></p><p class=3DMsoNormal><o:p=
> </o:p></p><p class=3DMsoNormal>Cheers,<o:p></o:p></p><p class=3DMsoN=
ormal>V.<o:p></o:p></p></div></body></html>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/5894cae9.b296df0a.eab4e.2d22%40mx.goo=
gle.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/a=
/isocpp.org/d/msgid/std-proposals/5894cae9.b296df0a.eab4e.2d22%40mx.google.=
com</a>.<br />
--_4A4FFA7E-231E-4C43-B26A-4B75F0E52504_--
.
Author: Avi Kivity <avi@scylladb.com>
Date: Fri, 3 Feb 2017 21:34:35 +0200
Raw View
On 02/02/2017 01:51 AM, Barry Revzin wrote:
> I updated the proposal to expand on one of the ideas (using >> not
> only as a substitute for std::forward, but also in lambda-capture to
> decay-copy, adding the ability to capture parameter packs not only by
> value and reference but also by decay-copy) and narrow another
> (omitting type-names in lambdas only applies to those introduces with
> =>).
>
> If this seems reasonable and agreeable, I'd like to add it to the next
> mailing.
A suggestion: add move-captures
[&&x] ()
is equivalent to
[x = std::move(x)] () mutable
and perhaps also [&&] to set the capture default.
This is used extensively in asynchronous coding.
--
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/bdaf4c83-9bac-18d9-687d-9d7b89ac8f86%40scylladb.com.
.
Author: Lorand Szollosi <szollosi.lorand@gmail.com>
Date: Fri, 3 Feb 2017 22:22:10 +0100
Raw View
--Apple-Mail-D3C2E0C9-1772-4F7C-BE8B-94695134F798
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Hi,
Based on the below, why not just let '@' equals 'auto&&' everywhere (and ma=
ybe introduce a digraph if really needed)?
Thanks,
-lorro
2017. febr. 3. d=C3=A1tummal, 16:51 id=C5=91pontban Barry Revzin <barry.rev=
zin@gmail.com> =C3=ADrta:
>>=20
>> Hmm. I really don't think the part about omitting the types is going to =
fly, parsing wise. Basing it on the use of `=3D>` syntax requires look-ahea=
d, and that's an uphill battle. As a possible alternative, consider this:
>>=20
>> []:(x, ...y) {};
>>=20
>=20
> Introducing identifiers with any type annotation is an uphill battle. The=
lookahead parsing is maybe just a side-skirmish? There's a lot of differen=
t directions we could take towards allowing the lack of type annotation:
>=20
> [](x, y) =3D> x > y // this proposal
> []@(x, y) =3D> x > y // : or any other identifier before the parameter=
list as a marking
> // to indicate that there's no type on any of the p=
arameters
> [](@x, @y) =3D> x > y // some marking on the parameters themselves to i=
ndicate that there's
> // no type (like : or ^ or %, probably not & or *)
> [](&&x, &&y) =3D> x > y // this is actually in the original generic lambd=
a proposal: making
> // the type-specifier optional.
>=20
> All of those seem fine to me and I believe are better than having to wri=
te out auto&& everywhere.=20
> --=20
> You received this message because you are subscribed to a topic in the Go=
ogle Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.=
org/d/topic/std-proposals/uu7mRNXnf8Q/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to std-p=
roposals+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/isoc=
pp.org/d/msgid/std-proposals/4f050b88-5176-4451-a77f-5cd8925c4f59%40isocpp.=
org.
--=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/40F54FC3-8D2B-4BDB-AB1E-7C52154B5A72%40gmail.com=
..
--Apple-Mail-D3C2E0C9-1772-4F7C-BE8B-94695134F798
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=
=3Dutf-8"></head><body dir=3D"auto"><div>Hi,<br></div><div id=3D"AppleMailS=
ignature"><br></div><div id=3D"AppleMailSignature">Based on the below, why =
not just let '@' equals 'auto&&' everywhere (and maybe introduce a =
digraph if really needed)?</div><div id=3D"AppleMailSignature"><br></div><d=
iv id=3D"AppleMailSignature">Thanks,</div><div id=3D"AppleMailSignature">-l=
orro</div><div><br>2017. febr. 3. d=C3=A1tummal, 16:51 id=C5=91pontban Barr=
y Revzin <<a href=3D"mailto:barry.revzin@gmail.com">barry.revzin@gmail.c=
om</a>> =C3=ADrta:<br><br></div><blockquote type=3D"cite"><div><div dir=
=3D"ltr"><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"><div=
><br>Hmm. I really don't think the part about omitting the types is going t=
o fly, parsing wise. Basing it on the use of `=3D>` syntax requires look=
-ahead, and that's an uphill battle. As a possible alternative, consider th=
is:<br><br><div style=3D"background-color:rgb(250,250,250);border-color:rgb=
(187,187,187);border-style:solid;border-width:1px"><code><div><span style=
=3D"color:#660">[]:(</span><span style=3D"color:#000">x</span><span style=
=3D"color:#660">,</span><span style=3D"color:#000"> </span><span style=3D"c=
olor:#660">...</span><span style=3D"color:#000">y</span><span style=3D"colo=
r:#660">)</span><span style=3D"color:#000"> </span><span style=3D"color:#66=
0">{};</span></div></code></div><br></div></div></blockquote><div><br></div=
><div>Introducing identifiers with any type annotation is an uphill battle.=
The lookahead parsing is maybe just a side-skirmish? There's a lot of diff=
erent directions we could take towards allowing the lack of type annotation=
:</div><div><br></div><div><div class=3D"prettyprint" style=3D"background-c=
olor: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: s=
olid; border-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint=
"><div class=3D"subprettyprint"><font color=3D"#000000"><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">[](</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"style=
d-by-prettify"> y</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D></sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> x </span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">></span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> y </span><sp=
an style=3D"color: #800;" class=3D"styled-by-prettify">// this proposal</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">[]@(</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify">x</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> y</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">=3D></span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> x </span><span style=3D"color: #660;" class=3D"styled-by-prettify">>=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> y =
</span><span style=3D"color: #800;" class=3D"styled-by-prettify">// :=
or any other identifier before the parameter list as a marking</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify"><br> &nbs=
p; </span><span sty=
le=3D"color: #800;" class=3D"styled-by-prettify">// to indicate that there'=
s no type on any of the parameters</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: #066;" class=3D"styled-by=
-prettify">@x</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </spa=
n><span style=3D"color: #066;" class=3D"styled-by-prettify">@y</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">=3D></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"st=
yled-by-prettify"> y </span><span style=3D"color: #800;" class=3D"st=
yled-by-prettify">// some marking on the parameters themselves to indicate =
that there's</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"><br> =
</span><span style=3D"color: #800;" class=3D"styled-by-prettify">//=
no type (like : or ^ or %, probably not & or *)</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">[](&&</span><span style=3D"colo=
r: #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"> </span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">&&</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify">y</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D></span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> x </span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">></span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> y </span><span style=3D"color:=
#800;" class=3D"styled-by-prettify">// this is actually in the original ge=
neric lambda proposal: making</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br> &nb=
sp; </span><span style=3D"color: #800;" class=3D"style=
d-by-prettify">// the type-</span><span style=3D"color: #800;" class=3D"sty=
led-by-prettify">specifier optional. </span></font></div></code></div><br>&=
nbsp;All of those seem fine to me and I believe are better than having to w=
rite out auto&& everywhere. </div></div>
<p></p>
-- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/uu7mRNXnf8Q/unsubscribe">https://groups.=
google.com/a/isocpp.org/d/topic/std-proposals/uu7mRNXnf8Q/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">std-proposals+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/4f050b88-5176-4451-a77f-5cd8925c4f59%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.goo=
gle.com/a/isocpp.org/d/msgid/std-proposals/4f050b88-5176-4451-a77f-5cd8925c=
4f59%40isocpp.org</a>.<br>
</div></blockquote></body></html>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/40F54FC3-8D2B-4BDB-AB1E-7C52154B5A72%=
40gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/40F54FC3-8D2B-4BDB-AB1E-7C52154B5A72%=
40gmail.com</a>.<br />
--Apple-Mail-D3C2E0C9-1772-4F7C-BE8B-94695134F798--
.
Author: Vittorio Romeo <vittorio.romeo.vee@gmail.com>
Date: Sat, 25 Mar 2017 06:43:45 -0700 (PDT)
Raw View
------=_Part_3390_351504557.1490449425745
Content-Type: multipart/alternative;
boundary="----=_Part_3391_1298781384.1490449425745"
------=_Part_3391_1298781384.1490449425745
Content-Type: text/plain; charset=UTF-8
Are there any news regarding this proposal? (https://wg21.link/p0573)
I'm really really looking forward to this, as it would not only improve
code readability immensely, but also open up opportunities for terse and
intuitive syntax.
However, one thing that I think would be very important to add to the
proposal is the ability to use compound statements after =>.
As far as I can see, the proposed new syntax only allows:
[captures...](args...) => expr
// would expand to
[captures...](args...) -> decltype(expr) { return expr; }
I propose an extension of that, which would support arbitrary compound
statements:
[captures...](args...) => { body; }
// would expand to
[captures...](args...) -> decltype(body, void()) { body; }
In case of multiple statements, multiple `decltype` clauses would be
generated:
[captures...](args...) => { s0; s1; s2; }
// would expand to
[captures...](args...) -> decltype(s0, s1, s2, void()) { s0; s1; s2; }
In case of a final return, the generated trailing return type would not
have the final `void()`:
[captures...](args...) => { s0; s1; return s2; }
// would expand to
[captures...](args...) -> decltype(s0, s1, s2) { s0; s1; return s2; }
As an example, having SFINAE-friendly lambdas with blocks could allow
recursive variant visitation to be implemented as follows:
// With a example `json` variant type whose alternatives are:
// * double
// * string
// * vector<json>
// * map<string, json>
json j = get_json_response();
match(j)([](double x) => { /* ... */ },
[](string x) => { /* ... */ },
[](auto recurse, vector<json> x) => { /* ... */ for(auto& v :
x) recurse(v); },
[](auto recurse, map<string, json> x) => { /* ... */ for(auto& [_,v
] : x) recurse(v); });
This is problematic to achieve without this proposal as trying to deduce
the arity of a non-SFINAE-friendly lambda can result in an hard error.
(The arity of the visitation branches are used to differentiate between the
base and recursive cases.)
If the block is complicated (e.g. it contains multiple return statements
constrained by `if constexpr(...)`) then the trailing return generation
would get trickier.
I think that P0315 (wg21.link/p0315) "Lambdas in unevaluated contexts"
could help here:
[captures...](args...) => { complex_body; }
// would expand to (with P0315)
[captures...](args...) -> decltype([captures...](Ts... xs){ complex_body; }(
std::declval<Ts>(xs)...)) { complex_body; }
--
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/58f91913-840f-439f-80b3-9f274b237736%40isocpp.org.
------=_Part_3391_1298781384.1490449425745
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Are there any news regarding this proposal? (<a href=3D"ht=
tps://wg21.link/p0573">https://wg21.link/p0573</a>)<br><br>I'm really r=
eally looking forward to this, as it would not only improve code readabilit=
y immensely, but also open up opportunities for terse and intuitive syntax.=
<br>However, one thing that I think would be very important to add to the p=
roposal is the ability to use compound statements after =3D>.<br><br>As =
far as I can see, the proposed new syntax only allows:<br><div class=3D"pre=
ttyprint" style=3D"background-color: rgb(250, 250, 250); border-color: rgb(=
187, 187, 187); border-style: solid; border-width: 1px; word-wrap: break-wo=
rd;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=
=3D"color: #660;" class=3D"styled-by-prettify">[</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify">captures</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">...](</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify">args</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">...)</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">=3D></span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> expr</span><font color=3D"#000000"><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"><br></span><span style=3D"color: #800;" class=3D"=
styled-by-prettify">// would expand to</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"><br></span></font><span style=3D"color: #660;" =
class=3D"styled-by-prettify">[</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify">captures</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">...](</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify">args</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">...)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">-></s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span=
style=3D"color: #008;" class=3D"styled-by-prettify">decltype</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify">expr</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">)</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">{</span><font color=3D"#880000"><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">return</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> expr</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> </span></font><font color=3D"#000000"><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">}</span></font><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"><br></span></div></code></div><br>I propose an ex=
tension of that, which would support arbitrary compound statements:<br><div=
class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); borde=
r-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-w=
rap: break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"=
><span style=3D"color: #660;" class=3D"styled-by-prettify">[</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify">captures</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">...](</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify">args</span><span style=3D"color:=
#660;" class=3D"styled-by-prettify">...)</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">=3D></span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">{</span><font color=3D"#880000"><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> body</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span></font><font color=3D"#000000"><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: #800;" class=
=3D"styled-by-prettify">// would expand to</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br></span></font><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">[</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">captures</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">...](</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify">args</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">...)</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">-&=
gt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #008;" class=3D"styled-by-prettify">decltype</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify">body</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">void</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">())</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">{</span><font color=3D"#880000" style=3D"font-family: Arial, Helvetica, s=
ans-serif;"><span style=3D"color: #000;" class=3D"styled-by-prettify"> body=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> </span></font><fon=
t color=3D"#000000" style=3D"font-family: Arial, Helvetica, sans-serif;"><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">}</span></font></di=
v></code></div><br>In case of multiple statements, multiple `decltype` clau=
ses would be generated:<br><div class=3D"prettyprint" style=3D"background-c=
olor: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: s=
olid; border-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint=
"><div class=3D"subprettyprint"><span style=3D"color: #660;" class=3D"style=
d-by-prettify">[</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify">captures</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">...](</span><span style=3D"color: #000;" class=3D"styled-by-prettify">a=
rgs</span><span style=3D"color: #660;" class=3D"styled-by-prettify">...)</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span=
style=3D"color: #660;" class=3D"styled-by-prettify">=3D></span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">{</span><font color=3D"#880000"><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> s0</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> s1</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> s2</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> </span></font><font color=3D"#000000"><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: #800;" class=3D"style=
d-by-prettify">// would expand to</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span></font><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">[</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify">captures</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">...](</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify">args</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">...)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">-></span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span sty=
le=3D"color: #008;" class=3D"styled-by-prettify">decltype</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify">s0</span><span style=3D"color: #660;"=
class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> s1</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> s2</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">void</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">())</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">{</span><font color=3D"#880000"><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> s0</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> s1</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> s2</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
</span></font><font color=3D"#000000"><span style=3D"color: #660;" class=
=3D"styled-by-prettify">}</span></font><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span></div></code></div><br>In case of a fina=
l return, the generated trailing return type would not have the final `void=
()`:<br><div class=3D"prettyprint" style=3D"background-color: rgb(250, 250,=
250); border-color: rgb(187, 187, 187); border-style: solid; border-width:=
1px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"sub=
prettyprint"><span style=3D"color: #660;" class=3D"styled-by-prettify">[</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify">captures</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">...](</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify">args</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">...)</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">=3D></span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">{</span><font color=3D"#880000"><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> s0</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> s1</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">r=
eturn</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> s2</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> </span></font><font =
color=3D"#000000"><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>}</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></sp=
an><span style=3D"color: #800;" class=3D"styled-by-prettify">// would expan=
d to</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></=
span></font><span style=3D"color: #660;" class=3D"styled-by-prettify">[</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify">captures</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">...](</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify">args</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">...)</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">-></span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"s=
tyled-by-prettify">decltype</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify">s0</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> s1</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> s2</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">)</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">{</span><font color=3D"#880000"><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> s0</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> s1</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">r=
eturn</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> s2</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> </span></font><font =
color=3D"#000000"><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>}</span></font></div></code></div><br><br>As an example, having SFINAE-fri=
endly lambdas with blocks could allow recursive variant visitation to be im=
plemented as follows:<br><div class=3D"prettyprint" style=3D"background-col=
or: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: sol=
id; border-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint">=
<div class=3D"subprettyprint"><font color=3D"#666600"><span style=3D"color:=
#800;" class=3D"styled-by-prettify">// With a example `json` variant type =
whose alternatives are:</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"><br></span></font><span style=3D"color: #800;" class=3D"styled=
-by-prettify">// * double</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br></span><span style=3D"color: #800;" class=3D"styled-by-p=
rettify">// * string</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"><br></span><span style=3D"color: #800;" class=3D"styled-by-pretti=
fy">// * vector<json></span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"><br></span><span style=3D"color: #800;" class=3D"styled-by=
-prettify">// * map<string, json></span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"><br><br>json j </span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">=3D</span><font color=3D"#000000"><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> get_json_response</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">();</span></font=
><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><font=
color=3D"#000000"><span style=3D"color: #000;" class=3D"styled-by-prettify=
">match</span></font><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">j</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">)([](</span><s=
pan style=3D"color: #008;" class=3D"styled-by-prettify">double</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"> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">=3D></span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;"=
class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> </span><font color=3D"#666600"><span style=3D"color: =
#800;" class=3D"styled-by-prettify">/* ... */</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">},</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</span></font><span=
style=3D"color: #660;" class=3D"styled-by-prettify">[](</span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">string</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;" cla=
ss=3D"styled-by-prettify"> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">=3D></span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> </span><font color=3D"#666600"><span style=3D"color: #800;" cla=
ss=3D"styled-by-prettify">/* ... */</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">},</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"><br></span></font><font color=3D"#666600"><span style=3D"color: #00=
0;" class=3D"styled-by-prettify">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</span><=
/font><span style=3D"color: #660;" class=3D"styled-by-prettify">[](</span><=
span style=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> recurse</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> vector</span><span style=3D"color:=
#080;" class=3D"styled-by-prettify"><json></span><span style=3D"colo=
r: #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"> =C2=A0 =C2=A0 =C2=A0</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">=3D></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"style=
d-by-prettify"> </span><font color=3D"#666600"><span style=3D"color: #800;"=
class=3D"styled-by-prettify">/* ... */</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"=
styled-by-prettify">for</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">(</span><span style=3D"color: #008;" class=3D"styled-by-pretti=
fy">auto</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&a=
mp;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> v </sp=
an><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;" class=3D"styled-by-prettify">)</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> =C2=A0 =C2=A0 recurse</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify">v</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">);</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">},</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"><br></span></font><font color=3D"#666600"><span style=3D"color: #000;" =
class=3D"styled-by-prettify">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</span></fon=
t><span style=3D"color: #660;" class=3D"styled-by-prettify">[](</span><span=
style=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> recurse</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> map</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify"><</span><span style=3D"color: #008;" cla=
ss=3D"styled-by-prettify">string</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> json</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">></span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> x</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span=
style=3D"color: #660;" class=3D"styled-by-prettify">=3D></span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> </span><span style=3D"color: #800;" class=
=3D"styled-by-prettify">/* ... */</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">for</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">(</span><span style=3D"color: #008;" class=3D"styled-by-prettify">a=
uto</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">[</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">_</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify">v</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">]</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">:</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> x</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> recurse</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify">v</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">);</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">});</span><font color=3D"#666600"><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br></span></font></div></code></div><br>Th=
is is problematic to achieve without this proposal as trying to deduce the =
arity of a non-SFINAE-friendly lambda can result in an hard error. <br>(The=
arity of the visitation branches are used to differentiate between the bas=
e and recursive cases.)<br><br>If the block is complicated (e.g. it contain=
s multiple return statements constrained by `if constexpr(...)`) then the t=
railing return generation would get trickier.<br>I think that P0315 (<a hre=
f=3D"http://wg21.link/p0315">wg21.link/p0315</a>) "Lambdas in unevalua=
ted contexts" could help here:<br><br><div class=3D"prettyprint" style=
=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187);=
border-style: solid; border-width: 1px; word-wrap: break-word;"><code clas=
s=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #660;=
" class=3D"styled-by-prettify">[</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">captures</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">...](</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify">args</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">...)</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
=3D></span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><fon=
t color=3D"#880000"><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> complex_body</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span></font><font color=3D"#000000"><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">}</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"><br></span><span style=3D"color: #800;" class=3D"styled-by-pretti=
fy">// would expand to (with P0315) </span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"><br></span></font><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">[</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify">captures</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">...](</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify">args</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">...)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">-></spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span s=
tyle=3D"color: #008;" class=3D"styled-by-prettify">decltype</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">([</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify">captures</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">...](</span><font color=3D"#000000">=
<span style=3D"color: #606;" class=3D"styled-by-prettify">Ts</span></font><=
span style=3D"color: #660;" class=3D"styled-by-prettify">...</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> xs</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">){</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> complex_body</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">}(</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify">std</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">dec=
lval</span><span style=3D"color: #660;" class=3D"styled-by-prettify"><</=
span><span style=3D"color: #606;" class=3D"styled-by-prettify">Ts</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">>(</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify">xs</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">)...))</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">{</span><font color=3D"#880000"><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> </span></font><span style=3D"c=
olor: rgb(0, 0, 0);"><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy">complex_body</span></span><font color=3D"#880000"><span style=3D"color:=
#660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> </span></font><font color=3D"#000000"><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">}</span></font></div></co=
de></div><br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/58f91913-840f-439f-80b3-9f274b237736%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/58f91913-840f-439f-80b3-9f274b237736=
%40isocpp.org</a>.<br />
------=_Part_3391_1298781384.1490449425745--
------=_Part_3390_351504557.1490449425745--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sat, 25 Mar 2017 07:07:59 -0700 (PDT)
Raw View
------=_Part_3540_211604628.1490450880006
Content-Type: multipart/alternative;
boundary="----=_Part_3541_1799194024.1490450880007"
------=_Part_3541_1799194024.1490450880007
Content-Type: text/plain; charset=UTF-8
On Saturday, March 25, 2017 at 9:43:45 AM UTC-4, Vittorio Romeo wrote:
>
> Are there any news regarding this proposal? (https://wg21.link/p0573)
>
> I'm really really looking forward to this, as it would not only improve
> code readability immensely, but also open up opportunities for terse and
> intuitive syntax.
> However, one thing that I think would be very important to add to the
> proposal is the ability to use compound statements after =>.
>
> As far as I can see, the proposed new syntax only allows:
> [captures...](args...) => expr
> // would expand to
> [captures...](args...) -> decltype(expr) { return expr; }
>
> I propose an extension of that, which would support arbitrary compound
> statements:
>
[captures...](args...) => { body; }
> // would expand to
> [captures...](args...) -> decltype(body, void()) { body; }
>
> In case of multiple statements, multiple `decltype` clauses would be
> generated:
>
That makes no sense, as you cannot apply `decltype` to *statements*; it can
only be applied to expressions. That's why `=>` syntax requires a single
expression.
> [captures...](args...) => { s0; s1; s2; }
> // would expand to
> [captures...](args...) -> decltype(s0, s1, s2, void()) { s0; s1; s2; }
>
> In case of a final return, the generated trailing return type would not
> have the final `void()`:
> [captures...](args...) => { s0; s1; return s2; }
> // would expand to
> [captures...](args...) -> decltype(s0, s1, s2) { s0; s1; return s2; }
>
>
> As an example, having SFINAE-friendly lambdas with blocks could allow
> recursive variant visitation to be implemented as follows:
>
Or you could just have a recursive visitation function. Or do what Boost
does for recursive visitation. Or something else.
The general problem of applying SFINAE to the entire contents of a function
definition is a very different one from the one being solved here.
--
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/a77a424f-fc28-4ec8-8c9f-135caf0ff0f5%40isocpp.org.
------=_Part_3541_1799194024.1490450880007
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Saturday, March 25, 2017 at 9:43:45 AM UTC-4, Vittorio =
Romeo wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div>Are there any=
news regarding this proposal? (<a href=3D"https://wg21.link/p0573" target=
=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'https://www.go=
ogle.com/url?q\x3dhttps%3A%2F%2Fwg21.link%2Fp0573\x26sa\x3dD\x26sntz\x3d1\x=
26usg\x3dAFQjCNErZK6tuGpLiSsYeuunfVgg-Qwf_A';return true;" onclick=3D"t=
his.href=3D'https://www.google.com/url?q\x3dhttps%3A%2F%2Fwg21.link%2Fp=
0573\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNErZK6tuGpLiSsYeuunfVgg-Qwf_A&#=
39;;return true;">https://wg21.link/p0573</a>)<br><br>I'm really really=
looking forward to this, as it would not only improve code readability imm=
ensely, but also open up opportunities for terse and intuitive syntax.<br>H=
owever, one thing that I think would be very important to add to the propos=
al is the ability to use compound statements after =3D>.<br><br>As far a=
s I can see, the proposed new syntax only allows:<br><div style=3D"backgrou=
nd-color:rgb(250,250,250);border-color:rgb(187,187,187);border-style:solid;=
border-width:1px;word-wrap:break-word"><code><div><span style=3D"color:#660=
">[</span><span style=3D"color:#000">captures</span><span style=3D"color:#6=
60">...](</span><span style=3D"color:#000">args</span><span style=3D"color:=
#660">...)</span><span style=3D"color:#000"> </span><span style=3D"color:#6=
60">=3D></span><span style=3D"color:#000"> expr</span><font color=3D"#00=
0000"><span style=3D"color:#000"><br></span><span style=3D"color:#800">// w=
ould expand to</span><span style=3D"color:#000"><br></span></font><span sty=
le=3D"color:#660">[</span><span style=3D"color:#000">captures</span><span s=
tyle=3D"color:#660">...](</span><span style=3D"color:#000">args</span><span=
style=3D"color:#660">...)</span><span style=3D"color:#000"> </span><span s=
tyle=3D"color:#660">-></span><span style=3D"color:#000"> </span><span st=
yle=3D"color:#008">decltype</span><span style=3D"color:#660">(</span><span =
style=3D"color:#000">expr</span><span style=3D"color:#660">)</span><span st=
yle=3D"color:#000"> </span><span style=3D"color:#660">{</span><font color=
=3D"#880000"><span style=3D"color:#000"> </span><span style=3D"color:#008">=
return</span><span style=3D"color:#000"> expr</span><span style=3D"color:#6=
60">;</span><span style=3D"color:#000"> </span></font><font color=3D"#00000=
0"><span style=3D"color:#660">}</span></font><span style=3D"color:#000"><br=
></span></div></code></div><br>I propose an extension of that, which would =
support arbitrary compound statements: <br></div></blockquote><blockquote c=
lass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px=
#ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div style=3D"background-c=
olor:rgb(250,250,250);border-color:rgb(187,187,187);border-style:solid;bord=
er-width:1px;word-wrap:break-word"><code><div><span style=3D"color:#660">[<=
/span><span style=3D"color:#000">captures</span><span style=3D"color:#660">=
....](</span><span style=3D"color:#000">args</span><span style=3D"color:#660=
">...)</span><span style=3D"color:#000"> </span><span style=3D"color:#660">=
=3D></span><span style=3D"color:#000"> </span><span style=3D"color:#660"=
>{</span><font color=3D"#880000"><span style=3D"color:#000"> body</span><sp=
an style=3D"color:#660">;</span><span style=3D"color:#000"> </span></font><=
font color=3D"#000000"><span style=3D"color:#660">}</span><span style=3D"co=
lor:#000"><br></span><span style=3D"color:#800">// would expand to</span><s=
pan style=3D"color:#000"><br></span></font><span style=3D"color:#660">[</sp=
an><span style=3D"color:#000">captures</span><span style=3D"color:#660">...=
](</span><span style=3D"color:#000">args</span><span style=3D"color:#660">.=
...)</span><span style=3D"color:#000"> </span><span style=3D"color:#660">-&g=
t;</span><span style=3D"color:#000"> </span><span style=3D"color:#008">decl=
type</span><span style=3D"color:#660">(</span><span style=3D"color:#000">bo=
dy</span><span style=3D"color:#660">,</span><span style=3D"color:#000"> </s=
pan><span style=3D"color:#008">void</span><span style=3D"color:#660">())</s=
pan><span style=3D"color:#000"> </span><span style=3D"color:#660">{</span><=
font style=3D"font-family:Arial,Helvetica,sans-serif" color=3D"#880000"><sp=
an style=3D"color:#000"> body</span><span style=3D"color:#660">;</span><spa=
n style=3D"color:#000"> </span></font><font style=3D"font-family:Arial,Helv=
etica,sans-serif" color=3D"#000000"><span style=3D"color:#660">}</span></fo=
nt></div></code></div><br>In case of multiple statements, multiple `decltyp=
e` clauses would be generated:<br></div></blockquote><div><br>That makes no=
sense, as you cannot apply `decltype` to <i>statements</i>; it can only be=
applied to expressions. That's why `=3D>` syntax requires a single =
expression.<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v><div style=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,=
187);border-style:solid;border-width:1px;word-wrap:break-word"><code><div><=
span style=3D"color:#660">[</span><span style=3D"color:#000">captures</span=
><span style=3D"color:#660">...](</span><span style=3D"color:#000">args</sp=
an><span style=3D"color:#660">...)</span><span style=3D"color:#000"> </span=
><span style=3D"color:#660">=3D></span><span style=3D"color:#000"> </spa=
n><span style=3D"color:#660">{</span><font color=3D"#880000"><span style=3D=
"color:#000"> s0</span><span style=3D"color:#660">;</span><span style=3D"co=
lor:#000"> s1</span><span style=3D"color:#660">;</span><span style=3D"color=
:#000"> s2</span><span style=3D"color:#660">;</span><span style=3D"color:#0=
00"> </span></font><font color=3D"#000000"><span style=3D"color:#660">}</sp=
an><span style=3D"color:#000"><br></span><span style=3D"color:#800">// woul=
d expand to</span><span style=3D"color:#000"><br></span></font><span style=
=3D"color:#660">[</span><span style=3D"color:#000">captures</span><span sty=
le=3D"color:#660">...](</span><span style=3D"color:#000">args</span><span s=
tyle=3D"color:#660">...)</span><span style=3D"color:#000"> </span><span sty=
le=3D"color:#660">-></span><span style=3D"color:#000"> </span><span styl=
e=3D"color:#008">decltype</span><span style=3D"color:#660">(</span><span st=
yle=3D"color:#000">s0</span><span style=3D"color:#660">,</span><span style=
=3D"color:#000"> s1</span><span style=3D"color:#660">,</span><span style=3D=
"color:#000"> s2</span><span style=3D"color:#660">,</span><span style=3D"co=
lor:#000"> </span><span style=3D"color:#008">void</span><span style=3D"colo=
r:#660">())</span><span style=3D"color:#000"> </span><span style=3D"color:#=
660">{</span><font color=3D"#880000"><span style=3D"color:#000"> s0</span><=
span style=3D"color:#660">;</span><span style=3D"color:#000"> s1</span><spa=
n style=3D"color:#660">;</span><span style=3D"color:#000"> s2</span><span s=
tyle=3D"color:#660">;</span><span style=3D"color:#000"> </span></font><font=
color=3D"#000000"><span style=3D"color:#660">}</span></font><span style=3D=
"color:#000"><br></span></div></code></div><br>In case of a final return, t=
he generated trailing return type would not have the final `void()`:<br><di=
v style=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187);=
border-style:solid;border-width:1px;word-wrap:break-word"><code><div><span =
style=3D"color:#660">[</span><span style=3D"color:#000">captures</span><spa=
n style=3D"color:#660">...](</span><span style=3D"color:#000">args</span><s=
pan style=3D"color:#660">...)</span><span style=3D"color:#000"> </span><spa=
n style=3D"color:#660">=3D></span><span style=3D"color:#000"> </span><sp=
an style=3D"color:#660">{</span><font color=3D"#880000"><span style=3D"colo=
r:#000"> s0</span><span style=3D"color:#660">;</span><span style=3D"color:#=
000"> s1</span><span style=3D"color:#660">;</span><span style=3D"color:#000=
"> </span><span style=3D"color:#008">return</span><span style=3D"color:#000=
"> s2</span><span style=3D"color:#660">;</span><span style=3D"color:#000"> =
</span></font><font color=3D"#000000"><span style=3D"color:#660">}</span><s=
pan style=3D"color:#000"><br></span><span style=3D"color:#800">// would exp=
and to</span><span style=3D"color:#000"><br></span></font><span style=3D"co=
lor:#660">[</span><span style=3D"color:#000">captures</span><span style=3D"=
color:#660">...](</span><span style=3D"color:#000">args</span><span style=
=3D"color:#660">...)</span><span style=3D"color:#000"> </span><span style=
=3D"color:#660">-></span><span style=3D"color:#000"> </span><span style=
=3D"color:#008">decltype</span><span style=3D"color:#660">(</span><span sty=
le=3D"color:#000">s0</span><span style=3D"color:#660">,</span><span style=
=3D"color:#000"> s1</span><span style=3D"color:#660">,</span><span style=3D=
"color:#000"> s2</span><span style=3D"color:#660">)</span><span style=3D"co=
lor:#000"> </span><span style=3D"color:#660">{</span><font color=3D"#880000=
"><span style=3D"color:#000"> s0</span><span style=3D"color:#660">;</span><=
span style=3D"color:#000"> s1</span><span style=3D"color:#660">;</span><spa=
n style=3D"color:#000"> </span><span style=3D"color:#008">return</span><spa=
n style=3D"color:#000"> s2</span><span style=3D"color:#660">;</span><span s=
tyle=3D"color:#000"> </span></font><font color=3D"#000000"><span style=3D"c=
olor:#660">}</span></font></div></code></div><br><br>As an example, having =
SFINAE-friendly lambdas with blocks could allow recursive variant visitatio=
n to be implemented as follows:</div></blockquote><div><br>Or you could jus=
t have a recursive visitation function. Or do what Boost does for recursive=
visitation. Or something else.<br><br>The general problem of applying SFIN=
AE to the entire contents of a function definition is a very different one =
from the one being solved here.</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/a77a424f-fc28-4ec8-8c9f-135caf0ff0f5%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a77a424f-fc28-4ec8-8c9f-135caf0ff0f5=
%40isocpp.org</a>.<br />
------=_Part_3541_1799194024.1490450880007--
------=_Part_3540_211604628.1490450880006--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Sat, 25 Mar 2017 08:34:04 -0700
Raw View
On s=C3=A1bado, 25 de mar=C3=A7o de 2017 06:43:45 PDT Vittorio Romeo wrote:
> I propose an extension of that, which would support arbitrary compound
> statements:
> [captures...](args...) =3D> { body; }
> // would expand to
> [captures...](args...) -> decltype(body, void()) { body; }
How is this different from
[captures....](args) { body; }
?
What's the advantage provided by those three extra keystrokes?
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--=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/7445082.xAEr1dpAVQ%40tjmaciei-mobl1.
.
Author: Vittorio Romeo <vittorio.romeo.vee@gmail.com>
Date: Sat, 25 Mar 2017 08:43:34 -0700 (PDT)
Raw View
------=_Part_1868_162619097.1490456614836
Content-Type: multipart/alternative;
boundary="----=_Part_1869_794857271.1490456614837"
------=_Part_1869_794857271.1490456614837
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
auto l =3D [](auto x){ x.foo(); };
static_assert(!std::is_invocable<decltype(l), int>::value);
The code above will produce an hard error:
prog.cc:3:24: error: request for member 'foo' in 'x', which is of non-class=
type 'int'
auto l =3D [](auto x){ x.foo(); };
~~^~~
On wandbox: https://wandbox.org/permlink/X0mVhC9Q3qfw5T8N
---
auto l =3D [](auto x) -> decltype(x.foo(), void()) { x.foo(); };
static_assert(!std::is_invocable<decltype(l), int>::value);
The code above will work as intended.
On wandbox: https://wandbox.org/permlink/oxExZ7WPNGS0YV2e
---
More info:=20
http://stackoverflow.com/questions/42739837/getting-sfinae-to-work-with-is-=
callable-on-an-overloaded-function-object
On Saturday, 25 March 2017 15:34:10 UTC, Thiago Macieira wrote:
>
> On s=C3=A1bado, 25 de mar=C3=A7o de 2017 06:43:45 PDT Vittorio Romeo wrot=
e:=20
> > I propose an extension of that, which would support arbitrary compound=
=20
> > statements:=20
> > [captures...](args...) =3D> { body; }=20
> > // would expand to=20
> > [captures...](args...) -> decltype(body, void()) { body; }=20
>
> How is this different from=20
>
> [captures....](args) { body; }=20
>
> ?=20
>
> What's the advantage provided by those three extra keystrokes?=20
>
> --=20
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org=20
> Software Architect - Intel Open Source Technology Center=20
>
>
--=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/45caae90-5766-4511-9916-d6f4dfc8db5f%40isocpp.or=
g.
------=_Part_1869_794857271.1490456614837
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"prettyprint" style=3D"background-color: rgb(=
250, 250, 250); border-color: rgb(187, 187, 187); border-style: solid; bord=
er-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div cla=
ss=3D"subprettyprint"><div class=3D"subprettyprint">auto l =3D [](auto x){ =
x.foo(); };</div><div class=3D"subprettyprint">static_assert(!std::is_invoc=
able<decltype(l), int>::value);</div></div></code></div><br>The code =
above will produce an hard error:<br><pre class=3D"CompilerMessageE" data-t=
ype=3D"CompilerMessageE" data-text=3D"prog.cc: In instantiation of '<=
;lambda(auto:1)> [with auto:1 =3D int]':
/opt/wandbox/gcc-head/include/c++/7.0.1/type_traits:2431:26: required by =
substitution of 'template<class _Fn, class ... _Args> static std:=
:__result_of_success<decltype (declval<_Fn>()((declval<_Args>=
;)()...)), std::__invoke_other> std::__result_of_other_impl::_S_test(int=
) [with _Fn =3D <lambda(auto:1)>; _Args =3D {int}]'
/opt/wandbox/gcc-head/include/c++/7.0.1/type_traits:2442:55: required fro=
m 'struct std::__result_of_impl<false, false, <lambda(auto:1)>=
, int>'
/opt/wandbox/gcc-head/include/c++/7.0.1/type_traits:2840:12: recursively =
required by substitution of 'template<class _Result, class _Ret> =
struct std::__is_invocable_impl<_Result, _Ret, std::__void_t<typename=
_Result::type> > [with _Result =3D std::__invoke_result<<lambd=
a(auto:1)>, int>; _Ret =3D void]'
/opt/wandbox/gcc-head/include/c++/7.0.1/type_traits:2840:12: required fro=
m 'struct std::is_invocable<<lambda(auto:1)>, int>'
prog.cc:4:51: required from here
prog.cc:3:24: error: request for member 'foo' in 'x', which=
is of non-class type 'int'
auto l =3D [](auto x){ x.foo(); };
~~^~~
prog.cc:4:1: error: static assertion failed
static_assert(!std::is_invocable<decltype(l), int>::value);
^~~~~~~~~~~~~
" style=3D"box-sizing: border-box; overflow: auto; font-family: "Couri=
er New", monospace; margin-bottom: 10px; line-height: 1.42857; color: =
rgb(255, 0, 0); word-break: break-all; word-wrap: break-word; background-co=
lor: rgb(0, 0, 0); border-radius: 4px;">prog.cc:3:24: error: request for me=
mber 'foo' in 'x', which is of non-class type 'int'
auto l =3D [](auto x){ x.foo(); };
~~^~~</pre><div>On wandbox:=C2=A0<a href=3D"https://w=
andbox.org/permlink/X0mVhC9Q3qfw5T8N">https://wandbox.org/permlink/X0mVhC9Q=
3qfw5T8N</a></div><div><br>---<br><br><div class=3D"prettyprint" style=3D"b=
ackground-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); bord=
er-style: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"=
prettyprint"><div class=3D"subprettyprint"><div class=3D"subprettyprint"><d=
iv class=3D"subprettyprint">auto l =3D [](auto x) -> decltype(x.foo(), v=
oid()) { x.foo(); };</div><div class=3D"subprettyprint">static_assert(!std:=
:is_invocable<decltype(l), int>::value);</div></div></div></code></di=
v><br>The code above will work as intended.<br></div>On wandbox: <a href=3D=
"https://wandbox.org/permlink/oxExZ7WPNGS0YV2e">https://wandbox.org/permlin=
k/oxExZ7WPNGS0YV2e</a><br><br>---<br><br>More info:=C2=A0<br><a href=3D"htt=
p://stackoverflow.com/questions/42739837/getting-sfinae-to-work-with-is-cal=
lable-on-an-overloaded-function-object">http://stackoverflow.com/questions/=
42739837/getting-sfinae-to-work-with-is-callable-on-an-overloaded-function-=
object<br></a><br><br><br>On Saturday, 25 March 2017 15:34:10 UTC, Thiago M=
acieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On s=C3=A1bado,=
25 de mar=C3=A7o de 2017 06:43:45 PDT Vittorio Romeo wrote:
<br>> I propose an extension of that, which would support arbitrary comp=
ound
<br>> statements:
<br>> [captures...](args...) =3D> { body; }
<br>> // would expand to
<br>> [captures...](args...) -> decltype(body, void()) { body; }
<br>
<br>How is this different from
<br>
<br>[captures....](args) { body; }
<br>
<br>?
<br>
<br>What's the advantage provided by those three extra keystrokes?
<br>
<br>--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=
=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.goo=
gle.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x3dD\x26sntz\x3d1\x26usg\=
x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return true;" onclick=3D"this.hr=
ef=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x=
3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return t=
rue;">macieira.info</a> - thiago (AT) <a href=3D"http://kde.org" target=3D"=
_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.google.=
com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNH=
GRJdo5_JYG1DowztwAHAKs80XSA';return true;" onclick=3D"this.href=3D'=
http://www.google.com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1=
\x26usg\x3dAFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';return true;">kde.org</a=
>
<br>=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center
<br>
<br></blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/45caae90-5766-4511-9916-d6f4dfc8db5f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/45caae90-5766-4511-9916-d6f4dfc8db5f=
%40isocpp.org</a>.<br />
------=_Part_1869_794857271.1490456614837--
------=_Part_1868_162619097.1490456614836--
.
Author: Vittorio Romeo <vittorio.romeo.vee@gmail.com>
Date: Sat, 25 Mar 2017 08:52:29 -0700 (PDT)
Raw View
------=_Part_1870_1974416920.1490457149201
Content-Type: multipart/alternative;
boundary="----=_Part_1871_111830280.1490457149202"
------=_Part_1871_111830280.1490457149202
Content-Type: text/plain; charset=UTF-8
Yeah, it doesn't make sense - I posted too quickly without thinking enough
about it.
Even my last example with the unevaluated context lambda wouldn't work, as
that lambda itself would need a proper `-> decltype(...)` and
`noexcept(noexcept(...))`.
I'm starting to realize that computing the result of `decltype(block)` and
`noexcept(noexcept(block))` is a very difficult task...
On Saturday, 25 March 2017 14:08:00 UTC, Nicol Bolas wrote:
>
> On Saturday, March 25, 2017 at 9:43:45 AM UTC-4, Vittorio Romeo wrote:
>>
>> Are there any news regarding this proposal? (https://wg21.link/p0573)
>>
>> I'm really really looking forward to this, as it would not only improve
>> code readability immensely, but also open up opportunities for terse and
>> intuitive syntax.
>> However, one thing that I think would be very important to add to the
>> proposal is the ability to use compound statements after =>.
>>
>> As far as I can see, the proposed new syntax only allows:
>> [captures...](args...) => expr
>> // would expand to
>> [captures...](args...) -> decltype(expr) { return expr; }
>>
>> I propose an extension of that, which would support arbitrary compound
>> statements:
>>
> [captures...](args...) => { body; }
>> // would expand to
>> [captures...](args...) -> decltype(body, void()) { body; }
>>
>> In case of multiple statements, multiple `decltype` clauses would be
>> generated:
>>
>
> That makes no sense, as you cannot apply `decltype` to *statements*; it
> can only be applied to expressions. That's why `=>` syntax requires a
> single expression.
>
>
>> [captures...](args...) => { s0; s1; s2; }
>> // would expand to
>> [captures...](args...) -> decltype(s0, s1, s2, void()) { s0; s1; s2; }
>>
>> In case of a final return, the generated trailing return type would not
>> have the final `void()`:
>> [captures...](args...) => { s0; s1; return s2; }
>> // would expand to
>> [captures...](args...) -> decltype(s0, s1, s2) { s0; s1; return s2; }
>>
>>
>> As an example, having SFINAE-friendly lambdas with blocks could allow
>> recursive variant visitation to be implemented as follows:
>>
>
> Or you could just have a recursive visitation function. Or do what Boost
> does for recursive visitation. Or something else.
>
> The general problem of applying SFINAE to the entire contents of a
> function definition is a very different one from the one being solved here.
>
--
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/1511bf59-8369-499b-b53e-19c3da8a99dc%40isocpp.org.
------=_Part_1871_111830280.1490457149202
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Yeah, it doesn't make sense - I posted too quickly wit=
hout thinking enough about it.<br>Even my last example with the unevaluated=
context lambda wouldn't work, as that lambda itself would need a prope=
r `-> decltype(...)` and `noexcept(noexcept(...))`.<br>I'm starting =
to realize that computing the result of `decltype(block)` and `noexcept(noe=
xcept(block))` is a very difficult task...<br><br><br>On Saturday, 25 March=
2017 14:08:00 UTC, Nicol Bolas wrote:<blockquote class=3D"gmail_quote" st=
yle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-lef=
t: 1ex;"><div dir=3D"ltr">On Saturday, March 25, 2017 at 9:43:45 AM UTC-4, =
Vittorio Romeo wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;ma=
rgin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Are there=
any news regarding this proposal? (<a href=3D"https://wg21.link/p0573" rel=
=3D"nofollow" target=3D"_blank" onmousedown=3D"this.href=3D'https://www=
..google.com/url?q\x3dhttps%3A%2F%2Fwg21.link%2Fp0573\x26sa\x3dD\x26sntz\x3d=
1\x26usg\x3dAFQjCNErZK6tuGpLiSsYeuunfVgg-Qwf_A';return true;" onclick=
=3D"this.href=3D'https://www.google.com/url?q\x3dhttps%3A%2F%2Fwg21.lin=
k%2Fp0573\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNErZK6tuGpLiSsYeuunfVgg-Qw=
f_A';return true;">https://wg21.link/p0573</a>)<br><br>I'm really r=
eally looking forward to this, as it would not only improve code readabilit=
y immensely, but also open up opportunities for terse and intuitive syntax.=
<br>However, one thing that I think would be very important to add to the p=
roposal is the ability to use compound statements after =3D>.<br><br>As =
far as I can see, the proposed new syntax only allows:<br><div style=3D"bac=
kground-color:rgb(250,250,250);border-color:rgb(187,187,187);border-style:s=
olid;border-width:1px;word-wrap:break-word"><code><div><span style=3D"color=
:#660">[</span><span style=3D"color:#000">captures</span><span style=3D"col=
or:#660">...](</span><span style=3D"color:#000">args</span><span style=3D"c=
olor:#660">...)</span><span style=3D"color:#000"> </span><span style=3D"col=
or:#660">=3D></span><span style=3D"color:#000"> expr</span><font color=
=3D"#000000"><span style=3D"color:#000"><br></span><span style=3D"color:#80=
0">// would expand to</span><span style=3D"color:#000"><br></span></font><s=
pan style=3D"color:#660">[</span><span style=3D"color:#000">captures</span>=
<span style=3D"color:#660">...](</span><span style=3D"color:#000">args</spa=
n><span style=3D"color:#660">...)</span><span style=3D"color:#000"> </span>=
<span style=3D"color:#660">-></span><span style=3D"color:#000"> </span><=
span style=3D"color:#008">decltype</span><span style=3D"color:#660">(</span=
><span style=3D"color:#000">expr</span><span style=3D"color:#660">)</span><=
span style=3D"color:#000"> </span><span style=3D"color:#660">{</span><font =
color=3D"#880000"><span style=3D"color:#000"> </span><span style=3D"color:#=
008">return</span><span style=3D"color:#000"> expr</span><span style=3D"col=
or:#660">;</span><span style=3D"color:#000"> </span></font><font color=3D"#=
000000"><span style=3D"color:#660">}</span></font><span style=3D"color:#000=
"><br></span></div></code></div><br>I propose an extension of that, which w=
ould support arbitrary compound statements: <br></div></blockquote><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div style=3D"background-c=
olor:rgb(250,250,250);border-color:rgb(187,187,187);border-style:solid;bord=
er-width:1px;word-wrap:break-word"><code><div><span style=3D"color:#660">[<=
/span><span style=3D"color:#000">captures</span><span style=3D"color:#660">=
....](</span><span style=3D"color:#000">args</span><span style=3D"color:#660=
">...)</span><span style=3D"color:#000"> </span><span style=3D"color:#660">=
=3D></span><span style=3D"color:#000"> </span><span style=3D"color:#660"=
>{</span><font color=3D"#880000"><span style=3D"color:#000"> body</span><sp=
an style=3D"color:#660">;</span><span style=3D"color:#000"> </span></font><=
font color=3D"#000000"><span style=3D"color:#660">}</span><span style=3D"co=
lor:#000"><br></span><span style=3D"color:#800">// would expand to</span><s=
pan style=3D"color:#000"><br></span></font><span style=3D"color:#660">[</sp=
an><span style=3D"color:#000">captures</span><span style=3D"color:#660">...=
](</span><span style=3D"color:#000">args</span><span style=3D"color:#660">.=
...)</span><span style=3D"color:#000"> </span><span style=3D"color:#660">-&g=
t;</span><span style=3D"color:#000"> </span><span style=3D"color:#008">decl=
type</span><span style=3D"color:#660">(</span><span style=3D"color:#000">bo=
dy</span><span style=3D"color:#660">,</span><span style=3D"color:#000"> </s=
pan><span style=3D"color:#008">void</span><span style=3D"color:#660">())</s=
pan><span style=3D"color:#000"> </span><span style=3D"color:#660">{</span><=
font style=3D"font-family:Arial,Helvetica,sans-serif" color=3D"#880000"><sp=
an style=3D"color:#000"> body</span><span style=3D"color:#660">;</span><spa=
n style=3D"color:#000"> </span></font><font style=3D"font-family:Arial,Helv=
etica,sans-serif" color=3D"#000000"><span style=3D"color:#660">}</span></fo=
nt></div></code></div><br>In case of multiple statements, multiple `decltyp=
e` clauses would be generated:<br></div></blockquote><div><br>That makes no=
sense, as you cannot apply `decltype` to <i>statements</i>; it can only be=
applied to expressions. That's why `=3D>` syntax requires a single =
expression.<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div><di=
v style=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187);=
border-style:solid;border-width:1px;word-wrap:break-word"><code><div><span =
style=3D"color:#660">[</span><span style=3D"color:#000">captures</span><spa=
n style=3D"color:#660">...](</span><span style=3D"color:#000">args</span><s=
pan style=3D"color:#660">...)</span><span style=3D"color:#000"> </span><spa=
n style=3D"color:#660">=3D></span><span style=3D"color:#000"> </span><sp=
an style=3D"color:#660">{</span><font color=3D"#880000"><span style=3D"colo=
r:#000"> s0</span><span style=3D"color:#660">;</span><span style=3D"color:#=
000"> s1</span><span style=3D"color:#660">;</span><span style=3D"color:#000=
"> s2</span><span style=3D"color:#660">;</span><span style=3D"color:#000"> =
</span></font><font color=3D"#000000"><span style=3D"color:#660">}</span><s=
pan style=3D"color:#000"><br></span><span style=3D"color:#800">// would exp=
and to</span><span style=3D"color:#000"><br></span></font><span style=3D"co=
lor:#660">[</span><span style=3D"color:#000">captures</span><span style=3D"=
color:#660">...](</span><span style=3D"color:#000">args</span><span style=
=3D"color:#660">...)</span><span style=3D"color:#000"> </span><span style=
=3D"color:#660">-></span><span style=3D"color:#000"> </span><span style=
=3D"color:#008">decltype</span><span style=3D"color:#660">(</span><span sty=
le=3D"color:#000">s0</span><span style=3D"color:#660">,</span><span style=
=3D"color:#000"> s1</span><span style=3D"color:#660">,</span><span style=3D=
"color:#000"> s2</span><span style=3D"color:#660">,</span><span style=3D"co=
lor:#000"> </span><span style=3D"color:#008">void</span><span style=3D"colo=
r:#660">())</span><span style=3D"color:#000"> </span><span style=3D"color:#=
660">{</span><font color=3D"#880000"><span style=3D"color:#000"> s0</span><=
span style=3D"color:#660">;</span><span style=3D"color:#000"> s1</span><spa=
n style=3D"color:#660">;</span><span style=3D"color:#000"> s2</span><span s=
tyle=3D"color:#660">;</span><span style=3D"color:#000"> </span></font><font=
color=3D"#000000"><span style=3D"color:#660">}</span></font><span style=3D=
"color:#000"><br></span></div></code></div><br>In case of a final return, t=
he generated trailing return type would not have the final `void()`:<br><di=
v style=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187);=
border-style:solid;border-width:1px;word-wrap:break-word"><code><div><span =
style=3D"color:#660">[</span><span style=3D"color:#000">captures</span><spa=
n style=3D"color:#660">...](</span><span style=3D"color:#000">args</span><s=
pan style=3D"color:#660">...)</span><span style=3D"color:#000"> </span><spa=
n style=3D"color:#660">=3D></span><span style=3D"color:#000"> </span><sp=
an style=3D"color:#660">{</span><font color=3D"#880000"><span style=3D"colo=
r:#000"> s0</span><span style=3D"color:#660">;</span><span style=3D"color:#=
000"> s1</span><span style=3D"color:#660">;</span><span style=3D"color:#000=
"> </span><span style=3D"color:#008">return</span><span style=3D"color:#000=
"> s2</span><span style=3D"color:#660">;</span><span style=3D"color:#000"> =
</span></font><font color=3D"#000000"><span style=3D"color:#660">}</span><s=
pan style=3D"color:#000"><br></span><span style=3D"color:#800">// would exp=
and to</span><span style=3D"color:#000"><br></span></font><span style=3D"co=
lor:#660">[</span><span style=3D"color:#000">captures</span><span style=3D"=
color:#660">...](</span><span style=3D"color:#000">args</span><span style=
=3D"color:#660">...)</span><span style=3D"color:#000"> </span><span style=
=3D"color:#660">-></span><span style=3D"color:#000"> </span><span style=
=3D"color:#008">decltype</span><span style=3D"color:#660">(</span><span sty=
le=3D"color:#000">s0</span><span style=3D"color:#660">,</span><span style=
=3D"color:#000"> s1</span><span style=3D"color:#660">,</span><span style=3D=
"color:#000"> s2</span><span style=3D"color:#660">)</span><span style=3D"co=
lor:#000"> </span><span style=3D"color:#660">{</span><font color=3D"#880000=
"><span style=3D"color:#000"> s0</span><span style=3D"color:#660">;</span><=
span style=3D"color:#000"> s1</span><span style=3D"color:#660">;</span><spa=
n style=3D"color:#000"> </span><span style=3D"color:#008">return</span><spa=
n style=3D"color:#000"> s2</span><span style=3D"color:#660">;</span><span s=
tyle=3D"color:#000"> </span></font><font color=3D"#000000"><span style=3D"c=
olor:#660">}</span></font></div></code></div><br><br>As an example, having =
SFINAE-friendly lambdas with blocks could allow recursive variant visitatio=
n to be implemented as follows:</div></blockquote><div><br>Or you could jus=
t have a recursive visitation function. Or do what Boost does for recursive=
visitation. Or something else.<br><br>The general problem of applying SFIN=
AE to the entire contents of a function definition is a very different one =
from the one being solved here.</div></div></blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/1511bf59-8369-499b-b53e-19c3da8a99dc%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/1511bf59-8369-499b-b53e-19c3da8a99dc=
%40isocpp.org</a>.<br />
------=_Part_1871_111830280.1490457149202--
------=_Part_1870_1974416920.1490457149201--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Sat, 25 Mar 2017 08:55:14 -0700
Raw View
On s=C3=A1bado, 25 de mar=C3=A7o de 2017 08:43:34 PDT Vittorio Romeo wrote:
> auto l =3D [](auto x){ x.foo(); };
> static_assert(!std::is_invocable<decltype(l), int>::value);
>=20
> The code above will produce an hard error:
>=20
> prog.cc:3:24: error: request for member 'foo' in 'x', which is of non-cla=
ss
> type 'int' auto l =3D [](auto x){ x.foo(); };
> ~~^~~
You didn't answer my question.
And this compiles:
struct S { void foo(); };
auto l =3D [](S x){ x.foo(); };
static_assert(!std::is_invocable<decltype(l), int>::value);
https://wandbox.org/permlink/VcoZff9PjRCHCFbx
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--=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/62132266.q9egrEA8ba%40tjmaciei-mobl1.
.
Author: Vittorio Romeo <vittorio.romeo.vee@gmail.com>
Date: Sat, 25 Mar 2017 09:14:28 -0700 (PDT)
Raw View
------=_Part_1830_499769470.1490458469034
Content-Type: multipart/alternative;
boundary="----=_Part_1831_1891875297.1490458469034"
------=_Part_1831_1891875297.1490458469034
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Were you referring to the `...` in `args...`?=20
If that's the case, it was just pseudocode that means "anything can be in=
=20
here" - I was trying to show expansion examples for lambdas with arbitrary=
=20
captures and arbitrary signatures.
And this compiles
It does, but the lambda is not generic anymore. You example compiles=20
because the error does not occur during instantiation, it occurs during=20
overload resolution.
In my example, the
l(0)
call expression is valid - it's the instantiation of `l<int>` that is=20
invalid.
In your example, the
l(0)
call expression is itself invalid - that can be detected by `is_invocable`=
=20
without causing an hard error.
=20
On Saturday, 25 March 2017 15:55:18 UTC, Thiago Macieira wrote:
>
> On s=C3=A1bado, 25 de mar=C3=A7o de 2017 08:43:34 PDT Vittorio Romeo wrot=
e:=20
> > auto l =3D [](auto x){ x.foo(); };=20
> > static_assert(!std::is_invocable<decltype(l), int>::value);=20
> >=20
> > The code above will produce an hard error:=20
> >=20
> > prog.cc:3:24: error: request for member 'foo' in 'x', which is of=20
> non-class=20
> > type 'int' auto l =3D [](auto x){ x.foo(); };=20
> > ~~^~~=20
>
> You didn't answer my question.=20
>
> And this compiles:=20
>
> struct S { void foo(); };=20
> auto l =3D [](S x){ x.foo(); };=20
> static_assert(!std::is_invocable<decltype(l), int>::value);=20
>
> https://wandbox.org/permlink/VcoZff9PjRCHCFbx=20
>
> --=20
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org=20
> Software Architect - Intel Open Source Technology Center=20
>
>
--=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/98ffdeec-76e4-458a-a371-441c31e3b68b%40isocpp.or=
g.
------=_Part_1831_1891875297.1490458469034
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Were you referring to the `...` in `args...`?=C2=A0<br>If =
that's the case, it was just pseudocode that means "anything can b=
e in here" -=C2=A0I was trying to show expansion examples for lambdas =
with arbitrary captures and arbitrary signatures.<br><br><blockquote class=
=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid=
rgb(204, 204, 204); padding-left: 1ex;">And this compiles</blockquote><div=
><br>It does, but the lambda is not generic anymore. You example compiles b=
ecause the error does not occur during instantiation, it occurs during over=
load resolution.<br>In my example, the<br><div class=3D"prettyprint" style=
=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187);=
border-style: solid; border-width: 1px; word-wrap: break-word;"><code clas=
s=3D"prettyprint"><div class=3D"subprettyprint"><font color=3D"#660066"><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify">l</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color=
: #066;" class=3D"styled-by-prettify">0</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">)</span></font></div></code></div>call express=
ion is valid - it's the instantiation of `l<int>` that is invalid=
..<br><br>In your example, the<br><div class=3D"prettyprint" style=3D"backgr=
ound-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-st=
yle: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"prett=
yprint"><div class=3D"subprettyprint"><font color=3D"#660066"><span style=
=3D"color: #000;" class=3D"styled-by-prettify">l</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">(</span><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></div></code></div>call expression is itself i=
nvalid - that can be detected by `is_invocable` without causing an hard err=
or.<br><br>=C2=A0</div><br>On Saturday, 25 March 2017 15:55:18 UTC, Thiago =
Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On s=C3=A1bado=
, 25 de mar=C3=A7o de 2017 08:43:34 PDT Vittorio Romeo wrote:
<br>> auto l =3D [](auto x){ x.foo(); };
<br>> static_assert(!std::is_<wbr>invocable<decltype(l), int>::val=
ue);
<br>>=20
<br>> The code above will produce an hard error:
<br>>=20
<br>> prog.cc:3:24: error: request for member 'foo' in 'x=
9;, which is of non-class
<br>> type 'int' auto l =3D [](auto x){ x.foo(); };
<br>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 ~~^~~
<br>
<br>You didn't answer my question.
<br>
<br>And this compiles:
<br>
<br>struct S { void foo(); };
<br>auto l =3D [](S x){ x.foo(); };
<br>static_assert(!std::is_<wbr>invocable<decltype(l), int>::value);
<br>
<br><a href=3D"https://wandbox.org/permlink/VcoZff9PjRCHCFbx" target=3D"_bl=
ank" rel=3D"nofollow" onmousedown=3D"this.href=3D'https://www.google.co=
m/url?q\x3dhttps%3A%2F%2Fwandbox.org%2Fpermlink%2FVcoZff9PjRCHCFbx\x26sa\x3=
dD\x26sntz\x3d1\x26usg\x3dAFQjCNHKiBWLpgY7e-D8zmRjgaAMgcSFEQ';return tr=
ue;" onclick=3D"this.href=3D'https://www.google.com/url?q\x3dhttps%3A%2=
F%2Fwandbox.org%2Fpermlink%2FVcoZff9PjRCHCFbx\x26sa\x3dD\x26sntz\x3d1\x26us=
g\x3dAFQjCNHKiBWLpgY7e-D8zmRjgaAMgcSFEQ';return true;">https://wandbox.=
org/permlink/<wbr>VcoZff9PjRCHCFbx</a>
<br>
<br>--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=
=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.goo=
gle.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x3dD\x26sntz\x3d1\x26usg\=
x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return true;" onclick=3D"this.hr=
ef=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x=
3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return t=
rue;">macieira.info</a> - thiago (AT) <a href=3D"http://kde.org" target=3D"=
_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.google.=
com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNH=
GRJdo5_JYG1DowztwAHAKs80XSA';return true;" onclick=3D"this.href=3D'=
http://www.google.com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1=
\x26usg\x3dAFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';return true;">kde.org</a=
>
<br>=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center
<br>
<br></blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/98ffdeec-76e4-458a-a371-441c31e3b68b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/98ffdeec-76e4-458a-a371-441c31e3b68b=
%40isocpp.org</a>.<br />
------=_Part_1831_1891875297.1490458469034--
------=_Part_1830_499769470.1490458469034--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Sat, 25 Mar 2017 14:16:34 -0700
Raw View
On s=C3=A1bado, 25 de mar=C3=A7o de 2017 09:14:28 PDT Vittorio Romeo wrote:
> Were you referring to the `...` in `args...`?
No. I thought it was a placeholder.
> It does, but the lambda is not generic anymore. You example compiles
> because the error does not occur during instantiation, it occurs during
> overload resolution.
Right, but why does the lambda have to be generic?
> In my example, the
> l(0)
> call expression is valid - it's the instantiation of `l<int>` that is
> invalid.
>=20
> In your example, the
> l(0)
> call expression is itself invalid - that can be detected by `is_invocable=
`
> without causing an hard error.
I know.
Please be clear: what's the advantage of using=20
=3D> { statements; }
over=20
{ statements; }
for the same lambda? What can the suggested syntax do that the existing syn=
tax=20
can't?
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--=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/13104234.FeGfUWe2pr%40tjmaciei-mobl1.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sat, 25 Mar 2017 14:42:27 -0700 (PDT)
Raw View
------=_Part_3984_2140849822.1490478147482
Content-Type: multipart/alternative;
boundary="----=_Part_3985_2126126290.1490478147482"
------=_Part_3985_2126126290.1490478147482
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Saturday, March 25, 2017 at 5:16:40 PM UTC-4, Thiago Macieira wrote:
>
> On s=C3=A1bado, 25 de mar=C3=A7o de 2017 09:14:28 PDT Vittorio Romeo wrot=
e:=20
> > Were you referring to the `...` in `args...`?=20
>
> No. I thought it was a placeholder.=20
>
> > It does, but the lambda is not generic anymore. You example compiles=20
> > because the error does not occur during instantiation, it occurs during=
=20
> > overload resolution.=20
>
> Right, but why does the lambda have to be generic?
>
Because that's the point: the functor is callable on any type which=20
satisfies the criteria. If a type doesn't satisfy the criteria, then=20
`is_callable` for those parameters will be false, rather than provoking a=
=20
compile error.
He essentially wants a general solution to the SFINAE problem: for all of a=
=20
function's expressions to provoke SFINAE if they are il-formed.
> In my example, the=20
> > l(0)=20
> > call expression is valid - it's the instantiation of `l<int>` that is=
=20
> > invalid.=20
> >=20
> > In your example, the=20
> > l(0)=20
> > call expression is itself invalid - that can be detected by=20
> `is_invocable`=20
> > without causing an hard error.=20
>
> I know.=20
>
> Please be clear: what's the advantage of using=20
> =3D> { statements; }=20
> over=20
> { statements; }=20
> for the same lambda? What can the suggested syntax do that the existing=
=20
> syntax=20
> can't?
>
He just told you what the advantage was: you can ask the question of=20
whether the lambda is callable with a particular parameter without causing=
=20
a compile error. This is why people still use `decltype(expression)`=20
instead of `decltype(auto)` with many return type declarations: because the=
=20
former provokes SFINAE and the latter does not.=20
--=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/cf133c46-3eec-402b-b18a-525e4159f8e9%40isocpp.or=
g.
------=_Part_3985_2126126290.1490478147482
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Saturday, March 25, 2017 at 5:16:40 PM UTC-4, T=
hiago Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On s=C3=
=A1bado, 25 de mar=C3=A7o de 2017 09:14:28 PDT Vittorio Romeo wrote:
<br>> Were you referring to the `...` in `args...`?
<br>
<br>No. I thought it was a placeholder.
<br>
<br>> It does, but the lambda is not generic anymore. You example compil=
es
<br>> because the error does not occur during instantiation, it occurs d=
uring
<br>> overload resolution.
<br>
<br>Right, but why does the lambda have to be generic?<br></blockquote><div=
><br>Because that's the point: the functor is callable on any type whic=
h satisfies the criteria. If a type doesn't satisfy the criteria, then =
`is_callable` for those parameters will be false, rather than provoking a c=
ompile error.<br><br>He essentially wants a general solution to the SFINAE =
problem: for all of a function's expressions to provoke SFINAE if they =
are il-formed.<br><br></div><blockquote class=3D"gmail_quote" style=3D"marg=
in: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
> In my example, the
<br>> l(0)
<br>> call expression is valid - it's the instantiation of `l<int=
>` that is
<br>> invalid.
<br>>=20
<br>> In your example, the
<br>> l(0)
<br>> call expression is itself invalid - that can be detected by `is_in=
vocable`
<br>> without causing an hard error.
<br>
<br>I know.
<br>
<br>Please be clear: what's the advantage of using=20
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=3D> { statements; }
<br>over=20
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0{ statements; }
<br>for the same lambda? What can the suggested syntax do that the existing=
syntax=20
<br>can't?<br></blockquote><div><br>He just told you what the advantage=
was: you can ask the question of whether the lambda is callable with a par=
ticular parameter without causing a compile error. This is why people still=
use `decltype(expression)` instead of `decltype(auto)` with many return ty=
pe declarations: because the former provokes SFINAE and the latter does not=
.. <br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/cf133c46-3eec-402b-b18a-525e4159f8e9%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/cf133c46-3eec-402b-b18a-525e4159f8e9=
%40isocpp.org</a>.<br />
------=_Part_3985_2126126290.1490478147482--
------=_Part_3984_2140849822.1490478147482--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Sat, 25 Mar 2017 22:55:45 -0700
Raw View
On s=C3=A1bado, 25 de mar=C3=A7o de 2017 14:42:27 PDT Nicol Bolas wrote:
> He just told you what the advantage was: you can ask the question of
> whether the lambda is callable with a particular parameter without causin=
g
> a compile error. This is why people still use `decltype(expression)`
> instead of `decltype(auto)` with many return type declarations: because t=
he
> former provokes SFINAE and the latter does not.
But does that require the additional syntax?
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--=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/5697207.kWH5T7BYs2%40tjmaciei-mobl1.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sun, 26 Mar 2017 07:30:35 -0700 (PDT)
Raw View
------=_Part_4609_1918187176.1490538636053
Content-Type: multipart/alternative;
boundary="----=_Part_4610_385994140.1490538636053"
------=_Part_4610_385994140.1490538636053
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Sunday, March 26, 2017 at 1:55:49 AM UTC-4, Thiago Macieira wrote:
>
> On s=C3=A1bado, 25 de mar=C3=A7o de 2017 14:42:27 PDT Nicol Bolas wrote:=
=20
> > He just told you what the advantage was: you can ask the question of=20
> > whether the lambda is callable with a particular parameter without=20
> causing=20
> > a compile error. This is why people still use `decltype(expression)`=20
> > instead of `decltype(auto)` with many return type declarations: because=
=20
> the=20
> > former provokes SFINAE and the latter does not.=20
>
> But does that require the additional syntax?=20
>
Because those are the rules of C++ SFINAE.
Il-formed constructs in a functions definition are hard errors. But=20
il-formed constructs in a function's *declaration* can invoke SFINAE. The=
=20
point of the syntax is to bring aspects of the definition into the=20
declaration without having to repeat them in a `decltype` return type.
Now personally, I think this idea is off-scope for this thread. The `=3D>`=
=20
syntax for expression lambdas is not just about SFINAE. It effectively=20
makes an expression-lambda almost exactly equivalent to using the=20
expression directly in the code. This includes things like `noexcept`=20
forwarding and the like. So hijacking `=3D>` to be about effectively bringi=
ng=20
SFINAE into an arbitrary function's definition is out of scope.
--=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/5584620f-6430-4314-bc4d-6a9673211e9d%40isocpp.or=
g.
------=_Part_4610_385994140.1490538636053
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Sunday, March 26, 2017 at 1:55:49 AM UTC-4, Thiago Maci=
eira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On s=C3=A1bado, 25 =
de mar=C3=A7o de 2017 14:42:27 PDT Nicol Bolas wrote:
<br>> He just told you what the advantage was: you can ask the question =
of
<br>> whether the lambda is callable with a particular parameter without=
causing
<br>> a compile error. This is why people still use `decltype(expression=
)`
<br>> instead of `decltype(auto)` with many return type declarations: be=
cause the
<br>> former provokes SFINAE and the latter does not.
<br>
<br>But does that require the additional syntax?
<br></blockquote><div><br>Because those are the rules of C++ SFINAE.<br><br=
>Il-formed constructs in a functions definition are hard errors. But il-for=
med constructs in a function's <i>declaration</i> can invoke SFINAE. Th=
e point of the syntax is to bring aspects of the definition into the declar=
ation without having to repeat them in a `decltype` return type.<br><br>Now=
personally, I think this idea is off-scope for this thread. The `=3D>` =
syntax for expression lambdas is not just about SFINAE. It effectively make=
s an expression-lambda almost exactly equivalent to using the expression di=
rectly in the code. This includes things like `noexcept` forwarding and the=
like. So hijacking `=3D>` to be about effectively bringing SFINAE into =
an arbitrary function's definition is out of scope.<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/5584620f-6430-4314-bc4d-6a9673211e9d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5584620f-6430-4314-bc4d-6a9673211e9d=
%40isocpp.org</a>.<br />
------=_Part_4610_385994140.1490538636053--
------=_Part_4609_1918187176.1490538636053--
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Tue, 28 Mar 2017 14:46:50 -0400
Raw View
On 2017-03-25 09:43, Vittorio Romeo wrote:
> Are there any news regarding this proposal? (https://wg21.link/p0573)
Shorter single-expression lambdas?
5 | 12 | 11 | 2 | 0
Typeless parameters?
0 | 5 | 9 | 6 | 5
Conjured SFINAEable return type?
3 | 7 | 11 | 5 | 1
Conjured noexcept specification?
1 | 7 | 10 | 6 | 2
Shorter forward?
4 | 7 | 9 | 4 | 3
> However, one thing that I think would be very important to add to the
> proposal is the ability to use compound statements after =>.
Statement-expressions could achieve this.
--
Matthew
--
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/58DAAF9A.6030408%40gmail.com.
.
Author: wpmgprostotema@gmail.com
Date: Sat, 7 Oct 2017 14:13:35 -0700 (PDT)
Raw View
------=_Part_3426_518440118.1507410815304
Content-Type: multipart/alternative;
boundary="----=_Part_3427_1964890403.1507410815304"
------=_Part_3427_1964890403.1507410815304
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
=D0=B2=D1=82=D0=BE=D1=80=D0=BD=D0=B8=D0=BA, 11 =D0=BE=D0=BA=D1=82=D1=8F=D0=
=B1=D1=80=D1=8F 2016 =D0=B3., 20:48:46 UTC+3 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=
=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Richard Smith=20
=D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:
> Minor correction to your "Effects on Existing Code" section: the characte=
r=20
> sequence =3D> can appear in legal C++ programs today. For instance,=20
> X<&Y::operator=3D>. That said, I've searched a large codebase for this=20
> (>100MLoC) and the only occurrence of =3D> (outside of comments, string=
=20
> literals, etc.) was in a compiler test suite.
>
Can you show an example code using =3D>?
--=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/eee6cfd7-240d-452f-8e27-50ffd90269ee%40isocpp.or=
g.
------=_Part_3427_1964890403.1507410815304
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">=D0=B2=D1=82=D0=BE=D1=80=D0=BD=D0=B8=D0=BA, 11 =D0=BE=D0=
=BA=D1=82=D1=8F=D0=B1=D1=80=D1=8F 2016 =D0=B3., 20:48:46 UTC+3 =D0=BF=D0=BE=
=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Richard Smith =
=D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:<br><blockquote class=3D"gmail_q=
uote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pad=
ding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>Mino=
r correction to your "Effects on Existing Code" section: the char=
acter sequence =3D> can appear in legal C++ programs today. For instance=
, X<&Y::operator=3D>. That said, I've searched a large codeba=
se for this (>100MLoC) and the only occurrence of =3D> (outside of co=
mments, string literals, etc.) was in a compiler test suite.</div></div></d=
iv></div></blockquote><div>Can you show an example code using =3D>?<br><=
/div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/eee6cfd7-240d-452f-8e27-50ffd90269ee%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/eee6cfd7-240d-452f-8e27-50ffd90269ee=
%40isocpp.org</a>.<br />
------=_Part_3427_1964890403.1507410815304--
------=_Part_3426_518440118.1507410815304--
.