------=_Part_315_17497210.1401196071679
Content-Type: text/plain; charset=UTF-8

A very short proposal to add a single word in the standard.

One feature that I think is really cool about lambda functions is that they
allow us to reason locally about the entities captured by copy.

Entities captured by copy are initialized at construction and are visible
only from within the lambda. They are by default const protected (because
the function call operator is const) unless the lambda is declared *mutable*.
This makes it really easy for programmers and compilers to reason about the
usage of these variables.

However the standard does not seems to clearly define permissions of the
the data members for by-copy capture:
> (5.1.2.15) For each entity captured by copy, an unnamed non-static data
member is declared in the closure type.

Because of the lack of visibility qualifier, local reasoning is potentially
threatened by reflection. If using reflection allows arbitrary code to
access and modify the value of a public by-copy captured variable, then the
strong isolation property is lost. Consider this example using the notation
proposed in N3951:

template<typename T>

void foo(T &t){

  // reflection allows us to alter data captured by copy

  auto reflect = std::make_tuple(typedef<T>...);

  // this changes the value of the captured value from outside the lambda

  *std::get<1>(reflect) = 0;

}


int main(){

  int i = 2;

  // This declaration should allow us to assume the value of 'i' will never change using local reasoning

  auto mult = [i](int j) mutable { return i * j; };

    // however this breaks the assumption above

  foo(mult);

    // this now returns 0

  mult(2);

}


I think the intent of the capture by-copy is to enable local reasoning,
hence the standard should explicitly specify the visibility of the data
members to emphasize locality.

Proposed changes:
> (5.1.2.15) For each entity captured by copy, an unnamed non-static
*private* data member is declared in the closure type.

Any thoughts?

--

---
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_315_17497210.1401196071679
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>A very short proposal to add a single word in the sta=
ndard.</div><div><br></div>One feature that I think is really cool about la=
mbda functions is that they allow us to reason locally about the entities c=
aptured by copy.&nbsp;<div><br></div><div>Entities captured by copy are ini=
tialized at construction and are visible only from within the lambda. They =
are by default const protected (because the function call operator is const=
) unless the lambda is declared <i>mutable</i>. This makes it really easy f=
or programmers and compilers to reason about the usage of these variables.<=
/div><div><br></div><div>However the standard does not seems to clearly def=
ine permissions of the the data members for by-copy capture:</div><div>&gt;=
 (5.1.2.15) For each entity captured by copy, an unnamed non-static data me=
mber is declared in the closure type.</div><div><br></div><div>Because of t=
he lack of visibility qualifier, local reasoning is potentially threatened =
by reflection. If using reflection allows arbitrary code to access and modi=
fy the value of a public by-copy captured variable, then the strong isolati=
on property is lost. Consider this example using the notation proposed in N=
3951:<br></div><div><br></div><div><pre><pre><pre><pre><!--StartFragment-->=
<span style=3D" color:#808000;">template</span><span style=3D" color:#00000=
0;">&lt;</span><span style=3D" color:#808000;">typename</span><span style=
=3D" color:#c0c0c0;"> </span><span style=3D" color:#800080;">T</span><span =
style=3D" color:#000000;">&gt;</span></pre><pre><span style=3D" color:#8080=
00;">void</span><span style=3D" color:#c0c0c0;"> </span><span style=3D" col=
or:#000000;">foo</span><span style=3D" color:#000000;">(</span><span style=
=3D" color:#800080;">T</span><span style=3D" color:#c0c0c0;"> </span><span =
style=3D" color:#000000;">&amp;</span><span style=3D" color:#000000;">t</sp=
an><span style=3D" color:#000000;">){</span></pre><pre><span style=3D" colo=
r:#c0c0c0;">  </span><span style=3D" color:#008000;">//</span><span style=
=3D" color:#c0c0c0;"> </span><span style=3D" color:#008000;">reflection</sp=
an><span style=3D" color:#c0c0c0;"> </span><span style=3D" color:#008000;">=
allows</span><span style=3D" color:#c0c0c0;"> </span><span style=3D" color:=
#008000;">us</span><span style=3D" color:#c0c0c0;"> </span><span style=3D" =
color:#008000;">to</span><span style=3D" color:#c0c0c0;"> </span><span styl=
e=3D" color:#008000;">alter</span><span style=3D" color:#c0c0c0;"> </span><=
span style=3D" color:#008000;">data</span><span style=3D" color:#c0c0c0;"> =
</span><span style=3D" color:#008000;">captured</span><span style=3D" color=
:#c0c0c0;"> </span><span style=3D" color:#008000;">by</span><span style=3D"=
 color:#c0c0c0;"> </span><span style=3D" color:#008000;">copy</span></pre><=
pre><span style=3D" color:#c0c0c0;">  </span><span style=3D" color:#808000;=
">auto</span><span style=3D" color:#c0c0c0;"> </span>reflect<span style=3D"=
 color:#c0c0c0;"> </span><span style=3D" color:#000000;">=3D</span><span st=
yle=3D" color:#c0c0c0;"> </span>std<span style=3D" color:#000000;">::</span=
>make_tuple<span style=3D" color:#000000;">(</span><span style=3D" color:#8=
08000;">typedef</span><span style=3D" color:#000000;">&lt;</span><span styl=
e=3D" color:#800080;">T</span><span style=3D" color:#000000;">&gt;...);</sp=
an></pre><pre><span style=3D" color:#c0c0c0;">  </span><span style=3D" colo=
r:#008000;">//</span><span style=3D" color:#c0c0c0;"> </span><span style=3D=
" color:#008000;">this</span><span style=3D" color:#c0c0c0;"> </span><span =
style=3D" color:#008000;">changes</span><span style=3D" color:#c0c0c0;"> </=
span><span style=3D" color:#008000;">the</span><span style=3D" color:#c0c0c=
0;"> </span><span style=3D" color:#008000;">value</span><span style=3D" col=
or:#c0c0c0;"> </span><span style=3D" color:#008000;">of</span><span style=
=3D" color:#c0c0c0;"> </span><span style=3D" color:#008000;">the</span><spa=
n style=3D" color:#c0c0c0;"> </span><span style=3D" color:#008000;">capture=
d</span><span style=3D" color:#c0c0c0;"> </span><span style=3D" color:#0080=
00;">value</span><span style=3D" color:#c0c0c0;"> </span><span style=3D" co=
lor:#008000;">from</span><span style=3D" color:#c0c0c0;"> </span><span styl=
e=3D" color:#008000;">outside</span><span style=3D" color:#c0c0c0;"> </span=
><span style=3D" color:#008000;">the</span><span style=3D" color:#c0c0c0;">=
 </span><span style=3D" color:#008000;">lambda</span></pre><pre><span style=
=3D" color:#c0c0c0;">  </span><span style=3D" color:#000000;">*</span>std<s=
pan style=3D" color:#000000;">::</span>get<span style=3D" color:#000000;">&=
lt;</span><span style=3D" color:#000080;">1</span><span style=3D" color:#00=
0000;">&gt;(</span>reflect<span style=3D" color:#000000;">)</span><span sty=
le=3D" color:#c0c0c0;"> </span><span style=3D" color:#000000;">=3D</span><s=
pan style=3D" color:#c0c0c0;"> </span><span style=3D" color:#000080;">0</sp=
an><span style=3D" color:#000000;">;</span></pre><pre><span style=3D" color=
:#000000;">}</span></pre><pre><br></pre><pre><span style=3D" color:#808000;=
">int</span><span style=3D" color:#c0c0c0;"> </span><span style=3D" color:#=
000000;">main</span><span style=3D" color:#000000;">(){</span></pre><pre><s=
pan style=3D" color:#c0c0c0;">  </span><span style=3D" color:#808000;">int<=
/span><span style=3D" color:#c0c0c0;"> </span><span style=3D" color:#000000=
;">i</span><span style=3D" color:#c0c0c0;"> </span><span style=3D" color:#0=
00000;">=3D</span><span style=3D" color:#c0c0c0;"> </span><span style=3D" c=
olor:#000080;">2</span><span style=3D" color:#000000;">;</span></pre><pre><=
span style=3D" color:#c0c0c0;">  </span><span style=3D" color:#008000;">//<=
/span><span style=3D" color:#c0c0c0;"> </span><span style=3D" color:#008000=
;">This</span><span style=3D" color:#c0c0c0;"> </span><span style=3D" color=
:#008000;">declaration</span><span style=3D" color:#c0c0c0;"> </span><span =
style=3D" color:#008000;">should</span><span style=3D" color:#c0c0c0;"> </s=
pan><span style=3D" color:#008000;">allow</span><span style=3D" color:#c0c0=
c0;"> </span><span style=3D" color:#008000;">us</span><span style=3D" color=
:#c0c0c0;"> </span><span style=3D" color:#008000;">to</span><span style=3D"=
 color:#c0c0c0;"> </span><span style=3D" color:#008000;">assume</span><span=
 style=3D" color:#c0c0c0;"> </span><span style=3D" color:#008000;">the</spa=
n><span style=3D" color:#c0c0c0;"> </span><span style=3D" color:#008000;">v=
alue</span><span style=3D" color:#c0c0c0;"> </span><span style=3D" color:#0=
08000;">of</span><span style=3D" color:#c0c0c0;"> </span><span style=3D" co=
lor:#008000;">'i'</span><span style=3D" color:#c0c0c0;"> </span><span style=
=3D" color:#008000;">will</span><span style=3D" color:#c0c0c0;"> </span><sp=
an style=3D" color:#008000;">never</span><span style=3D" color:#c0c0c0;"> <=
/span><span style=3D" color:#008000;">change using local reasoning</span></=
pre><pre><span style=3D" color:#c0c0c0;">  </span><span style=3D" color:#80=
8000;">auto</span><span style=3D" color:#c0c0c0;"> </span><span style=3D" c=
olor:#000000;">mult</span><span style=3D" color:#c0c0c0;"> </span><span sty=
le=3D" color:#000000;">=3D</span><span style=3D" color:#c0c0c0;"> </span><s=
pan style=3D" color:#000000;">[</span><span style=3D" color:#000000;">i</sp=
an><span style=3D" color:#000000;">](</span><span style=3D" color:#808000;"=
>int</span><span style=3D" color:#c0c0c0;"> </span>j<span style=3D" color:#=
000000;">)</span><span style=3D" color:#c0c0c0;"> </span><span style=3D" co=
lor:#808000;">mutable</span><span style=3D" color:#c0c0c0;"> </span><span s=
tyle=3D" color:#000000;">{</span><span style=3D" color:#c0c0c0;"> </span><s=
pan style=3D" color:#808000;">return</span><span style=3D" color:#c0c0c0;">=
 </span><span style=3D" color:#000000;">i</span><span style=3D" color:#c0c0=
c0;"> </span><span style=3D" color:#000000;">*</span><span style=3D" color:=
#c0c0c0;"> </span>j<span style=3D" color:#000000;">;</span><span style=3D" =
color:#c0c0c0;"> </span><span style=3D" color:#000000;">};</span></pre><pre=
><span style=3D" color:#c0c0c0;">  </span></pre><pre><span style=3D" color:=
#c0c0c0;">  </span><span style=3D" color:#008000;">//</span><span style=3D"=
 color:#c0c0c0;"> </span><span style=3D" color:#008000;">however</span><spa=
n style=3D" color:#c0c0c0;"> </span><span style=3D" color:#008000;">this</s=
pan><span style=3D" color:#c0c0c0;"> </span><span style=3D" color:#008000;"=
>breaks</span><span style=3D" color:#c0c0c0;"> </span><span style=3D" color=
:#008000;">the</span><span style=3D" color:#c0c0c0;"> </span><span style=3D=
" color:#008000;">assumption</span><span style=3D" color:#c0c0c0;"> </span>=
<span style=3D" color:#008000;">above</span></pre><pre><span style=3D" colo=
r:#c0c0c0;">  </span><span style=3D" color:#000000;">foo</span><span style=
=3D" color:#000000;">(</span><span style=3D" color:#000000;">mult</span><sp=
an style=3D" color:#000000;">);</span></pre><pre><span style=3D" color:#c0c=
0c0;">  </span></pre><pre><span style=3D" color:#c0c0c0;">  </span><span st=
yle=3D" color:#008000;">//</span><span style=3D" color:#c0c0c0;"> </span><s=
pan style=3D" color:#008000;">this</span><span style=3D" color:#c0c0c0;"> <=
/span><span style=3D" color:#008000;">now</span><span style=3D" color:#c0c0=
c0;"> </span><span style=3D" color:#008000;">returns</span><span style=3D" =
color:#c0c0c0;"> </span><span style=3D" color:#008000;">0</span></pre><pre>=
<span style=3D" color:#c0c0c0;">  </span><span style=3D" color:#000000;">mu=
lt</span><span style=3D" color:#000000;">(</span><span style=3D" color:#000=
080;">2</span><span style=3D" color:#000000;">);</span><span style=3D" colo=
r:#c0c0c0;"> </span></pre><pre><span style=3D" color:#000000;">}</span><!--=
EndFragment--></pre></pre><pre><!--EndFragment--></pre></pre></pre><pre><!-=
-EndFragment--></pre></div><div><br></div><div>I think the intent of the ca=
pture by-copy is to enable local reasoning, hence the standard should expli=
citly specify the visibility of the data members to emphasize locality.</di=
v><div><br></div><div>Proposed changes:</div><div>&gt; (5.1.2.15) For each =
entity captured by copy, an unnamed non-static <b><i style=3D"background-co=
lor: rgb(255, 255, 0);">private</i></b> data member is declared in the clos=
ure type.</div><div><br></div><div>Any thoughts?</div></div>

<p></p>

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

------=_Part_315_17497210.1401196071679--

.

On 27 May 2014 16:07, Thibaut Lutz <thibaut.lutz@googlemail.com> wrote:
> I think the intent of the capture by-copy is to enable local reasoning,
> hence the standard should explicitly specify the visibility of the data
> members to emphasize locality.
>
> Proposed changes:
>> (5.1.2.15) For each entity captured by copy, an unnamed non-static private
>> data member is declared in the closure type.
>
> Any thoughts?


I certainly think we need to carefully consider what sort of things we
allow reflection
facilities to be able to see and modify. Reflection shouldn't be a
means of bypassing
access control, for instance, and we should also be careful about
reflection being
able to treat lambdas as regular classes, since we don't really mean
that by design.
However, we don't need such wording changes yet.

--

---
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_3493_27400847.1401199220756
Content-Type: text/plain; charset=UTF-8


>
> Reflection shouldn't be a means of bypassing access control
>

Agreed, but my point was that access control is underspecified for by-copy
entities in the context of reflection: according to the current spec, they
could be public and are not const even for non-mutable lambdas. We
currently rely only on limited accessibility to guarantee local reasoning.


> However, we don't need such wording changes yet.
>

Fine, I'll wait for reflection to get in the standard to re-post this issue
;)

--

---
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_3493_27400847.1401199220756
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;">Reflection sh=
ouldn't be a
means of bypassing
access control<br></blockquote><div><br></div><div>Agreed, but my point was=
 that access control is underspecified for by-copy entities in the context =
of reflection: according to the current spec, they could be public and are =
not const even for non-mutable lambdas. We currently rely only on limited a=
ccessibility to guarantee local reasoning.</div><div>&nbsp;</div><blockquot=
e class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: =
1px #ccc solid;padding-left: 1ex;">However, we don't need such wording chan=
ges yet.
<br></blockquote><div><br></div><div>Fine, I'll wait for reflection to get =
in the standard to re-post this issue ;)&nbsp;</div></div>

<p></p>

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

------=_Part_3493_27400847.1401199220756--

.

On 27 May 2014 17:00, Thibaut Lutz <thibaut.lutz@googlemail.com> wrote:
>> Reflection shouldn't be a means of bypassing access control
> Agreed, but my point was that access control is underspecified for by-copy
> entities in the context of reflection: according to the current spec, they
> could be public and are not const even for non-mutable lambdas. We currently
> rely only on limited accessibility to guarantee local reasoning.

One could see the members being unnamed as a way to achieve access control.
Then again, that remark wasn't targeted at lambdas in particular, but
as a wider-scope
reminder. Lambdas as such are intended to act so that they do not expose their
captured "members", and reflection probably indeed shouldn't make that
happen either.
For what it's worth, I have stumbled upon this area relatively recently:
https://gcc.gnu.org/ml/gcc-patches/2014-05/msg00656.html

>> However, we don't need such wording changes yet.
> Fine, I'll wait for reflection to get in the standard to re-post this issue
> ;)


I'm sure such a pre-issue would be useful to mention to SG7 as a request for
general guidelines about what reflection should and should not be able to do.

--

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

.

--20cf303bf5e0875f9604fa63abf1
Content-Type: text/plain; charset=UTF-8

On Tue, May 27, 2014 at 3:46 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:

> I certainly think we need to carefully consider what sort of things we
> allow reflection
> facilities to be able to see and modify. Reflection shouldn't be a
> means of bypassing
> access control, for instance, and we should also be careful about
> reflection being
> able to treat lambdas as regular classes, since we don't really mean
> that by design.
> However, we don't need such wording changes yet.
>

So you're saying that you think reflection should only be able to see
public members?  If so, the memberwise use cases go out the window for
classes with private data members.

In N4027 we propose that you can reflect all members of any access control,
but the access level (public, protected, private) of each member is exposed
too - so if the client library wants to filter public-only, it can - or -
if you want to write a generic memberwise operation (like equality or
comparison for example) that uses private members as well, you can do that
too.  This seems like the better of the two alternatives to me.

When you think about it, the copy constructor and assignment operator
implicitly generated by the compiler bypasses access control as they reads
and writes private members.  I would argue that the reflection facility
should have the same privileges.  Ultimately, reflection competes with
compiler extensions that have full access to the AST.  It shouldn't be
viewed as breaking encapsulation - but in any case - it is certainly
something that would never happen accidentally.

--

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

--20cf303bf5e0875f9604fa63abf1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>On Tue, May 27, 2014 at 3:46 PM, Ville Voutilainen=C2=
=A0<span dir=3D"ltr">&lt;<a href=3D"mailto:ville.voutilainen@gmail.com" tar=
get=3D"_blank">ville.voutilainen@gmail.com</a>&gt;</span>=C2=A0wrote:<br><b=
lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le=
ft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pad=
ding-left:1ex">
<div class=3D"">I certainly think we need to carefully consider what sort o=
f things we<br></div>allow reflection<br>facilities to be able to see and m=
odify. Reflection shouldn&#39;t be a<br>means of bypassing<br>access contro=
l, for instance, and we should also be careful about<br>
reflection being<br>able to treat lambdas as regular classes, since we don&=
#39;t really mean<br>that by design.<br>However, we don&#39;t need such wor=
ding changes yet.<br><div class=3D""></div></blockquote></div><div><br></di=
v>
So you&#39;re saying that you think reflection should only be able to see p=
ublic members? =C2=A0If so, the memberwise use cases go out the window for =
classes with private data members.<div><br></div><div>In N4027 we propose t=
hat you can reflect all members of any access control, but the access level=
 (public, protected, private) of each member is exposed too - so if the cli=
ent library wants to filter public-only, it can - or - if you want to write=
 a generic memberwise operation (like equality or comparison for example) t=
hat uses private members as well, you can do that too. =C2=A0This seems lik=
e the better of the two alternatives to me.</div>
<div><br></div><div>When you think about it, the copy constructor and assig=
nment operator implicitly generated by the compiler bypasses access control=
 as they reads and writes private members. =C2=A0I would argue that the ref=
lection facility should have the same privileges. =C2=A0Ultimately, reflect=
ion competes with compiler extensions that have full access to the AST. =C2=
=A0It shouldn&#39;t be viewed as breaking encapsulation - but in any case -=
 it is certainly something that would never happen accidentally.<div class=
=3D"gmail_extra">
<br></div><div class=3D"gmail_extra">=C2=A0</div></div></div>

<p></p>

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

--20cf303bf5e0875f9604fa63abf1--

.

On 27 May 2014 18:51, Andrew Tomazos <andrewtomazos@gmail.com> wrote:
> On Tue, May 27, 2014 at 3:46 PM, Ville Voutilainen
> <ville.voutilainen@gmail.com> wrote:
>> I certainly think we need to carefully consider what sort of things we
>> allow reflection
>> facilities to be able to see and modify. Reflection shouldn't be a
>> means of bypassing
>> access control, for instance, and we should also be careful about
>> reflection being
>> able to treat lambdas as regular classes, since we don't really mean
>> that by design.
>> However, we don't need such wording changes yet.
> So you're saying that you think reflection should only be able to see public
> members?  If so, the memberwise use cases go out the window for classes with
> private data members.

I don't think I said that reflection should only be able to see public
members. But
I do maintain that reflection shouldn't by-magic allow bypassing access control
in contexts that normally can't access private members.

> In N4027 we propose that you can reflect all members of any access control,
> but the access level (public, protected, private) of each member is exposed
> too - so if the client library wants to filter public-only, it can - or - if
> you want to write a generic memberwise operation (like equality or
> comparison for example) that uses private members as well, you can do that
> too.  This seems like the better of the two alternatives to me.
>
> When you think about it, the copy constructor and assignment operator
> implicitly generated by the compiler bypasses access control as they reads
> and writes private members.  I would argue that the reflection facility
> should have the same privileges.  Ultimately, reflection competes with
> compiler extensions that have full access to the AST.  It shouldn't be
> viewed as breaking encapsulation - but in any case - it is certainly
> something that would never happen accidentally.


If you want to allow a reflection mechanism to access any member regardless
of whether it's used in a context that has proper access, I predict you're
inviting people to propose a facility that allows defining which members do
not participate in reflection. Then again, I expect such a facility to surface
regardless of access. :)

--

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

.

--20cf303bf5e0cd722204fa768fb4
Content-Type: text/plain; charset=UTF-8

On Tue, May 27, 2014 at 8:04 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:

> If you want to allow a reflection mechanism to access any member regardless
> of whether it's used in a context that has proper access, I predict you're
> inviting people to propose a facility that allows defining which members do
> not participate in reflection. Then again, I expect such a facility to
> surface
> regardless of access. :)
>

Given this class C:

class C
{
public:
    int f() { return x; }
private:
    int x;
};

and given an object c of type C:

C c = ...;

Using the raw N4027 primitives, you could write:

// get pointer to second member of C
int C::* p = std::class_member_pointer_v<C, 1>;

int y = c.*p; // read x

c.*p = 42; // write x

But you can check access control as follows:

static_assert(std::class_member_access_level_v<C,1> ==
    std::public_access, "must have public access");

(Of course the primitives are not designed to be used this way on
individual classes, they are designed to be used within templates on
generic type template parameters T of class type.)

What do you mean a facility that "allows defining which members do not
participate in reflection"?  You can always filter the member list in your
reflection library in whatever way you want.  You can give it a list the
names of members you want reflected, or you can give it a list of names to
be excluded, or you can give members some naming convention and filter
based on a regular expression on their name, etc.

It isn't clear to me what you are imagining- are you talking about a core
language addition to somehow mark in the class specifier something isn't
visible to reflection.  Like a "noreflect" specifier or something?

--

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

--20cf303bf5e0cd722204fa768fb4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tue, May 27, 2014 at 8:04 PM, Ville Voutilainen <span d=
ir=3D"ltr">&lt;<a href=3D"mailto:ville.voutilainen@gmail.com" target=3D"_bl=
ank">ville.voutilainen@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gma=
il_extra">

<div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex=
">If you want to allow a reflection mechanism to access any member regardle=
ss<br>

of whether it&#39;s used in a context that has proper access, I predict you=
&#39;re<br>
inviting people to propose a facility that allows defining which members do=
<br>
not participate in reflection. Then again, I expect such a facility to surf=
ace<br>
regardless of access. :)<br></blockquote><br>Given this class C:<br><div><b=
r></div><div>class C<br>{<br></div><div>public:<br></div><div>=C2=A0 =C2=A0=
 int f() { return x; }<br></div><div>private:<br></div><div>
=C2=A0 =C2=A0 int x;<br>};<br><br></div><div>and given an object c of type =
C:<br><br>C c =3D ...;<br></div><div><br></div><div>Using the raw N4027 pri=
mitives, you could write:<br><br></div><div>// get pointer to second member=
 of C<br>
</div><div>int C::* p =3D std::class_member_pointer_v&lt;C, 1&gt;;<br></div=
><div><br>int y =3D c.*p; // read x<br><br></div><div>c.*p =3D 42; // write=
 x<br>
<br></div><div>But you can check access control as follows:<br><br></div>st=
atic_assert(std::class_member_access_level_v&lt;C,1&gt; =3D=3D<br><div>=C2=
=A0=C2=A0=C2=A0 std::public_access, &quot;must have public access&quot;);<b=
r><br></div><div>
(Of course the primitives are not designed to be used this way on individua=
l classes, they are designed to be used within templates on generic type te=
mplate parameters T of class type.)<br></div><div><br></div><div>What do yo=
u mean a facility that &quot;allows defining which members do not participa=
te in reflection&quot;?=C2=A0 You can always filter the member list in your=
 reflection library in whatever way you want.=C2=A0 You can give it a list =
