------=_Part_947_1450641341.1500240296602
Content-Type: multipart/alternative;
 boundary="----=_Part_948_1584089166.1500240296602"

------=_Part_948_1584089166.1500240296602
Content-Type: text/plain; charset="UTF-8"

There's a bug (I think so) in Clang that exists up to the latest released
one, 4.0.1, where one
can parenthesize a declarator to force a rvalue reference parameter,
instead of having a
forwarding reference:

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

f(42); // OK
int x;
f(x); // error

Without parenthesis, a forwarding reference as usual:

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

f(42); // OK
int x;
f(x); // OK

This is not in trunk anymore as far as I've tested on online compilers, nor
does GCC behaves
this way.

Still, for me, this seems quite useful, hence I'm opening the discussion
whether it would be worth
having.

Regards,
Francisco Lopes

--
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/c6bb78b4-7aed-426d-9eae-fb26a7ede9cb%40isocpp.org.

------=_Part_948_1584089166.1500240296602
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">There&#39;s a bug (I think so) in Clang that exists up to =
the latest released one, 4.0.1, where one<br>can parenthesize a declarator =
to force a rvalue reference parameter, instead of having a<br>forwarding re=
ference:<br><br><span style=3D"font-family: courier new,monospace;">auto f =
=3D [](auto (&amp;&amp;r)) {}<br><br>f(42); // OK<br>int x;<br>f(x); // err=
or</span><br><br>Without parenthesis, a forwarding reference as usual:<br><=
br><span style=3D"font-family: courier new,monospace;">auto f =3D [](auto &=
amp;&amp;r) {}<br><br>f(42); // OK<br>int x;<br>f(x); // OK</span><br><br>T=
his is not in trunk anymore as far as I&#39;ve tested on online compilers, =
nor does GCC behaves<br>this way.<br><br>Still, for me, this seems quite us=
eful, hence I&#39;m opening the discussion whether it would be worth<br>hav=
ing.<br><br>Regards,<br>Francisco Lopes<br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/c6bb78b4-7aed-426d-9eae-fb26a7ede9cb%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c6bb78b4-7aed-426d-9eae-fb26a7ede9cb=
%40isocpp.org</a>.<br />

------=_Part_948_1584089166.1500240296602--

------=_Part_947_1450641341.1500240296602--

.