------=_Part_586_13055401.1372185895504
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

The C++14 CD (N3690) at the paragraph $5.1.2/11, says:
For every init-capture a non-static data member named by the identifier of=
=20
the init-capture is declared in
the closure type. This member is not a bit-field and not mutable. The type=
=20
of that member corresponds to
the type of a hypothetical variable declaration of the form =93auto=20
init-capture ;=94, except that the variable
name (i.e., the identifier of the init-capture) is replaced by a unique=20
identifier.

As I understand this means that the type of member x declared in lambda=20
capture as [x{std::move(uniq_ptr)}] () {} will be the same as would be for=
=20
the expression auto x{std::move(unique_ptr)}. That means that type of x=20
would be std::initializer_list<std::unique_ptr<int>> (assuming that type of=
=20
unique_ptr is std::unique_ptr<int>). in contrast the original prposal<http:=
//www.open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3610.html>contains of l=
ambda example [=20
x { move(x) }, y =3D transform(y, z), foo, bar, baz ] { ... }, which sugges=
t=20
that type of x would be std::unique_ptr<int>.

I am understanding the wording correctly? If so was this change made on=20
purpose?

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.



------=_Part_586_13055401.1372185895504
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

The C++14 CD (N3690) at the paragraph $5.1.2/11, says:<br>For every init-ca=
pture a non-static data member named by the identifier of the init-capture =
is declared in<br>the closure type. This member is not a bit-field and not =
mutable. The type of that member corresponds to<br>the type of a hypothetic=
al variable declaration of the form =93auto init-capture ;=94, except that =
the variable<br>name (i.e., the identifier of the init-capture) is replaced=
 by a unique identifier.<br><br>As I understand this means that the type of=
 member <span style=3D"font-family: courier new,monospace;">x</span> declar=
ed in lambda capture as<span style=3D"font-family: courier new,monospace;">=
 [x{std::move(uniq_ptr)}] () {}</span>&nbsp;will be the same as would be fo=
r the expression <span style=3D"font-family: courier new,monospace;">auto x=
{std::move(unique_ptr)}</span>. That means that type of x would be <span st=
yle=3D"font-family: courier new,monospace;">std::initializer_list&lt;std::u=
nique_ptr&lt;int&gt;&gt;</span> (assuming that type of <span style=3D"font-=
family: courier new,monospace;">unique_ptr</span> is <span style=3D"font-fa=
mily: courier new,monospace;">std::unique_ptr&lt;int&gt;</span>). <span id=
=3D"result_box" class=3D"short_text" lang=3D"en"><span class=3D"hps">in con=
trast the <a href=3D"http://www.open-std.org/JTC1/SC22/WG21/docs/papers/201=
3/n3610.html">original prposal</a></span></span> contains of lambda example=
<span style=3D"font-family: courier new,monospace;"><code> <span style=3D"f=
ont-family: courier new,monospace;"><font size=3D"2">[ x { move(x) }, y =3D=
 transform(y, z), foo, bar, baz ] { ... },<font face=3D"arial,sans-serif"> =
which suggest that </font></font></span></code></span>type of <font face=3D=
"courier new,monospace">x</font> would be <span style=3D"font-family: couri=
er new,monospace;">std::unique_ptr&lt;int&gt;.<br><br><font face=3D"arial,s=
ans-serif">I am understanding the wording correctly? If so was this change =
made on purpose?</font><br></span>

<p></p>

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

------=_Part_586_13055401.1372185895504--

.

On Tue, Jun 25, 2013 at 11:44 AM,  <tomaszkam@gmail.com> wrote:
> The C++14 CD (N3690) at the paragraph $5.1.2/11, says:
> For every init-capture a non-static data member named by the identifier o=
f
> the init-capture is declared in
> the closure type. This member is not a bit-field and not mutable. The typ=
e
> of that member corresponds to
> the type of a hypothetical variable declaration of the form =93auto
> init-capture ;=94, except that the variable
> name (i.e., the identifier of the init-capture) is replaced by a unique
> identifier.
>
> As I understand this means that the type of member x declared in lambda
> capture as [x{std::move(uniq_ptr)}] () {} will be the same as would be fo=
r
> the expression auto x{std::move(unique_ptr)}. That means that type of x
> would be std::initializer_list<std::unique_ptr<int>> (assuming that type =
of
> unique_ptr is std::unique_ptr<int>). in contrast the original prposal
> contains of lambda example [ x { move(x) }, y =3D transform(y, z), foo, b=
ar,
> baz ] { ... }, which suggest that type of x would be std::unique_ptr<int>=
..
>
> I am understanding the wording correctly? If so was this change made on
> purpose?