the names of members you want reflected, or you can give it a list of names=
 to be excluded, or you can give members some naming convention and filter =
based on a regular expression on their name, etc.<br>
<br>It isn&#39;t clear to me what you are imagining- are you talking about =
a core language addition to somehow mark in the class specifier something i=
sn&#39;t visible to reflection.=C2=A0 Like a &quot;noreflect&quot; specifie=
r or something?<br>
<br></div></div></div></div>

<p></p>

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

--20cf303bf5e0cd722204fa768fb4--

.

On 28 May 2014 17:23, Andrew Tomazos <andrewtomazos@gmail.com> wrote:
> What do you mean a facility that "allows defining which members do not
> participate in reflection"?  You can always filter the member list in your

I mean that as a class designer, I think I want to be able to say which parts
of my system can access my members. Including reflection facilities.

> It isn't clear to me what you are imagining- are you talking about a core
> language addition to somehow mark in the class specifier something isn't
> visible to reflection.  Like a "noreflect" specifier or something?


No - I'm imagining that reflection shouldn't be any more able to access private
members than any non-member non-friends are. I do not think that rules out
use cases where you generate eg. comparison operators, since I can still
write such comparison operators - I just need to grant them access, with
traditional access control facilities.

And no, I don't think reflection is equivalent to copy constructors -
copy constructors
are members. If you use reflection facilities inside a class, sure,
access private
members all you like. Or mix in a base class that reflects your
members via CRTP, and make
that base a friend.

--

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

.

--047d7bd6be02dcaa4e04fa7706aa
Content-Type: text/plain; charset=UTF-8

On Wed, May 28, 2014 at 4:36 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:

> On 28 May 2014 17:23, Andrew Tomazos <andrewtomazos@gmail.com> wrote:
> > What do you mean a facility that "allows defining which members do not
> > participate in reflection"?  You can always filter the member list in
> your
>
> I mean that as a class designer, I think I want to be able to say which
> parts
> of my system can access my members. Including reflection facilities.
>
> > It isn't clear to me what you are imagining- are you talking about a core
> > language addition to somehow mark in the class specifier something isn't
> > visible to reflection.  Like a "noreflect" specifier or something?
>
>
No - I'm imagining that reflection shouldn't be any more able to access
> private
> members than any non-member non-friends are. I do not think that rules out
> use cases where you generate eg. comparison operators, since I can still
> write such comparison operators - I just need to grant them access, with
> traditional access control facilities.
>
> And no, I don't think reflection is equivalent to copy constructors -
> copy constructors
> are members. If you use reflection facilities inside a class, sure,
> access private
> members all you like. Or mix in a base class that reflects your
> members via CRTP, and make
> that base a friend.


Compiler extensions are non-member non-friends, and they can access your
private members just fine.

But philosophical discussion aside - I've looked at it pretty closely, and
I don't think its practical.  To my class C example above - what concrete
change to the proposal are you suggesting?

--

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

--047d7bd6be02dcaa4e04fa7706aa
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, May 28, 2014 at 4:36 PM, Ville Voutilainen <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilaine=
n@gmail.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"">On 28 May 2014 17:23, Andrew=
 Tomazos &lt;<a href=3D"mailto:andrewtomazos@gmail.com">andrewtomazos@gmail=
..com</a>&gt; wrote:<br>

&gt; What do you mean a facility that &quot;allows defining which members d=
o not<br>
&gt; participate in reflection&quot;? =C2=A0You can always filter the membe=
r list in your<br>
<br>
</div>I mean that as a class designer, I think I want to be able to say whi=
ch parts<br>
of my system can access my members. Including reflection facilities.<br>
<div class=3D""><br>
&gt; It isn&#39;t clear to me what you are imagining- are you talking about=
 a core<br>
&gt; language addition to somehow mark in the class specifier something isn=
&#39;t<br>
&gt; visible to reflection. =C2=A0Like a &quot;noreflect&quot; specifier or=
 something?<br>=C2=A0=C2=A0</div></blockquote><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
"><div class=3D"">
No - I&#39;m imagining that reflection shouldn&#39;t be any more able to ac=
cess private<br></div>
members than any non-member non-friends are. I do not think that rules out<=
br>
use cases where you generate eg. comparison operators, since I can still<br=
>
write such comparison operators - I just need to grant them access, with<br=
>
traditional access control facilities.<br>
<br>
And no, I don&#39;t think reflection is equivalent to copy constructors -<b=
r>
copy constructors<br>
are members. If you use reflection facilities inside a class, sure,<br>
access private<br>
members all you like. Or mix in a base class that reflects your<br>
members via CRTP, and make<br>
that base a friend.</blockquote><div><br></div><div>Compiler extensions are=
 non-member non-friends, and they can access your private members just fine=
..</div><div><br></div><div>But philosophical discussion aside - I&#39;ve lo=
oked at it pretty closely, and I don&#39;t think its practical. =C2=A0To my=
 class C example above - what concrete change to the proposal are you sugge=
sting?</div>
<div><br></div></div></div></div>

<p></p>

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

--047d7bd6be02dcaa4e04fa7706aa--

.

On 28 May 2014 17:57, Andrew Tomazos <andrewtomazos@gmail.com> wrote:
>> And no, I don't think reflection is equivalent to copy constructors -
>> copy constructors
>> are members. If you use reflection facilities inside a class, sure,
>> access private
>> members all you like. Or mix in a base class that reflects your
>> members via CRTP, and make
>> that base a friend.
> Compiler extensions are non-member non-friends, and they can access your
> private members just fine.

I don't think these reflection facilities should be considered
equivalent to compiler
extensions, either.

> But philosophical discussion aside - I've looked at it pretty closely, and I
> don't think its practical.  To my class C example above - what concrete
> change to the proposal are you suggesting?

I am suggesting that these facilities need to obey access controls. What that
means concretely is that you can read/write private members via these facilities
only if you have the proper access. In other words, the get_member_pointer
needs to be changed.

Regarding class C, I heard SG7 guidance to the direction that we should have
a class reflect that is used for reflection facilities. In your class,
you could of course
have
friend class std::reflect<C>;
or even
template <class T> friend class std::reflect<T>;

--

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

.

On 28 May 2014 18:10, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
> Regarding class C, I heard SG7 guidance to the direction that we should have
> a class reflect that is used for reflection facilities. In your class,
> you could of course
> have
> friend class std::reflect<C>;
> or even
> template <class T> friend class std::reflect<T>;

The latter should be template <class T> friend class std::reflect;

--

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

.

--bcaec5299be365691604fa77b26f
Content-Type: text/plain; charset=UTF-8

There wasn't any rationale given in the suggestion to change from our
ListTrait concept in N3815 and N4027 to the one universal reflect class
template, and it is largely an aesthetic isomorphism as I far as I am
aware, and is inconsistent with the rest of the type traits library, and
there are some other problems with it in terms of potentially instantiating
everything all at once, and when you have member templates of templates,
things start to become a bit of a mess, and enumerations and class types
don't have anything in common, so I've ignored the std::reflect<T>
suggestion for now.  Happy to discuss further with SG7 at Issequah.

With regard to to requiring classes to globally "friend" the standard
reflection primitives somehow, well, that is one idea I guess.  Another
would be to think of the reflection primitives like compiler extensions and
take this friending as read.




On Wed, May 28, 2014 at 5:10 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:

> On 28 May 2014 17:57, Andrew Tomazos <andrewtomazos@gmail.com> wrote:
> >> And no, I don't think reflection is equivalent to copy constructors -
> >> copy constructors
> >> are members. If you use reflection facilities inside a class, sure,
> >> access private
> >> members all you like. Or mix in a base class that reflects your
> >> members via CRTP, and make
> >> that base a friend.
> > Compiler extensions are non-member non-friends, and they can access your
> > private members just fine.
>
> I don't think these reflection facilities should be considered
> equivalent to compiler
> extensions, either.
>
> > But philosophical discussion aside - I've looked at it pretty closely,
> and I
> > don't think its practical.  To my class C example above - what concrete
> > change to the proposal are you suggesting?
>
> I am suggesting that these facilities need to obey access controls. What
> that
> means concretely is that you can read/write private members via these
> facilities
> only if you have the proper access. In other words, the get_member_pointer
> needs to be changed.
>
> Regarding class C, I heard SG7 guidance to the direction that we should
> have
> a class reflect that is used for reflection facilities. In your class,
> you could of course
> have
> friend class std::reflect<C>;
> or even
> template <class T> friend class std::reflect<T>;
>
> --
>
> ---
> 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/.
>

--

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

--bcaec5299be365691604fa77b26f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">There wasn&#39;t any rationale given in the suggestion to =
change from our ListTrait concept in N3815 and N4027 to the one universal r=
eflect class template, and it is largely an aesthetic isomorphism as I far =
as I am aware, and is inconsistent with the rest of the type traits library=
, and there are some other problems with it in terms of potentially instant=
iating everything all at once, and when you have member templates of templa=
tes, things start to become a bit of a mess, and enumerations and class typ=
es don&#39;t have anything in common, so I&#39;ve ignored the std::reflect&=
lt;T&gt; suggestion for now. =C2=A0Happy to discuss further with SG7 at Iss=
equah.<div>
<br></div><div>With regard to to requiring classes to globally &quot;friend=
&quot; the standard reflection primitives somehow, well, that is one idea I=
 guess. =C2=A0Another would be to think of the reflection primitives like c=
ompiler extensions and take this friending as read.</div>
<div><br></div><div><br></div></div><div class=3D"gmail_extra"><br><br><div=
 class=3D"gmail_quote">On Wed, May 28, 2014 at 5:10 PM, Ville Voutilainen <=
span dir=3D"ltr">&lt;<a href=3D"mailto:ville.voutilainen@gmail.com" target=
=3D"_blank">ville.voutilainen@gmail.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"">On 28 May 2014 17:57, Andrew=
 Tomazos &lt;<a href=3D"mailto:andrewtomazos@gmail.com">andrewtomazos@gmail=
..com</a>&gt; wrote:<br>

&gt;&gt; And no, I don&#39;t think reflection is equivalent to copy constru=
ctors -<br>
&gt;&gt; copy constructors<br>
&gt;&gt; are members. If you use reflection facilities inside a class, sure=
,<br>
&gt;&gt; access private<br>
&gt;&gt; members all you like. Or mix in a base class that reflects your<br=
>
&gt;&gt; members via CRTP, and make<br>
&gt;&gt; that base a friend.<br>
&gt; Compiler extensions are non-member non-friends, and they can access yo=
ur<br>
&gt; private members just fine.<br>
<br>
</div>I don&#39;t think these reflection facilities should be considered<br=
>
equivalent to compiler<br>
extensions, either.<br>
<div class=3D""><br>
&gt; But philosophical discussion aside - I&#39;ve looked at it pretty clos=
ely, and I<br>
&gt; don&#39;t think its practical. =C2=A0To my class C example above - wha=
t concrete<br>
&gt; change to the proposal are you suggesting?<br>
<br>
</div>I am suggesting that these facilities need to obey access controls. W=
hat that<br>
means concretely is that you can read/write private members via these facil=
ities<br>
only if you have the proper access. In other words, the get_member_pointer<=
br>
needs to be changed.<br>
<br>
Regarding class C, I heard SG7 guidance to the direction that we should hav=
e<br>
a class reflect that is used for reflection facilities. In your class,<br>
you could of course<br>
have<br>
friend class std::reflect&lt;C&gt;;<br>
or even<br>
template &lt;class T&gt; friend class std::reflect&lt;T&gt;;<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
--<br>
<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 <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-propo=
sals+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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

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

--bcaec5299be365691604fa77b26f--

.

--089e01182e4861ae9d04fa77bb97
Content-Type: text/plain; charset=UTF-8

On Wed, May 28, 2014 at 5:45 PM, Andrew Tomazos <andrewtomazos@gmail.com>wrote:

> Happy to discuss further with SG7 at Issequah.
>
> *Rapperswil of course, lol.

--

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

--089e01182e4861ae9d04fa77bb97
Content-Type: text/html; charset=UTF-8

<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, May 28, 2014 at 5:45 PM, Andrew Tomazos <span dir="ltr">&lt;<a href="mailto:andrewtomazos@gmail.com" target="_blank">andrewtomazos@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Happy to discuss further with SG7 at Issequah.<div>
<br></div></div></blockquote><div>*Rapperswil of course, lol.</div><div><br></div></div></div></div>

<p></p>

-- <br />
<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 email to <a href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />

--089e01182e4861ae9d04fa77bb97--

.

On Wed, May 28, 2014 at 8:10 AM, Ville Voutilainen
<ville.voutilainen@gmail.com> wrote:
> On 28 May 2014 17:57, Andrew Tomazos <andrewtomazos@gmail.com> wrote:
>>> And no, I don't think reflection is equivalent to copy constructors -
>>> copy constructors
>>> are members. If you use reflection facilities inside a class, sure,
>>> access private
>>> members all you like. Or mix in a base class that reflects your
>>> members via CRTP, and make
>>> that base a friend.
>> Compiler extensions are non-member non-friends, and they can access your
>> private members just fine.
>
> I don't think these reflection facilities should be considered
> equivalent to compiler
> extensions, either.
>
>> But philosophical discussion aside - I've looked at it pretty closely, and I
>> don't think its practical.  To my class C example above - what concrete
>> change to the proposal are you suggesting?
>
> I am suggesting that these facilities need to obey access controls. What that
> means concretely is that you can read/write private members via these facilities
> only if you have the proper access. In other words, the get_member_pointer
> needs to be changed.
>
> Regarding class C, I heard SG7 guidance to the direction that we should have
> a class reflect that is used for reflection facilities. In your class,
> you could of course
> have
> friend class std::reflect<C>;
> or even
> template <class T> friend class std::reflect;

This is interesting because it turns on global access to private
members through reflection, in order to support a use inside the
class. It'd be nicer if the language supported some way of granting
friend access through a template argument, so that the friend-ness of
the call site could be taken into account. This is somewhat possible
for non-reflection uses in the library:

class Private {
  int mem1;
  struct Access {
    static int& GetMem1(Private&);
  };
public:
  void foo() {
    SomeTemplate<Access>(this);
  }
};

but clearly that doesn't work for reflection.

--

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

.

--bcaec5299be352a8b504fa7870a1
Content-Type: text/plain; charset=UTF-8

For some comparison, this is how it works in Java:

public class PrivateObject {

  private String privateString = null;

  public PrivateObject(String privateString) {
    this.privateString = privateString;
  }

  private String getPrivateString(){
    return this.privateString;
  }
}

PrivateObject privateObject = new PrivateObject("The Private Value");

Method privateStringMethod = PrivateObject.class.
        getDeclaredMethod("getPrivateString", null);
*privateStringMethod.setAccessible(true);*

String returnValue = (String)
        privateStringMethod.invoke(privateObject, null);

System.out.println("returnValue = " + returnValue);

Basically the reflection library decides whether to access private members
(by using setAccessible), and doesn't need some special line added to the
class specifier.  Using the N4027 primitives you can build a user-facing
reflection library like this by utilizing the class_member_access_level to
filter on access level.




On Wed, May 28, 2014 at 6:07 PM, 'Jeffrey Yasskin' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:

> On Wed, May 28, 2014 at 8:10 AM, Ville Voutilainen
> <ville.voutilainen@gmail.com> wrote:
> > On 28 May 2014 17:57, Andrew Tomazos <andrewtomazos@gmail.com> wrote:
> >>> And no, I don't think reflection is equivalent to copy constructors -
> >>> copy constructors
> >>> are members. If you use reflection facilities inside a class, sure,
> >>> access private
> >>> members all you like. Or mix in a base class that reflects your
> >>> members via CRTP, and make
> >>> that base a friend.
> >> Compiler extensions are non-member non-friends, and they can access your
> >> private members just fine.
> >
> > I don't think these reflection facilities should be considered
> > equivalent to compiler
> > extensions, either.
> >
> >> But philosophical discussion aside - I've looked at it pretty closely,
> and I
> >> don't think its practical.  To my class C example above - what concrete
> >> change to the proposal are you suggesting?
> >
> > I am suggesting that these facilities need to obey access controls. What
> that
> > means concretely is that you can read/write private members via these
> facilities
> > only if you have the proper access. In other words, the
> get_member_pointer
> > needs to be changed.
> >
> > Regarding class C, I heard SG7 guidance to the direction that we should
> have
> > a class reflect that is used for reflection facilities. In your class,
> > you could of course
> > have
> > friend class std::reflect<C>;
> > or even
> > template <class T> friend class std::reflect;
>
> This is interesting because it turns on global access to private
> members through reflection, in order to support a use inside the
> class. It'd be nicer if the language supported some way of granting
> friend access through a template argument, so that the friend-ness of
> the call site could be taken into account. This is somewhat possible
> for non-reflection uses in the library:
>
> class Private {
>   int mem1;
>   struct Access {
>     static int& GetMem1(Private&);
>   };
> public:
>   void foo() {
>     SomeTemplate<Access>(this);
>   }
> };
>
> but clearly that doesn't work for reflection.
>
> --
>
> ---
> 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/.
>

--

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

--bcaec5299be352a8b504fa7870a1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">For some comparison, this is how it works in Java:<div><pr=
e class=3D"" style=3D"font-family:Courier;font-size:0.8em;white-space:pre-w=
rap;word-wrap:break-word;margin-top:20px;margin-bottom:20px;border:1px soli=
d rgb(204,204,204);padding:10px;color:rgb(85,85,85);background-color:rgb(23=
8,238,238)">
public class PrivateObject {

  private String privateString =3D null;

  public PrivateObject(String privateString) {
    this.privateString =3D privateString;
  }

  private String getPrivateString(){
    return this.privateString;
  }
}
</pre><pre class=3D"" style=3D"font-family:Courier;font-size:0.8em;white-sp=
ace:pre-wrap;word-wrap:break-word;margin-top:20px;margin-bottom:20px;border=
:1px solid rgb(204,204,204);padding:10px;color:rgb(85,85,85);background-col=
or:rgb(238,238,238)">
PrivateObject privateObject =3D new PrivateObject(&quot;The Private Value&q=
uot;);

Method privateStringMethod =3D PrivateObject.class.
        getDeclaredMethod(&quot;getPrivateString&quot;, null);

<b>privateStringMethod.setAccessible(true);</b>

String returnValue =3D (String)
        privateStringMethod.invoke(privateObject, null);

System.out.println(&quot;returnValue =3D &quot; + returnValue);
</pre><div>Basically the reflection library decides whether to access priva=
te members (by using setAccessible), and doesn&#39;t need some special line=
 added to the class specifier. =C2=A0Using the N4027 primitives you can bui=
ld a user-facing reflection library like this by utilizing the class_member=
_access_level to filter on access level.</div>
<div><br></div><div><br></div></div></div><div class=3D"gmail_extra"><br><b=
r><div class=3D"gmail_quote">On Wed, May 28, 2014 at 6:07 PM, &#39;Jeffrey =
Yasskin&#39; via ISO C++ Standard - Future Proposals <span dir=3D"ltr">&lt;=
<a href=3D"mailto:std-proposals@isocpp.org" target=3D"_blank">std-proposals=
@isocpp.org</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"HOEnZb"><div class=3D"h5">On W=
ed, May 28, 2014 at 8:10 AM, Ville Voutilainen<br>
&lt;<a href=3D"mailto:ville.voutilainen@gmail.com">ville.voutilainen@gmail.=
com</a>&gt; wrote:<br>
&gt; On 28 May 2014 17:57, Andrew Tomazos &lt;<a href=3D"mailto:andrewtomaz=
os@gmail.com">andrewtomazos@gmail.com</a>&gt; wrote:<br>
&gt;&gt;&gt; And no, I don&#39;t think reflection is equivalent to copy con=
structors -<br>
&gt;&gt;&gt; copy constructors<br>
&gt;&gt;&gt; are members. If you use reflection facilities inside a class, =
sure,<br>
&gt;&gt;&gt; access private<br>
&gt;&gt;&gt; members all you like. Or mix in a base class that reflects you=
r<br>
&gt;&gt;&gt; members via CRTP, and make<br>
&gt;&gt;&gt; that base a friend.<br>
&gt;&gt; Compiler extensions are non-member non-friends, and they can acces=
s your<br>
&gt;&gt; private members just fine.<br>
&gt;<br>
&gt; I don&#39;t think these reflection facilities should be considered<br>
&gt; equivalent to compiler<br>
&gt; extensions, either.<br>
&gt;<br>
&gt;&gt; But philosophical discussion aside - I&#39;ve looked at it pretty =
closely, and I<br>
&gt;&gt; don&#39;t think its practical. =C2=A0To my class C example above -=
 what concrete<br>
&gt;&gt; change to the proposal are you suggesting?<br>
&gt;<br>
&gt; I am suggesting that these facilities need to obey access controls. Wh=
at that<br>
&gt; means concretely is that you can read/write private members via these =
facilities<br>
&gt; only if you have the proper access. In other words, the get_member_poi=
nter<br>
&gt; needs to be changed.<br>
&gt;<br>
&gt; Regarding class C, I heard SG7 guidance to the direction that we shoul=
d have<br>
&gt; a class reflect that is used for reflection facilities. In your class,=
<br>
&gt; you could of course<br>
&gt; have<br>
&gt; friend class std::reflect&lt;C&gt;;<br>
&gt; or even<br>
</div></div>&gt; template &lt;class T&gt; friend class std::reflect;<br>
<br>
This is interesting because it turns on global access to private<br>
members through reflection, in order to support a use inside the<br>
class. It&#39;d be nicer if the language supported some way of granting<br>
friend access through a template argument, so that the friend-ness of<br>
the call site could be taken into account. This is somewhat possible<br>
for non-reflection uses in the library:<br>
<br>
class Private {<br>
=C2=A0 int mem1;<br>
=C2=A0 struct Access {<br>
=C2=A0 =C2=A0 static int&amp; GetMem1(Private&amp;);<br>
=C2=A0 };<br>
public:<br>
=C2=A0 void foo() {<br>
=C2=A0 =C2=A0 SomeTemplate&lt;Access&gt;(this);<br>
=C2=A0 }<br>
};<br>
<br>
but clearly that doesn&#39;t work for reflection.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
--<br>
<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 <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-propo=
sals+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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

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

--bcaec5299be352a8b504fa7870a1--

.

------=_Part_605_13005088.1401306363071
Content-Type: text/plain; charset=UTF-8

And also FYI C# does it essentially the same way:

FieldInfo[] fields = myType.GetFields(
                         BindingFlags.NonPublic |
                         BindingFlags.Instance);

The BindingFlags.NonPublic flag nominates that you want to view (and access) private members, and doesn't require special permission from the class specifier (either globally or about the call-site).





On Wednesday, May 28, 2014 6:38:16 PM UTC+2, Andrew Tomazos wrote:
>
> For some comparison, this is how it works in Java:
>
> public class PrivateObject {
>
>   private String privateString = null;
>
>   public PrivateObject(String privateString) {
>     this.privateString = privateString;
>   }
>
>   private String getPrivateString(){
>     return this.privateString;
>   }
> }
>
> PrivateObject privateObject = new PrivateObject("The Private Value");
>
> Method privateStringMethod = PrivateObject.class.
>         getDeclaredMethod("getPrivateString", null);
> *privateStringMethod.setAccessible(true);*
>
> String returnValue = (String)
>         privateStringMethod.invoke(privateObject, null);
>
> System.out.println("returnValue = " + returnValue);
>
> Basically the reflection library decides whether to access private members
> (by using setAccessible), and doesn't need some special line added to the
> class specifier.  Using the N4027 primitives you can build a user-facing
> reflection library like this by utilizing the class_member_access_level to
> filter on access level.
>
>
>
>
> On Wed, May 28, 2014 at 6:07 PM, 'Jeffrey Yasskin' via ISO C++ Standard -
> Future Proposals <std-proposals@isocpp.org> wrote:
>
>> On Wed, May 28, 2014 at 8:10 AM, Ville Voutilainen
>> <ville.voutilainen@gmail.com> wrote:
>> > On 28 May 2014 17:57, Andrew Tomazos <andrewtomazos@gmail.com> wrote:
>> >>> And no, I don't think reflection is equivalent to copy constructors -
>> >>> copy constructors
>> >>> are members. If you use reflection facilities inside a class, sure,
>> >>> access private
>> >>> members all you like. Or mix in a base class that reflects your
>> >>> members via CRTP, and make
>> >>> that base a friend.
>> >> Compiler extensions are non-member non-friends, and they can access
>> your
>> >> private members just fine.
>> >
>> > I don't think these reflection facilities should be considered
>> > equivalent to compiler
>> > extensions, either.
>> >
>> >> But philosophical discussion aside - I've looked at it pretty closely,
>> and I
>> >> don't think its practical.  To my class C example above - what concrete
>> >> change to the proposal are you suggesting?
>> >
>> > I am suggesting that these facilities need to obey access controls.
>> What that
>> > means concretely is that you can read/write private members via these
>> facilities
>> > only if you have the proper access. In other words, the
>> get_member_pointer
>> > needs to be changed.
>> >
>> > Regarding class C, I heard SG7 guidance to the direction that we should
>> have
>> > a class reflect that is used for reflection facilities. In your class,
>> > you could of course
>> > have
>> > friend class std::reflect<C>;
>> > or even
>> > template <class T> friend class std::reflect;
>>
>> This is interesting because it turns on global access to private
>> members through reflection, in order to support a use inside the
>> class. It'd be nicer if the language supported some way of granting
>> friend access through a template argument, so that the friend-ness of
>> the call site could be taken into account. This is somewhat possible
>> for non-reflection uses in the library:
>>
>> class Private {
>>   int mem1;
>>   struct Access {
>>     static int& GetMem1(Private&);
>>   };
>> public:
>>   void foo() {
>>     SomeTemplate<Access>(this);
>>   }
>> };
>>
>> but clearly that doesn't work for reflection.
>>
>> --
>>
>> ---
>> 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/.
>>
>
>

