------=_Part_6633_1368339936.1507020341691
Content-Type: multipart/alternative;
 boundary="----=_Part_6634_1013674057.1507020341692"

------=_Part_6634_1013674057.1507020341692
Content-Type: text/plain; charset="UTF-8"

Regarding the return types of lambdas, the c++ standard says in section
5.1.2/4

> [...] The lambda return type is auto, which is replaced by the type
specified by the trailing-return-type if provided and/or deduced from
return statements [...]

and it provides the examples:

> auto x1 = [](int i) { return i; }; // OK: return type is _int_

> auto x2 = [] { return { 1, 2 }; }; // error: deducing return type from
_braced-init-list_

However, it is worth noting that the type specifier for both `x1` and `x2`
is auto.

If you use a type specifier that defines the return type, e.g.


struct Foo { int x; int y; };

function<Foo()> x3 = [] { return { 1, 2 }; };

Foo (*x4)() = [] { return { 1, 2 }; };


the definitions of x3 and x4 still produce errors saying that lambdas
cannot return initializer lists (tested in mingw with -std=c++1z).  The
standard does not allow the return type of a lambda to be determined by its
type specifier.  Is there any reason this has to be this way, or could the
standard be updated to allow this in the next edition?

Why not change the text to say this:

> [...] The lambda return type is auto, which is replaced by the type
specified by the trailing-return-type if provided, specified by the
type-specifier if in a definition, and/or deduced from return statements
[...]

--
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/d5ed1197-93ce-45ca-b807-013214962cac%40isocpp.org.

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

<div dir=3D"ltr">Regarding the return types of lambdas, the c++ standard sa=
ys in section 5.1.2/4<br><br>&gt; [...] The lambda return type is auto, whi=
ch is replaced by the type specified by the trailing-return-type if provide=
d and/or deduced from return statements [...]<br><br>and it provides the ex=
amples:<br><br>&gt; auto x1 =3D [](int i) { return i; }; // OK: return type=
 is _int_<br><br>&gt; auto x2 =3D [] { return { 1, 2 }; }; // error: deduci=
ng return type from _braced-init-list_<br><br><div>However, it is worth not=
ing that the type specifier for both `x1` and `x2` is auto.</div><div><br><=
/div><div>If you use a type specifier that defines the return type, e.g.</d=
iv><div><br></div><div><br></div>struct Foo { int x; int y; };<br><br><div>=
function&lt;Foo()&gt; x3 =3D [] { return { 1, 2 }; };</div><div><br></div><=
div>Foo (*x4)() =3D [] { return { 1, 2 }; };<br><br></div><br><div>the defi=
nitions of x3 and x4 still produce errors saying that lambdas cannot return=
 initializer lists (tested in mingw with -std=3Dc++1z).=C2=A0 The standard =
does not allow the return type of a lambda to be determined by its type spe=
cifier.=C2=A0 Is there any reason this has to be this way, or could the sta=
ndard be updated to allow this in the next edition?</div><div><br></div><di=
v>Why not change the text to say this:</div><div><br></div><div>&gt; [...] =
The lambda return type is auto, which is replaced by the type specified by =
the trailing-return-type if provided, specified by the type-specifier if in=
 a definition, and/or deduced from return statements [...]<br></div></div>

<p></p>

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

------=_Part_6634_1013674057.1507020341692--

------=_Part_6633_1368339936.1507020341691--

.