We discussed this in core. We didn't want init-captures to behave
differently from auto variable initialization, but there was a feeling
that auto variable initialization from a braced-init-list should be
fixed to not produce a std::initializer_list type here. We are
expecting at least one national body comment requesting a fix for
this, so there's a good chance that auto-deduction from initializer
lists will change in the C++14 FDIS to not give an initializer_list
type in the above case.

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.



.

--047d7bea3fce9ec47b04e0011ab9
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On 25 June 2013 22:07, Richard Smith <richard@metafoo.co.uk> wrote:

> On Tue, Jun 25, 2013 at 11:44 AM,  <tomaszkam@gmail.com> wrote:
> > The C++14 CD (N3690) at the paragraph $5.1.2/11, says:
> > For every init-capture a non-static data member named by the identifier
> of
> > the init-capture is declared in
> > the closure type. This member is not a bit-field and not mutable. The
> type
> > of that member corresponds to
> > the type of a hypothetical variable declaration of the form =93auto
> > init-capture ;=94, except that the variable
> > name (i.e., the identifier of the init-capture) is replaced by a unique
> > identifier.
> >
> > As I understand this means that the type of member x declared in lambda
> > capture as [x{std::move(uniq_ptr)}] () {} will be the same as would be
> for
> > the expression auto x{std::move(unique_ptr)}. That means that type of x
> > would be std::initializer_list<std::unique_ptr<int>> (assuming that typ=
e
> of
> > unique_ptr is std::unique_ptr<int>). in contrast the original prposal
> > contains of lambda example [ x { move(x) }, y =3D transform(y, z), foo,
> bar,
> > baz ] { ... }, which suggest that type of x would be
> std::unique_ptr<int>.
> >
> > I am understanding the wording correctly? If so was this change made on
> > purpose?
>
> We discussed this in core. We didn't want init-captures to behave
> differently from auto variable initialization, but there was a feeling
> that auto variable initialization from a braced-init-list should be
> fixed to not produce a std::initializer_list type here. We are
> expecting at least one national body comment requesting a fix for
> this, so there's a good chance that auto-deduction from initializer
> lists will change in the C++14 FDIS to not give an initializer_list
> type in the above case.
>


There's also a paper about it at
http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3681.html

Richard, if you want to help with the wording, that would be much
appreciated.
I can utilize such wording with or without attribution, depending on whethe=
r
you want to be a co-conspirator or an innocent bystander. ;)

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.



--047d7bea3fce9ec47b04e0011ab9
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 25 June 2013 22:07, Richard Smith <span dir=3D"ltr">&lt;<a href=
=3D"mailto:richard@metafoo.co.uk" target=3D"_blank">richard@metafoo.co.uk</=
a>&gt;</span> 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"><div class=3D"im">On Tue,=
 Jun 25, 2013 at 11:44 AM, =A0&lt;<a href=3D"mailto:tomaszkam@gmail.com">to=
maszkam@gmail.com</a>&gt; wrote:<br>

&gt; The C++14 CD (N3690) at the paragraph $5.1.2/11, says:<br>
&gt; For every init-capture a non-static data member named by the identifie=
r of<br>
&gt; the init-capture is declared in<br>
&gt; the closure type. This member is not a bit-field and not mutable. The =
type<br>
&gt; of that member corresponds to<br>
&gt; the type of a hypothetical variable declaration of the form =93auto<br=
>
&gt; init-capture ;=94, except that the variable<br>
&gt; name (i.e., the identifier of the init-capture) is replaced by a uniqu=
e<br>
&gt; identifier.<br>
&gt;<br>
&gt; As I understand this means that the type of member x declared in lambd=
a<br>
&gt; capture as [x{std::move(uniq_ptr)}] () {} will be the same as would be=
 for<br>