--

---
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_605_13005088.1401306363071
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">And also FYI C# does it essentially the same way:<br><br><=
pre style=3D"" class=3D"lang-cs prettyprint prettyprinted"><code><span clas=
s=3D"typ">FieldInfo</span><span class=3D"pun">[]</span><span class=3D"pln">=
 fields </span><span class=3D"pun">=3D</span><span class=3D"pln"> myType</s=
pan><span class=3D"pun">.</span><span class=3D"typ">GetFields</span><span c=
lass=3D"pun">(</span><span class=3D"pln">
                         </span><span class=3D"typ">BindingFlags</span><spa=
n class=3D"pun">.</span><span class=3D"typ">NonPublic</span><span class=3D"=
pln"> </span><span class=3D"pun">|</span><span class=3D"pln">=20
                         </span><span class=3D"typ">BindingFlags</span><spa=
n class=3D"pun">.</span><span class=3D"typ">Instance</span><span class=3D"p=
un">);<br><br>The BindingFlags.NonPublic flag nominates that you want to vi=
ew (and access) private members, and doesn't require special permission fro=
m the class specifier (either globally or about the call-site).<br><br><br>=
<br></span></code></pre><br><br>On Wednesday, May 28, 2014 6:38:16 PM UTC+2=
, Andrew Tomazos wrote:<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">For some comparison, this is how it works in Java:<div><pre style=
=3D"font-family:Courier;font-size:0.8em;white-space:pre-wrap;word-wrap:brea=
k-word;margin-top:20px;margin-bottom:20px;border:1px solid rgb(204,204,204)=
;padding:10px;color:rgb(85,85,85);background-color:rgb(238,238,238)">public=
 class PrivateObject {

  private String privateString =3D null;

  public PrivateObject(String privateString) {
    this.privateString =3D privateString;
  }

  private String getPrivateString(){
    return this.privateString;
  }
}
</pre><pre style=3D"font-family:Courier;font-size:0.8em;white-space:pre-wra=
p;word-wrap:break-word;margin-top:20px;margin-bottom:20px;border:1px solid =
rgb(204,204,204);padding:10px;color:rgb(85,85,85);background-color:rgb(238,=
238,238)">PrivateObject privateObject =3D new PrivateObject("The Private Va=
lue");

Method privateStringMethod =3D PrivateObject.class.
        getDeclaredMethod("<wbr>getPrivateString", null);

<b>privateStringMethod.<wbr>setAccessible(true);</b>

String returnValue =3D (String)
        privateStringMethod.invoke(<wbr>privateObject, null);

System.out.println("<wbr>returnValue =3D " + returnValue);
</pre><div>Basically the reflection library decides whether to access priva=
te members (by using setAccessible), and doesn't need some special line add=
ed to the class specifier. &nbsp;Using the N4027 primitives you can build a=
 user-facing reflection library like this by utilizing the class_member_acc=
ess_level to filter on access level.</div>
<div><br></div><div><br></div></div></div><div><br><br><div class=3D"gmail_=
quote">On Wed, May 28, 2014 at 6:07 PM, 'Jeffrey Yasskin' via ISO C++ Stand=
ard - Future Proposals <span dir=3D"ltr">&lt;<a href=3D"mailto:std-proposal=
s@isocpp.org" target=3D"_blank" onmousedown=3D"this.href=3D'mailto:std-prop=
osals@isocpp.org';return true;" onclick=3D"this.href=3D'mailto:std-proposal=
s@isocpp.org';return true;">std-proposals@isocpp.org</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><div>On Wed, May 28, 2014 at 8:10 AM, V=
ille Voutilainen<br>
&lt;<a href=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank" onmous=
edown=3D"this.href=3D'mailto:ville.voutilainen@gmail.com';return true;" onc=
lick=3D"this.href=3D'mailto:ville.voutilainen@gmail.com';return true;">vill=
e.voutilainen@gmail.com</a>&gt; wrote:<br>
&gt; On 28 May 2014 17:57, Andrew Tomazos &lt;<a href=3D"mailto:andrewtomaz=
os@gmail.com" target=3D"_blank" onmousedown=3D"this.href=3D'mailto:andrewto=
mazos@gmail.com';return true;" onclick=3D"this.href=3D'mailto:andrewtomazos=
@gmail.com';return true;">andrewtomazos@gmail.com</a>&gt; wrote:<br>
&gt;&gt;&gt; And no, I don't think reflection is equivalent to copy constru=
ctors -<br>
&gt;&gt;&gt; copy constructors<br>
&gt;&gt;&gt; are members. If you use reflection facilities inside a class, =
sure,<br>
&gt;&gt;&gt; access private<br>
&gt;&gt;&gt; members all you like. Or mix in a base class that reflects you=
r<br>
&gt;&gt;&gt; members via CRTP, and make<br>
&gt;&gt;&gt; that base a friend.<br>
&gt;&gt; Compiler extensions are non-member non-friends, and they can acces=
s your<br>
&gt;&gt; private members just fine.<br>
&gt;<br>
&gt; I don't think these reflection facilities should be considered<br>
&gt; equivalent to compiler<br>
&gt; extensions, either.<br>
&gt;<br>
&gt;&gt; But philosophical discussion aside - I've looked at it pretty clos=
ely, and I<br>
&gt;&gt; don't think its practical. &nbsp;To my class C example above - wha=
t concrete<br>
&gt;&gt; change to the proposal are you suggesting?<br>
&gt;<br>
&gt; I am suggesting that these facilities need to obey access controls. Wh=
at that<br>
&gt; means concretely is that you can read/write private members via these =
facilities<br>
&gt; only if you have the proper access. In other words, the get_member_poi=
nter<br>
&gt; needs to be changed.<br>
&gt;<br>
&gt; Regarding class C, I heard SG7 guidance to the direction that we shoul=
d have<br>
&gt; a class reflect that is used for reflection facilities. In your class,=
<br>
&gt; you could of course<br>
&gt; have<br>
&gt; friend class std::reflect&lt;C&gt;;<br>
&gt; or even<br>
</div></div>&gt; template &lt;class T&gt; friend class std::reflect;<br>
<br>
This is interesting because it turns on global access to private<br>
members through reflection, in order to support a use inside the<br>
class. It'd be nicer if the language supported some way of granting<br>
friend access through a template argument, so that the friend-ness of<br>
the call site could be taken into account. This is somewhat possible<br>
for non-reflection uses in the library:<br>
<br>
class Private {<br>
&nbsp; int mem1;<br>
&nbsp; struct Access {<br>
&nbsp; &nbsp; static int&amp; GetMem1(Private&amp;);<br>
&nbsp; };<br>
public:<br>
&nbsp; void foo() {<br>
&nbsp; &nbsp; SomeTemplate&lt;Access&gt;(this);<br>
&nbsp; }<br>
};<br>
<br>
but clearly that doesn't work for reflection.<br>
<div><div><br>
--<br>
<br>
---<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%2Bunsubscribe@isocpp.org" target=3D=
"_blank" onmousedown=3D"this.href=3D'mailto:std-proposals%2Bunsubscribe@iso=
cpp.org';return true;" onclick=3D"this.href=3D'mailto:std-proposals%2Bunsub=
scribe@isocpp.org';return true;">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" onmousedown=3D"this.href=3D'mailto:std-proposals@is=
ocpp.org';return true;" onclick=3D"this.href=3D'mailto:std-proposals@isocpp=
..org';return true;">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank" onmousedown=3D"this.href=3D'http://groups=
..google.com/a/isocpp.org/group/std-proposals/';return true;" onclick=3D"thi=
s.href=3D'http://groups.google.com/a/isocpp.org/group/std-proposals/';retur=
n true;">http://groups.google.com/a/<wbr>isocpp.org/group/std-<wbr>proposal=
s/</a>.<br>
</div></div></blockquote></div><br></div>
</blockquote></div>

<p></p>

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

------=_Part_605_13005088.1401306363071--

.

------=_Part_9_9594182.1401309519231
Content-Type: text/plain; charset=UTF-8

Also, access modifiers are not there for security reasons - it's trivial to
bypass them if one really wanted to - they're there to prevent accidental
misuse, or in other words, human error, although they also serve as a
useful form of documentation. Since reflection is a tool used by the
program, not the programmer, there's no reason for access control to exist
with respect to reflection. When using reflection it should be possible to
ignore private members if that's what is desired, but allowing the author
of a class to prevent reflection serves no purpose other than to irritate.
In .net or java where different parts of the same program can have
different access rights which are strictly enforced by the runtime, it
might make sense, in C++ it doesn't.

--

---
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_9_9594182.1401309519231
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Also, access modifiers are not there for security reasons =
- it's trivial to bypass them if one really wanted to - they're there to pr=
event accidental misuse, or in other words, human error, although they also=
 serve as a useful form of documentation. Since reflection is a tool used b=
y the program, not the programmer, there's no reason for access control to =
exist with respect to reflection. When using reflection it should be possib=
le to ignore private members if that's what is desired, but allowing the au=
thor of a class to prevent reflection serves no purpose other than to irrit=
ate. In .net or java where different parts of the same program can have dif=
ferent access rights which are strictly enforced by the runtime, it might m=
ake sense, in C++ it doesn't.<br></div>

<p></p>

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

------=_Part_9_9594182.1401309519231--

.

On Wed, May 28, 2014 at 1:38 PM, Diggory Blake <diggsey@googlemail.com> wrote:
> Also, access modifiers are not there for security reasons - it's trivial to
> bypass them if one really wanted to - they're there to prevent accidental
> misuse, or in other words, human error, although they also serve as a useful
> form of documentation.

Yep. And the fact that Java and C# -- languages which _could_ use
access control for security purposes -- choose to allow reflection to
override that control, is an argument that C++ shouldn't try either. I
also haven't heard big complaints from Java users that this use of
reflection causes problems.

However, it's still an extra way for users of a class to write fragile
code, which the author of the class is more likely to have to work
around because the user wasn't taking advantage of undefined behavior.

Jeffrey

--

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

.

--047d7ba97a8817db0f04fa7c5aa7
Content-Type: text/plain; charset=UTF-8

On 28 May 2014 15:38, Diggory Blake <diggsey@googlemail.com> wrote:

> Also, access modifiers are not there for security reasons - it's trivial
> to bypass them if one really wanted to
>

While there are a few places in the language where encapsulation is broken
(templated member functions, for instance), I don't think it is trivial to
bypass them in a *standard conforming* C++ program.  Could you give us some
simple examples?

- they're there to prevent accidental misuse,
>

Relying on an implementation detail is misuse, because the class author has
not promised to either maintain that implementation or fix the external
things dependent on the implementation.  By, say, granting friendship, the
author is making that promise.


> Since reflection is a tool used by the program, not the programmer,
>

Huh?
--
 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/.

--047d7ba97a8817db0f04fa7c5aa7
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On 28 May 2014 15:38, Diggory Blake <span dir=3D"ltr">&lt;=
<a href=3D"mailto:diggsey@googlemail.com" target=3D"_blank">diggsey@googlem=
ail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"g=
mail_quote">

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Also, access modifiers are =
not there for security reasons - it&#39;s trivial to bypass them if one rea=
lly wanted to </div>

</blockquote><div><br></div><div>While there are a few places in the langua=
ge where encapsulation is broken (templated member functions, for instance)=
, I don&#39;t think it is trivial to bypass them in a <i>standard conformin=
g</i> C++ program. =C2=A0Could you give us some simple examples?</div>

<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">- they&#39;r=
e there to prevent accidental misuse, </div></blockquote><div><br></div><di=
v>

Relying on an implementation detail is misuse, because the class author has=
 not promised to either maintain that implementation or fix the external th=
ings dependent on the implementation. =C2=A0By, say, granting friendship, t=
he author is making that promise.</div>

<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Since refl=
ection is a tool used by the program, not the programmer, </div></blockquot=
e><div>

<br></div><div>Huh?</div></div>-- <br>=C2=A0Nevin &quot;:-)&quot; Liber=C2=
=A0 &lt;mailto:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">=
nevin@eviloverlord.com</a>&gt;=C2=A0 (847) 691-1404
</div></div>

<p></p>

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

--047d7ba97a8817db0f04fa7c5aa7--

.

------=_Part_4299_33134710.1401313685319
Content-Type: text/plain; charset=UTF-8



On Wednesday, 28 May 2014 22:18:24 UTC+1, Nevin ":-)" Liber wrote:
>
> On 28 May 2014 15:38, Diggory Blake <dig...@googlemail.com <javascript:>>wrote:
>
>> Also, access modifiers are not there for security reasons - it's trivial
>> to bypass them if one really wanted to
>>
>
> While there are a few places in the language where encapsulation is broken
> (templated member functions, for instance), I don't think it is trivial to
> bypass them in a *standard conforming* C++ program.  Could you give us
> some simple examples?
>

struct Foo {
public:
    int m_public;
private:
    int m_private;
};

struct Bar {
public:
    int m_public;
    int m_private;
};

void setPrivate(Foo* foo, int v) {
    ((Bar*)foo)->m_private = v;
}

C++ allows direct memory access, of course it's trivial to bypass any kind
of access control not enforced by the underlying operating system.


>
> - they're there to prevent accidental misuse,
>>
>
> Relying on an implementation detail is misuse, because the class author
> has not promised to either maintain that implementation or fix the external
> things dependent on the implementation.  By, say, granting friendship, the
> author is making that promise.
>

Just because a program is using reflection to enumerate private members
does not imply that it is relying on implementation detail. The program may
be doing any number of tasks which the author of the class cannot possible
have predicted, and the program may not require any kind of promise that
the implementation will not change for it to succeed.


>
>
>> Since reflection is a tool used by the program, not the programmer,
>>
>
> Huh?
>

The purpose of reflection is not to do this (pseudocode):
findClass("Foo").construct("Hello, world!")

Instead of just:
new Foo("Hello, world!")

If the programmer was the one supplying these arguments then it would be
pointless. The only time it's useful is if the programmer doesn't know what
the arguments should be (ie. they are determined by the program at either
compile-time or run-time). Access control only mitigates human error, so
using it to restrict what the program itself can do has no benefit.


> --
>  Nevin ":-)" Liber  <mailto:ne...@eviloverlord.com <javascript:>>  (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/.

------=_Part_4299_33134710.1401313685319
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Wednesday, 28 May 2014 22:18:24 UTC+1, Nevin ":=
-)" Liber  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">On 28 May 2014 15:38, Diggory Blake <span dir=3D"ltr">&lt;<a href=3D"ja=
vascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"Mc0UTCxqI4MJ" onmouse=
down=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'jav=
ascript:';return true;">dig...@googlemail.com</a>&gt;</span> wrote:<br><div=
><div class=3D"gmail_quote">

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Also, access modifiers are =
not there for security reasons - it's trivial to bypass them if one really =
wanted to </div>

</blockquote><div><br></div><div>While there are a few places in the langua=
ge where encapsulation is broken (templated member functions, for instance)=
, I don't think it is trivial to bypass them in a <i>standard conforming</i=
> C++ program. &nbsp;Could you give us some simple examples?</div></div></d=
iv></div></blockquote><div><br><div class=3D"prettyprint" style=3D"backgrou=
nd-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-styl=
e: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"prettyp=
rint"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"s=
tyled-by-prettify">struct</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #606;" class=3D"styled-by-pret=
tify">Foo</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span st=
yle=3D"color: #008;" class=3D"styled-by-prettify">public</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">:</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">int</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> m_public</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: #008;" class=
=3D"styled-by-prettify">private</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">:</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"><br>&nbsp; &nbsp; </span><span style=3D"color: #008;" class=3D"=
styled-by-prettify">int</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> m_private</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"><br></span><span style=3D"color: #660;" class=3D"styled-by-prettify">};=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span=
></div></code></div><br><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"color: #008;" class=3D"styled-b=
y-prettify">struct</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">B=
ar</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"=
color: #008;" class=3D"styled-by-prettify">public</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">:</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"><br>&nbsp; &nbsp; </span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">int</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> m_public</span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"><br>&nbsp; &nbsp; </span><span style=3D"color: #008;" =
class=3D"styled-by-prettify">int</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> m_private</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">};</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
><br><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">v=
oid</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> setPri=
vate</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</spa=
n><span style=3D"color: #606;" class=3D"styled-by-prettify">Foo</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">*</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> foo</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">int</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> v</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: #660;" class=3D"styled-by-prettify">{</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; </sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">((</span><span=
 style=3D"color: #606;" class=3D"styled-by-prettify">Bar</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">*)</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify">foo</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">)-&gt;</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify">m_private </span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">=3D</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-pretti=
fy"><br></span><span style=3D"color: #660;" class=3D"styled-by-prettify">}<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span>=
</div></code></div><br>C++ allows direct memory access, of course it's triv=
ial to bypass any kind of access control not enforced by the underlying ope=
rating system.<br>&nbsp;</div><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"><div><div class=3D"gmail_quote">

<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">- they're th=
ere to prevent accidental misuse, </div></blockquote><div><br></div><div>

Relying on an implementation detail is misuse, because the class author has=
 not promised to either maintain that implementation or fix the external th=
ings dependent on the implementation. &nbsp;By, say, granting friendship, t=
he author is making that promise.</div></div></div></div></blockquote><div>=
<br>Just because a program is using reflection to enumerate private members=
 does not imply that it is relying on implementation detail. The program ma=
y be doing any number of tasks which the author of the class cannot possibl=
e have predicted, and the program may not require any kind of promise that =
the implementation will not change for it to succeed.<br>&nbsp;</div><block=
quote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-le=
ft: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"=
gmail_quote">

<div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Since refl=
ection is a tool used by the program, not the programmer, </div></blockquot=
e><div>

<br></div><div>Huh?</div></div></div></div></blockquote><div><br>The purpos=
e of reflection is not to do this (pseudocode):<br>findClass("Foo").constru=
ct("Hello, world!")<br><br>Instead of just:<br>new Foo("Hello, world!")<br>=
<br>If the programmer was the one supplying these arguments then it would b=
e pointless. The only time it's useful is if the programmer doesn't know wh=
at the arguments should be (ie. they are determined by the program at eithe=
r compile-time or run-time). Access control only mitigates human error, so =
using it to restrict what the program itself can do has no benefit.<br>&nbs=
p;</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"ltr"><div>=
-- <br>&nbsp;Nevin ":-)" Liber&nbsp; &lt;mailto:<a href=3D"javascript:" tar=
get=3D"_blank" gdf-obfuscated-mailto=3D"Mc0UTCxqI4MJ" onmousedown=3D"this.h=
ref=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript:';retu=
rn true;">ne...@eviloverlord.com</a><wbr>&gt;&nbsp; (847) 691-1404
</div></div>
</blockquote></div>

<p></p>

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

------=_Part_4299_33134710.1401313685319--

.

--bcaec50e5ea555bd9304fa7ce4be
Content-Type: text/plain; charset=UTF-8

On Wed, May 28, 2014 at 11:17 PM, Nevin Liber <nevin@eviloverlord.com>wrote:

> - they're there to prevent accidental misuse,
>
> Relying on an implementation detail is misuse, because the class author
> has not promised to either maintain that implementation or fix the external
> things dependent on the implementation.  By, say, granting friendship, the
> author is making that promise.
>

It's quite difficult relative to normal member access to use the reflection
mechanism to access a specific member of a specific class.  It's designed
to write code that accesses all members of any class in a uniform way, and
performs some sort of aggregate operation.  As such, this access is
generally a "cross-cutting concern" so when those implementation details
change, the reflection application changes along with them in an expected
way.  The reflection application isn't dependent or brittle on the specific
details.

Take for example a debugger that shows the names and values of private data
members.  You wouldn't say the debugger is dependant on the details of
those private data members.  If private members are added, changed or
deleted - the debugger continues to work, it just shows the new names and
values automatically.

Now, if some nitwit jumps cartwheels to use the reflection mechanism to
access and depend on a specific private member of a specific class that he
couldn't get access to with normal member access, the class author changes
that member, and said nitwits code breaks.  I would say that is the nitwits
fault and not the class designers.

Furthermore, I don't think adding some boilerplate "friend reflection" line
to all class specifiers changes that analysis or blame assignment.

--

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

--bcaec50e5ea555bd9304fa7ce4be
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wed, May 28, 2014 at 11:17 PM, 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><div class=3D"gmail_extra"><div =
class=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">- they&#39;re there to prev=
ent accidental misuse, <div class=3D"gmail_extra"><div class=3D"gmail_quote=
"><div class=3D"">
<div><br></div></div><div>

Relying on an implementation detail is misuse, because the class author has=
 not promised to either maintain that implementation or fix the external th=
ings dependent on the implementation. =C2=A0By, say, granting friendship, t=
he author is making that promise.</div>
</div></div></div></blockquote><div>=C2=A0<br></div><div>It&#39;s quite dif=
ficult relative to normal member access to use the reflection mechanism to =
access a specific member of a specific class.=C2=A0 It&#39;s designed to wr=
ite code that accesses all members of any class in a uniform way, and perfo=
rms some sort of aggregate operation.=C2=A0 As such, this access is general=
ly a &quot;cross-cutting concern&quot; so when those implementation details=
 change, the reflection application changes along with them in an expected =
way.=C2=A0 The reflection application isn&#39;t dependent or brittle on the=
 specific details.<br>
<br></div><div>Take for example a debugger that shows the names and values =
of private data members.=C2=A0 You wouldn&#39;t say the debugger is dependa=
nt on the details of those private data members.=C2=A0 If private members a=
re added, changed or deleted - the debugger continues to work, it just show=
s the new names and values automatically.<br>
<br></div><div>Now, if some nitwit jumps cartwheels to use the reflection m=
echanism to access and depend on a specific private member of a specific cl=
ass that he couldn&#39;t get access to with normal member access, the class=
 author changes that member, and said nitwits code breaks.=C2=A0 I would sa=
y that is the nitwits fault and not the class designers.<br>
</div><div><br></div><div>Furthermore, I don&#39;t think adding some boiler=
plate &quot;friend reflection&quot; line to all class specifiers changes th=
at analysis or blame assignment.<br><br></div></div></div></div>

<p></p>

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

--bcaec50e5ea555bd9304fa7ce4be--

.

--f46d043c08646aade604fa7d2f8f
Content-Type: text/plain; charset=UTF-8

On 28 May 2014 16:48, Diggory Blake <diggsey@googlemail.com> wrote:

>
>
> On Wednesday, 28 May 2014 22:18:24 UTC+1, Nevin ":-)" Liber wrote:
>
>> On 28 May 2014 15:38, Diggory Blake <dig...@googlemail.com> wrote:
>>
>>> Also, access modifiers are not there for security reasons - it's trivial
>>> to bypass them if one really wanted to
>>>
>>
>> While there are a few places in the language where encapsulation is
>> broken (templated member functions, for instance), I don't think it is
>> trivial to bypass them in a *standard conforming* C++ program.  Could
>> you give us some simple examples?
>>
>
> struct Foo {
> public:
>     int m_public;
> private:
>     int m_private;
> };
>
> struct Bar {
> public:
>     int m_public;
>     int m_private;
> };
>
> void setPrivate(Foo* foo, int v) {
>     ((Bar*)foo)->m_private = v;
> }
>
>
And you are asserting that is a legal, standards conforming C++ program??
 Anything that generates undefined behavior is by definition not guaranteed
to generate the code you think it will generate.

C++ allows direct memory access, of course it's trivial to bypass any kind
> of access control not enforced by the underlying operating system.
>

I'm not arguing this from a security perspective (that would be silly), but
from a language perspective.


> Just because a program is using reflection to enumerate private members
> does not imply that it is relying on implementation detail.
>

If public/protected/private is ignored, how is reflection not exposing the
implementation details of the class?


