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

Currently the standard (C++14 CD - NS3690) disallows explicit capture of=20
this by reference the this seems to be allowed to be captured implicit by=
=20
reference by the [&]. $5.1.2:
15. An entity is captured by copy if it is implicitly captured and the=20
capture-default is =3D or if it is explicitly
captured with a capture that does not include an &. For each entity=20
captured by copy, an unnamed non-
static data member is declared in the closure type. The declaration order=
=20
of these members is unspecified.
The type of such a data member is the type of the corresponding captured=20
entity if the entity is not a
reference to an object, or the referenced type otherwise. [ Note: If the=20
captured entity is a reference to a
function, the corresponding data member is also a reference to a function.=
=20
=97 end note ] An array of runtime
bound (8.3.4) shall not be captured by copy.
16. An entity is captured by reference if it is implicitly or explicitly=20
captured but not captured by copy. It is
unspecified whether additional unnamed non-static data members are declared=
=20
in the closure type for entities
captured by reference. [ Note: Capturing by reference an array of runtime=
=20
bound also
.. See also. this questions.<http://stackoverflow.com/questions/12718064/und=
erstanding-in-c-lambda-capture-specification>

Contrary the statement $5.1.2/18:
Every id-expression that is an odr-use (3.2) of an entity captured by copy=
=20
is transformed into an access to the
corresponding unnamed data member of the closure type. [ Note: An=20
id-expression that is not an odr-use
refers to the original entity, never to a member of the closure type.=20
Furthermore, such an id-expression
does not cause the implicit capture of the entity. =97 end note ] *If this =
is=20
captured, each odr-use of this
is transformed into an access to the corresponding unnamed data member of=
=20
the closure type, cast (5.4)
to the type of this.* [ Note: The cast ensures that the transformed=20
expression is a prvalue. =97 end note ]
Sugest that this is always stored in separate unnamed member of closuer=20
type, which with combination with $5.1.2/16:
An entity is captured by reference if it is implicitly or explicitly=20
captured but not captured by copy.* It is
unspecified whether additional unnamed non-static data members are declared=
=20
in the closure type for entities
captured by reference. *[ Note: Capturing by reference an array of runtime=
=20
bound also implicitly captures
the value of the bound to support the range-based for statement (6.5.4). =
=97=20
end note ]
So in combination this to statement suggests that this is always captured=
=20
by copy.

Is this the issue in the standard wording and the this was designed to be=
=20
always captured by value? If so the point be changed to explicitly mention=
=20
this.
15. An entity is captured by copy if it is *this or* implicitly captured=20
and the capture-default is =3D or if it is explicitly
captured with a capture that does not include an &. For each entity=20
captured by copy, an unnamed non-
static data member is declared in the closure type. The declaration order=
=20
of these members is unspecified.
The type of such a data member is the type of the corresponding captured=20
entity if the entity is not a
reference to an object, or the referenced type otherwise. [ Note: If the=20
captured entity is a reference to a
function, the corresponding data member is also a reference to a function.=
=20
=97 end note ] An array of runtime
bound (8.3.4) shall not be captured by copy.

--=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_1_13674258.1371154609502
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Currently the standard (C++14 CD - NS3690) disallows explicit capture of th=
is by reference the this seems to be allowed to be captured implicit by ref=
erence by the [&amp;]. $5.1.2:<br><span style=3D"font-family: courier new,m=
onospace;">15. An entity is captured by copy if it is implicitly captured a=
nd the capture-default is =3D or if it is explicitly<br>captured with a cap=
ture that does not include an &amp;. For each entity captured by copy, an u=
nnamed non-<br>static data member is declared in the closure type. The decl=
aration order of these members is unspecified.<br>The type of such a data m=
ember is the type of the corresponding captured entity if the entity is not=
 a<br>reference to an object, or the referenced type otherwise. [ Note: If =
the captured entity is a reference to a<br>function, the corresponding data=
 member is also a reference to a function. =97 end note ] An array of runti=
me<br>bound (8.3.4) shall not be captured by copy.<br>16. An entity is capt=
ured by reference if it is implicitly or explicitly captured but not captur=
ed by copy. It is<br>unspecified whether additional unnamed non-static data=
 members are declared in the closure type for entities<br>captured by refer=
ence. [ Note: Capturing by reference an array of runtime bound also</span><=
br>. See also. <a href=3D"http://stackoverflow.com/questions/12718064/under=
standing-in-c-lambda-capture-specification">this questions.</a><br><br>Cont=
rary the statement $5.1.2/18:<br><span style=3D"font-family: courier new,mo=
nospace;">Every id-expression that is an odr-use (3.2) of an entity capture=
d by copy is transformed into an access to the<br>corresponding unnamed dat=
a member of the closure type. [ Note: An id-expression that is not an odr-u=
se<br>refers to the original entity, never to a member of the closure type.=
 Furthermore, such an id-expression<br>does not cause the implicit capture =
of the entity. =97 end note ] <b>If this is captured, each odr-use of this<=
br>is transformed into an access to the corresponding unnamed data member o=
f the closure type, cast (5.4)<br>to the type of this.</b> [ Note: The cast=
 ensures that the transformed expression is a prvalue. =97 end note ]<br><f=
ont face=3D"arial,sans-serif">Sugest that this is always stored in separate=
 unnamed member of closuer type, which with combination with $5.1.2/16:<br>=
<span style=3D"font-family: courier new,monospace;">An entity is captured b=
y reference if it is implicitly or explicitly captured but not captured by =
copy.<b> It is<br>unspecified whether additional unnamed non-static data me=
mbers are declared in the closure type for entities<br>captured by referenc=
e. </b>[ Note: Capturing by reference an array of runtime bound also implic=
itly captures<br>the value of the bound to support the range-based for stat=
ement (6.5.4). =97 end note ]</span><br></font></span>So in combination thi=
s to statement suggests that this is always captured by copy.<br><br>Is thi=
s the issue in the standard wording and the this was designed to be always =
captured by value? If so the point be changed to explicitly mention this.<b=
r><span style=3D"font-family: courier new,monospace;">15. An entity is capt=
ured by copy if it is <span style=3D"color: rgb(0, 0, 0);"><u>this or</u> <=
/span>implicitly captured and the capture-default is =3D or if it is explic=
itly<br>captured with a capture that does not include an &amp;. For each en=
tity captured by copy, an unnamed non-<br>static data member is declared in=
 the closure type. The declaration order of these members is unspecified.<b=
r>The type of such a data member is the type of the corresponding captured =
entity if the entity is not a<br>reference to an object, or the referenced =
type otherwise. [ Note: If the captured entity is a reference to a<br>funct=
ion, the corresponding data member is also a reference to a function. =97 e=
nd note ] An array of runtime<br>bound (8.3.4) shall not be captured by cop=
y.</span><br>

<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_1_13674258.1371154609502--

.

--047d7bea42d4a09cfe04df0f4551
Content-Type: text/plain; charset=ISO-8859-1

On 13 June 2013 15:16, <tomaszkam@gmail.com> wrote:

> Currently the standard (C++14 CD - NS3690) disallows explicit capture of
> this by reference the this seems to be allowed to be captured implicit by
> reference by the [&]. $5.1.2:
>

Is this something that can be handled editorially?

Does it matter?  Is there a use case that can distinguish between capturing
this by reference and this by value?
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--

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



--047d7bea42d4a09cfe04df0f4551
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 13 June 2013 15:16,  <span dir=3D"ltr">&lt;<a href=3D"mailto:tomaszkam@g=
mail.com" target=3D"_blank">tomaszkam@gmail.com</a>&gt;</span> wrote:<br><d=
iv class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Currently the standard (C++14 CD - NS3690) disallows explicit capture of th=
is by reference the this seems to be allowed to be captured implicit by ref=
erence by the [&amp;]. $5.1.2:<br></blockquote><div><br>Is this something t=
hat can be handled editorially?<br>

<br>Does it matter?=A0 Is there a use case that can distinguish between cap=
turing this by reference and this by value?<br></div></div>-- <br>=A0Nevin =
&quot;:-)&quot; Liber=A0 &lt;mailto:<a href=3D"mailto:nevin@eviloverlord.co=
m" target=3D"_blank">nevin@eviloverlord.com</a>&gt;=A0 (847) 691-1404

<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 />

--047d7bea42d4a09cfe04df0f4551--

.

--f46d0446325298671d04df0f53b8
Content-Type: text/plain; charset=ISO-8859-1

On 13 June 2013 23:49, Nevin Liber <nevin@eviloverlord.com> wrote:

> On 13 June 2013 15:16, <tomaszkam@gmail.com> wrote:
>
>> Currently the standard (C++14 CD - NS3690) disallows explicit capture of
>> this by reference the this seems to be allowed to be captured implicit by
>> reference by the [&]. $5.1.2:
>>
>
> Is this something that can be handled editorially?
>
> Does it matter?  Is there a use case that can distinguish between
> capturing this by reference and this by value?
>
>
And if there is such a use case, is it not covered by using an
init-capture?

Hmm. [&foo = this] doesn't work, we can't initialize a ref-to-nonconst from
a prvalue, and this is a prvalue...

--

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



--f46d0446325298671d04df0f53b8
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 13 June 2013 23:49, Nevin Liber <span dir=3D"ltr">&lt;<a href=3D=
"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a=
>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On 13 June 2013 15:16,  <s=
pan dir=3D"ltr">&lt;<a href=3D"mailto:tomaszkam@gmail.com" target=3D"_blank=
">tomaszkam@gmail.com</a>&gt;</span> wrote:<br>
</div><div class=3D"gmail_quote"><div class=3D"im"><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex">

Currently the standard (C++14 CD - NS3690) disallows explicit capture of th=
is by reference the this seems to be allowed to be captured implicit by ref=
erence by the [&amp;]. $5.1.2:<br></blockquote></div><div><br>Is this somet=
hing that can be handled editorially?<br>


<br>Does it matter?=A0 Is there a use case that can distinguish between cap=
turing this by reference and this by value?<span class=3D"HOEnZb"><font col=
or=3D"#888888"><br></font></span></div></div><span class=3D"HOEnZb"><font c=
olor=3D"#888888"><br>
</font></span></blockquote><div><br></div><div>And if there is such a use c=
ase, is it not covered by using an init-capture? <br></div></div><br></div>=
<div class=3D"gmail_extra">Hmm. [&amp;foo =3D this] doesn&#39;t work, we ca=
n&#39;t initialize a ref-to-nonconst from a prvalue, and this is a prvalue.=
...<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 />

--f46d0446325298671d04df0f53b8--

.

On Thu, Jun 13, 2013 at 1:53 PM, Ville Voutilainen
<ville.voutilainen@gmail.com> wrote:
> On 13 June 2013 23:49, Nevin Liber <nevin@eviloverlord.com> wrote:
>> On 13 June 2013 15:16, <tomaszkam@gmail.com> wrote:
>>>
>>> Currently the standard (C++14 CD - NS3690) disallows explicit capture of
>>> this by reference the this seems to be allowed to be captured implicit by
>>> reference by the [&]. $5.1.2:
>>
>>
>> Is this something that can be handled editorially?
>>
>> Does it matter?  Is there a use case that can distinguish between
>> capturing this by reference and this by value?
>>
>
> And if there is such a use case, is it not covered by using an init-capture?
>
> Hmm. [&foo = this] doesn't work, we can't initialize a ref-to-nonconst from
> a prvalue, and this is a prvalue...

That seems like a good reason to disallow [&this]: we'd be binding a
reference to a prvalue. Even if that worked, what lifetime would the
temporary we created have?

--

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



.

------=_Part_345_6933156.1371188518509
Content-Type: text/plain; charset=ISO-8859-1

For may point of view standard is requiring the this to by captured by
copy: *If this is captured, each odr-use of this
is transformed into an access to the corresponding unnamed data member of
the closure type, cast (5.4)
to the type of this.* and *It is unspecified whether additional unnamed
non-static data members are declared
in the closure type for entities captured by reference.*

While the statements about the type of capture, suggest that this is
captured by reference if it is implicitly captured by [&], so  I think that
is a defect, and the wording
should be changed to say explicitly that this is always captured by value.

--

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



------=_Part_345_6933156.1371188518509
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

For may point of view standard is requiring the this to by captured by copy=
: <span style=3D"font-family: courier new,monospace;"><b>If this is capture=
d, each odr-use of this<br>is transformed into an access to the correspondi=
ng unnamed data member of the closure type, cast (5.4)<br>to the type of th=
is.</b> <span style=3D"font-family: arial,sans-serif;">and</span> </span><s=
pan style=3D"font-family: courier new,monospace;"><font face=3D"arial,sans-=
serif"><span style=3D"font-family:courier new,monospace"><b>It is unspecifi=
ed whether additional unnamed non-static data members are declared<br>in th=
e closure type for entities captured by reference.</b></span></font></span>=
<br><br>While the statements about the type of capture, suggest that this i=
s captured by reference if it is implicitly captured by [&amp;], so&nbsp; I=
 think that is a defect, and the wording<br>should be changed to say explic=
itly that this is always captured by value.<br><br>

<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_345_6933156.1371188518509--

.

------=_Part_1106_8050577.1371299335036
Content-Type: text/plain; charset=ISO-8859-1

The point is that *this *is a keyword not an identifier.
In section 2.1.2, *this* is listed among the keywords. In section 5.1.2,
when the capture is defined, it allows identifies, &identifies and *this*.
That's why *&this* is not allowed.

Here are the sections of the standard:

*2.12 Keywords.*

*5.1.2* Lambda Expressions
*capture:
     identifier
    & identifier
    this*




--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.



------=_Part_1106_8050577.1371299335036
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div>The point is that <strong><em>this </em></strong>is a keyword not an i=
dentifier. </div><div>In section 2.1.2, <strong><em>this</em></strong> is l=
isted among the keywords. In section 5.1.2, when the capture is defined, it=
 allows identifies, &amp;identifies and <strong><em>this</em></strong>.</di=
v><div>That's why <strong>&amp;this</strong> is not allowed.</div><div>&nbs=
p;</div><div>Here are the sections of the standard:</div><div>&nbsp;</div><=
div><strong>2.12 Keywords.</strong></div><div><br><strong>5.1.2</strong> La=
mbda Expressions</div><div><strong>capture:<br>&nbsp;&nbsp;&nbsp;&nbsp; ide=
ntifier<br>&nbsp;&nbsp;&nbsp; &amp; identifier<br>&nbsp;&nbsp;&nbsp; this</=
strong></div><div>&nbsp;</div><div><br>&nbsp;</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 />

------=_Part_1106_8050577.1371299335036--

.