&gt; the expression auto x{std::move(unique_ptr)}. That means that type of =
x<br>
&gt; would be std::initializer_list&lt;std::unique_ptr&lt;int&gt;&gt; (assu=
ming that type of<br>
&gt; unique_ptr is std::unique_ptr&lt;int&gt;). in contrast the original pr=
posal<br>
&gt; contains of lambda example [ x { move(x) }, y =3D transform(y, z), foo=
, bar,<br>
&gt; baz ] { ... }, which suggest that type of x would be std::unique_ptr&l=
t;int&gt;.<br>
&gt;<br>
&gt; I am understanding the wording correctly? If so was this change made o=
n<br>
&gt; purpose?<br>
<br>
</div>We discussed this in core. We didn&#39;t want init-captures to behave=
<br>
differently from auto variable initialization, but there was a feeling<br>
that auto variable initialization from a braced-init-list should be<br>
fixed to not produce a std::initializer_list type here. We are<br>
expecting at least one national body comment requesting a fix for<br>
this, so there&#39;s a good chance that auto-deduction from initializer<br>
lists will change in the C++14 FDIS to not give an initializer_list<br>
type in the above case.<br></blockquote><div><br><br></div><div>There&#39;s=
 also a paper about it at<br><a href=3D"http://open-std.org/JTC1/SC22/WG21/=
docs/papers/2013/n3681.html">http://open-std.org/JTC1/SC22/WG21/docs/papers=
/2013/n3681.html</a><br>
<br></div><div>Richard, if you want to help with the wording, that would be=
 much appreciated.<br></div><div>I can utilize such wording with or without=
 attribution, depending on whether<br>you want to be a co-conspirator or an=
 innocent bystander. ;)<br>
</div></div><br></div></div>

<p></p>

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

--047d7bea3fce9ec47b04e0011ab9--

.

On Tue, Jun 25, 2013 at 2:20 PM, Ville Voutilainen
<ville.voutilainen@gmail.com> wrote:
> On 25 June 2013 22:07, Richard Smith <richard@metafoo.co.uk> wrote:
>> On Tue, Jun 25, 2013 at 11:44 AM,  <tomaszkam@gmail.com> wrote:
>> > The C++14 CD (N3690) at the paragraph $5.1.2/11, says:
>> > For every init-capture a non-static data member named by the identifie=
r
>> > of
>> > the init-capture is declared in
>> > the closure type. This member is not a bit-field and not mutable. The
>> > type
>> > of that member corresponds to
>> > the type of a hypothetical variable declaration of the form =93auto
>> > init-capture ;=94, except that the variable
>> > name (i.e., the identifier of the init-capture) is replaced by a uniqu=
e
>> > identifier.
>> >
>> > As I understand this means that the type of member x declared in lambd=
a
>> > capture as [x{std::move(uniq_ptr)}] () {} will be the same as would be
>> > for
>> > the expression auto x{std::move(unique_ptr)}. That means that type of =
x
>> > would be std::initializer_list<std::unique_ptr<int>> (assuming that ty=
pe
>> > of
>> > unique_ptr is std::unique_ptr<int>). in contrast the original prposal
>> > contains of lambda example [ x { move(x) }, y =3D transform(y, z), foo=
,
>> > bar,
>> > baz ] { ... }, which suggest that type of x would be
>> > std::unique_ptr<int>.
>> >
>> > I am understanding the wording correctly? If so was this change made o=
n
>> > purpose?
>>
>> We discussed this in core. We didn't want init-captures to behave
>> differently from auto variable initialization, but there was a feeling
>> that auto variable initialization from a braced-init-list should be
>> fixed to not produce a std::initializer_list type here. We are
>> expecting at least one national body comment requesting a fix for
>> this, so there's a good chance that auto-deduction from initializer
>> lists will change in the C++14 FDIS to not give an initializer_list
>> type in the above case.
>
>
>
> There's also a paper about it at
> http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3681.html
>
> Richard, if you want to help with the wording, that would be much
> appreciated.
> I can utilize such wording with or without attribution, depending on whet=
her
> you want to be a co-conspirator or an innocent bystander. ;)

I'd be happy to help. You should also contact Jason Merrill; he was
looking at wording changes for this, and they were briefly included in
his drafting for DR1467/1490/1589/1631. The approach of that drafting
made braced auto initialization deduce initializer_list<T> only if
there were multiple initializers in the braces. FWIW, I much prefer
your wholesale removal of deduction of initializer_list.

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.



.