> The program may be doing any number of tasks which the author of the class
> cannot possible have predicted, and the program may not require any kind of
> promise that the implementation will not change for it to succeed.
>

And if I make an implementation change, I can break any of those tasks.
 For exposed interface breaking changes, that's expected.  You want to add
that ability for *any* class change; that makes things very fragile.


> If the programmer was the one supplying these arguments then it would be
> pointless. The only time it's useful is if the programmer doesn't know what
> the arguments should be (ie. they are determined by the program at either
> compile-time or run-time). Access control only mitigates human error, so
> using it to restrict what the program itself can do has no benefit.
>

Access control stops people from mucking with my invariants and relying on
a specific implementation.


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

--f46d043c08646aade604fa7d2f8f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On 28 May 2014 16:48, Diggory Blake <span dir=3D"ltr">&lt;=
<a href=3D"mailto:diggsey@googlemail.com" target=3D"_blank">diggsey@googlem=
ail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"g=
mail_quote">

<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div dir=3D"ltr"><br><br>On Wednesday, 28 May 2014 22:18:2=
4 UTC+1, Nevin &quot;:-)&quot; Liber  wrote:<div class=3D"">

<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div dir=3D"ltr">On 28 May 2014 15:38, Diggory Blake <span=
 dir=3D"ltr">&lt;<a>dig...@googlemail.com</a>&gt;</span> wrote:<br>

<div><div class=3D"gmail_quote">

<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div dir=3D"ltr">Also, access modifiers are not there for =
security reasons - it&#39;s trivial to bypass them if one really wanted to =
</div>



</blockquote><div><br></div><div>While there are a few places in the langua=
ge where encapsulation is broken (templated member functions, for instance)=
, I don&#39;t think it is trivial to bypass them in a <i>standard conformin=
g</i> C++ program. =C2=A0Could you give us some simple examples?</div>

</div></div></div></blockquote></div><div><br><div style=3D"background-colo=
r:rgb(250,250,250);border:1px solid rgb(187,187,187);word-wrap:break-word">=
<code><div><span style=3D"color:rgb(0,0,136)">struct</span><span style=3D"c=
olor:rgb(0,0,0)"> </span><span style=3D"color:rgb(102,0,102)">Foo</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)"><br>

</span><span style=3D"color:rgb(0,0,136)">public</span><span style=3D"color=
:rgb(102,102,0)">:</span><span style=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0=
 </span><span style=3D"color:rgb(0,0,136)">int</span><span style=3D"color:r=
gb(0,0,0)"> m_public</span><span style=3D"color:rgb(102,102,0)">;</span><sp=
an style=3D"color:rgb(0,0,0)"><br>

</span><span style=3D"color:rgb(0,0,136)">private</span><span style=3D"colo=
r:rgb(102,102,0)">:</span><span style=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=
=A0 </span><span style=3D"color:rgb(0,0,136)">int</span><span style=3D"colo=
r:rgb(0,0,0)"> m_private</span><span style=3D"color:rgb(102,102,0)">;</span=
><span style=3D"color:rgb(0,0,0)"><br>

</span><span style=3D"color:rgb(102,102,0)">};</span><span style=3D"color:r=
gb(0,0,0)"><br></span></div></code></div><br><div style=3D"background-color=
:rgb(250,250,250);border:1px solid rgb(187,187,187);word-wrap:break-word"><=
code><div>

<span style=3D"color:rgb(0,0,136)">struct</span><span style=3D"color:rgb(0,=
0,0)"> </span><span style=3D"color:rgb(102,0,102)">Bar</span><span style=3D=
"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(102,102,0)">{</span><sp=
an style=3D"color:rgb(0,0,0)"><br>

</span><span style=3D"color:rgb(0,0,136)">public</span><span style=3D"color=
:rgb(102,102,0)">:</span><span style=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0=
 </span><span style=3D"color:rgb(0,0,136)">int</span><span style=3D"color:r=
gb(0,0,0)"> m_public</span><span style=3D"color:rgb(102,102,0)">;</span><sp=
an style=3D"color:rgb(0,0,0)"><br>

=C2=A0 =C2=A0 </span><span style=3D"color:rgb(0,0,136)">int</span><span sty=
le=3D"color:rgb(0,0,0)"> m_private</span><span style=3D"color:rgb(102,102,0=
)">;</span><span style=3D"color:rgb(0,0,0)"><br></span><span style=3D"color=
:rgb(102,102,0)">};</span><span style=3D"color:rgb(0,0,0)"><br>

<br></span><span style=3D"color:rgb(0,0,136)">void</span><span style=3D"col=
or:rgb(0,0,0)"> setPrivate</span><span style=3D"color:rgb(102,102,0)">(</sp=
an><span style=3D"color:rgb(102,0,102)">Foo</span><span style=3D"color:rgb(=
102,102,0)">*</span><span style=3D"color:rgb(0,0,0)"> foo</span><span style=
=3D"color:rgb(102,102,0)">,</span><span style=3D"color:rgb(0,0,0)"> </span>=
<span style=3D"color:rgb(0,0,136)">int</span><span style=3D"color:rgb(0,0,0=
)"> v</span><span style=3D"color:rgb(102,102,0)">)</span><span style=3D"col=
or:rgb(0,0,0)"> </span><span style=3D"color:rgb(102,102,0)">{</span><span s=
tyle=3D"color:rgb(0,0,0)"><br>

=C2=A0 =C2=A0 </span><span style=3D"color:rgb(102,102,0)">((</span><span st=
yle=3D"color:rgb(102,0,102)">Bar</span><span style=3D"color:rgb(102,102,0)"=
>*)</span><span style=3D"color:rgb(0,0,0)">foo</span><span style=3D"color:r=
gb(102,102,0)">)-&gt;</span><span style=3D"color:rgb(0,0,0)">m_private </sp=
an><span style=3D"color:rgb(102,102,0)">=3D</span><span style=3D"color:rgb(=
0,0,0)"> v</span><span style=3D"color:rgb(102,102,0)">;</span><span style=
=3D"color:rgb(0,0,0)"><br>

</span><span style=3D"color:rgb(102,102,0)">}</span><span style=3D"color:rg=
b(0,0,0)"><br></span></div></code></div><br></div></div></blockquote><div><=
br></div><div>And you are asserting that is a legal, standards conforming C=
++ program?? =C2=A0Anything that generates undefined behavior is by definit=
ion not guaranteed to generate the code you think it will generate.</div>

<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-lef=
t-style:solid;padding-left:1ex"><div dir=3D"ltr"><div>C++ allows direct mem=
ory access, of course it&#39;s trivial to bypass any kind of access control=
 not enforced by the underlying operating system.<br>

</div></div></blockquote><div><br></div><div>I&#39;m not arguing this from =
a security perspective (that would be silly), but from a language perspecti=
ve.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin=
:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204)=
;border-left-style:solid;padding-left:1ex">

<div dir=3D"ltr"><div>Just because a program is using reflection to enumera=
te private members does not imply that it is relying on implementation deta=
il.</div></div></blockquote><div><br></div><div>If public/protected/private=
 is ignored, how is reflection not exposing the implementation details of t=
he class?</div>

<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-l=
eft-style:solid;padding-left:1ex"><div dir=3D"ltr"><div> The program may be=
 doing any number of tasks which the author of the class cannot possible ha=
ve predicted, and the program may not require any kind of promise that the =
implementation will not change for it to succeed.<br>

</div></div></blockquote><div><br></div><div>And if I make an implementatio=
n change, I can break any of those tasks. =C2=A0For exposed interface break=
ing changes, that&#39;s expected. =C2=A0You want to add that ability for *a=
ny* class change; that makes things very fragile.</div>

<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-l=
eft-style:solid;padding-left:1ex"><div dir=3D"ltr"><div>If the programmer w=
as the one supplying these arguments then it would be pointless. The only t=
ime it&#39;s useful is if the programmer doesn&#39;t know what the argument=
s should be (ie. they are determined by the program at either compile-time =
or run-time). Access control only mitigates human error, so using it to res=
trict what the program itself can do has no benefit.</div>

</div></blockquote><div><br></div><div>Access control stops people from muc=
king with my invariants and relying on a specific implementation.</div><div=
>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-=
style:solid;padding-left:1ex">

<div dir=3D"ltr"><div>--=C2=A0<br></div></div></blockquote></div>=C2=A0Nevi=
n &quot;:-)&quot; Liber=C2=A0 &lt;mailto:<a href=3D"mailto:nevin@eviloverlo=
rd.com" target=3D"_blank">nevin@eviloverlord.com</a>&gt;=C2=A0 (847) 691-14=
04
</div></div>

<p></p>

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

--f46d043c08646aade604fa7d2f8f--

.

--047d7b5d2deabb4aa904fa7d351d
Content-Type: text/plain; charset=UTF-8

On 28 May 2014 16:57, Andrew Tomazos <andrewtomazos@gmail.com> wrote:

> It's quite difficult relative to normal member access to use the
> reflection mechanism to access a specific member of a specific class.  It's
> designed to write code that accesses all members of any class in a uniform
> way, and performs some sort of aggregate operation.  As such, this access
> is generally a "cross-cutting concern" so when those implementation details
> change, the reflection application changes along with them in an expected
> way.  The reflection application isn't dependent or brittle on the specific
> details.
>

You cannot guarantee that, which makes code that relies on it very fragile.

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

--047d7b5d2deabb4aa904fa7d351d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On 28 May 2014 16:57, Andrew Tomazos <span dir=3D"ltr">&lt=
;<a href=3D"mailto:andrewtomazos@gmail.com" target=3D"_blank">andrewtomazos=
@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=
=3D"gmail_quote">

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"">It&#39;s qu=
ite difficult relative to normal member access to use the reflection mechan=
ism to access a specific member of a specific class.=C2=A0 It&#39;s designe=
d to write code that accesses all members of any class in a uniform way, an=
d performs some sort of aggregate operation.=C2=A0 As such, this access is =
generally a &quot;cross-cutting concern&quot; so when those implementation =
details change, the reflection application changes along with them in an ex=
pected way.=C2=A0 The reflection application isn&#39;t dependent or brittle=
 on the specific details.<br>

</div></div></blockquote><div><br></div><div>You cannot guarantee that, whi=
ch makes code that relies on it very fragile.</div><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex">

<div dir=3D"ltr"><div class=3D""></div><div class=3D"gmail_extra"><div clas=
s=3D"gmail_quote"><div>--=C2=A0<br></div></div></div></div></blockquote></d=
iv>=C2=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt;mailto:<a href=3D"mailto:nev=
in@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&gt;=C2=A0=
 (847) 691-1404
</div></div>

<p></p>

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

--047d7b5d2deabb4aa904fa7d351d--

.

--bcaec50e5ea5c6001704fa7d3fc1
Content-Type: text/plain; charset=UTF-8

On Thu, May 29, 2014 at 12:19 AM, Nevin Liber <nevin@eviloverlord.com>wrote:

> On 28 May 2014 16:57, Andrew Tomazos <andrewtomazos@gmail.com> wrote:
>
>> It's quite difficult relative to normal member access to use the
>> reflection mechanism to access a specific member of a specific class.  It's
>> designed to write code that accesses all members of any class in a uniform
>> way, and performs some sort of aggregate operation.  As such, this access
>> is generally a "cross-cutting concern" so when those implementation details
>> change, the reflection application changes along with them in an expected
>> way.  The reflection application isn't dependent or brittle on the specific
>> details.
>>
>
> You cannot guarantee that, which makes code that relies on it very fragile.
>

Adding "friend reflection" doesn't guarantee it either.

--

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

--bcaec50e5ea5c6001704fa7d3fc1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thu, May 29, 2014 at 12:19 AM, 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><div class=3D"gmail_extra"><div =
class=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"">On 28 May 2=
014 16:57, Andrew Tomazos <span dir=3D"ltr">&lt;<a href=3D"mailto:andrewtom=
azos@gmail.com" target=3D"_blank">andrewtomazos@gmail.com</a>&gt;</span> wr=
ote:<br>
</div><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div class=3D""=
>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>It&#39;s quite difficu=
lt relative to normal member access to use the reflection mechanism to acce=
ss a specific member of a specific class.=C2=A0 It&#39;s designed to write =
code that accesses all members of any class in a uniform way, and performs =
some sort of aggregate operation.=C2=A0 As such, this access is generally a=
 &quot;cross-cutting concern&quot; so when those implementation details cha=
nge, the reflection application changes along with them in an expected way.=
=C2=A0 The reflection application isn&#39;t dependent or brittle on the spe=
cific details.<br>


</div></div></blockquote><div><br></div></div><div>You cannot guarantee tha=
t, which makes code that relies on it very fragile.</div></div></div></div>=
</blockquote><div><br></div><div>Adding &quot;friend reflection&quot; doesn=
&#39;t guarantee it either.<br>
</div></div><br></div></div>

<p></p>

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

--bcaec50e5ea5c6001704fa7d3fc1--

.

On Wed, May 28, 2014 at 2:48 PM, Diggory Blake <diggsey@googlemail.com> wrote:
>
>
> On Wednesday, 28 May 2014 22:18:24 UTC+1, Nevin ":-)" Liber wrote:
>>
>> On 28 May 2014 15:38, Diggory Blake <dig...@googlemail.com> wrote:
>>>
>>> Also, access modifiers are not there for security reasons - it's trivial
>>> to bypass them if one really wanted to
>>
>>
>> While there are a few places in the language where encapsulation is broken
>> (templated member functions, for instance), I don't think it is trivial to
>> bypass them in a standard conforming C++ program.  Could you give us some
>> simple examples?
>
>
> struct Foo {
> public:
>     int m_public;
> private:
>     int m_private;
> };
>
> struct Bar {
> public:
>     int m_public;
>     int m_private;
> };
>
> void setPrivate(Foo* foo, int v) {
>     ((Bar*)foo)->m_private = v;
> }
>
> C++ allows direct memory access, of course it's trivial to bypass any kind
> of access control not enforced by the underlying operating system.

This violates basic.lval's aliasing restrictions, which causes
undefined behavior. It also relies on the compiler not taking
advantage of the permission to reorder things at access control
boundaries. That's why Nevin specified "standard conforming". It's
true that malicious code within a single process can, in practice, use
undefined behavior to get whatever behavior it wants, but undefined
behavior still affects who's blamed for breakage.

>>> Since reflection is a tool used by the program, not the programmer,
>>
>>
>> Huh?
>
>
> The purpose of reflection is not to do this (pseudocode):
> findClass("Foo").construct("Hello, world!")
>
> Instead of just:
> new Foo("Hello, world!")
>
> If the programmer was the one supplying these arguments then it would be
> pointless.

If Foo's constructor is private, but reflection allows access to it
anyway, people will use reflection to get access to it, and the people
trying to maintain Foo will curse us the next time they try to upgrade
it. You saying that's not the purpose won't stop any of that from
happening.

That said, I think I do prefer reflection to ignore access control,
and not to provide an escape hatch for class authors. If class authors
can't explicitly block reflection, it'll be a bit easier for them to
place the blame on the "nitwits" where it belongs. :)

Jeffrey

--

---
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_2713_32309209.1401318863986
Content-Type: text/plain; charset=UTF-8



On Wednesday, 28 May 2014 23:18:02 UTC+1, Nevin ":-)" Liber wrote:
>
> On 28 May 2014 16:48, Diggory Blake <dig...@googlemail.com <javascript:>>wrote:
>
>>
>>
>> On Wednesday, 28 May 2014 22:18:24 UTC+1, Nevin ":-)" Liber wrote:
>>
>>> On 28 May 2014 15:38, Diggory Blake <dig...@googlemail.com> wrote:
>>>
>>>> Also, access modifiers are not there for security reasons - it's
>>>> trivial to bypass them if one really wanted to
>>>>
>>>
>>> While there are a few places in the language where encapsulation is
>>> broken (templated member functions, for instance), I don't think it is
>>> trivial to bypass them in a *standard conforming* C++ program.  Could
>>> you give us some simple examples?
>>>
>>
>> struct Foo {
>> public:
>>     int m_public;
>> private:
>>     int m_private;
>> };
>>
>> struct Bar {
>> public:
>>     int m_public;
>>     int m_private;
>> };
>>
>> void setPrivate(Foo* foo, int v) {
>>     ((Bar*)foo)->m_private = v;
>> }
>>
>>
> And you are asserting that is a legal, standards conforming C++ program??
>  Anything that generates undefined behavior is by definition not guaranteed
> to generate the code you think it will generate.
>

No, but it does work in practically every C++ compiler ever.


>
> C++ allows direct memory access, of course it's trivial to bypass any kind
>> of access control not enforced by the underlying operating system.
>>
>
> I'm not arguing this from a security perspective (that would be silly),
> but from a language perspective.
>

And the same people who are going to try accessing private members are not
going to give up because their code isn't 100% standards compliant, if it
works they'll do it. If you impose restrictions they'll find a way around
them, and in the process you annoy every sane programmer who actually knows
what they're doing.


>
>
>> Just because a program is using reflection to enumerate private members
>> does not imply that it is relying on implementation detail.
>>
>
> If public/protected/private is ignored, how is reflection not exposing the
> implementation details of the class?
>
>
>> The program may be doing any number of tasks which the author of the
>> class cannot possible have predicted, and the program may not require any
>> kind of promise that the implementation will not change for it to succeed.
>>
>
> And if I make an implementation change, I can break any of those tasks.
>  For exposed interface breaking changes, that's expected.  You want to add
> that ability for *any* class change; that makes things very fragile.
>

Really, so if I make a library which uses reflection to generate debug
information for a program you can break it by changing your implementation?
No. In addition, there are cases where the class author simply cannot
foresee a use. For example, what if I want to generate memory layout
information for a garbage collector such as Boehm to more precisely scan
the heap?


>
>
>> If the programmer was the one supplying these arguments then it would be
>> pointless. The only time it's useful is if the programmer doesn't know what
>> the arguments should be (ie. they are determined by the program at either
>> compile-time or run-time). Access control only mitigates human error, so
>> using it to restrict what the program itself can do has no benefit.
>>
>
> Access control stops people from mucking with my invariants and relying on
> a specific implementation.
>

Nope, it just tells them they shouldn't, and it will continue to do that
even if it's possible to bypass it via reflection.


>
>
>> --
>>
>  Nevin ":-)" Liber  <mailto:ne...@eviloverlord.com <javascript:>>  (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/.

------=_Part_2713_32309209.1401318863986
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Wednesday, 28 May 2014 23:18:02 UTC+1, Nevin ":=
-)" Liber  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">On 28 May 2014 16:48, Diggory Blake <span dir=3D"ltr">&lt;<a href=3D"ja=
vascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"Cr2cnbPtWNoJ" onmouse=
down=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'jav=
ascript:';return true;">dig...@googlemail.com</a>&gt;</span> wrote:<br><div=
><div class=3D"gmail_quote">

<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div dir=3D"ltr"><br><br>On Wednesday, 28 May 2014 22:18:2=
4 UTC+1, Nevin ":-)" Liber  wrote:<div>

<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div dir=3D"ltr">On 28 May 2014 15:38, Diggory Blake <span=
 dir=3D"ltr">&lt;<a>dig...@googlemail.com</a>&gt;</span> wrote:<br>

<div><div class=3D"gmail_quote">

<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div dir=3D"ltr">Also, access modifiers are not there for =
security reasons - it's trivial to bypass them if one really wanted to </di=
v>



</blockquote><div><br></div><div>While there are a few places in the langua=
ge where encapsulation is broken (templated member functions, for instance)=
, I don't think it is trivial to bypass them in a <i>standard conforming</i=
> C++ program. &nbsp;Could you give us some simple examples?</div>

</div></div></div></blockquote></div><div><br><div style=3D"background-colo=
r:rgb(250,250,250);border:1px solid rgb(187,187,187);word-wrap:break-word">=
<code><div><span style=3D"color:rgb(0,0,136)">struct</span><span style=3D"c=
olor:rgb(0,0,0)"> </span><span style=3D"color:rgb(102,0,102)">Foo</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)"><br>

</span><span style=3D"color:rgb(0,0,136)">public</span><span style=3D"color=
:rgb(102,102,0)">:</span><span style=3D"color:rgb(0,0,0)"><br>&nbsp; &nbsp;=
 </span><span style=3D"color:rgb(0,0,136)">int</span><span style=3D"color:r=
gb(0,0,0)"> m_public</span><span style=3D"color:rgb(102,102,0)">;</span><sp=
an style=3D"color:rgb(0,0,0)"><br>

</span><span style=3D"color:rgb(0,0,136)">private</span><span style=3D"colo=
r:rgb(102,102,0)">:</span><span style=3D"color:rgb(0,0,0)"><br>&nbsp; &nbsp=
; </span><span style=3D"color:rgb(0,0,136)">int</span><span style=3D"color:=
rgb(0,0,0)"> m_private</span><span style=3D"color:rgb(102,102,0)">;</span><=
span style=3D"color:rgb(0,0,0)"><br>

</span><span style=3D"color:rgb(102,102,0)">};</span><span style=3D"color:r=
gb(0,0,0)"><br></span></div></code></div><br><div style=3D"background-color=
:rgb(250,250,250);border:1px solid rgb(187,187,187);word-wrap:break-word"><=
code><div>

<span style=3D"color:rgb(0,0,136)">struct</span><span style=3D"color:rgb(0,=
0,0)"> </span><span style=3D"color:rgb(102,0,102)">Bar</span><span style=3D=
"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(102,102,0)">{</span><sp=
an style=3D"color:rgb(0,0,0)"><br>

</span><span style=3D"color:rgb(0,0,136)">public</span><span style=3D"color=
:rgb(102,102,0)">:</span><span style=3D"color:rgb(0,0,0)"><br>&nbsp; &nbsp;=
 </span><span style=3D"color:rgb(0,0,136)">int</span><span style=3D"color:r=
gb(0,0,0)"> m_public</span><span style=3D"color:rgb(102,102,0)">;</span><sp=
an style=3D"color:rgb(0,0,0)"><br>

&nbsp; &nbsp; </span><span style=3D"color:rgb(0,0,136)">int</span><span sty=
le=3D"color:rgb(0,0,0)"> m_private</span><span style=3D"color:rgb(102,102,0=
)">;</span><span style=3D"color:rgb(0,0,0)"><br></span><span style=3D"color=
:rgb(102,102,0)">};</span><span style=3D"color:rgb(0,0,0)"><br>

<br></span><span style=3D"color:rgb(0,0,136)">void</span><span style=3D"col=
or:rgb(0,0,0)"> setPrivate</span><span style=3D"color:rgb(102,102,0)">(</sp=
an><span style=3D"color:rgb(102,0,102)">Foo</span><span style=3D"color:rgb(=
102,102,0)">*</span><span style=3D"color:rgb(0,0,0)"> foo</span><span style=
=3D"color:rgb(102,102,0)">,</span><span style=3D"color:rgb(0,0,0)"> </span>=
<span style=3D"color:rgb(0,0,136)">int</span><span style=3D"color:rgb(0,0,0=
)"> v</span><span style=3D"color:rgb(102,102,0)">)</span><span style=3D"col=
or:rgb(0,0,0)"> </span><span style=3D"color:rgb(102,102,0)">{</span><span s=
tyle=3D"color:rgb(0,0,0)"><br>

&nbsp; &nbsp; </span><span style=3D"color:rgb(102,102,0)">((</span><span st=
yle=3D"color:rgb(102,0,102)">Bar</span><span style=3D"color:rgb(102,102,0)"=
>*)</span><span style=3D"color:rgb(0,0,0)">foo</span><span style=3D"color:r=
gb(102,102,0)">)-&gt;</span><span style=3D"color:rgb(0,0,0)">m_private </sp=
an><span style=3D"color:rgb(102,102,0)">=3D</span><span style=3D"color:rgb(=
0,0,0)"> v</span><span style=3D"color:rgb(102,102,0)">;</span><span style=
=3D"color:rgb(0,0,0)"><br>

</span><span style=3D"color:rgb(102,102,0)">}</span><span style=3D"color:rg=
b(0,0,0)"><br></span></div></code></div><br></div></div></blockquote><div><=
br></div><div>And you are asserting that is a legal, standards conforming C=
++ program?? &nbsp;Anything that generates undefined behavior is by definit=
ion not guaranteed to generate the code you think it will generate.</div></=
div></div></div></blockquote><div><br>No, but it does work in practically e=
very C++ compiler ever.<br>&nbsp;</div><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"><div><div class=3D"gmail_quote">

<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-lef=
t-style:solid;padding-left:1ex"><div dir=3D"ltr"><div>C++ allows direct mem=
ory access, of course it's trivial to bypass any kind of access control not=
 enforced by the underlying operating system.<br>

</div></div></blockquote><div><br></div><div>I'm not arguing this from a se=
curity perspective (that would be silly), but from a language perspective.<=
/div></div></div></div></blockquote><div><br>And the same people who are go=
ing to try accessing private members are not going to give up because their=
 code isn't 100% standards compliant, if it works they'll do it. If you imp=
ose restrictions they'll find a way around them, and in the process you ann=
oy every sane programmer who actually knows what they're doing.<br>&nbsp;</=
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"ltr"><div><div=
 class=3D"gmail_quote"><div>&nbsp;</div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rg=
b(204,204,204);border-left-style:solid;padding-left:1ex">

<div dir=3D"ltr"><div>Just because a program is using reflection to enumera=
te private members does not imply that it is relying on implementation deta=
il.</div></div></blockquote><div><br></div><div>If public/protected/private=
 is ignored, how is reflection not exposing the implementation details of t=
he class?</div>

<div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-l=
eft-style:solid;padding-left:1ex"><div dir=3D"ltr"><div> The program may be=
 doing any number of tasks which the author of the class cannot possible ha=
ve predicted, and the program may not require any kind of promise that the =
implementation will not change for it to succeed.<br>

</div></div></blockquote><div><br></div><div>And if I make an implementatio=
n change, I can break any of those tasks. &nbsp;For exposed interface break=
ing changes, that's expected. &nbsp;You want to add that ability for *any* =
class change; that makes things very fragile.</div></div></div></div></bloc=
kquote><div><br>Really, so if I make a library which uses reflection to gen=
erate debug information for a program you can break it by changing your imp=
lementation? No. In addition, there are cases where the class author simply=
 cannot foresee a use. For example, what if I want to generate memory layou=
t information for a garbage collector such as Boehm to more precisely scan =
the heap?<br>&nbsp;</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"ltr"><div><div class=3D"gmail_quote">

<div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-l=
eft-style:solid;padding-left:1ex"><div dir=3D"ltr"><div>If the programmer w=
as the one supplying these arguments then it would be pointless. The only t=
ime it's useful is if the programmer doesn't know what the arguments should=
 be (ie. they are determined by the program at either compile-time or run-t=
ime). Access control only mitigates human error, so using it to restrict wh=
at the program itself can do has no benefit.</div>

</div></blockquote><div><br></div><div>Access control stops people from muc=
king with my invariants and relying on a specific implementation.</div></di=
v></div></div></blockquote><div><br>Nope, it just tells them they shouldn't=
, and it will continue to do that even if it's possible to bypass it via re=
flection.<br>&nbsp;</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"ltr"><div><div class=3D"gmail_quote"><div>&nbsp;</div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px=
;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1e=
x">

<div dir=3D"ltr"><div>--&nbsp;<br></div></div></blockquote></div>&nbsp;Nevi=
n ":-)" Liber&nbsp; &lt;mailto:<a href=3D"javascript:" target=3D"_blank" gd=
f-obfuscated-mailto=3D"Cr2cnbPtWNoJ" onmousedown=3D"this.href=3D'javascript=
:';return true;" onclick=3D"this.href=3D'javascript:';return true;">ne...@e=
viloverlord.com</a><wbr>&gt;&nbsp; (847) 691-1404
</div></div>
</blockquote></div>

<p></p>

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

------=_Part_2713_32309209.1401318863986--

.

On 29 May 2014 00:15, 'Jeffrey Yasskin' via ISO C++ Standard - Future
Proposals <std-proposals@isocpp.org> wrote:
> On Wed, May 28, 2014 at 1:38 PM, Diggory Blake <diggsey@googlemail.com> wrote:
>> Also, access modifiers are not there for security reasons - it's trivial to
>> bypass them if one really wanted to - they're there to prevent accidental
>> misuse, or in other words, human error, although they also serve as a useful
>> form of documentation.
>
> Yep. And the fact that Java and C# -- languages which _could_ use
> access control for security purposes -- choose to allow reflection to
> override that control, is an argument that C++ shouldn't try either. I
> also haven't heard big complaints from Java users that this use of
> reflection causes problems.

Ah. My understanding of java reflection seems outdated, I didn't know
that it's possible to use setAccessible.

I'm not thinking of security. I'm thinking of what a class designer is trying
to express, and what the repercussions of allowing violations of that
are.

I still think it would be worthwhile to carefully consider what we
want to enable,
and certainly what we want to enable by-default/conveniently. Providing a
too-convenient way to bypass access controls via a reflection mechanism
will sure as hell mean such tricks will spread like a wildfire. I'm not going
to debug the end result, and neither is any of you, regardless of how
convenient it may seem to be at first glance.

--

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

.

On 29 May 2014 02:27, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
> On 29 May 2014 00:15, 'Jeffrey Yasskin' via ISO C++ Standard - Future
> Proposals <std-proposals@isocpp.org> wrote:
>> On Wed, May 28, 2014 at 1:38 PM, Diggory Blake <diggsey@googlemail.com> wrote:
>>> Also, access modifiers are not there for security reasons - it's trivial to
>>> bypass them if one really wanted to - they're there to prevent accidental
>>> misuse, or in other words, human error, although they also serve as a useful
>>> form of documentation.
>>
>> Yep. And the fact that Java and C# -- languages which _could_ use
>> access control for security purposes -- choose to allow reflection to
>> override that control, is an argument that C++ shouldn't try either. I
>> also haven't heard big complaints from Java users that this use of
>> reflection causes problems.
>
> Ah. My understanding of java reflection seems outdated, I didn't know
> that it's possible to use setAccessible.
>
> I'm not thinking of security. I'm thinking of what a class designer is trying
> to express, and what the repercussions of allowing violations of that
> are.
>
> I still think it would be worthwhile to carefully consider what we
> want to enable,
> and certainly what we want to enable by-default/conveniently. Providing a
> too-convenient way to bypass access controls via a reflection mechanism
> will sure as hell mean such tricks will spread like a wildfire. I'm not going
> to debug the end result, and neither is any of you, regardless of how
> convenient it may seem to be at first glance.

And, please allow this flippant digression, with all puns intended. I helpfully
provide the following java-ish pseudo-code:

interface ViolationHandler
{
    void check();
}

public class CHandler implements ViolationHandler
{
   void check() {
      if (Reflection.CanBypassAccessControl()) {
        throw new
HissyFitError(Ban().It().In().CodingGuidelines().Post().Haste());
      }
   }
}

--

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

.

Em qui 29 maio 2014, =E0s 02:27:11, Ville Voutilainen escreveu:
> I still think it would be worthwhile to carefully consider what we
> want to enable,
> and certainly what we want to enable by-default/conveniently. Providing a
> too-convenient way to bypass access controls via a reflection mechanism
> will sure as hell mean such tricks will spread like a wildfire. I'm not
> going to debug the end result, and neither is any of you, regardless of h=
ow
> convenient it may seem to be at first glance.

This seems easy to solve, to me.

So far, we've discussed only compile-time reflection. Let's say it's access=
ed=20
via typedef<T>.

So:

struct S
{
 int i;
 friend void f();
private:
 int j;
};

void f()
{
 typedef<S>; // here, we see both i and j
}

void g()
{
 typedef<S>; // here, we see only i, since g isn't a friend
}

Now, nothing stops you from adding a member function that does:

 auto metaObject() { return typedef<ThisClass>; }

and thus leak all your privates without access verification.

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

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

.

> And the same people who are going to try accessing private members are not
> going to give up because their code isn't 100% standards compliant, if it
> works they'll do it. If you impose restrictions they'll find a way around
> them, and in the process you annoy every sane programmer who actually knows
> what they're doing.

The fact that everything can be bypassed (with standard-compliant or non-
compliant code), is not an excuse to leave the door open by default.

If it were, we'd have no access specifiers in the language, and you wouldn't
lock your car, your house when you are not in it.



Cheers,
Ivan


KDE, ivan.cukic at kde.org, http://ivan.fomentgroup.org/
gpg key id: 850B6F76, keyserver.pgp.com

--

---
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_4473_3522701.1401357769555
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


It's not good someone messing with the class invariants, so you should not=
=20
access private members, however, as Herb always remember us, you should be=
=20
able to look under the hood.

So, what is intended in N3951 is by default do not violate access=20
specification:

class A {
typedef<A> // see all from A;
};

class B : public A {
typedef<A> // see protected and public from A;
};

class C  {
typedef<A> // see public from A;
};

I don=C2=B4t let anyone looking my private members, unless if you buy me a =
drink=20
first and ask nicely "typedef<A requires std::is_private>" I will let you=
=20
see my private parts;   // trait from N3987


BR
Cleiton



Em quarta-feira, 28 de maio de 2014 19h27min36s UTC-3, Jeffrey Yasskin=20
escreveu:
>
> On Wed, May 28, 2014 at 2:48 PM, Diggory Blake <dig...@googlemail.com<jav=
ascript:>>=20
> wrote:=20
> >=20
> >=20
> > On Wednesday, 28 May 2014 22:18:24 UTC+1, Nevin ":-)" Liber wrote:=20
> >>=20
> >> On 28 May 2014 15:38, Diggory Blake <dig...@googlemail.com> wrote:=20
> >>>=20
> >>> Also, access modifiers are not there for security reasons - it's=20
> trivial=20
> >>> to bypass them if one really wanted to=20
> >>=20
> >>=20
> >> While there are a few places in the language where encapsulation is=20
> broken=20
> >> (templated member functions, for instance), I don't think it is trivia=
l=20
> to=20
> >> bypass them in a standard conforming C++ program.  Could you give us=
=20
> some=20
> >> simple examples?=20
> >=20
> >=20
> > struct Foo {=20
> > public:=20
> >     int m_public;=20
> > private:=20
> >     int m_private;=20
> > };=20
> >=20
> > struct Bar {=20
> > public:=20
> >     int m_public;=20
> >     int m_private;=20
> > };=20
> >=20
> > void setPrivate(Foo* foo, int v) {=20
> >     ((Bar*)foo)->m_private =3D v;=20
> > }=20
> >=20
> > C++ allows direct memory access, of course it's trivial to bypass any=
=20
> kind=20
> > of access control not enforced by the underlying operating system.=20
>
> This violates basic.lval's aliasing restrictions, which causes=20
> undefined behavior. It also relies on the compiler not taking=20
> advantage of the permission to reorder things at access control=20
> boundaries. That's why Nevin specified "standard conforming". It's=20
> true that malicious code within a single process can, in practice, use=20
> undefined behavior to get whatever behavior it wants, but undefined=20
> behavior still affects who's blamed for breakage.=20
>
> >>> Since reflection is a tool used by the program, not the programmer,=
=20
> >>=20
> >>=20
> >> Huh?=20
> >=20
> >=20
> > The purpose of reflection is not to do this (pseudocode):=20
> > findClass("Foo").construct("Hello, world!")=20
> >=20
> > Instead of just:=20
> > new Foo("Hello, world!")=20
> >=20
> > If the programmer was the one supplying these arguments then it would b=
e=20
> > pointless.=20
>
> If Foo's constructor is private, but reflection allows access to it=20
> anyway, people will use reflection to get access to it, and the people=20
> trying to maintain Foo will curse us the next time they try to upgrade=20
> it. You saying that's not the purpose won't stop any of that from=20
> happening.=20
>
> That said, I think I do prefer reflection to ignore access control,=20
> and not to provide an escape hatch for class authors. If class authors=20
> can't explicitly block reflection, it'll be a bit easier for them to=20
> place the blame on the "nitwits" where it belongs. :)=20
>
> Jeffrey=20
>

--=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_4473_3522701.1401357769555
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><br></div><div>It's not good someone messing with the=
 class invariants, so you should not access private members, however, as He=
rb always remember us, you should be able to look under the hood.</div><div=
><br></div><div>So, what is intended in N3951 is by default do not violate =
access specification:</div><div><br></div><div>class A {</div><div>typedef&=
lt;A&gt; // see all from A;</div><div>};</div><div><br></div><div>class B :=
 public A {</div><div>typedef&lt;A&gt; // see protected and public from A;<=
/div><div>};</div><div><br></div><div><div>class C &nbsp;{</div><div>typede=
f&lt;A&gt; // see public from A;</div><div>};</div></div><div><br></div><di=
v>I don=C2=B4t let anyone looking my private members, unless if you&nbsp;bu=
y me a drink first and ask nicely "typedef&lt;A requires std::is_private&gt=
;" I will let you see my private parts; &nbsp; // trait from N3987</div><di=
v><br></div><div><br></div>BR<div>Cleiton</div><div><br></div><div><br><br>=
Em quarta-feira, 28 de maio de 2014 19h27min36s UTC-3, Jeffrey Yasskin  esc=
reveu:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Wed, May 28, 2014 at =
2:48 PM, Diggory Blake &lt;<a href=3D"javascript:" target=3D"_blank" gdf-ob=
fuscated-mailto=3D"SeljTzX-bUgJ" onmousedown=3D"this.href=3D'javascript:';r=
eturn true;" onclick=3D"this.href=3D'javascript:';return true;">dig...@goog=
lemail.com</a>&gt; wrote:
<br>&gt;
<br>&gt;
<br>&gt; On Wednesday, 28 May 2014 22:18:24 UTC+1, Nevin ":-)" Liber wrote:
<br>&gt;&gt;
<br>&gt;&gt; On 28 May 2014 15:38, Diggory Blake &lt;<a>dig...@googlemail.c=
om</a>&gt; wrote:
<br>&gt;&gt;&gt;
<br>&gt;&gt;&gt; Also, access modifiers are not there for security reasons =
- it's trivial
<br>&gt;&gt;&gt; to bypass them if one really wanted to
<br>&gt;&gt;
<br>&gt;&gt;
<br>&gt;&gt; While there are a few places in the language where encapsulati=
on is broken
<br>&gt;&gt; (templated member functions, for instance), I don't think it i=
s trivial to
<br>&gt;&gt; bypass them in a standard conforming C++ program. &nbsp;Could =
you give us some
<br>&gt;&gt; simple examples?
<br>&gt;
<br>&gt;
<br>&gt; struct Foo {
<br>&gt; public:
<br>&gt; &nbsp; &nbsp; int m_public;
<br>&gt; private:
<br>&gt; &nbsp; &nbsp; int m_private;
<br>&gt; };
<br>&gt;
<br>&gt; struct Bar {
<br>&gt; public:
<br>&gt; &nbsp; &nbsp; int m_public;
<br>&gt; &nbsp; &nbsp; int m_private;
<br>&gt; };
<br>&gt;
<br>&gt; void setPrivate(Foo* foo, int v) {
<br>&gt; &nbsp; &nbsp; ((Bar*)foo)-&gt;m_private =3D v;
<br>&gt; }
<br>&gt;
<br>&gt; C++ allows direct memory access, of course it's trivial to bypass =
any kind
<br>&gt; of access control not enforced by the underlying operating system.
<br>
<br>This violates basic.lval's aliasing restrictions, which causes
<br>undefined behavior. It also relies on the compiler not taking
<br>advantage of the permission to reorder things at access control
<br>boundaries. That's why Nevin specified "standard conforming". It's
<br>true that malicious code within a single process can, in practice, use
<br>undefined behavior to get whatever behavior it wants, but undefined
<br>behavior still affects who's blamed for breakage.
<br>
<br>&gt;&gt;&gt; Since reflection is a tool used by the program, not the pr=
ogrammer,
<br>&gt;&gt;
<br>&gt;&gt;
<br>&gt;&gt; Huh?
<br>&gt;
<br>&gt;
<br>&gt; The purpose of reflection is not to do this (pseudocode):
<br>&gt; findClass("Foo").construct("<wbr>Hello, world!")
<br>&gt;
<br>&gt; Instead of just:
<br>&gt; new Foo("Hello, world!")
<br>&gt;
<br>&gt; If the programmer was the one supplying these arguments then it wo=
uld be
<br>&gt; pointless.
<br>
<br>If Foo's constructor is private, but reflection allows access to it
<br>anyway, people will use reflection to get access to it, and the people
<br>trying to maintain Foo will curse us the next time they try to upgrade
<br>it. You saying that's not the purpose won't stop any of that from
<br>happening.
<br>
<br>That said, I think I do prefer reflection to ignore access control,
<br>and not to provide an escape hatch for class authors. If class authors
<br>can't explicitly block reflection, it'll be a bit easier for them to
<br>place the blame on the "nitwits" where it belongs. :)
<br>
<br>Jeffrey
<br></blockquote></div></div>

<p></p>

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

------=_Part_4473_3522701.1401357769555--

.

--047d7bd76fa65655c804fa887f60
Content-Type: text/plain; charset=UTF-8

On Thu May 29 2014 at 00:18:02, Nevin Liber <nevin@eviloverlord.com> wrote:

> On 28 May 2014 16:48, Diggory Blake <diggsey@googlemail.com> wrote:
>
>>
>>
>> On Wednesday, 28 May 2014 22:18:24 UTC+1, Nevin ":-)" Liber wrote:
>>
>>> On 28 May 2014 15:38, Diggory Blake <dig...@googlemail.com> wrote:
>>>
>>>> Also, access modifiers are not there for security reasons - it's
>>>> trivial to bypass them if one really wanted to
>>>>
>>>
>>> While there are a few places in the language where encapsulation is
>>> broken (templated member functions, for instance), I don't think it is
>>> trivial to bypass them in a *standard conforming* C++ program.  Could
>>> you give us some simple examples?
>>>
>>
>> struct Foo {
>> public:
>>     int m_public;
>> private:
>>     int m_private;
>> };
>>
>> struct Bar {
>> public:
>>     int m_public;
>>     int m_private;
>> };
>>
>> void setPrivate(Foo* foo, int v) {
>>     ((Bar*)foo)->m_private = v;
>> }
>>
>>
> And you are asserting that is a legal, standards conforming C++ program??
>  Anything that generates undefined behavior is by definition not guaranteed
> to generate the code you think it will generate.
>

It is totally possible to access arbitrary private members using only
standards-conforming means:
http://bloglitb.blogspot.de/2010/07/access-to-private-members-thats-easy.html
Quoting Herb Sutter, access control is to protect yourself against Murphy,
not Machiavelli. A reflection library should (optionally) allow access to
private members. As described this is no further breakage of accessibility
specifiers (which are enforced only in straightforward cases), and it is
common in other languages. Any restriction would be purely artificial and
would restrict the usefulness of a general-purpose reflection library.

--

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

--047d7bd76fa65655c804fa887f60
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<br><br><div>On Thu May 29 2014 at 00:18:02, Nevin Liber &lt;<a href=3D"mai=
lto:nevin@eviloverlord.com">nevin@eviloverlord.com</a>&gt; wrote:</div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex">
<div dir=3D"ltr">On 28 May 2014 16:48, Diggory Blake <span dir=3D"ltr">&lt;=
<a href=3D"mailto:diggsey@googlemail.com" target=3D"_blank">diggsey@googlem=
ail.com</a>&gt;</span> wrote:<br></div><div class=3D"gmail_extra"><div clas=
s=3D"gmail_quote">
<div dir=3D"ltr">

<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div dir=3D"ltr"><br><br>On Wednesday, 28 May 2014 22:18:2=
4 UTC+1, Nevin &quot;:-)&quot; Liber  wrote:<div>


<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div dir=3D"ltr">On 28 May 2014 15:38, Diggory Blake <span=
 dir=3D"ltr">&lt;<a>dig...@googlemail.com</a>&gt;</span> wrote:<br>


<div><div class=3D"gmail_quote">

<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div dir=3D"ltr">Also, access modifiers are not there for =
security reasons - it&#39;s trivial to bypass them if one really wanted to =
</div>




</blockquote><div><br></div><div>While there are a few places in the langua=
ge where encapsulation is broken (templated member functions, for instance)=
, I don&#39;t think it is trivial to bypass them in a <i>standard conformin=
g</i> C++ program. =C2=A0Could you give us some simple examples?</div>


</div></div></div></blockquote></div><div><br><div style=3D"background-colo=
r:rgb(250,250,250);border:1px solid rgb(187,187,187);word-wrap:break-word">=
<code><div><span style=3D"color:rgb(0,0,136)">struct</span><span style=3D"c=
olor:rgb(0,0,0)"> </span><span style=3D"color:rgb(102,0,102)">Foo</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)"><br>


</span><span style=3D"color:rgb(0,0,136)">public</span><span style=3D"color=
:rgb(102,102,0)">:</span><span style=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0=
 </span><span style=3D"color:rgb(0,0,136)">int</span><span style=3D"color:r=
gb(0,0,0)"> m_public</span><span style=3D"color:rgb(102,102,0)">;</span><sp=
an style=3D"color:rgb(0,0,0)"><br>


</span><span style=3D"color:rgb(0,0,136)">private</span><span style=3D"colo=
r:rgb(102,102,0)">:</span><span style=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=
=A0 </span><span style=3D"color:rgb(0,0,136)">int</span><span style=3D"colo=
r:rgb(0,0,0)"> m_private</span><span style=3D"color:rgb(102,102,0)">;</span=
><span style=3D"color:rgb(0,0,0)"><br>


</span><span style=3D"color:rgb(102,102,0)">};</span><span style=3D"color:r=
gb(0,0,0)"><br></span></div></code></div><br><div style=3D"background-color=
:rgb(250,250,250);border:1px solid rgb(187,187,187);word-wrap:break-word"><=
code><div>


<span style=3D"color:rgb(0,0,136)">struct</span><span style=3D"color:rgb(0,=
0,0)"> </span><span style=3D"color:rgb(102,0,102)">Bar</span><span style=3D=
"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(102,102,0)">{</span><sp=
an style=3D"color:rgb(0,0,0)"><br>


</span><span style=3D"color:rgb(0,0,136)">public</span><span style=3D"color=
:rgb(102,102,0)">:</span><span style=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0=
 </span><span style=3D"color:rgb(0,0,136)">int</span><span style=3D"color:r=
gb(0,0,0)"> m_public</span><span style=3D"color:rgb(102,102,0)">;</span><sp=
an style=3D"color:rgb(0,0,0)"><br>


=C2=A0 =C2=A0 </span><span style=3D"color:rgb(0,0,136)">int</span><span sty=
le=3D"color:rgb(0,0,0)"> m_private</span><span style=3D"color:rgb(102,102,0=
)">;</span><span style=3D"color:rgb(0,0,0)"><br></span><span style=3D"color=
:rgb(102,102,0)">};</span><span style=3D"color:rgb(0,0,0)"><br>


<br></span><span style=3D"color:rgb(0,0,136)">void</span><span style=3D"col=
or:rgb(0,0,0)"> setPrivate</span><span style=3D"color:rgb(102,102,0)">(</sp=
an><span style=3D"color:rgb(102,0,102)">Foo</span><span style=3D"color:rgb(=
102,102,0)">*</span><span style=3D"color:rgb(0,0,0)"> foo</span><span style=
=3D"color:rgb(102,102,0)">,</span><span style=3D"color:rgb(0,0,0)"> </span>=
<span style=3D"color:rgb(0,0,136)">int</span><span style=3D"color:rgb(0,0,0=
)"> v</span><span style=3D"color:rgb(102,102,0)">)</span><span style=3D"col=
or:rgb(0,0,0)"> </span><span style=3D"color:rgb(102,102,0)">{</span><span s=
tyle=3D"color:rgb(0,0,0)"><br>


=C2=A0 =C2=A0 </span><span style=3D"color:rgb(102,102,0)">((</span><span st=
yle=3D"color:rgb(102,0,102)">Bar</span><span style=3D"color:rgb(102,102,0)"=
>*)</span><span style=3D"color:rgb(0,0,0)">foo</span><span style=3D"color:r=
gb(102,102,0)">)-&gt;</span><span style=3D"color:rgb(0,0,0)">m_private </sp=
an><span style=3D"color:rgb(102,102,0)">=3D</span><span style=3D"color:rgb(=
0,0,0)"> v</span><span style=3D"color:rgb(102,102,0)">;</span><span style=
=3D"color:rgb(0,0,0)"><br>


</span><span style=3D"color:rgb(102,102,0)">}</span><span style=3D"color:rg=
b(0,0,0)"><br></span></div></code></div><br></div></div></blockquote><div><=
br></div></div></div></div><div class=3D"gmail_extra"><div class=3D"gmail_q=
uote">
<div dir=3D"ltr"><div>And you are asserting that is a legal, standards conf=
orming C++ program?? =C2=A0Anything that generates undefined behavior is by=
 definition not guaranteed to generate the code you think it will generate.=
</div>
</div></div></div></blockquote><div><br></div><div>It is totally possible t=
o access arbitrary private members using only standards-conforming means:=
=C2=A0<a href=3D"http://bloglitb.blogspot.de/2010/07/access-to-private-memb=
ers-thats-easy.html">http://bloglitb.blogspot.de/2010/07/access-to-private-=
members-thats-easy.html</a></div>
<div>Quoting Herb Sutter, access control is to protect yourself against Mur=
phy, not Machiavelli. A reflection library should (optionally) allow access=
 to private members. As described this is no further breakage of accessibil=
ity specifiers (which are enforced only in straightforward cases), and it i=
s common in other languages. Any restriction would be purely artificial and=
 would restrict the usefulness of a general-purpose reflection library.</di=
v>

<p></p>

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

--047d7bd76fa65655c804fa887f60--

.

------=_Part_68_15325213.1401368703031
Content-Type: text/plain; charset=UTF-8

To re-center the debate around my original post, I think lambda-generated
classes have to be treated differently compared to user-defined classes.

While I don't follow SG7 closely, allowing reflection to access private
members seems logical, as long as it doesn't provide an obvious way to
completely disregard visibility qualifiers in basic design. However this
debate is different from the case exposed here originally, and has probably
been discussed extensively in the SG7.

If possible I would like to come back to lambda functions. The class they
generate is intentionally not well defined in the standard (by-ref entities
could be members or not), and the entire design is really focused around
making the generated class opaque (by obfuscation, which is enough without
reflection), probably to express the local reasoning I talked about in my
original post.

I realized shortly after posting the first message, and I think this is
what Ville pointed out as well, that adding a visibility keyword is
probably not going to be enough, I think reflection all together should not
be applied to generated Closure types, or should at least be treated as a
very special case of reflection.

Do you think reflection should be allowed on closure types? Is there any
use-case for it? Serialization comes to mind, but I think it could only
apply to by-copy entities, and it would require adding clauses to the
standard to order by-copy members before by-ref, and reflection should only
be able to access those. As I said earlier, the by-copy entities should
have a restrained visibility, and that should be taken into account by the
reflection mechanism to prevent users to modify by-copy entities unless
they jump through a few hoops to clearly state their intent.

--

---
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_68_15325213.1401368703031
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">To re-center the debate around my original post, I think l=
ambda-generated classes have to be treated differently compared to user-def=
ined classes.<div><br></div><div>While I don't follow SG7 closely, allowing=
 reflection to access private members seems logical, as long as it doesn't =
provide an obvious way to completely disregard visibility qualifiers in bas=
ic design. However this debate is different from the case exposed here orig=
inally, and has probably been discussed extensively in the SG7.</div><div><=
br></div><div>If possible I would like to come back to lambda functions. Th=
e class they generate is intentionally not well defined in the standard (by=
-ref entities could be members or not), and the entire design is really foc=
used around making the generated class opaque (by obfuscation, which is eno=
ugh without reflection), probably to express the local reasoning I talked a=
bout in my original post.</div><div><br></div><div>I realized shortly after=
 posting the first message, and I think this is what Ville pointed out as w=
ell, that adding a visibility keyword is probably not going to be enough, I=
 think reflection all together should not be applied to generated Closure t=
ypes, or should at least be treated as a very special case of reflection.</=
div><div><br></div><div>Do you think reflection should be allowed on closur=
e types? Is there any use-case for it? Serialization comes to mind, but I t=
hink it could only apply to by-copy entities, and it would require adding c=
lauses to the standard to order by-copy members before by-ref, and reflecti=
on should only be able to access those. As I said earlier, the by-copy enti=
ties should have a restrained visibility, and that should be taken into acc=
ount by the reflection mechanism to prevent users to modify by-copy entitie=
s unless they jump through a few hoops to clearly state their intent.</div>=
</div>

<p></p>

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

------=_Part_68_15325213.1401368703031--

.

------=_Part_3089_30387345.1401379965128
Content-Type: text/plain; charset=UTF-8

It's not hugely different from any other class whose implementation details
are not specified. One possibility is to allow reflection of the generated
struct directly, but also consider it a special case. Relying on a
particular implementation specific layout for the struct would not be
portable, but the implementation could provide methods implemented using
the lower-level reflection functionality to access the struct in a portable
way. This higher level interface would expose the bound variables exactly
as they are seen in the capture list, regardless of how the compiler chose
to actually implement them.

On Thursday, 29 May 2014 14:05:03 UTC+1, Thibaut Lutz wrote:
>
> To re-center the debate around my original post, I think lambda-generated
> classes have to be treated differently compared to user-defined classes.
>
> While I don't follow SG7 closely, allowing reflection to access private
> members seems logical, as long as it doesn't provide an obvious way to
> completely disregard visibility qualifiers in basic design. However this
> debate is different from the case exposed here originally, and has probably
> been discussed extensively in the SG7.
>
> If possible I would like to come back to lambda functions. The class they
> generate is intentionally not well defined in the standard (by-ref entities
> could be members or not), and the entire design is really focused around
> making the generated class opaque (by obfuscation, which is enough without
> reflection), probably to express the local reasoning I talked about in my
> original post.
>
> I realized shortly after posting the first message, and I think this is
> what Ville pointed out as well, that adding a visibility keyword is
> probably not going to be enough, I think reflection all together should not
> be applied to generated Closure types, or should at least be treated as a
> very special case of reflection.
>
> Do you think reflection should be allowed on closure types? Is there any
> use-case for it? Serialization comes to mind, but I think it could only
> apply to by-copy entities, and it would require adding clauses to the
> standard to order by-copy members before by-ref, and reflection should only
> be able to access those. As I said earlier, the by-copy entities should
> have a restrained visibility, and that should be taken into account by the
> reflection mechanism to prevent users to modify by-copy entities unless
> they jump through a few hoops to clearly state their intent.
>

--

---
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_3089_30387345.1401379965128
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">It's not hugely different from any other class whose imple=
mentation details are not specified. One possibility is to allow reflection=
 of the generated struct directly, but also consider it a special case. Rel=
ying on a particular implementation specific layout for the struct would no=
t be portable, but the implementation could provide methods implemented usi=
ng the lower-level reflection functionality to access the struct in a porta=
ble way. This higher level interface would expose the bound variables exact=
ly as they are seen in the capture list, regardless of how the compiler cho=
se to actually implement them.<br><br>On Thursday, 29 May 2014 14:05:03 UTC=
+1, Thibaut Lutz  wrote:<blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div d=
ir=3D"ltr">To re-center the debate around my original post, I think lambda-=
generated classes have to be treated differently compared to user-defined c=
lasses.<div><br></div><div>While I don't follow SG7 closely, allowing refle=
ction to access private members seems logical, as long as it doesn't provid=
e an obvious way to completely disregard visibility qualifiers in basic des=
ign. However this debate is different from the case exposed here originally=
, and has probably been discussed extensively in the SG7.</div><div><br></d=
iv><div>If possible I would like to come back to lambda functions. The clas=
s they generate is intentionally not well defined in the standard (by-ref e=
ntities could be members or not), and the entire design is really focused a=
round making the generated class opaque (by obfuscation, which is enough wi=
thout reflection), probably to express the local reasoning I talked about i=
n my original post.</div><div><br></div><div>I realized shortly after posti=
ng the first message, and I think this is what Ville pointed out as well, t=
hat adding a visibility keyword is probably not going to be enough, I think=
 reflection all together should not be applied to generated Closure types, =
or should at least be treated as a very special case of reflection.</div><d=
iv><br></div><div>Do you think reflection should be allowed on closure type=
s? Is there any use-case for it? Serialization comes to mind, but I think i=
t could only apply to by-copy entities, and it would require adding clauses=
 to the standard to order by-copy members before by-ref, and reflection sho=
uld only be able to access those. As I said earlier, the by-copy entities s=
hould have a restrained visibility, and that should be taken into account b=
y the reflection mechanism to prevent users to modify by-copy entities unle=
ss they jump through a few hoops to clearly state their intent.</div></div>=
</blockquote></div>

<p></p>

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

------=_Part_3089_30387345.1401379965128--

.

------=_Part_269_11640035.1401381474558
Content-Type: text/plain; charset=UTF-8


>
> This higher level interface would expose the bound variables exactly as
> they are seen in the capture list, regardless of how the compiler chose to
> actually implement them.
>

That would force by-ref entities to be represented as members as well,
otherwise it would not be portable (some reflection code could modify those
while other can't).

I think it is a bit different from any other class, because while the other
classes are "not specified" (the guts are considered implementation
detail), closure members are explicitly obfuscated. There is probably a
good reason for that, otherwise it would be much simpler to keep the same
identifiers in the lambda body and the closure function 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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_269_11640035.1401381474558
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">This higher level interface would expose the bound variables exactly as=
 they are seen in the capture list, regardless of how the compiler chose to=
 actually implement them.<br></div></blockquote><div><br></div><div>That wo=
uld force by-ref entities to be represented as members as well, otherwise i=
t would not be portable (some reflection code could modify those while othe=
r can't).</div><div><br></div><div>I think it is a bit different from any o=
ther class, because while the other classes are "not specified" (the guts a=
re considered implementation detail), closure members are explicitly obfusc=
ated. There is probably a good reason for that, otherwise it would be much =
simpler to keep the same identifiers in the lambda body and the closure fun=
ction operator.</div></div>

<p></p>

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

------=_Part_269_11640035.1401381474558--

.

------=_Part_3023_2663012.1401382036443
Content-Type: text/plain; charset=UTF-8

No, that's my point, it doesn't require by-ref entities to be members, all
it requires is that the implementation provide the ability to enumerate and
access them, and this it can do regardless of whether it stores them as
members or just keeps a stack pointer.

On Thursday, 29 May 2014 17:37:54 UTC+1, Thibaut Lutz wrote:
>
> This higher level interface would expose the bound variables exactly as
>> they are seen in the capture list, regardless of how the compiler chose to
>> actually implement them.
>>
>
> That would force by-ref entities to be represented as members as well,
> otherwise it would not be portable (some reflection code could modify those
> while other can't).
>
> I think it is a bit different from any other class, because while the
> other classes are "not specified" (the guts are considered implementation
> detail), closure members are explicitly obfuscated. There is probably a
> good reason for that, otherwise it would be much simpler to keep the same
> identifiers in the lambda body and the closure function 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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_3023_2663012.1401382036443
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">No, that's my point, it doesn't require by-ref entities to=
 be members, all it requires is that the implementation provide the ability=
 to enumerate and access them, and this it can do regardless of whether it =
stores them as members or just keeps a stack pointer.<br><br>On Thursday, 2=
9 May 2014 17:37:54 UTC+1, Thibaut Lutz  wrote:<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"><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">This higher level interface would expose the bound variab=
les exactly as they are seen in the capture list, regardless of how the com=
piler chose to actually implement them.<br></div></blockquote><div><br></di=
v><div>That would force by-ref entities to be represented as members as wel=
l, otherwise it would not be portable (some reflection code could modify th=
ose while other can't).</div><div><br></div><div>I think it is a bit differ=
ent from any other class, because while the other classes are "not specifie=
d" (the guts are considered implementation detail), closure members are exp=
licitly obfuscated. There is probably a good reason for that, otherwise it =
would be much simpler to keep the same identifiers in the lambda body and t=
he closure function operator.</div></div></blockquote></div>

<p></p>

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

------=_Part_3023_2663012.1401382036443--

.

--047d7bd760c24fc39304fa8cb111
Content-Type: text/plain; charset=UTF-8

It's a good point.  Lambdas are of a distinct class type that doesnt have a
class specifier in the translation unit.  What reflection does with these
lambda types is unspecified at the moment (or even arguably defectively
specified), and I guess it should be.  We have a term defined in the
wording called a "reflectible class type".  For forward-compatibility it
creates some initial restrictions on the kinds of members that a class can
have in order to be compatible with reflection (notably reference members
and bit fields).  I would be tempted to initially exclude the types of
lambdas from this category called reflectible class types.  This would
allow us to standardize a lambda class specifier layout later if one is so
desired.

Concretely, that would mean that initially the observed behaviour is as
follows:

auto a = [&x](int y, float z) { ... };

using A = decltype(a);

static_assert(std::is_reflectible_class_v<A>, ""); // ERROR: assert failed

size_t n = class_member_list_size_v<A>; // ERROR: `A` is not a reflectible
class type.

Regards,
Andrew.




On Thu, May 29, 2014 at 3:05 PM, Thibaut Lutz <thibaut.lutz@googlemail.com>
wrote:

> To re-center the debate around my original post, I think lambda-generated
> classes have to be treated differently compared to user-defined classes.
>
> While I don't follow SG7 closely, allowing reflection to access private
> members seems logical, as long as it doesn't provide an obvious way to
> completely disregard visibility qualifiers in basic design. However this
> debate is different from the case exposed here originally, and has probably
> been discussed extensively in the SG7.
>
> If possible I would like to come back to lambda functions. The class they
> generate is intentionally not well defined in the standard (by-ref entities
> could be members or not), and the entire design is really focused around
> making the generated class opaque (by obfuscation, which is enough without
> reflection), probably to express the local reasoning I talked about in my
> original post.
>
> I realized shortly after posting the first message, and I think this is
> what Ville pointed out as well, that adding a visibility keyword is
> probably not going to be enough, I think reflection all together should not
> be applied to generated Closure types, or should at least be treated as a
> very special case of reflection.
>
> Do you think reflection should be allowed on closure types? Is there any
> use-case for it? Serialization comes to mind, but I think it could only
> apply to by-copy entities, and it would require adding clauses to the
> standard to order by-copy members before by-ref, and reflection should only
> be able to access those. As I said earlier, the by-copy entities should
> have a restrained visibility, and that should be taken into account by the
> reflection mechanism to prevent users to modify by-copy entities unless
> they jump through a few hoops to clearly state their intent.
>
> --
>
> ---
> 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/.
>

--

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

--047d7bd760c24fc39304fa8cb111
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">It&#39;s a good point. =C2=A0Lambdas are of a distinct cla=
ss type that doesnt have a class specifier in the translation unit. =C2=A0W=
hat reflection does with these lambda types is unspecified at the moment (o=
r even arguably defectively specified), and I guess it should be. =C2=A0We =
have a term defined in the wording called a &quot;reflectible class type&qu=
ot;. =C2=A0For forward-compatibility it creates some initial restrictions o=
n the kinds of members that a class can have in order to be compatible with=
 reflection (notably reference members and bit fields). =C2=A0I would be te=
mpted to initially exclude the types of lambdas from this category called r=
eflectible class types. =C2=A0This would allow us to standardize a lambda c=
lass specifier layout later if one is so desired.<div>
<br></div><div>Concretely, that would mean that initially the observed beha=
viour is as follows:</div><div><br></div><div>auto a =3D [&amp;x](int y, fl=
oat z) { ... };</div><div><br></div><div>using A =3D decltype(a);</div><div=
>
<br></div><div>static_assert(std::is_reflectible_class_v&lt;A&gt;, &quot;&q=
uot;); // ERROR: assert failed</div><div><br></div><div>size_t n =3D class_=
member_list_size_v&lt;A&gt;; // ERROR: `A` is not a reflectible class type.=
</div>
<div><br></div><div>Regards,</div><div>Andrew.</div><div><br></div><div><br=
></div></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">=
On Thu, May 29, 2014 at 3:05 PM, Thibaut Lutz <span dir=3D"ltr">&lt;<a href=
=3D"mailto:thibaut.lutz@googlemail.com" target=3D"_blank">thibaut.lutz@goog=
lemail.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 dir=3D"ltr">To re-center the debate aro=
und my original post, I think lambda-generated classes have to be treated d=
ifferently compared to user-defined classes.<div>
<br></div><div>While I don&#39;t follow SG7 closely, allowing reflection to=
 access private members seems logical, as long as it doesn&#39;t provide an=
 obvious way to completely disregard visibility qualifiers in basic design.=
 However this debate is different from the case exposed here originally, an=
d has probably been discussed extensively in the SG7.</div>
<div><br></div><div>If possible I would like to come back to lambda functio=
ns. The class they generate is intentionally not well defined in the standa=
rd (by-ref entities could be members or not), and the entire design is real=
ly focused around making the generated class opaque (by obfuscation, which =
is enough without reflection), probably to express the local reasoning I ta=
lked about in my original post.</div>
<div><br></div><div>I realized shortly after posting the first message, and=
 I think this is what Ville pointed out as well, that adding a visibility k=
eyword is probably not going to be enough, I think reflection all together =
should not be applied to generated Closure types, or should at least be tre=
ated as a very special case of reflection.</div>
<div><br></div><div>Do you think reflection should be allowed on closure ty=
pes? Is there any use-case for it? Serialization comes to mind, but I think=
 it could only apply to by-copy entities, and it would require adding claus=
es to the standard to order by-copy members before by-ref, and reflection s=
hould only be able to access those. As I said earlier, the by-copy entities=
 should have a restrained visibility, and that should be taken into account=
 by the reflection mechanism to prevent users to modify by-copy entities un=
less they jump through a few hoops to clearly state their intent.</div>
</div><div class=3D"HOEnZb"><div class=3D"h5">

<p></p>

-- <br>
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

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

--047d7bd760c24fc39304fa8cb111--

.

------=_Part_849_19967130.1401383621120
Content-Type: text/plain; charset=UTF-8

@Diggory: I would not call the code portable if the number of members in
the enumeration depends entirely on the compiler. Besides, since the names
are obfuscated, the members would have to be accessed by index, in which
case one could not distinguish between by-copy and by-ref members. I am not
saying we definitely should or should not allow reflection on closure
types, but it is definitely a lot trickier than plain classes, and we
should think about it for the design of reflection.

@Andrew: forbidding reflection on closure types at least for the first
version of reflection seems like a good idea to me. This would allow us to
see what people use reflection for and if the use case for reflection on
lambda functions even arises. Could you point a document number for this
proposal so I can propose a patch to exclude closure types explicitly?

--

---
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_849_19967130.1401383621120
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">@Diggory: I would not call the code portable if the number=
 of members in the enumeration depends entirely on the compiler. Besides, s=
ince the names are obfuscated, the members would have to be accessed by ind=
ex, in which case one could not distinguish between by-copy and by-ref memb=
ers. I am not saying we definitely should or should not allow reflection on=
 closure types, but it is definitely a lot trickier than plain classes, and=
 we should think about it for the design of reflection.<div><br></div><div>=
@Andrew: forbidding reflection on closure types at least for the first vers=
ion of reflection seems like a good idea to me. This would allow us to see =
what people use reflection for and if the use case for reflection on lambda=
 functions even arises. Could you point a document number for this proposal=
 so I can propose a patch to exclude closure types explicitly?</div></div>

<p></p>

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

------=_Part_849_19967130.1401383621120--

.

--089e01182e484af45704fa8d3ab6
Content-Type: text/plain; charset=UTF-8

N4027


On Thu, May 29, 2014 at 7:13 PM, Thibaut Lutz <thibaut.lutz@googlemail.com>
wrote:

> @Diggory: I would not call the code portable if the number of members in
> the enumeration depends entirely on the compiler. Besides, since the names
> are obfuscated, the members would have to be accessed by index, in which
> case one could not distinguish between by-copy and by-ref members. I am not
> saying we definitely should or should not allow reflection on closure
> types, but it is definitely a lot trickier than plain classes, and we
> should think about it for the design of reflection.
>
> @Andrew: forbidding reflection on closure types at least for the first
> version of reflection seems like a good idea to me. This would allow us to
> see what people use reflection for and if the use case for reflection on
> lambda functions even arises. Could you point a document number for this
> proposal so I can propose a patch to exclude closure types explicitly?
>
> --
>
> ---
> 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/.
>

--

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

--089e01182e484af45704fa8d3ab6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">N4027</div><div class=3D"gmail_extra"><br><br><div class=
=3D"gmail_quote">On Thu, May 29, 2014 at 7:13 PM, Thibaut Lutz <span dir=3D=
"ltr">&lt;<a href=3D"mailto:thibaut.lutz@googlemail.com" target=3D"_blank">=
thibaut.lutz@googlemail.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 dir=3D"ltr">@Diggory: I would not call =
the code portable if the number of members in the enumeration depends entir=
ely on the compiler. Besides, since the names are obfuscated, the members w=
ould have to be accessed by index, in which case one could not distinguish =
between by-copy and by-ref members. I am not saying we definitely should or=
 should not allow reflection on closure types, but it is definitely a lot t=
rickier than plain classes, and we should think about it for the design of =
reflection.<div>
<br></div><div>@Andrew: forbidding reflection on closure types at least for=
 the first version of reflection seems like a good idea to me. This would a=
llow us to see what people use reflection for and if the use case for refle=
ction on lambda functions even arises. Could you point a document number fo=
r this proposal so I can propose a patch to exclude closure types explicitl=
y?</div>
</div><div class=3D"HOEnZb"><div class=3D"h5">

<p></p>

-- <br>
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

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

--089e01182e484af45704fa8d3ab6--

.

------=_Part_411_348083.1401384719584
Content-Type: text/plain; charset=UTF-8

No, the higher level interface I'm talking about would be exactly the same
for the same lambda across all compilers, it would expose the capture list,
for example:

auto f = [&a, b]() {};

Using this higher level interface on 'f' would tell you that there are two
captures, 'a', and 'b', and that 'a' is captured by reference. It would not
tell you exactly how those are represented in the lambda object, but it
might provide methods to get/set them given an instance of the lambda.

The normal reflection interface would expose the inner workings of the
lambda if you asked it to show private members just as it would any other
struct.


On Thursday, 29 May 2014 18:13:41 UTC+1, Thibaut Lutz wrote:
>
> @Diggory: I would not call the code portable if the number of members in
> the enumeration depends entirely on the compiler. Besides, since the names
> are obfuscated, the members would have to be accessed by index, in which
> case one could not distinguish between by-copy and by-ref members. I am not
> saying we definitely should or should not allow reflection on closure
> types, but it is definitely a lot trickier than plain classes, and we
> should think about it for the design of reflection.
>
> @Andrew: forbidding reflection on closure types at least for the first
> version of reflection seems like a good idea to me. This would allow us to
> see what people use reflection for and if the use case for reflection on
> lambda functions even arises. Could you point a document number for this
> proposal so I can propose a patch to exclude closure types explicitly?
>

--

---
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_411_348083.1401384719584
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">No, the higher level interface I'm talking about would be =
exactly the same for the same lambda across all compilers, it would expose =
the capture list, for example:<br><br>auto f =3D [&amp;a, b]() {};<br><br>U=
sing this higher level interface on 'f' would tell you that there are two c=
aptures, 'a', and 'b', and that 'a' is captured by reference. It would not =
tell you exactly how those are represented in the lambda object, but it mig=
ht provide methods to get/set them given an instance of the lambda.<br><br>=
The normal reflection interface would expose the inner workings of the lamb=
da if you asked it to show private members just as it would any other struc=
t.<br><br><br>On Thursday, 29 May 2014 18:13:41 UTC+1, Thibaut Lutz  wrote:=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">@Diggory: I w=
ould not call the code portable if the number of members in the enumeration=
 depends entirely on the compiler. Besides, since the names are obfuscated,=
 the members would have to be accessed by index, in which case one could no=
t distinguish between by-copy and by-ref members. I am not saying we defini=
tely should or should not allow reflection on closure types, but it is defi=
nitely a lot trickier than plain classes, and we should think about it for =
the design of reflection.<div><br></div><div>@Andrew: forbidding reflection=
 on closure types at least for the first version of reflection seems like a=
 good idea to me. This would allow us to see what people use reflection for=
 and if the use case for reflection on lambda functions even arises. Could =
you point a document number for this proposal so I can propose a patch to e=
xclude closure types explicitly?</div></div></blockquote></div>

<p></p>

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

------=_Part_411_348083.1401384719584--

.

------=_Part_9_7570057.1401386162351
Content-Type: text/plain; charset=UTF-8

But the by-ref captures might not be stored anywhere (by that I mean
anywhere specific to the lambda instance). In this case, how would you
express a change in the reference (not the referee) done using reflection
in the compiler-generated code?
This would anyway be an interface very specific to closure types, which
goes with what Andrew was saying, we can always roll that in later if
needed. As for normal reflection, I think for now saying that a closure
type cannot be used for reflection is the right way to go. I have a feeling
that it might be the case for all anonymous types, but I haven't read the
proposal yet, I don;t know what they say about that.

On Thursday, May 29, 2014 6:31:59 PM UTC+1, Diggory Blake wrote:
>
> No, the higher level interface I'm talking about would be exactly the same
> for the same lambda across all compilers, it would expose the capture list,
> for example:
>
> auto f = [&a, b]() {};
>
> Using this higher level interface on 'f' would tell you that there are two
> captures, 'a', and 'b', and that 'a' is captured by reference. It would not
> tell you exactly how those are represented in the lambda object, but it
> might provide methods to get/set them given an instance of the lambda.
>
> The normal reflection interface would expose the inner workings of the
> lambda if you asked it to show private members just as it would any other
> struct.
>
>
> On Thursday, 29 May 2014 18:13:41 UTC+1, Thibaut Lutz wrote:
>>
>> @Diggory: I would not call the code portable if the number of members in
>> the enumeration depends entirely on the compiler. Besides, since the names
>> are obfuscated, the members would have to be accessed by index, in which
>> case one could not distinguish between by-copy and by-ref members. I am not
>> saying we definitely should or should not allow reflection on closure
>> types, but it is definitely a lot trickier than plain classes, and we
>> should think about it for the design of reflection.
>>
>> @Andrew: forbidding reflection on closure types at least for the first
>> version of reflection seems like a good idea to me. This would allow us to
>> see what people use reflection for and if the use case for reflection on
>> lambda functions even arises. Could you point a document number for this
>> proposal so I can propose a patch to exclude closure types explicitly?
>>
>

--

---
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_9_7570057.1401386162351
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">But the by-ref captures might not be stored anywhere (by t=
hat I mean anywhere specific to the lambda instance). In this case, how wou=
ld you express a change in the reference (not the referee) done using refle=
ction in the compiler-generated code?&nbsp;<div>This would anyway be an int=
erface very specific to closure types, which goes with what Andrew was sayi=
ng, we can always roll that in later if needed. As for normal reflection, I=
 think for now saying that a closure type cannot be used for reflection is =
the right way to go. I have a feeling that it might be the case for all ano=
nymous types, but I haven't read the proposal yet, I don;t know what they s=
ay about that.<br><br>On Thursday, May 29, 2014 6:31:59 PM UTC+1, Diggory B=
lake 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=
, the higher level interface I'm talking about would be exactly the same fo=
r the same lambda across all compilers, it would expose the capture list, f=
or example:<br><br>auto f =3D [&amp;a, b]() {};<br><br>Using this higher le=
vel interface on 'f' would tell you that there are two captures, 'a', and '=
b', and that 'a' is captured by reference. It would not tell you exactly ho=
w those are represented in the lambda object, but it might provide methods =
to get/set them given an instance of the lambda.<br><br>The normal reflecti=
on interface would expose the inner workings of the lambda if you asked it =
to show private members just as it would any other struct.<br><br><br>On Th=
ursday, 29 May 2014 18:13:41 UTC+1, Thibaut Lutz  wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr">@Diggory: I would not call the code=
 portable if the number of members in the enumeration depends entirely on t=
he compiler. Besides, since the names are obfuscated, the members would hav=
e to be accessed by index, in which case one could not distinguish between =
by-copy and by-ref members. I am not saying we definitely should or should =
not allow reflection on closure types, but it is definitely a lot trickier =
than plain classes, and we should think about it for the design of reflecti=
on.<div><br></div><div>@Andrew: forbidding reflection on closure types at l=
east for the first version of reflection seems like a good idea to me. This=
 would allow us to see what people use reflection for and if the use case f=
or reflection on lambda functions even arises. Could you point a document n=
umber for this proposal so I can propose a patch to exclude closure types e=
xplicitly?</div></div></blockquote></div></blockquote></div></div>

<p></p>

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

------=_Part_9_7570057.1401386162351--

.

------=_Part_286_10544835.1401388567744
Content-Type: text/plain; charset=UTF-8

First, I completely agree that this is something that can be added later.

"how would you express a change in the reference (not the referee) done
using reflection in the compiler-generated code"
C++ has no concept of a change in reference, I wasn't suggesting adding the
ability to do that, only the ability to access the referee.

"I think for now saying that a closure type cannot be used for reflection
is the right way to go."
Perhaps, although there are still use cases such as for garbage collection
where the only thing that matters is that the reflected layout matches the
actual layout, and there's no need for that layout to be consistent across
compilers.

On Thursday, 29 May 2014 18:56:02 UTC+1, Thibaut Lutz wrote:
>
> But the by-ref captures might not be stored anywhere (by that I mean
> anywhere specific to the lambda instance). In this case, how would you
> express a change in the reference (not the referee) done using reflection
> in the compiler-generated code?
> This would anyway be an interface very specific to closure types, which
> goes with what Andrew was saying, we can always roll that in later if
> needed. As for normal reflection, I think for now saying that a closure
> type cannot be used for reflection is the right way to go. I have a feeling
> that it might be the case for all anonymous types, but I haven't read the
> proposal yet, I don;t know what they say about that.
>
> On Thursday, May 29, 2014 6:31:59 PM UTC+1, Diggory Blake wrote:
>>
>> No, the higher level interface I'm talking about would be exactly the
>> same for the same lambda across all compilers, it would expose the capture
>> list, for example:
>>
>> auto f = [&a, b]() {};
>>
>> Using this higher level interface on 'f' would tell you that there are
>> two captures, 'a', and 'b', and that 'a' is captured by reference. It would
>> not tell you exactly how those are represented in the lambda object, but it
>> might provide methods to get/set them given an instance of the lambda.
>>
>> The normal reflection interface would expose the inner workings of the
>> lambda if you asked it to show private members just as it would any other
>> struct.
>>
>>
>> On Thursday, 29 May 2014 18:13:41 UTC+1, Thibaut Lutz wrote:
>>>
>>> @Diggory: I would not call the code portable if the number of members in
>>> the enumeration depends entirely on the compiler. Besides, since the names
>>> are obfuscated, the members would have to be accessed by index, in which
>>> case one could not distinguish between by-copy and by-ref members. I am not
>>> saying we definitely should or should not allow reflection on closure
>>> types, but it is definitely a lot trickier than plain classes, and we
>>> should think about it for the design of reflection.
>>>
>>> @Andrew: forbidding reflection on closure types at least for the first
>>> version of reflection seems like a good idea to me. This would allow us to
>>> see what people use reflection for and if the use case for reflection on
>>> lambda functions even arises. Could you point a document number for this
>>> proposal so I can propose a patch to exclude closure types explicitly?
>>>
>>

--

---
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_286_10544835.1401388567744
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">First, I completely agree that this is something that can =
be added later.<br><br>"how would you express a change in the reference (no=
t the referee) done using reflection in the compiler-generated code"<br>C++=
 has no concept of a change in reference, I wasn't suggesting adding the ab=
ility to do that, only the ability to access the referee.<br><br>"I think f=
or now saying that a closure type cannot be used for reflection is the righ=
t way to go."<br>Perhaps, although there are still use cases such as for ga=
rbage collection where the only thing that matters is that the reflected la=
yout matches the actual layout, and there's no need for that layout to be c=
onsistent across compilers.<br><br>On Thursday, 29 May 2014 18:56:02 UTC+1,=
 Thibaut Lutz  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">But the by-ref captures might not be stored anywhere (by that I me=
an anywhere specific to the lambda instance). In this case, how would you e=
xpress a change in the reference (not the referee) done using reflection in=
 the compiler-generated code?&nbsp;<div>This would anyway be an interface v=
ery specific to closure types, which goes with what Andrew was saying, we c=
an always roll that in later if needed. As for normal reflection, I think f=
or now saying that a closure type cannot be used for reflection is the righ=
t way to go. I have a feeling that it might be the case for all anonymous t=
ypes, but I haven't read the proposal yet, I don;t know what they say about=
 that.<br><br>On Thursday, May 29, 2014 6:31:59 PM UTC+1, Diggory Blake wro=
te:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">No, the higher =
level interface I'm talking about would be exactly the same for the same la=
mbda across all compilers, it would expose the capture list, for example:<b=
r><br>auto f =3D [&amp;a, b]() {};<br><br>Using this higher level interface=
 on 'f' would tell you that there are two captures, 'a', and 'b', and that =
'a' is captured by reference. It would not tell you exactly how those are r=
epresented in the lambda object, but it might provide methods to get/set th=
em given an instance of the lambda.<br><br>The normal reflection interface =
would expose the inner workings of the lambda if you asked it to show priva=
te members just as it would any other struct.<br><br><br>On Thursday, 29 Ma=
y 2014 18:13:41 UTC+1, Thibaut Lutz  wrote:<blockquote class=3D"gmail_quote=
" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><div dir=3D"ltr">@Diggory: I would not call the code portable if th=
e number of members in the enumeration depends entirely on the compiler. Be=
sides, since the names are obfuscated, the members would have to be accesse=
d by index, in which case one could not distinguish between by-copy and by-=
ref members. I am not saying we definitely should or should not allow refle=
ction on closure types, but it is definitely a lot trickier than plain clas=
ses, and we should think about it for the design of reflection.<div><br></d=
iv><div>@Andrew: forbidding reflection on closure types at least for the fi=
rst version of reflection seems like a good idea to me. This would allow us=
 to see what people use reflection for and if the use case for reflection o=
n lambda functions even arises. Could you point a document number for this =
proposal so I can propose a patch to exclude closure types explicitly?</div=
></div></blockquote></div></blockquote></div></div></blockquote></div>

<p></p>

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

------=_Part_286_10544835.1401388567744--

.

------=_Part_13_14133256.1401407687025
Content-Type: text/plain; charset=UTF-8

By a change in the reference I meant creating a new one (by invoking the
constructor of the closure through reflection).

At least we seem to all agree that there needs to be more work on closure
types for reflection and it is not a trivial problem.

I will write a proposal to add this to N4027 over the weekend (for now we
just need to explicitly exclude closure types as suggested by Andrew).

I will think about the impact of reflection a bit longer and open a new
thread in the SG7 forum where we can study this a bit more in depth and
formalize our findings. I'll link the post here to conclude this thread
once it is done.

Thank you all for your input.

--

---
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_13_14133256.1401407687025
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">By a change in the reference I meant creating a new one (b=
y invoking the constructor of the closure through reflection).<div><br></di=
v><div>At least we seem to all agree that there needs to be more work on cl=
osure types for reflection and it is not a trivial problem.&nbsp;</div><div=
><br></div><div>I will write a proposal to add this to N4027 over the weeke=
nd (for now we just need to explicitly exclude closure types as suggested b=
y Andrew).</div><div><br></div><div>I will think about the impact of reflec=
tion a bit longer and open a new thread in the SG7 forum where we can study=
 this a bit more in depth and formalize our findings. I'll link the post he=
re to conclude this thread once it is done.</div><div><br></div><div>Thank =
you all for your input.</div></div>

<p></p>

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

------=_Part_13_14133256.1401407687025--

.

------=_Part_2038_27975861.1401715154851
Content-Type: text/plain; charset=UTF-8

As promised, here is the link to the new thread
<https://groups.google.com/a/isocpp.org/forum/?fromgroups=#!topic/reflection/5IGBjnwTUNA>.
It propose small changes to N3951 and N4027 to include special cases for
closure types.

@Diggory: the new thread contains an example of what I meant by a change in
reference.

On Friday, May 30, 2014 12:54:47 AM UTC+1, Thibaut Lutz wrote:
>
> By a change in the reference I meant creating a new one (by invoking the
> constructor of the closure through reflection).
>
> At least we seem to all agree that there needs to be more work on closure
> types for reflection and it is not a trivial problem.
>
> I will write a proposal to add this to N4027 over the weekend (for now we
> just need to explicitly exclude closure types as suggested by Andrew).
>
> I will think about the impact of reflection a bit longer and open a new
> thread in the SG7 forum where we can study this a bit more in depth and
> formalize our findings. I'll link the post here to conclude this thread
> once it is done.
>
> Thank you all for your input.
>

--

---
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_2038_27975861.1401715154851
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">As promised, here is the link to the <a href=3D"https://gr=
oups.google.com/a/isocpp.org/forum/?fromgroups=3D#!topic/reflection/5IGBjnw=
TUNA">new thread</a>. It propose small changes to N3951 and N4027 to includ=
e special cases for closure types.<div><br></div><div>@Diggory: the new thr=
ead contains an example of what I meant by a change in reference.<br><br>On=
 Friday, May 30, 2014 12:54:47 AM UTC+1, Thibaut Lutz wrote:<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">By a change in the reference=
 I meant creating a new one (by invoking the constructor of the closure thr=
ough reflection).<div><br></div><div>At least we seem to all agree that the=
re needs to be more work on closure types for reflection and it is not a tr=
ivial problem.&nbsp;</div><div><br></div><div>I will write a proposal to ad=
d this to N4027 over the weekend (for now we just need to explicitly exclud=
e closure types as suggested by Andrew).</div><div><br></div><div>I will th=
ink about the impact of reflection a bit longer and open a new thread in th=
e SG7 forum where we can study this a bit more in depth and formalize our f=
indings. I'll link the post here to conclude this thread once it is done.</=
div><div><br></div><div>Thank you all for your input.</div></div></blockquo=
te></div></div>

<p></p>

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

------=_Part_2038_27975861.1401715154851--

.

------=_Part_316_8637847.1401716740464
Content-Type: text/plain; charset=UTF-8

I can't reply directly to your new thread, but I only have a few comments:
- Any use of the "normal" reflection capabilities with lambdas is not
portable as you said.
- If construction of lambdas is ever allowed through reflection, then it
should create a new type of lambda, constructing an existing type should
only be possible via copy or move, this avoids the problem you mentioned
with references.
- Maybe it's worth at least having a function which just returns the types
and names of captured variables: this would make it possible for a portable
higher level interface to lambdas to be added to the standard library at a
later time without any additional compiler support (the standard library
can 'know' exactly what the layout of a lambda looks like given a capture
list because it can be aware of the inner workings of the compiler).

On Monday, 2 June 2014 14:19:14 UTC+1, Thibaut Lutz wrote:
>
> As promised, here is the link to the new thread
> <https://groups.google.com/a/isocpp.org/forum/?fromgroups=#!topic/reflection/5IGBjnwTUNA>.
> It propose small changes to N3951 and N4027 to include special cases for
> closure types.
>
> @Diggory: the new thread contains an example of what I meant by a change
> in reference.
>
> On Friday, May 30, 2014 12:54:47 AM UTC+1, Thibaut Lutz wrote:
>>
>> By a change in the reference I meant creating a new one (by invoking the
>> constructor of the closure through reflection).
>>
>> At least we seem to all agree that there needs to be more work on closure
>> types for reflection and it is not a trivial problem.
>>
>> I will write a proposal to add this to N4027 over the weekend (for now we
>> just need to explicitly exclude closure types as suggested by Andrew).
>>
>> I will think about the impact of reflection a bit longer and open a new
>> thread in the SG7 forum where we can study this a bit more in depth and
>> formalize our findings. I'll link the post here to conclude this thread
>> once it is done.
>>
>> Thank you all for your input.
>>
>

--

---
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_316_8637847.1401716740464
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I can't reply directly to your new thread, but I only have=
 a few comments:<br>- Any use of the "normal" reflection capabilities with =
lambdas is not portable as you said.<br>- If construction of lambdas is eve=
r allowed through reflection, then it should create a new type of lambda, c=
onstructing an existing type should only be possible via copy or move, this=
 avoids the problem you mentioned with references.<br>- Maybe it's worth at=
 least having a function which just returns the types and names of captured=
 variables: this would make it possible for a portable higher level interfa=
ce to lambdas to be added to the standard library at a later time without a=
ny additional compiler support (the standard library can 'know' exactly wha=
t the layout of a lambda looks like given a capture list because it can be =
aware of the inner workings of the compiler).<br><br>On Monday, 2 June 2014=
 14:19:14 UTC+1, Thibaut Lutz  wrote:<blockquote class=3D"gmail_quote" styl=
e=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left:=
 1ex;"><div dir=3D"ltr">As promised, here is the link to the <a href=3D"htt=
ps://groups.google.com/a/isocpp.org/forum/?fromgroups=3D#!topic/reflection/=
5IGBjnwTUNA" target=3D"_blank" onmousedown=3D"this.href=3D'https://groups.g=
oogle.com/a/isocpp.org/forum/?fromgroups\75#!topic/reflection/5IGBjnwTUNA';=
return true;" onclick=3D"this.href=3D'https://groups.google.com/a/isocpp.or=
g/forum/?fromgroups\75#!topic/reflection/5IGBjnwTUNA';return true;">new thr=
ead</a>. It propose small changes to N3951 and N4027 to include special cas=
es for closure types.<div><br></div><div>@Diggory: the new thread contains =
an example of what I meant by a change in reference.<br><br>On Friday, May =
30, 2014 12:54:47 AM UTC+1, Thibaut Lutz wrote:<blockquote class=3D"gmail_q=
uote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddin=
g-left:1ex"><div dir=3D"ltr">By a change in the reference I meant creating =
a new one (by invoking the constructor of the closure through reflection).<=
div><br></div><div>At least we seem to all agree that there needs to be mor=
e work on closure types for reflection and it is not a trivial problem.&nbs=
p;</div><div><br></div><div>I will write a proposal to add this to N4027 ov=
er the weekend (for now we just need to explicitly exclude closure types as=
 suggested by Andrew).</div><div><br></div><div>I will think about the impa=
ct of reflection a bit longer and open a new thread in the SG7 forum where =
we can study this a bit more in depth and formalize our findings. I'll link=
 the post here to conclude this thread once it is done.</div><div><br></div=
><div>Thank you all for your input.</div></div></blockquote></div></div></b=
lockquote></div>

<p></p>

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

------=_Part_316_8637847.1401716740464--

.

------=_Part_196_14608244.1401719415169
Content-Type: text/plain; charset=UTF-8

Thanks for the comments.

- If construction of lambdas is ever allowed through reflection, then it
> should create a new type of lambda, constructing an existing type should
> only be possible via copy or move, this avoids the problem you mentioned
> with references.
>

This is a bit tricky. A Lambda declaration is implicitly a constructor
call, so the constructor does exist and is accessible. Moreover the type of
the newly created object might be explicitly the same as the lambda's:

  auto test = [](){return 0;};

  using Lambda = decltype(test);

  Lambda closure = std::reflect<Lambda>::construct();


Also, creating new types on the fly introduces transitive oddities:

  auto test = [](){return 0;};

  auto closure = std::reflect<decltype(test)>::construct();

  static_assert<is_same<decltype(test),decltype(closure)>::value>(); // this fails

  test = closure; // this fails



> - Maybe it's worth at least having a function which just returns the types
> and names of captured variables: this would make it possible for a portable
> higher level interface to lambdas to be added to the standard library at a
> later time without any additional compiler support (the standard library
> can 'know' exactly what the layout of a lambda looks like given a capture
> list because it can be aware of the inner workings of the compiler).
>

This might be one possibility, but it looks to me like it would be more of
an extension of the current lambda capabilities rather than a feature of
reflection. Another possibility would be to enforce that identifiers are
the same in the capture list and the closure type, instead of being
unnamed. It would be interesting to know why they decided the members
should be unnamed in the first place, my guess it they don't want them to
be accessible, which is something reflection would expose.

--

---
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_196_14608244.1401719415169
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Thanks for the comments.<div><br><blockquote class=3D"gmai=
l_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;=
padding-left: 1ex;"><div dir=3D"ltr">- If construction of lambdas is ever a=
llowed through reflection, then it should create a new type of lambda, cons=
tructing an existing type should only be possible via copy or move, this av=
oids the problem you mentioned with references.<br></div></blockquote><div>=
<br></div><div>This is a bit tricky. A Lambda declaration is implicitly a c=
onstructor call, so the constructor does exist and is accessible. Moreover =
the type of the newly created object might be explicitly the same as the la=
mbda's:</div><div><pre><pre><!--StartFragment--><span style=3D" color:#c0c0=
c0;">  </span><span style=3D" color:#808000;">auto</span><span style=3D" co=
lor:#c0c0c0;"> </span><span style=3D" color:#000000;">test</span><span styl=
e=3D" color:#c0c0c0;"> </span><span style=3D" color:#000000;">=3D</span><sp=
an style=3D" color:#c0c0c0;"> </span><span style=3D" color:#000000;">[](){<=
/span><span style=3D" color:#808000;">return</span><span style=3D" color:#c=
0c0c0;"> </span><span style=3D" color:#000080;">0</span><span style=3D" col=
or:#000000;">;};</span><!--EndFragment--></pre></pre>
<pre><span style=3D" color:#c0c0c0;">  </span><span style=3D" color:#808000=
;">using</span><span style=3D" color:#c0c0c0;"> </span><span style=3D" colo=
r:#800080;">Lambda</span><span style=3D" color:#c0c0c0;"> </span><span styl=
e=3D" color:#000000;">=3D</span><span style=3D" color:#c0c0c0;"> </span><sp=
an style=3D" color:#808000;">decltype</span><span style=3D" color:#000000;"=
>(</span><span style=3D" color:#000000;">test</span><span style=3D" color:#=
000000;">);</span></pre>
<pre><span style=3D" color:#c0c0c0;">  </span><span style=3D" color:#800080=
;">Lambda</span><span style=3D" color:#c0c0c0;"> </span><span style=3D" col=
or:#000000;">closure</span><span style=3D" color:#c0c0c0;"> </span><span st=
yle=3D" color:#000000;">=3D</span><span style=3D" color:#c0c0c0;"> </span>s=
td<span style=3D" color:#000000;">::</span>reflect<span style=3D" color:#00=
0000;">&lt;</span><span style=3D" color:#800080;">Lambda</span><span style=
=3D" color:#000000;">&gt;::</span>construct<span style=3D" color:#000000;">=
(</span><span style=3D" color:#000000;">);</span><!--EndFragment--></pre></=
div><div><br></div><div>Also, creating new types on the fly introduces tran=
sitive oddities:</div><div>
<pre><!--StartFragment--><span style=3D" color:#c0c0c0;">  </span><span sty=
le=3D" color:#808000;">auto</span><span style=3D" color:#c0c0c0;"> </span><=
span style=3D" color:#000000;">test</span><span style=3D" color:#c0c0c0;"> =
</span><span style=3D" color:#000000;">=3D</span><span style=3D" color:#c0c=
0c0;"> </span><span style=3D" color:#000000;">[](){</span><span style=3D" c=
olor:#808000;">return</span><span style=3D" color:#c0c0c0;"> </span><span s=
tyle=3D" color:#000080;">0</span><span style=3D" color:#000000;">;};</span>=
</pre>
<pre><span style=3D" color:#c0c0c0;">  </span><span style=3D" color:#808000=
;">auto</span><span style=3D" color:#c0c0c0;"> </span><span style=3D" color=
:#000000;">closure</span><span style=3D" color:#c0c0c0;"> </span><span styl=
e=3D" color:#000000;">=3D</span><span style=3D" color:#c0c0c0;"> </span>std=
<span style=3D" color:#000000;">::</span>reflect<span style=3D" color:#0000=
00;">&lt;</span><span style=3D" color:#808000;">decltype</span><span style=
=3D" color:#000000;">(</span><span style=3D" color:#000000;">test</span><sp=
an style=3D" color:#000000;">)&gt;::</span>construct<span style=3D" color:#=
000000;">();</span></pre>
<pre><span style=3D" color:#c0c0c0;">  </span><span style=3D" color:#808000=
;">static_assert</span><span style=3D" color:#000000;">&lt;</span>is_same<s=
pan style=3D" color:#000000;">&lt;</span><span style=3D" color:#808000;">de=
cltype</span><span style=3D" color:#000000;">(</span><span style=3D" color:=
#000000;">test</span><span style=3D" color:#000000;">),</span><span style=
=3D" color:#808000;">decltype</span><span style=3D" color:#000000;">(</span=
><span style=3D" color:#000000;">closure</span><span style=3D" color:#00000=
0;">)&gt;::</span>value<span style=3D" color:#000000;">&gt;();</span><span =
style=3D" color:#c0c0c0;"> </span><span style=3D" color:#008000;">//</span>=
<span style=3D" color:#c0c0c0;"> </span><span style=3D" color:#008000;">thi=
s</span><span style=3D" color:#c0c0c0;"> </span><span style=3D" color:#0080=
00;">fails</span></pre><pre><pre><!--StartFragment--><span style=3D" color:=
#000000;">  test</span><span style=3D" color:#c0c0c0;"> </span><span style=
=3D" color:#000000;">=3D</span><span style=3D" color:#c0c0c0;"> </span><spa=
n style=3D" color:#000000;">closure</span><span style=3D" color:#000000;">;=
</span><span style=3D" color:#c0c0c0;"> </span><span style=3D" color:#00800=
0;">//</span><span style=3D" color:#c0c0c0;"> </span><span style=3D" color:=
#008000;">this</span><span style=3D" color:#c0c0c0;"> </span><span style=3D=
" color:#008000;">fails</span><!--EndFragment--></pre></pre></div><div>&nbs=
p;</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"ltr">- May=
be it's worth at least having a function which just returns the types and n=
ames of captured variables: this would make it possible for a portable high=
er level interface to lambdas to be added to the standard library at a late=
r time without any additional compiler support (the standard library can 'k=
now' exactly what the layout of a lambda looks like given a capture list be=
cause it can be aware of the inner workings of the compiler).<br></div></bl=
ockquote><div><br></div><div>This might be one possibility, but it looks to=
 me like it would be more of an extension of the current lambda capabilitie=
s rather than a feature of reflection. Another possibility would be to enfo=
rce that identifiers are the same in the capture list and the closure type,=
 instead of being unnamed. It would be interesting to know why they decided=
 the members should be unnamed in the first place, my guess it they don't w=
ant them to be accessible, which is something reflection would expose.</div=
></div></div>

<p></p>

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

------=_Part_196_14608244.1401719415169--

.

------=_Part_2217_29074498.1401721046235
Content-Type: text/plain; charset=UTF-8



On Monday, 2 June 2014 15:30:15 UTC+1, Thibaut Lutz wrote:
>
> Thanks for the comments.
>
> - If construction of lambdas is ever allowed through reflection, then it
>> should create a new type of lambda, constructing an existing type should
>> only be possible via copy or move, this avoids the problem you mentioned
>> with references.
>>
>
> This is a bit tricky. A Lambda declaration is implicitly a constructor
> call, so the constructor does exist and is accessible. Moreover the type of
> the newly created object might be explicitly the same as the lambda's:
>
>   auto test = [](){return 0;};
>
>   using Lambda = decltype(test);
>
>   Lambda closure = std::reflect<Lambda>::construct();
>
>
That's only the case for lambdas with no captures, for lambdas with
captures the constructor effectively has one argument of some internal type
(essentially a reference to a stack frame). This internal type need not
have any constructors or could even be a type without a definition, but
certainly reflection need not be supported on it, so that would make it
impossible to call the constructor in a valid way.


>
> Also, creating new types on the fly introduces transitive oddities:
>
>   auto test = [](){return 0;};
>
>   auto closure = std::reflect<decltype(test)>::construct();
>
>   static_assert<is_same<decltype(test),decltype(closure)>::value>(); // this fails
>
>   test = closure; // this fails
>
>
I didn't mean based off an existing lambda, I meant creating a completely
new one: if reflection is going to include ways to create a new class, then
it could also create a new lambda type.


>
>
>> - Maybe it's worth at least having a function which just returns the
>> types and names of captured variables: this would make it possible for a
>> portable higher level interface to lambdas to be added to the standard
>> library at a later time without any additional compiler support (the
>> standard library can 'know' exactly what the layout of a lambda looks like
>> given a capture list because it can be aware of the inner workings of the
>> compiler).
>>
>
> This might be one possibility, but it looks to me like it would be more of
> an extension of the current lambda capabilities rather than a feature of
> reflection. Another possibility would be to enforce that identifiers are
> the same in the capture list and the closure type, instead of being
> unnamed. It would be interesting to know why they decided the members
> should be unnamed in the first place, my guess it they don't want them to
> be accessible, which is something reflection would expose.
>

So that the compiler can just store a single stack pointer in the closure
for however many by-ref captures there are?

--

---
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_2217_29074498.1401721046235
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Monday, 2 June 2014 15:30:15 UTC+1, Thibaut Lut=
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">Than=
ks for the comments.<div><br><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div d=
ir=3D"ltr">- If construction of lambdas is ever allowed through reflection,=
 then it should create a new type of lambda, constructing an existing type =
should only be possible via copy or move, this avoids the problem you menti=
oned with references.<br></div></blockquote><div><br></div><div>This is a b=
it tricky. A Lambda declaration is implicitly a constructor call, so the co=
nstructor does exist and is accessible. Moreover the type of the newly crea=
ted object might be explicitly the same as the lambda's:</div><div><pre><pr=
e><span style=3D"color:#c0c0c0">  </span><span style=3D"color:#808000">auto=
</span><span style=3D"color:#c0c0c0"> </span><span style=3D"color:#000000">=
test</span><span style=3D"color:#c0c0c0"> </span><span style=3D"color:#0000=
00">=3D</span><span style=3D"color:#c0c0c0"> </span><span style=3D"color:#0=
00000">[](){</span><span style=3D"color:#808000">return</span><span style=
=3D"color:#c0c0c0"> </span><span style=3D"color:#000080">0</span><span styl=
e=3D"color:#000000">;};</span></pre></pre>
<pre><span style=3D"color:#c0c0c0">  </span><span style=3D"color:#808000">u=
sing</span><span style=3D"color:#c0c0c0"> </span><span style=3D"color:#8000=
80">Lambda</span><span style=3D"color:#c0c0c0"> </span><span style=3D"color=
:#000000">=3D</span><span style=3D"color:#c0c0c0"> </span><span style=3D"co=
lor:#808000">decltype</span><span style=3D"color:#000000">(</span><span sty=
le=3D"color:#000000">test</span><span style=3D"color:#000000">);</span></pr=
e>
<pre><span style=3D"color:#c0c0c0">  </span><span style=3D"color:#800080">L=
ambda</span><span style=3D"color:#c0c0c0"> </span><span style=3D"color:#000=
000">closure</span><span style=3D"color:#c0c0c0"> </span><span style=3D"col=
or:#000000">=3D</span><span style=3D"color:#c0c0c0"> </span>std<span style=
=3D"color:#000000">::</span>reflect<span style=3D"color:#000000">&lt;</span=
><span style=3D"color:#800080">Lambda</span><span style=3D"color:#000000">&=
gt;::</span>construc<wbr>t<span style=3D"color:#000000">(</span><span style=
=3D"color:#000000">);</span></pre></div></div></div></blockquote><div><br>T=
hat's only the case for lambdas with no captures, for lambdas with captures=
 the constructor effectively has one argument of some internal type (essent=
ially a reference to a stack frame). This internal type need not have any c=
onstructors or could even be a type without a definition, but certainly ref=
lection need not be supported on it, so that would make it impossible to ca=
ll the constructor in a valid way.<br>&nbsp;</div><blockquote class=3D"gmai=
l_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;=
padding-left: 1ex;"><div dir=3D"ltr"><div><div><br></div><div>Also, creatin=
g new types on the fly introduces transitive oddities:</div><div>
<pre><span style=3D"color:#c0c0c0">  </span><span style=3D"color:#808000">a=
uto</span><span style=3D"color:#c0c0c0"> </span><span style=3D"color:#00000=
0">test</span><span style=3D"color:#c0c0c0"> </span><span style=3D"color:#0=
00000">=3D</span><span style=3D"color:#c0c0c0"> </span><span style=3D"color=
:#000000">[](){</span><span style=3D"color:#808000">return</span><span styl=
e=3D"color:#c0c0c0"> </span><span style=3D"color:#000080">0</span><span sty=
le=3D"color:#000000">;};</span></pre>
<pre><span style=3D"color:#c0c0c0">  </span><span style=3D"color:#808000">a=
uto</span><span style=3D"color:#c0c0c0"> </span><span style=3D"color:#00000=
0">closure</span><span style=3D"color:#c0c0c0"> </span><span style=3D"color=
:#000000">=3D</span><span style=3D"color:#c0c0c0"> </span>std<span style=3D=
"color:#000000">::</span>reflect<span style=3D"color:#000000">&lt;</span><s=
pan style=3D"color:#808000">decltype</span><span style=3D"color:#000000">(<=
/span><span style=3D"color:#000000">test</span><span style=3D"color:#000000=
">)&gt;::</span><wbr>construct<span style=3D"color:#000000">();</span></pre=
>
<pre><span style=3D"color:#c0c0c0">  </span><span style=3D"color:#808000">s=
tatic_assert</span><span style=3D"color:#000000">&lt;</span>is_same<span st=
yle=3D"color:#000000">&lt;</span><span style=3D"color:#808000">decltype</sp=
an><span style=3D"color:#000000"><wbr>(</span><span style=3D"color:#000000"=
>test</span><span style=3D"color:#000000">),</span><span style=3D"color:#80=
8000">decltype</span><span style=3D"color:#000000">(</span><span style=3D"c=
olor:#000000">closure</span><span style=3D"color:#000000">)&gt;::</span>val=
<wbr>ue<span style=3D"color:#000000">&gt;();</span><span style=3D"color:#c0=
c0c0"> </span><span style=3D"color:#008000">//</span><span style=3D"color:#=
c0c0c0"> </span><span style=3D"color:#008000">this</span><span style=3D"col=
or:#c0c0c0"> </span><span style=3D"color:#008000">fails</span></pre><pre><p=
re><span style=3D"color:#000000">  test</span><span style=3D"color:#c0c0c0"=
> </span><span style=3D"color:#000000">=3D</span><span style=3D"color:#c0c0=
c0"> </span><span style=3D"color:#000000">closure</span><span style=3D"colo=
r:#000000">;</span><span style=3D"color:#c0c0c0"> </span><span style=3D"col=
or:#008000">//</span><span style=3D"color:#c0c0c0"> </span><span style=3D"c=
olor:#008000">this</span><span style=3D"color:#c0c0c0"> </span><span style=
=3D"color:#008000">fails</span></pre></pre></div></div></div></blockquote><=
div><br>I didn't mean based off an existing lambda, I meant creating a comp=
letely new one: if reflection is going to include ways to create a new clas=
s, then it could also create a new lambda type.<br>&nbsp;</div><blockquote =
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1p=
x #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div>&nbsp;</div><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">- Maybe it's worth at=
 least having a function which just returns the types and names of captured=
 variables: this would make it possible for a portable higher level interfa=
ce to lambdas to be added to the standard library at a later time without a=
ny additional compiler support (the standard library can 'know' exactly wha=
t the layout of a lambda looks like given a capture list because it can be =
aware of the inner workings of the compiler).<br></div></blockquote><div><b=
r></div><div>This might be one possibility, but it looks to me like it woul=
d be more of an extension of the current lambda capabilities rather than a =
feature of reflection. Another possibility would be to enforce that identif=
iers are the same in the capture list and the closure type, instead of bein=
g unnamed. It would be interesting to know why they decided the members sho=
uld be unnamed in the first place, my guess it they don't want them to be a=
ccessible, which is something reflection would expose.</div></div></div></b=
lockquote><div><br>So that the compiler can just store a single stack point=
er in the closure for however many by-ref captures there are?<br></div></di=
v>

<p></p>

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

------=_Part_2217_29074498.1401721046235--

.

------=_Part_2283_9351424.1401722114541
Content-Type: text/plain; charset=UTF-8


>
> That's only the case for lambdas with no captures, for lambdas with
> captures the constructor effectively has one argument of some internal type
> (essentially a reference to a stack frame). This internal type need not
> have any constructors or could even be a type without a definition, but
> certainly reflection need not be supported on it, so that would make it
> impossible to call the constructor in a valid way.
>

This is implementation specific, isn't it? The following could be a valid
compiler transformation too, and exposes a valid constructor:

int a, b;

auto test = [&a, &b](){a++; b--};


// could be translated into

struct __Closure {

 int &__a;

 int &__b;

 __Closure(int &a, int &b)

     : __a{a}, __b{b} {}

 /* function op, cast op... */

} test {a,b} ;



> I didn't mean based off an existing lambda, I meant creating a completely
> new one: if reflection is going to include ways to create a new class, then
> it could also create a new lambda type.
>

Right, this is a different use case then.


> So that the compiler can just store a single stack pointer in the closure
> for however many by-ref captures there are?
>

I was thinking more about the by-copy entities. I think the consensus is
that once initialized they are semantically immutable outside the lambda.

--

---
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_2283_9351424.1401722114541
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>That's only the case for lambdas with no captures, for lambdas wit=
h captures the constructor effectively has one argument of some internal ty=
pe (essentially a reference to a stack frame). This internal type need not =
have any constructors or could even be a type without a definition, but cer=
tainly reflection need not be supported on it, so that would make it imposs=
ible to call the constructor in a valid way.<br></div></div></blockquote><d=
iv><br></div><div>This is implementation specific, isn't it? The following =
could be a valid compiler transformation too, and exposes a valid construct=
or:</div><div><br></div><div>
<pre><!--StartFragment--><span style=3D" color:#808000;">int</span><span st=
yle=3D" color:#c0c0c0;"> </span>a<span style=3D" color:#000000;">,</span><s=
pan style=3D" color:#c0c0c0;"> </span>b<span style=3D" color:#000000;">;</s=
pan></pre>
<pre><span style=3D" color:#808000;">auto</span><span style=3D" color:#c0c0=
c0;"> </span>test<span style=3D" color:#c0c0c0;"> </span><span style=3D" co=
lor:#000000;">=3D</span><span style=3D" color:#c0c0c0;"> </span><span style=
=3D" color:#000000;">[&amp;</span>a<span style=3D" color:#000000;">,</span>=
<span style=3D" color:#c0c0c0;"> </span><span style=3D" color:#000000;">&am=
p;</span>b<span style=3D" color:#000000;">](){</span>a<span style=3D" color=
:#000000;">++;</span><span style=3D" color:#c0c0c0;"> </span>b<span style=
=3D" color:#000000;">--};</span></pre>
<pre><br></pre>
<pre><span style=3D" color:#008000;">//</span><span style=3D" color:#c0c0c0=
;"> </span><span style=3D" color:#008000;">could</span><span style=3D" colo=
r:#c0c0c0;"> </span><span style=3D" color:#008000;">be</span><span style=3D=
" color:#c0c0c0;"> </span><span style=3D" color:#008000;">translated</span>=
<span style=3D" color:#c0c0c0;"> </span><span style=3D" color:#008000;">int=
o</span></pre>
<pre><span style=3D" color:#808000;">struct</span><span style=3D" color:#c0=
c0c0;"> </span><span style=3D" color:#800080;">__Closure</span><span style=
=3D" color:#c0c0c0;"> </span><span style=3D" color:#000000;">{</span></pre>
<pre><span style=3D" color:#c0c0c0;"> </span><span style=3D" color:#808000;=
">int</span><span style=3D" color:#c0c0c0;"> </span><span style=3D" color:#=
000000;">&amp;</span><span style=3D" color:#800000;">__a</span><span style=
=3D" color:#000000;">;</span></pre>
<pre><span style=3D" color:#c0c0c0;"> </span><span style=3D" color:#808000;=
">int</span><span style=3D" color:#c0c0c0;"> </span><span style=3D" color:#=
000000;">&amp;</span><span style=3D" color:#800000;">__b</span><span style=
=3D" color:#000000;">;</span></pre>
<pre><span style=3D" color:#c0c0c0;"> </span><span style=3D" color:#800080;=
">__Closure</span><span style=3D" color:#000000;">(</span><span style=3D" c=
olor:#808000;">int</span><span style=3D" color:#c0c0c0;"> </span><span styl=
e=3D" color:#000000;">&amp;</span><span style=3D" color:#000000;">a</span><=
span style=3D" color:#000000;">,</span><span style=3D" color:#c0c0c0;"> </s=
pan><span style=3D" color:#808000;">int</span><span style=3D" color:#c0c0c0=
;"> </span><span style=3D" color:#000000;">&amp;</span><span style=3D" colo=
r:#000000;">b</span><span style=3D" color:#000000;">)</span><span style=3D"=
 color:#c0c0c0;"> </span></pre>
<pre><span style=3D" color:#c0c0c0;">     </span><span style=3D" color:#000=
000;">:</span><span style=3D" color:#c0c0c0;"> </span><span style=3D" color=
:#800000;">__a</span><span style=3D" color:#000000;">{</span><span style=3D=
" color:#000000;">a</span><span style=3D" color:#000000;">},</span><span st=
yle=3D" color:#c0c0c0;"> </span><span style=3D" color:#800000;">__b</span><=
span style=3D" color:#000000;">{</span><span style=3D" color:#000000;">b</s=
pan><span style=3D" color:#000000;">}</span><span style=3D" color:#c0c0c0;"=
> </span><span style=3D" color:#000000;">{}</span></pre>
<pre><span style=3D" color:#c0c0c0;"> </span><span style=3D" color:#008000;=
">/*</span><span style=3D" color:#c0c0c0;"> </span><span style=3D" color:#0=
08000;">function</span><span style=3D" color:#c0c0c0;"> </span><span style=
=3D" color:#008000;">op,</span><span style=3D" color:#c0c0c0;"> </span><spa=
n style=3D" color:#008000;">cast op...</span><span style=3D" color:#c0c0c0;=
"> </span><span style=3D" color:#008000;">*/</span></pre>
<pre><span style=3D" color:#000000;">}</span><span style=3D" color:#c0c0c0;=
"> </span>test<span style=3D" color:#c0c0c0;"> </span><span style=3D" color=
:#000000;">{</span>a<span style=3D" color:#000000;">,</span>b<span style=3D=
" color:#000000;">}</span><span style=3D" color:#c0c0c0;"> </span><span sty=
le=3D" color:#000000;">;</span><!--EndFragment--></pre></div><div>&nbsp;</d=
iv><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>I did=
n't mean based off an existing lambda, I meant creating a completely new on=
e: if reflection is going to include ways to create a new class, then it co=
uld also create a new lambda type.<br></div></div></blockquote><div><br></d=
iv><div>Right, this is a different use case then.</div><div>&nbsp;</div><bl=
ockquote 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>So that the=
 compiler can just store a single stack pointer in the closure for however =
many by-ref captures there are?<br></div></div></blockquote><div><br></div>=
<div>I was thinking more about the by-copy entities. I think the consensus =
is that once initialized they are semantically immutable outside the lambda=
..&nbsp;</div></div>

<p></p>

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

------=_Part_2283_9351424.1401722114541--

.

------=_Part_136_16210407.1401725449746
Content-Type: text/plain; charset=UTF-8



On Monday, 2 June 2014 16:15:14 UTC+1, Thibaut Lutz wrote:
>
> That's only the case for lambdas with no captures, for lambdas with
>> captures the constructor effectively has one argument of some internal type
>> (essentially a reference to a stack frame). This internal type need not
>> have any constructors or could even be a type without a definition, but
>> certainly reflection need not be supported on it, so that would make it
>> impossible to call the constructor in a valid way.
>>
>
> This is implementation specific, isn't it? The following could be a valid
> compiler transformation too, and exposes a valid constructor:
>
>
Sure, but your original comment about lambdas having constructors is
implementation specific - the compiler could just materialise an instance
of the lambda from nothing without it even having a constructor, but we're
talking about the abstraction that the user can see. Logically, a lambda is
constructed from a stack frame, regardless of how it's actually implemented
in the compiler, so if the user can see that there's a constructor, that's
what it should look like.


> I didn't mean based off an existing lambda, I meant creating a completely
>> new one: if reflection is going to include ways to create a new class, then
>> it could also create a new lambda type.
>>
>
> Right, this is a different use case then.
>
>
>> So that the compiler can just store a single stack pointer in the closure
>> for however many by-ref captures there are?
>>
>
> I was thinking more about the by-copy entities. I think the consensus is
> that once initialized they are semantically immutable outside the lambda.
>

In that case, the only case I can think of is so that the compiler can
re-order members to reduce space requirements if members have different
alignments, but most likely it's left unspecified because there's no need
for it to be so.

--

---
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_136_16210407.1401725449746
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Monday, 2 June 2014 16:15:14 UTC+1, Thibaut Lut=
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"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>That's only the c=
ase for lambdas with no captures, for lambdas with captures the constructor=
 effectively has one argument of some internal type (essentially a referenc=
e to a stack frame). This internal type need not have any constructors or c=
ould even be a type without a definition, but certainly reflection need not=
 be supported on it, so that would make it impossible to call the construct=
or in a valid way.<br></div></div></blockquote><div><br></div><div>This is =
implementation specific, isn't it? The following could be a valid compiler =
transformation too, and exposes a valid constructor:</div><br></div></block=
quote><div>&nbsp;</div><div>Sure, but your original comment about lambdas h=
aving constructors is implementation specific - the compiler could just mat=
erialise an instance of the lambda from nothing without it even having a co=
nstructor, but we're talking about the abstraction that the user can see. L=
ogically, a lambda is constructed from a stack frame, regardless of how it'=
s actually implemented in the compiler, so if the user can see that there's=
 a constructor, that's what it should look like.<br>&nbsp;</div><blockquote=
 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"><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"><div>I didn't mean based off an existing l=
ambda, I meant creating a completely new one: if reflection is going to inc=
lude ways to create a new class, then it could also create a new lambda typ=
e.<br></div></div></blockquote><div><br></div><div>Right, this is a differe=
nt use case then.</div><div>&nbsp;</div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:=
1ex"><div dir=3D"ltr"><div>So that the compiler can just store a single sta=
ck pointer in the closure for however many by-ref captures there are?<br></=
div></div></blockquote><div><br></div><div>I was thinking more about the by=
-copy entities. I think the consensus is that once initialized they are sem=
antically immutable outside the lambda.&nbsp;</div></div></blockquote><div>=
<br>In that case, the only case I can think of is so that the compiler can =
re-order members to reduce space requirements if members have different ali=
gnments, but most likely it's left unspecified because there's no need for =
it to be so.<br></div></div>

<p></p>

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

------=_Part_136_16210407.1401725449746--

.

------=_Part_305_15682273.1401728086500
Content-Type: text/plain; charset=UTF-8


>
> Sure, but your original comment about lambdas having constructors is
> implementation specific - the compiler could just materialise an instance
> of the lambda from nothing without it even having a constructor, but we're
> talking about the abstraction that the user can see. Logically, a lambda is
> constructed from a stack frame, regardless of how it's actually implemented
> in the compiler, so if the user can see that there's a constructor, that's
> what it should look like.
>

For this example, I was assuming that reflection would allow users to list
the constructors and there just happens to be one with this signature. My
point is that the generated constructor should only be invoked where the
lambda was declared, because that is what the design intended. Reflection
should not allow users to artificially invoke it, especially out of
context. I think it goes with what you are saying too, we just have
different ways of justifying it.


> In that case, the only case I can think of is so that the compiler can
> re-order members to reduce space requirements if members have different
> alignments
>

That justifies the unsorted bit, not the anonymity of the members. For the
ordering, I suspect the same thing. The reason why they are also unnnamed
is I think to explicitly forbid external access to the captured entities:

  int i = 2;

  auto test = [i](int x){ return i * x; };

  //...

  test.i = 10;

  //...



--

---
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_305_15682273.1401728086500
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>Sure, but your original comment about lambdas having constructors =
is implementation specific - the compiler could just materialise an instanc=
e of the lambda from nothing without it even having a constructor, but we'r=
e talking about the abstraction that the user can see. Logically, a lambda =
is constructed from a stack frame, regardless of how it's actually implemen=
ted in the compiler, so if the user can see that there's a constructor, tha=
t's what it should look like.<br></div></div></blockquote><div><br></div><d=
iv>For this example, I was assuming that reflection would allow users to li=
st the constructors and there just happens to be one with this signature. M=
y point is that the generated constructor should only be invoked where the =
lambda was declared, because that is what the design intended. Reflection s=
hould not allow users to artificially invoke it, especially out of context.=
 I think it goes with what you are saying too, we just have different ways =
of justifying it.</div><div>&nbsp;</div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-le=
ft: 1ex;"><div dir=3D"ltr"><div>In that case, the only case I can think of =
is so that the compiler can re-order members to reduce space requirements i=
f members have different alignments<br></div></div></blockquote><div><br></=
div><div>That justifies the unsorted bit, not the anonymity of the members.=
 For the ordering, I suspect the same thing. The reason why they are also u=
nnnamed is I think to explicitly forbid external access to the captured ent=
ities:</div><div><br></div><div>
<pre><!--StartFragment--><span style=3D" color:#c0c0c0;">  </span><span sty=
le=3D" color:#808000;">int</span><span style=3D" color:#c0c0c0;"> </span><s=
pan style=3D" color:#000000;">i</span><span style=3D" color:#c0c0c0;"> </sp=
an><span style=3D" color:#000000;">=3D</span><span style=3D" color:#c0c0c0;=
"> </span><span style=3D" color:#000080;">2</span><span style=3D" color:#00=
0000;">;</span></pre>
<pre><span style=3D" color:#c0c0c0;">  </span><span style=3D" color:#808000=
;">auto</span><span style=3D" color:#c0c0c0;"> </span><span style=3D" color=
:#000000;">test</span><span style=3D" color:#c0c0c0;"> </span><span style=
=3D" color:#000000;">=3D</span><span style=3D" color:#c0c0c0;"> </span><spa=
n style=3D" color:#000000;">[</span><span style=3D" color:#000000;">i</span=
><span style=3D" color:#000000;">](</span><span style=3D" color:#808000;">i=
nt</span><span style=3D" color:#c0c0c0;"> </span>x<span style=3D" color:#00=
0000;">){</span><span style=3D" color:#c0c0c0;"> </span><span style=3D" col=
or:#808000;">return</span><span style=3D" color:#c0c0c0;"> </span><span sty=
le=3D" color:#000000;">i</span><span style=3D" color:#c0c0c0;"> </span><spa=
n style=3D" color:#000000;">*</span><span style=3D" color:#c0c0c0;"> </span=
>x<span style=3D" color:#000000;">;</span><span style=3D" color:#c0c0c0;"> =
</span><span style=3D" color:#000000;">};</span></pre>
<pre><span style=3D" color:#c0c0c0;">  </span><span style=3D" color:#008000=
;">//...</span></pre>
<pre><span style=3D" color:#c0c0c0;">  </span><span style=3D" color:#000000=
;">test</span><span style=3D" color:#000000;">.</span>i<span style=3D" colo=
r:#c0c0c0;"> </span><span style=3D" color:#000000;">=3D</span><span style=
=3D" color:#c0c0c0;"> </span><span style=3D" color:#000080;">10</span><span=
 style=3D" color:#000000;">;</span></pre>
<pre><span style=3D" color:#c0c0c0;">  </span><span style=3D" color:#008000=
;">//...</span><!--EndFragment--></pre></div><div>&nbsp;</div></div>

<p></p>

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

------=_Part_305_15682273.1401728086500--

.