------=_Part_144_1609590182.1461557799701
Content-Type: multipart/alternative;
 boundary="----=_Part_145_1880648469.1461557799701"

------=_Part_145_1880648469.1461557799701
Content-Type: text/plain; charset=UTF-8

Quoting Herb Sutter's "GotW #76"[1] this is about "*liars, cheats,
pickpockets, and thieves*" (but have Robin Hood in mind) and "*protecting
against Murphy vs. protecting against Machiavelli*".

A few "inflammatory" questions:

1) Should C++ have a standard (obvious) way to subvert the defined access
right of given class?

2) If no, access rights should be followed strictly, does that also applies
to a future reflection support?

3) If yes, reflection should be the way to do it, why using the standard
way (in this case reflection) should cost more than the non-standard
options? (in this case, potentially adding some compile-time cost).

4) If yes, the fact reflection is the common solution in other languages
(such as Java, C#) for subverting access rights, does that mean this should
the ideal way to do it in C++?

5) If not even reflection should be allowed to do it, should then the users
of language keep resorting to dirty tricks to, let's say, serialize the
contents of a class? (think third-party code, in particular).

If the answers for the question above were:
1) "yes, there should be a way" and
2) "yes, access rights applies to reflection" or
3) "no, the cost should be at least similar" or
4) "no, C++ should have a different solution for this problem" or
5) "well, no"
Then, how a standard solution for violating the defined access rights
should look like?

Some characteristics to have in mind:
- It should state clearly the intention. Such as "const_cast" or
"reintepret_cast", it's the "signature" of a violation.
- It should have no side-effects by itself. Of course, the act of accessing
a forbidden piece of code will have side-effects.

Some open questions:
a) Should it be done at the language level or at the pre-processor?
i.e. #pragma (unrestricted_access)

b) Should it be done for the entire class?
i.e. class Violator : friend Victim {};

c) Or with more granularity?
unrestricted_access(x.private_member) = 0;

d) Should it be costly in terms of the developer time?
#pragma - requires a separate header or even translation unit - costly.
friend inheritance - requires a derived class - half way
unrestricted_access "cast" - cheap

e) Should the class's author still have a final word?
#pragma - class author has no say
friend inheritance - make the class final: class NotVictim final {};
unrestricted_access - attribute? [[forbid_unrestricted_access]]

f) Applies equally to data members and member functions and nested types
and typedef/using alias?

[1] http://www.gotw.ca/gotw/076.htm

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/20e81af7-4506-4408-b73a-58371434bd40%40isocpp.org.

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

<div dir=3D"ltr">Quoting Herb Sutter&#39;s &quot;GotW #76&quot;[1] this is =
abou<span style=3D"background-color: rgb(255, 255, 255);">t &quot;<i style=
=3D"color: rgb(0, 0, 0); font-family: Arial, Arial, Helvetica; font-size: 1=
3.3333px;">liars, cheats, pickpockets, and thieves</i>&quot; (but have Robi=
n Hood in mind) and &quot;<span style=3D"color: rgb(0, 0, 0); font-family: =
Arial, Arial, Helvetica; font-size: 13.3333px;"><i>protecting against Murph=
y vs. protecting against Machiavelli</i></span>&quot;.</span><div><span sty=
le=3D"background-color: rgb(255, 255, 255);"><br></span></div><div><span st=
yle=3D"background-color: rgb(255, 255, 255);">A few &quot;inflammatory&quot=
;=C2=A0questions:</span></div><div><span style=3D"background-color: rgb(255=
, 255, 255);"><br></span></div><div><span style=3D"background-color: rgb(25=
5, 255, 255);">1) Should C++ have a standard (obvious) way to subvert the d=
efined access right of given class?</span></div><div><span style=3D"backgro=
und-color: rgb(255, 255, 255);">=C2=A0</span></div><div><span style=3D"back=
ground-color: rgb(255, 255, 255);">2) If no, access rights should be follow=
ed strictly, does that also applies to a future reflection support?</span><=
/div><div><br></div><div><span style=3D"background-color: rgb(255, 255, 255=
);">3) If yes, reflection should be the way to do it, why using the standar=
d way (in this case reflection) should cost more than the non-standard opti=
ons? (in this case, potentially adding some compile-time cost).</span></div=
><div><span style=3D"background-color: rgb(255, 255, 255);"><br></span></di=
v><div><div>4) If yes, the fact reflection is the common solution in other =
languages (such as Java, C#) for subverting access rights, does that mean t=
his should the ideal way to do it in C++?</div></div><div><br></div><div><s=
pan style=3D"background-color: rgb(255, 255, 255);">5) If not even reflecti=
on should be allowed to do it, should then the users of language keep resor=
ting to dirty tricks to, let&#39;s say, serialize the contents of a class? =
(think third-party code, in particular).</span></div><div><span style=3D"ba=
ckground-color: rgb(255, 255, 255);"><br></span></div><div><span style=3D"b=
ackground-color: rgb(255, 255, 255);">If the answers for the question above=
 were:</span></div><div><span style=3D"background-color: rgb(255, 255, 255)=
;">1) &quot;yes, there should be a way&quot; and</span></div><div><span sty=
le=3D"background-color: rgb(255, 255, 255);">2) &quot;yes, access rights ap=
plies to reflection&quot; or</span></div><div><span style=3D"background-col=
or: rgb(255, 255, 255);">3) &quot;no, the cost should be at least similar&q=
uot; or</span></div><div><span style=3D"background-color: rgb(255, 255, 255=
);">4) &quot;no, C++ should have a different solution for this problem&quot=
; or</span></div><div><span style=3D"background-color: rgb(255, 255, 255);"=
>5) &quot;well, no&quot;</span></div><div>Then, how a standard solution for=
 violating the defined access rights should look like?</div><div><br></div>=
<div>Some characteristics to have in mind:</div><div>- It should state clea=
rly the intention. Such as &quot;const_cast&quot; or &quot;reintepret_cast&=
quot;, it&#39;s the &quot;signature&quot; of a violation.</div><div>- It sh=
ould have no side-effects by itself. Of course, the act of accessing a forb=
idden piece of code will have side-effects.</div><div><br></div><div>Some o=
pen questions:</div><div>a) Should it be done at the language level or at t=
he pre-processor?</div><div>i.e. #pragma (unrestricted_access)</div><div><b=
r></div><div>b) Should it be done for the entire class?</div><div>i.e. clas=
s Violator : friend Victim {};</div><div><br></div><div>c) Or with more gra=
nularity?<br></div><div>unrestricted_access(x.private_member) =3D 0;</div><=
div><br></div><div>d) Should it be costly in terms of the developer time?<b=
r></div><div>#pragma - requires a separate header or even translation unit =
- costly.</div><div>friend inheritance - requires a derived class - half wa=
y</div><div>unrestricted_access &quot;cast&quot; - cheap<br></div><div><br>=
</div><div>e) Should the class&#39;s author still have a final word?</div><=
div>#pragma - class author has no say</div><div>friend inheritance - make t=
he class final: class NotVictim final {};<br></div><div>unrestricted_access=
 - attribute? [[forbid_unrestricted_access]]<br></div><div><br></div><div>f=
) Applies equally to data members and member functions and nested types and=
 typedef/using alias?</div><div><span style=3D"background-color: rgb(255, 2=
55, 255);"><br></span></div><div><span style=3D"background-color: rgb(255, =
255, 255);">[1]=C2=A0</span>http://www.gotw.ca/gotw/076.htm</div></div>

<p></p>

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

------=_Part_145_1880648469.1461557799701--
------=_Part_144_1609590182.1461557799701--

.

------=_Part_1753_1438929843.1461599244875
Content-Type: multipart/alternative;
 boundary="----=_Part_1754_366898621.1461599244875"

------=_Part_1754_366898621.1461599244875
Content-Type: text/plain; charset=UTF-8

On Monday, April 25, 2016 at 12:16:40 AM UTC-4, Ricardo Andrade wrote:
>
> Quoting Herb Sutter's "GotW #76"[1] this is about "*liars, cheats,
> pickpockets, and thieves*" (but have Robin Hood in mind) and "*protecting
> against Murphy vs. protecting against Machiavelli*".
>
> A few "inflammatory" questions:
>
> 1) Should C++ have a standard (obvious) way to subvert the defined access
> right of given class?
>

No.

2) If no, access rights should be followed strictly, does that also applies
> to a future reflection support?
>

Reflection does not exist to break access controls. It has to be able to do
that in order for it to do its job, but that isn't its purpose, nor would
it be an "obvious" way to break access controls.


> 3) If yes, reflection should be the way to do it, why using the standard
> way (in this case reflection) should cost more than the non-standard
> options? (in this case, potentially adding some compile-time cost).
>

Because we shouldn't make it easy for people to do stupid things.

4) If yes, the fact reflection is the common solution in other languages
> (such as Java, C#) for subverting access rights,
>

Again, that's not what reflection is *for*. It can do that, but that's not
its purpose.

5) If not even reflection should be allowed to do it, should then the users
> of language keep resorting to dirty tricks to, let's say, serialize the
> contents of a class? (think third-party code, in particular).
>

Do you really think that you could reasonably serialize the contents of a
class that you didn't create, cannot modify, and don't even know the
meaning of the data it stores?

Oh sure, you may be able to access the *values*, writing them to a file and
read them back. But without knowing the *meaning* of them (and no, the type
is not sufficient), you have *no clue* if merely reading those values back
will actually accomplish the goal of creating a functional object, with all
of that class's invariants intact.

As a simple example, what if there's a class that has a `int`. You might
just write that out and read it back later. But what if this value is
sourced from a monotonically increasing value somewhere? And thus, when you
recreate it, you shouldn't just read the value you wrote. You have to talk
to the monotonically increasing value and regenerate this number at
deserialization time.

Whether you have access to a type's privates or not, you *cannot*
effectively serialize a type without that type's knowledge or *explicit
consent*.

So users of the language shouldn't be "resorting to dirty tricks" to
serialize other people's types at all. It simply is non-functional in the
general case.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/de4ba8f4-55c3-417b-ab44-61e54596df4b%40isocpp.org.

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

<div dir=3D"ltr">On Monday, April 25, 2016 at 12:16:40 AM UTC-4, Ricardo An=
drade wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">Q=
uoting Herb Sutter&#39;s &quot;GotW #76&quot;[1] this is abou<span style=3D=
"background-color:rgb(255,255,255)">t &quot;<i style=3D"color:rgb(0,0,0);fo=
nt-family:Arial,Arial,Helvetica;font-size:13.3333px">liars, cheats, pickpoc=
kets, and thieves</i>&quot; (but have Robin Hood in mind) and &quot;<span s=
tyle=3D"color:rgb(0,0,0);font-family:Arial,Arial,Helvetica;font-size:13.333=
3px"><i>protecting against Murphy vs. protecting against Machiavelli</i></s=
pan>&quot;.</span><div><span style=3D"background-color:rgb(255,255,255)"><b=
r></span></div><div><span style=3D"background-color:rgb(255,255,255)">A few=
 &quot;inflammatory&quot;=C2=A0questions:</span></div><div><span style=3D"b=
ackground-color:rgb(255,255,255)"><br></span></div><div><span style=3D"back=
ground-color:rgb(255,255,255)">1) Should C++ have a standard (obvious) way =
to subvert the defined access right of given class?</span></div></div></blo=
ckquote><div><br>No.<br><br></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><span style=3D"background-color:rgb(255,255,255=
)"></span></div><div><span style=3D"background-color:rgb(255,255,255)">2) I=
f no, access rights should be followed strictly, does that also applies to =
a future reflection support?</span></div></div></blockquote><div><br>Reflec=
tion does not exist to break access controls. It has to be able to do that =
in order for it to do its job, but that isn&#39;t its purpose, nor would it=
 be an &quot;obvious&quot; way to break access controls.<br>=C2=A0</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></div><div>=
<span style=3D"background-color:rgb(255,255,255)">3) If yes, reflection sho=
uld be the way to do it, why using the standard way (in this case reflectio=
n) should cost more than the non-standard options? (in this case, potential=
ly adding some compile-time cost).</span></div></div></blockquote><div><br>=
Because we shouldn&#39;t make it easy for people to do stupid things.<br><b=
r></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>4) If yes, the fact reflection is the common solution in other languag=
es (such as Java, C#) for subverting access rights,</div></div></div></bloc=
kquote><div><br>Again, that&#39;s not what reflection is <i>for</i>. It can=
 do that, but that&#39;s not its purpose.<br><br></div><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"><div><span style=3D"background-co=
lor:rgb(255,255,255)">5) If not even reflection should be allowed to do it,=
 should then the users of language keep resorting to dirty tricks to, let&#=
39;s say, serialize the contents of a class? (think third-party code, in pa=
rticular).</span></div></div></blockquote><div><br>Do you really think that=
 you could reasonably serialize the contents of a class that you didn&#39;t=
 create, cannot modify, and don&#39;t even know the meaning of the data it =
stores?<br><br>Oh sure, you may be able to access the <i>values</i>, writin=
g them to a file and read them back. But without knowing the <i>meaning</i>=
 of them (and no, the type is not sufficient), you have <i>no clue</i> if m=
erely reading those values back will actually accomplish the goal of creati=
ng a functional object, with all of that class&#39;s invariants intact.<br>=
<br>As a simple example, what if there&#39;s a class that has a `int`. You =
might just write that out and read it back later. But what if this value is=
 sourced from a monotonically increasing value somewhere? And thus, when yo=
u recreate it, you shouldn&#39;t just read the value you wrote. You have to=
 talk to the monotonically increasing value and regenerate this number at d=
eserialization time.<br><br>Whether you have access to a type&#39;s private=
s or not, you <i>cannot</i> effectively serialize a type without that type&=
#39;s knowledge or <i>explicit consent</i>.<br><br>So users of the language=
 shouldn&#39;t be &quot;<span style=3D"background-color:rgb(255,255,255)">r=
esorting to dirty tricks&quot; to serialize other people&#39;s types at all=
.. It simply is non-functional in the general case.</span><br></div></div>

<p></p>

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

------=_Part_1754_366898621.1461599244875--
------=_Part_1753_1438929843.1461599244875--

.

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

Hi Nicol, I knew those would be your answers :)
I appreciate you reply and I'll leave a few additional comments.

On Mon, Apr 25, 2016 at 10:47 AM, Nicol Bolas <jmckesson@gmail.com> wrote:

> On Monday, April 25, 2016 at 12:16:40 AM UTC-4, Ricardo Andrade wrote:
>>
>> Quoting Herb Sutter's "GotW #76"[1] this is about "*liars, cheats,
>> pickpockets, and thieves*" (but have Robin Hood in mind) and "*protecting
>> against Murphy vs. protecting against Machiavelli*".
>>
>> A few "inflammatory" questions:
>>
>> 1) Should C++ have a standard (obvious) way to subvert the defined access
>> right of given class?
>>
>
> No.
>

People will do it anyway. And it's not obvious or easy to find that in code
when they do.
At least having a standard way would make it easier for humans and tools to
deal with that.
It's just easier to maintain code that clearly states the programmer
intentions (without having to rely in comments).

2) If no, access rights should be followed strictly, does that also applies
>> to a future reflection support?
>>
>
> Reflection does not exist to break access controls. It has to be able to
> do that in order for it to do its job, but that isn't its purpose, nor
> would it be an "obvious" way to break access controls.
>

Agreed. But are you implying C++ reflection should allow it then?


>
3) If yes, reflection should be the way to do it, why using the standard
>> way (in this case reflection) should cost more than the non-standard
>> options? (in this case, potentially adding some compile-time cost).
>>
>
> Because we shouldn't make it easy for people to do stupid things.
>

I also agree, but...
const_cast, reinterpret_cast, or getting pointers to internal references
returned by members, etc.
All stupid things easy to be done while having no cost in terms of
compilation time, resource usage.


>
> 4) If yes, the fact reflection is the common solution in other languages
>> (such as Java, C#) for subverting access rights,
>>
>
> Again, that's not what reflection is *for*. It can do that, but that's
> not its purpose.
>
> 5) If not even reflection should be allowed to do it, should then the
>> users of language keep resorting to dirty tricks to, let's say, serialize
>> the contents of a class? (think third-party code, in particular).
>>
>
> Do you really think that you could reasonably serialize the contents of a
> class that you didn't create, cannot modify, and don't even know the
> meaning of the data it stores?
>
>
The reasonability of it depends on the level of knowledge one have about
such piece of code. It may be your own code that for some reason you can't
retrofit support for serialization on it.
Yes, it's certainly not the more correct approach and by doing it you are
incurring certain risks. But there's the theory and the practice.


> Oh sure, you may be able to access the *values*, writing them to a file
> and read them back. But without knowing the *meaning* of them (and no,
> the type is not sufficient), you have *no clue* if merely reading those
> values back will actually accomplish the goal of creating a functional
> object, with all of that class's invariants intact.
>
>
As a simple example, what if there's a class that has a `int`. You might
> just write that out and read it back later. But what if this value is
> sourced from a monotonically increasing value somewhere? And thus, when you
> recreate it, you shouldn't just read the value you wrote. You have to talk
> to the monotonically increasing value and regenerate this number at
> deserialization time.
>
>
Like I said, it depends how much you know about the code. So sometimes you
know the meaning and you can trust that.

There's also the question of doing certain operations such as serialization
in a non-invasive manner. Or "make it public for just this operation".
For example, I may want to serialize std::string the way it has been
implemented to preserve any optimizations such as small buffer optimization.
Definitely, no one will make these implementation-specific members public.
Creating my own serialization-aware type just blow away my goals of
preserving the characteristics of the original type I wanted to serialize.

Let's suppose a future reflection support gives me such power.
Suppose that dissecting std::string with reflection having the goal of
serialization in mind incurs an horrendous compile time cost and then I
just resort to other non-standard ways.
I just made a complex piece of code even more complex and less maintainable
because the language "got in my way".



> Whether you have access to a type's privates or not, you *cannot*
> effectively serialize a type without that type's knowledge or *explicit
> consent*.
> So users of the language shouldn't be "resorting to dirty tricks" to
> serialize other people's types at all. It simply is non-functional in the
> general case.
>
> This technically sound, but it may be not practical. Forcing people that
way is just asking for having workarounds that are a lot of boilerplate
code or a collection of dirty tricks.

IMO, there must be a balance between theory and practice in a programming
language.
Trying find the right balance for this specific matter with this discussion.


> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/de4ba8f4-55c3-417b-ab44-61e54596df4b%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/de4ba8f4-55c3-417b-ab44-61e54596df4b%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BfGSbNUOg59FDrUux0DUKi-vZ9m7Ec7Fu%2B_%2B3Y-Q4dhAZMUvA%40mail.gmail.com.

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

<div dir=3D"ltr">Hi Nicol, I knew those would be your answers :)<div>I appr=
eciate you reply and I&#39;ll leave a few additional comments.</div><div><b=
r></div><div><div class=3D"gmail_extra"><div class=3D"gmail_quote">On Mon, =
Apr 25, 2016 at 10:47 AM, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"mail=
to:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</span=
> wrote:<br><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-s=
tyle:solid;padding-left:1ex"><div dir=3D"ltr">On Monday, April 25, 2016 at =
12:16:40 AM UTC-4, Ricardo Andrade wrote:<blockquote class=3D"gmail_quote" =
style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:r=
gb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr">=
Quoting Herb Sutter&#39;s &quot;GotW #76&quot;[1] this is abou<span style=
=3D"background-color:rgb(255,255,255)">t &quot;<i style=3D"color:rgb(0,0,0)=
;font-family:Arial,Arial,Helvetica;font-size:13.3333px">liars, cheats, pick=
pockets, and thieves</i>&quot; (but have Robin Hood in mind) and &quot;<spa=
n style=3D"color:rgb(0,0,0);font-family:Arial,Arial,Helvetica;font-size:13.=
3333px"><i>protecting against Murphy vs. protecting against Machiavelli</i>=
</span>&quot;.</span><div><span style=3D"background-color:rgb(255,255,255)"=
><br></span></div><div><span style=3D"background-color:rgb(255,255,255)">A =
few &quot;inflammatory&quot;=C2=A0questions:</span></div><div><span style=
=3D"background-color:rgb(255,255,255)"><br></span></div><div><span style=3D=
"background-color:rgb(255,255,255)">1) Should C++ have a standard (obvious)=
 way to subvert the defined access right of given class?</span></div></div>=
</blockquote><div><br>No.<br></div></div></blockquote><div><br></div><div>P=
eople will do it anyway. And it&#39;s not obvious or easy to find that in c=
ode when they do.</div><div>At least having a standard way would make it ea=
sier for humans and tools to deal with that.<br></div><div>It&#39;s just ea=
sier to maintain code that clearly states the programmer intentions (withou=
t having to rely in comments).</div><div><br></div><blockquote class=3D"gma=
il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-le=
ft-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div di=
r=3D"ltr"><div></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);bord=
er-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div><span style=3D"=
background-color:rgb(255,255,255)"></span></div><div><span style=3D"backgro=
und-color:rgb(255,255,255)">2) If no, access rights should be followed stri=
ctly, does that also applies to a future reflection support?</span></div></=
div></blockquote><div><br>Reflection does not exist to break access control=
s. It has to be able to do that in order for it to do its job, but that isn=
&#39;t its purpose, nor would it be an &quot;obvious&quot; way to break acc=
ess controls.<br></div></div></blockquote><div><br></div><div>Agreed. But a=
re you implying C++ reflection should allow it then?</div><div><br></div><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 dir=3D"ltr"><div>=C2=A0=C2=A0</div></div></blockquote><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa=
dding-left:1ex"><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,2=
04,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div></d=
iv><div><span style=3D"background-color:rgb(255,255,255)">3) If yes, reflec=
tion should be the way to do it, why using the standard way (in this case r=
eflection) should cost more than the non-standard options? (in this case, p=
otentially adding some compile-time cost).</span></div></div></blockquote><=
div><br>Because we shouldn&#39;t make it easy for people to do stupid thing=
s.<br></div></div></blockquote><div><br></div><div>I also agree, but...</di=
v><div>const_cast, reinterpret_cast, or getting pointers to internal refere=
nces returned by members, etc.</div><div>All stupid things easy to be done =
while having no cost in terms of compilation time, resource usage.<br></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><br></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-wid=
th:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-l=
eft:1ex"><div dir=3D"ltr"><div><div>4) If yes, the fact reflection is the c=
ommon solution in other languages (such as Java, C#) for subverting access =
rights,</div></div></div></blockquote><div><br>Again, that&#39;s not what r=
eflection is <i>for</i>. It can do that, but that&#39;s not its purpose.<br=
><br></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-st=
yle:solid;padding-left:1ex"><div dir=3D"ltr"><div><span style=3D"background=
-color:rgb(255,255,255)">5) If not even reflection should be allowed to do =
it, should then the users of language keep resorting to dirty tricks to, le=
t&#39;s say, serialize the contents of a class? (think third-party code, in=
 particular).</span></div></div></blockquote><div><br>Do you really think t=
hat you could reasonably serialize the contents of a class that you didn&#3=
9;t create, cannot modify, and don&#39;t even know the meaning of the data =
it stores?<br><br></div></div></blockquote><div>=C2=A0</div><div>The reason=
ability of it depends on the level of knowledge one have about such piece o=
f code. It may be your own code that for some reason you can&#39;t retrofit=
 support for serialization on it.</div><div>Yes, it&#39;s certainly not the=
 more correct approach and by doing it you are incurring certain risks. But=
 there&#39;s the theory and the practice.</div><div>=C2=A0<br></div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-wi=
dth:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-=
left:1ex"><div dir=3D"ltr"><div>Oh sure, you may be able to access the <i>v=
alues</i>, writing them to a file and read them back. But without knowing t=
he <i>meaning</i> of them (and no, the type is not sufficient), you have <i=
>no clue</i> if merely reading those values back will actually accomplish t=
he goal of creating a functional object, with all of that class&#39;s invar=
iants intact.<br>=C2=A0<br></div></div></blockquote><blockquote class=3D"gm=
ail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-l=
eft-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div d=
ir=3D"ltr"><div>As a simple example, what if there&#39;s a class that has a=
 `int`. You might just write that out and read it back later. But what if t=
his value is sourced from a monotonically increasing value somewhere? And t=
hus, when you recreate it, you shouldn&#39;t just read the value you wrote.=
 You have to talk to the monotonically increasing value and regenerate this=
 number at deserialization time.<br><br></div></div></blockquote><div><br><=
/div><div><div>Like I said, it depends how much you know about the code. So=
 sometimes you know the meaning and you can trust that.</div><div><br></div=
><div>There&#39;s also the question of doing certain operations such as ser=
ialization in a non-invasive manner. Or &quot;make it public for just this =
operation&quot;.</div><div>For example, I may want to serialize std::string=
 the way it has been implemented to preserve any optimizations such as smal=
l buffer optimization.<br></div><div>Definitely, no one will make these imp=
lementation-specific members public.</div><div>Creating my own serializatio=
n-aware type just blow away my goals of preserving the characteristics of t=
he original type I wanted to serialize.<br></div><div><br></div><div>Let&#3=
9;s suppose a future reflection support gives me such power.<br></div><div>=
Suppose that dissecting std::string with reflection having the goal of seri=
alization in mind incurs an horrendous compile time cost and then I just re=
sort to other non-standard ways.</div><div>I just made a complex piece of c=
ode even more complex and less maintainable because the language &quot;got =
in my way&quot;.</div></div><div><br></div><div>=C2=A0</div><blockquote cla=
ss=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>Whether you have access to a type&#39;s privates or=
 not, you <i>cannot</i> effectively serialize a type without that type&#39;=
s knowledge or <i>explicit consent</i>.<br><div dir=3D"ltr">So users of the=
 language shouldn&#39;t be &quot;resorting to dirty tricks&quot; to seriali=
ze other people&#39;s types at all. It simply is non-functional in the gene=
ral case.<span class=3D""><font color=3D"#888888"><br></font></span></div><=
span class=3D""><font color=3D"#888888"><p></p></font></span></div></div></=
blockquote><div>This technically sound, but it may be not practical. Forcin=
g people that way is just asking for having workarounds that are a lot of b=
oilerplate code or a collection of dirty tricks.<br></div><div><br></div><d=
iv>IMO, there must be a balance between theory and practice in a programmin=
g language.</div><div>Trying find the right balance for this specific matte=
r with this discussion.</div><div>=C2=A0</div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-co=
lor:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"=
ltr"><div><span style=3D"color:rgb(136,136,136)">--=C2=A0</span><br></div><=
/div><span class=3D""><font color=3D"#888888">
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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/de4ba8f4-55c3-417b-ab44-61e54596df4b%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/de4ba8f4-55c3-=
417b-ab44-61e54596df4b%40isocpp.org</a>.<br>
</font></span></blockquote></div><br></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CA%2BfGSbNUOg59FDrUux0DUKi-vZ9m7Ec7Fu=
%2B_%2B3Y-Q4dhAZMUvA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BfGSbNU=
Og59FDrUux0DUKi-vZ9m7Ec7Fu%2B_%2B3Y-Q4dhAZMUvA%40mail.gmail.com</a>.<br />

--94eb2c124e6a2b649805315249ec--

.

On 2016-04-25 11:47, Nicol Bolas wrote:
> On Monday, April 25, 2016 at 12:16:40 AM UTC-4, Ricardo Andrade wrote:
>> 2) If no, access rights should be followed strictly, does that also applies
>> to a future reflection support?
>
> Reflection [...] has to be able to do that in order for it to do its job

Really? I think that depends on the implementation. At least some of the
proposals discussed at Jacksonville would only expose those parts of the
class that were visible anyway at the point reflection is used. I would
define that as reflection which a) works and b) obeys access rights,
thus falsifying your assertion.

On 2016-04-25 13:12, Ricardo Fabiano de Andrade wrote:
> There's also the question of doing certain operations such as serialization
> in a non-invasive manner. Or "make it public for just this operation".

The aforementioned reflection mechanisms would allow this (via friends).

--
Matthew

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/nflju1%24sv4%241%40ger.gmane.org.

.

On 25 April 2016 at 20:25, Matthew Woehlke <mwoehlke.floss@gmail.com> wrote:
> On 2016-04-25 11:47, Nicol Bolas wrote:
>> On Monday, April 25, 2016 at 12:16:40 AM UTC-4, Ricardo Andrade wrote:
>>> 2) If no, access rights should be followed strictly, does that also applies
>>> to a future reflection support?
>>
>> Reflection [...] has to be able to do that in order for it to do its job
>
> Really? I think that depends on the implementation. At least some of the
> proposals discussed at Jacksonville would only expose those parts of the
> class that were visible anyway at the point reflection is used. I would
> define that as reflection which a) works and b) obeys access rights,
> thus falsifying your assertion.
>
> On 2016-04-25 13:12, Ricardo Fabiano de Andrade wrote:
>> There's also the question of doing certain operations such as serialization
>> in a non-invasive manner. Or "make it public for just this operation".
>
> The aforementioned reflection mechanisms would allow this (via friends).

http://open-std.org/JTC1/SC22/WG21/docs/papers/2016/p0194r0.pdf
allows accessing all data members without requiring friends to be
used. It also allows
accessing just public members, and various combinations. In SG7 discussions
it has been amply explained why being able to get to the private parts
is sometimes
important, and it has also been explained why some audiences want to easily
grep whether such reach-into-privates are used in some codebase, and possibly
ban such usages.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUbarSOgFFy%3DBM3XLP6hvWqrCcxQxxPqoS1CcGZmSgRp7g%40mail.gmail.com.

.

------=_Part_599_1983302150.1461608705730
Content-Type: multipart/alternative;
 boundary="----=_Part_600_1478804388.1461608705731"

------=_Part_600_1478804388.1461608705731
Content-Type: text/plain; charset=UTF-8



On Monday, April 25, 2016 at 1:12:49 PM UTC-4, Ricardo Andrade wrote:
>
> Hi Nicol, I knew those would be your answers :)
> I appreciate you reply and I'll leave a few additional comments.
>
> On Mon, Apr 25, 2016 at 10:47 AM, Nicol Bolas <jmck...@gmail.com
> <javascript:>> wrote:
>
>> On Monday, April 25, 2016 at 12:16:40 AM UTC-4, Ricardo Andrade wrote:
>>>
>>> Quoting Herb Sutter's "GotW #76"[1] this is about "*liars, cheats,
>>> pickpockets, and thieves*" (but have Robin Hood in mind) and "*protecting
>>> against Murphy vs. protecting against Machiavelli*".
>>>
>>> A few "inflammatory" questions:
>>>
>>> 1) Should C++ have a standard (obvious) way to subvert the defined
>>> access right of given class?
>>>
>>
>> No.
>>
>
> People will do it anyway. And it's not obvious or easy to find that in
> code when they do.
>

Yes, but pretty much every way to do that violates that C++ standard.

At least having a standard way would make it easier for humans and tools to
> deal with that.
> It's just easier to maintain code that clearly states the programmer
> intentions (without having to rely in comments).
>

We shouldn't do something just because a certain class of programmers
choose to do it in spite of the standard. There are things that we
shouldn't make "easier to maintain".

We shouldn't standardize bad code.

2) If no, access rights should be followed strictly, does that also applies
>>> to a future reflection support?
>>>
>>
>> Reflection does not exist to break access controls. It has to be able to
>> do that in order for it to do its job, but that isn't its purpose, nor
>> would it be an "obvious" way to break access controls.
>>
>
> Agreed. But are you implying C++ reflection should allow it then?
>

That's up to the reflection people. Personally, I would prefer it if
reflection would restrict your access based on where you were when you
initiated the reflection (P0194's get_all_data_members could not be invoked
on a type unless your code directly had private access, for example). But
that's for them to decide, based on the needs of reflection.

What C++ should not have is a facility who's primary purpose is to violate
access controls.

3) If yes, reflection should be the way to do it, why using the standard
>>> way (in this case reflection) should cost more than the non-standard
>>> options? (in this case, potentially adding some compile-time cost).
>>>
>>
>> Because we shouldn't make it easy for people to do stupid things.
>>
>
> I also agree, but...
> const_cast, reinterpret_cast, or getting pointers to internal references
> returned by members, etc.
> All stupid things easy to be done while having no cost in terms of
> compilation time, resource usage.
>

That sounds like a very good and convincing argument for not to *adding* to
that list.

Oh sure, you may be able to access the *values*, writing them to a file and
>> read them back. But without knowing the *meaning* of them (and no, the
>> type is not sufficient), you have *no clue* if merely reading those
>> values back will actually accomplish the goal of creating a functional
>> object, with all of that class's invariants intact.
>>
>>
> As a simple example, what if there's a class that has a `int`. You might
>> just write that out and read it back later. But what if this value is
>> sourced from a monotonically increasing value somewhere? And thus, when you
>> recreate it, you shouldn't just read the value you wrote. You have to talk
>> to the monotonically increasing value and regenerate this number at
>> deserialization time.
>>
>>
> Like I said, it depends how much you know about the code. So sometimes you
> know the meaning and you can trust that.
>

And sometimes you don't know the meaning. And sometimes, people think they
do but actually don't. And sometimes, people just don't think at all and
simply believe that the tool that worked on all these other types will work
on this new type too.

Fragile code is fragile.

There's also the question of doing certain operations such as serialization
> in a non-invasive manner. Or "make it public for just this operation".
> For example, I may want to serialize std::string the way it has been
> implemented to preserve any optimizations such as small buffer optimization.
> Definitely, no one will make these implementation-specific members public.
> Creating my own serialization-aware type just blow away my goals of
> preserving the characteristics of the original type I wanted to serialize.
>

Let's take your example at face value. You have intimate knowledge of how
that `basic_string` implementation works. You know well what it does and
how to interact with it. It uses SSO, and you know exactly how many
characters it uses.

What does your serialized data look like? It has to have a sequence of
characters and it has to have a length. So what more exactly is it that you
plan on serializing? Do you need to write how many SSO characters the
buffer has? No; you can't use that information when reading it back, since
it's a *static* property of the particular instantiation of `basic_string`.
The only thing you would do when serializing it back is check the string's
length and use the SSO buffer if it's below that length.

Which `basic_string`'s constructor will do for you.

In short, the *only data* you need to write when serializing a
`basic_string`, with SSO and so forth intact, are the array of characters
and its length. All of which are public information and both of which can
be provided to a `basic_string` constructor.

So why do you need to look at `basic_string`'s privates?

Let's suppose a future reflection support gives me such power.
> Suppose that dissecting std::string with reflection having the goal of
> serialization in mind incurs an horrendous compile time cost and then I
> just resort to other non-standard ways.
> I just made a complex piece of code even more complex and less
> maintainable because the language "got in my way".
>

No, the language did not "got in my way." A *person* got in your way.

You do not have the right to access the private members of an object. *That's
what private members are for!* For the language to make it easy to violate
this completely defeats the purpose of the construct.

If I declare something to be `private`, I want it to be *private*. If you
want it to not be private, I have no problem with you having to resort to
ugly non-standard hacks or template metaprogramming. That's what
encapsulation is for. It's not a *guarantee*, but you must commit a
deliberate and clear act of perfidy to do so.

We should not standardize *perfidy*.

Whether you have access to a type's privates or not, you *cannot*
>> effectively serialize a type without that type's knowledge or *explicit
>> consent*.
>> So users of the language shouldn't be "resorting to dirty tricks" to
>> serialize other people's types at all. It simply is non-functional in the
>> general case.
>>
>> This technically sound, but it may be not practical. Forcing people that
> way is just asking for having workarounds that are a lot of boilerplate
> code or a collection of dirty tricks.
>

You say that as if it's a bad thing. Dirty things should look dirty. Unsafe
code should look unsafe.

And a serialization system built on the idea that it can serialize anything
without that types knowledge is unsafe. It may work in many cases. But so
does naked use of `new` and `delete`.

IMO, there must be a balance between theory and practice in a programming
> language.
> Trying find the right balance for this specific matter with this
> discussion.
>

I don't see what's wrong with the current balance.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/37a4f22c-4c74-4398-ae2f-b4b5b90e3796%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Monday, April 25, 2016 at 1:12:49 PM UTC-4, Ric=
ardo Andrade wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D=
"ltr">Hi Nicol, I knew those would be your answers :)<div>I appreciate you =
reply and I&#39;ll leave a few additional comments.</div><div><br></div><di=
v><div><div class=3D"gmail_quote">On Mon, Apr 25, 2016 at 10:47 AM, Nicol B=
olas <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-ob=
fuscated-mailto=3D"zCMEY0zXBwAJ" rel=3D"nofollow" onmousedown=3D"this.href=
=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascri=
pt:&#39;;return true;">jmck...@gmail.com</a>&gt;</span> wrote:<br><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-widt=
h:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-le=
ft:1ex"><div dir=3D"ltr">On Monday, April 25, 2016 at 12:16:40 AM UTC-4, Ri=
cardo Andrade wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);borde=
r-left-style:solid;padding-left:1ex"><div dir=3D"ltr">Quoting Herb Sutter&#=
39;s &quot;GotW #76&quot;[1] this is abou<span style=3D"background-color:rg=
b(255,255,255)">t &quot;<i style=3D"color:rgb(0,0,0);font-family:Arial,Aria=
l,Helvetica;font-size:13.3333px">liars, cheats, pickpockets, and thieves</i=
>&quot; (but have Robin Hood in mind) and &quot;<span style=3D"color:rgb(0,=
0,0);font-family:Arial,Arial,Helvetica;font-size:13.3333px"><i>protecting a=
gainst Murphy vs. protecting against Machiavelli</i></span>&quot;.</span><d=
iv><span style=3D"background-color:rgb(255,255,255)"><br></span></div><div>=
<span style=3D"background-color:rgb(255,255,255)">A few &quot;inflammatory&=
quot;=C2=A0questions:</span></div><div><span style=3D"background-color:rgb(=
255,255,255)"><br></span></div><div><span style=3D"background-color:rgb(255=
,255,255)">1) Should C++ have a standard (obvious) way to subvert the defin=
ed access right of given class?</span></div></div></blockquote><div><br>No.=
<br></div></div></blockquote><div><br></div><div>People will do it anyway. =
And it&#39;s not obvious or easy to find that in code when they do.</div></=
div></div></div></div></blockquote><div><br>Yes, but pretty much every way =
to do that violates that C++ standard.<br><br></div><blockquote class=3D"gm=
ail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc soli=
d;padding-left: 1ex;"><div dir=3D"ltr"><div><div><div class=3D"gmail_quote"=
><div>At least having a standard way would make it easier for humans and to=
ols to deal with that.<br></div><div>It&#39;s just easier to maintain code =
that clearly states the programmer intentions (without having to rely in co=
mments).</div></div></div></div></div></blockquote><div><br>We shouldn&#39;=
t do something just because a certain class of programmers choose to do it =
in spite of the standard. There are things that we shouldn&#39;t make &quot=
;easier to maintain&quot;.<br><br>We shouldn&#39;t standardize bad code.<br=
><br></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"><d=
iv><div><div class=3D"gmail_quote"><div></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-co=
lor:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"=
ltr"><div></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-le=
ft-style:solid;padding-left:1ex"><div dir=3D"ltr"><div><span style=3D"backg=
round-color:rgb(255,255,255)"></span></div><div><span style=3D"background-c=
olor:rgb(255,255,255)">2) If no, access rights should be followed strictly,=
 does that also applies to a future reflection support?</span></div></div><=
/blockquote><div><br>Reflection does not exist to break access controls. It=
 has to be able to do that in order for it to do its job, but that isn&#39;=
t its purpose, nor would it be an &quot;obvious&quot; way to break access c=
ontrols.<br></div></div></blockquote><div><br></div><div>Agreed. But are yo=
u implying C++ reflection should allow it then?</div></div></div></div></di=
v></blockquote><div><br>That&#39;s up to the reflection people. Personally,=
 I would prefer it if reflection would restrict your access based on where =
you were when you initiated the reflection (P0194&#39;s get_all_data_member=
s could not be invoked on a type unless your code directly had private acce=
ss, for example). But that&#39;s for them to decide, based on the needs of =
reflection.<br><br>What C++ should not have is a facility who&#39;s primary=
 purpose is to violate access controls.<br><br></div><blockquote class=3D"g=
mail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc sol=
id;padding-left: 1ex;"><div dir=3D"ltr"><div><div><div class=3D"gmail_quote=
"><div></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></div></div></blockquot=
e><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid=
;padding-left:1ex"><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(20=
4,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div>=
</div><div><span style=3D"background-color:rgb(255,255,255)">3) If yes, ref=
lection should be the way to do it, why using the standard way (in this cas=
e reflection) should cost more than the non-standard options? (in this case=
, potentially adding some compile-time cost).</span></div></div></blockquot=
e><div><br>Because we shouldn&#39;t make it easy for people to do stupid th=
ings.<br></div></div></blockquote><div><br></div><div>I also agree, but...<=
/div><div>const_cast, reinterpret_cast, or getting pointers to internal ref=
erences returned by members, etc.</div><div>All stupid things easy to be do=
ne while having no cost in terms of compilation time, resource usage.<br></=
div></div></div></div></div></blockquote><div><br>That sounds like a very g=
ood and convincing argument for not to <i>adding</i> to that list.<br><br><=
/div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><di=
v><div class=3D"gmail_quote"><div></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></div></block=
quote></div></div></div></div></blockquote><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><div class=3D"gmail_quote"><div></d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord=
er-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:soli=
d;padding-left:1ex"><div dir=3D"ltr"><div>Oh sure, you may be able to acces=
s the <i>values</i>, writing them to a file and read them back. But without=
 knowing the <i>meaning</i> of them (and no, the type is not sufficient), y=
ou have <i>no clue</i> if merely reading those values back will actually ac=
complish the goal of creating a functional object, with all of that class&#=
39;s invariants intact.<br>=C2=A0<br></div></div></blockquote><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1p=
x;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1=
ex"><div dir=3D"ltr"><div>As a simple example, what if there&#39;s a class =
that has a `int`. You might just write that out and read it back later. But=
 what if this value is sourced from a monotonically increasing value somewh=
ere? And thus, when you recreate it, you shouldn&#39;t just read the value =
you wrote. You have to talk to the monotonically increasing value and regen=
erate this number at deserialization time.<br><br></div></div></blockquote>=
<div><br></div><div><div>Like I said, it depends how much you know about th=
e code. So sometimes you know the meaning and you can trust that.</div></di=
v></div></div></div></div></blockquote><div><br>And sometimes you don&#39;t=
 know the meaning. And sometimes, people think they do but actually don&#39=
;t. And sometimes, people just don&#39;t think at all and simply believe th=
at the tool that worked on all these other types will work on this new type=
 too.<br><br>Fragile code is fragile.<br><br></div><blockquote class=3D"gma=
il_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid=
;padding-left: 1ex;"><div dir=3D"ltr"><div><div><div class=3D"gmail_quote">=
<div><div></div><div>There&#39;s also the question of doing certain operati=
ons such as serialization in a non-invasive manner. Or &quot;make it public=
 for just this operation&quot;.</div><div>For example, I may want to serial=
ize std::string the way it has been implemented to preserve any optimizatio=
ns such as small buffer optimization.<br></div><div>Definitely, no one will=
 make these implementation-specific members public.</div><div>Creating my o=
wn serialization-aware type just blow away my goals of preserving the chara=
cteristics of the original type I wanted to serialize.<br></div></div></div=
></div></div></div></blockquote><div><br>Let&#39;s take your example at fac=
e value. You have intimate knowledge of how that `basic_string` implementat=
ion works. You know well what it does and how to interact with it. It uses =
SSO, and you know exactly how many characters it uses.<br><br>What does you=
r serialized data look like? It has to have a sequence of characters and it=
 has to have a length. So what more exactly is it that you plan on serializ=
ing? Do you need to write how many SSO characters the buffer has? No; you c=
an&#39;t use that information when reading it back, since it&#39;s a <i>sta=
tic</i> property of the particular instantiation of `basic_string`. The onl=
y thing you would do when serializing it back is check the string&#39;s len=
gth and use the SSO buffer if it&#39;s below that length.<br><br>Which `bas=
ic_string`&#39;s constructor will do for you.<br><br>In short, the <i>only =
data</i> you need to write when serializing a `basic_string`, with SSO and =
so forth intact, are the array of characters and its length. All of which a=
re public information and both of which can be provided to a `basic_string`=
 constructor.<br><br>So why do you need to look at `basic_string`&#39;s pri=
vates?<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div><div><div class=3D"gmail_quote"><div><div></div><div></div><d=
iv>Let&#39;s suppose a future reflection support gives me such power.<br></=
div><div>Suppose that dissecting std::string with reflection having the goa=
l of serialization in mind incurs an horrendous compile time cost and then =
I just resort to other non-standard ways.</div><div>I just made a complex p=
iece of code even more complex and less maintainable because the language &=
quot;got in my way&quot;.</div></div></div></div></div></div></blockquote><=
div><br>No, the language did not &quot;got in my way.&quot; A <i>person</i>=
 got in your way.<br><br>You do not have the right to access the private me=
mbers of an object. <i>That&#39;s what private members are for!</i> For the=
 language to make it easy to violate this completely defeats the purpose of=
 the construct.<br><br>If I declare something to be `private`, I want it to=
 be <i>private</i>. If you want it to not be private, I have no problem wit=
h you having to resort to ugly non-standard hacks or template metaprogrammi=
ng. That&#39;s what encapsulation is for. It&#39;s not a <i>guarantee</i>, =
but you must commit a deliberate and clear act of perfidy to do so.<br><br>=
We should not standardize <i>perfidy</i>.<br><br></div><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"><div><div><div class=3D"gmail_quo=
te"><div></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>Whether you have acce=
ss to a type&#39;s privates or not, you <i>cannot</i> effectively serialize=
 a type without that type&#39;s knowledge or <i>explicit consent</i>.<br><d=
iv dir=3D"ltr">So users of the language shouldn&#39;t be &quot;resorting to=
 dirty tricks&quot; to serialize other people&#39;s types at all. It simply=
 is non-functional in the general case.<span><font color=3D"#888888"><br></=
font></span></div><span><font color=3D"#888888"><p></p></font></span></div>=
</div></blockquote><div>This technically sound, but it may be not practical=
.. Forcing people that way is just asking for having workarounds that are a =
lot of boilerplate code or a collection of dirty tricks.<br></div></div></d=
iv></div></div></blockquote><div><br>You say that as if it&#39;s a bad thin=
g. Dirty things should look dirty. Unsafe code should look unsafe.<br><br>A=
nd a serialization system built on the idea that it can serialize anything =
without that types knowledge is unsafe. It may work in many cases. But so d=
oes naked use of `new` and `delete`.<br><br></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><div class=3D"gmail_quote"><=
div></div><div></div><div>IMO, there must be a balance between theory and p=
ractice in a programming language.</div><div>Trying find the right balance =
for this specific matter with this discussion.<br></div></div></div></div><=
/div></blockquote><div><br>I don&#39;t see what&#39;s wrong with the curren=
t balance.<br></div></div>

<p></p>

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

------=_Part_600_1478804388.1461608705731--
------=_Part_599_1983302150.1461608705730--

.

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

Hi Ville,

This reflection proposal and the decisions around it are the main
motivation behind for my initial post.
I should not have assumed others would know about its existence and current
direction, so I appreciate your comments and the fact you have linked to it.

That said, my concerns is that this reflection proposal introduces a new,
standard way to violate encapsulation.
However, it has some costs both in terms of computing resources - time to
compile, program size - and human resources - time to learn reflection and
template meta-programming and apply these effectively and consistently.
Which may lead to people ditching it and keep using the existing "dirty"
ways, which are difficult to identify in the code.

It's introducing just another a new way to do it, but some may not see it
as *the definitive*, way.

Using Nicol's argument in the opposite direction, reflection does exist to
violate encapsulation but it will be used with this purpose.
Then comes the question that maybe it would be better to allow this to be
done outside of the context of reflection (so reflection would not be used
when it's not necessary).
Being also the main reason why this is not being discussed in the SG7 group.

I wish I didn't have to bring this up to discussion but since we cannot
(and may not want to) prevent people from doing it, I hope at least we can
get some ideas out of it.

Best,
Ricardo


On Mon, Apr 25, 2016 at 12:40 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:

> On 25 April 2016 at 20:25, Matthew Woehlke <mwoehlke.floss@gmail.com>
> wrote:
> > On 2016-04-25 11:47, Nicol Bolas wrote:
> >> On Monday, April 25, 2016 at 12:16:40 AM UTC-4, Ricardo Andrade wrote:
> >>> 2) If no, access rights should be followed strictly, does that also
> applies
> >>> to a future reflection support?
> >>
> >> Reflection [...] has to be able to do that in order for it to do its job
> >
> > Really? I think that depends on the implementation. At least some of the
> > proposals discussed at Jacksonville would only expose those parts of the
> > class that were visible anyway at the point reflection is used. I would
> > define that as reflection which a) works and b) obeys access rights,
> > thus falsifying your assertion.
> >
> > On 2016-04-25 13:12, Ricardo Fabiano de Andrade wrote:
> >> There's also the question of doing certain operations such as
> serialization
> >> in a non-invasive manner. Or "make it public for just this operation".
> >
> > The aforementioned reflection mechanisms would allow this (via friends).
>
> http://open-std.org/JTC1/SC22/WG21/docs/papers/2016/p0194r0.pdf
> allows accessing all data members without requiring friends to be
> used. It also allows
> accessing just public members, and various combinations. In SG7 discussions
> it has been amply explained why being able to get to the private parts
> is sometimes
> important, and it has also been explained why some audiences want to easily
> grep whether such reach-into-privates are used in some codebase, and
> possibly
> ban such usages.
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUbarSOgFFy%3DBM3XLP6hvWqrCcxQxxPqoS1CcGZmSgRp7g%40mail.gmail.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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BfGSbMkr1W%3Dhj8%3D2eSjHUGMYjgh%3Dj7y2wnZ0JRgqrvPV85Qiw%40mail.gmail.com.

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

<div dir=3D"ltr">Hi Ville,<div><br></div><div>This reflection proposal and =
the decisions around it are the main motivation behind for my initial post.=
<br></div><div>I should not have assumed others would know about its existe=
nce and current direction, so I appreciate your comments and the fact you h=
ave linked to it.</div><div><br></div><div>That said, my concerns is that t=
his reflection proposal introduces a new, standard way to violate encapsula=
tion.</div><div>However, it has some costs both in terms of computing resou=
rces - time to compile, program size - and human resources - time to learn =
reflection and template meta-programming and apply these effectively and co=
nsistently.</div><div>Which may lead to people ditching it and keep using t=
he existing &quot;dirty&quot; ways, which are difficult to identify in the =
code.</div><div><br></div><div>It&#39;s introducing just another a new way =
to do it, but some may not see it as <i>the definitive</i>, way.</div><div>=
<br></div><div>Using Nicol&#39;s argument in the opposite direction, reflec=
tion does exist to violate encapsulation but it will be used with this purp=
ose.</div><div>Then comes the question that maybe it would be better to all=
ow this to be done outside of the context of reflection (so reflection woul=
d not be used when it&#39;s not necessary).</div><div>Being also the main r=
eason why this is not being discussed in the SG7 group.<br></div><div><br><=
/div><div>I wish I didn&#39;t have to bring this up to discussion but since=
 we cannot (and may not want to) prevent people from doing it, I hope at le=
ast we can get some ideas out of it.</div><div><br></div><div>Best,</div><d=
iv>Ricardo</div><div><br></div></div><div class=3D"gmail_extra"><br><div cl=
ass=3D"gmail_quote">On Mon, Apr 25, 2016 at 12:40 PM, Ville Voutilainen <sp=
an 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 c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex">On 25 April 2016 at 20:25, Matthew Woehlke &lt;<a href=3D=
"mailto:mwoehlke.floss@gmail.com">mwoehlke.floss@gmail.com</a>&gt; wrote:<b=
r>
&gt; On 2016-04-25 11:47, Nicol Bolas wrote:<br>
&gt;&gt; On Monday, April 25, 2016 at 12:16:40 AM UTC-4, Ricardo Andrade wr=
ote:<br>
&gt;&gt;&gt; 2) If no, access rights should be followed strictly, does that=
 also applies<br>
&gt;&gt;&gt; to a future reflection support?<br>
&gt;&gt;<br>
&gt;&gt; Reflection [...] has to be able to do that in order for it to do i=
ts job<br>
&gt;<br>
&gt; Really? I think that depends on the implementation. At least some of t=
he<br>
&gt; proposals discussed at Jacksonville would only expose those parts of t=
he<br>
&gt; class that were visible anyway at the point reflection is used. I woul=
d<br>
&gt; define that as reflection which a) works and b) obeys access rights,<b=
r>
&gt; thus falsifying your assertion.<br>
&gt;<br>
&gt; On 2016-04-25 13:12, Ricardo Fabiano de Andrade wrote:<br>
&gt;&gt; There&#39;s also the question of doing certain operations such as =
serialization<br>
&gt;&gt; in a non-invasive manner. Or &quot;make it public for just this op=
eration&quot;.<br>
&gt;<br>
&gt; The aforementioned reflection mechanisms would allow this (via friends=
).<br>
<br>
<a href=3D"http://open-std.org/JTC1/SC22/WG21/docs/papers/2016/p0194r0.pdf"=
 rel=3D"noreferrer" target=3D"_blank">http://open-std.org/JTC1/SC22/WG21/do=
cs/papers/2016/p0194r0.pdf</a><br>
allows accessing all data members without requiring friends to be<br>
used. It also allows<br>
accessing just public members, and various combinations. In SG7 discussions=
<br>
it has been amply explained why being able to get to the private parts<br>
is sometimes<br>
important, and it has also been explained why some audiences want to easily=
<br>
grep whether such reach-into-privates are used in some codebase, and possib=
ly<br>
ban such usages.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAFk2RUbarSOgFFy%3DBM3XLP6hvWqrCcxQxx=
PqoS1CcGZmSgRp7g%40mail.gmail.com" rel=3D"noreferrer" target=3D"_blank">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUbarSOgFFy%=
3DBM3XLP6hvWqrCcxQxxPqoS1CcGZmSgRp7g%40mail.gmail.com</a>.<br>
</font></span></blockquote></div><br></div>

<p></p>

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

--94eb2c04137c8f412305315479e2--

.

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

On 25 April 2016 at 13:25, Nicol Bolas <jmckesson@gmail.com> wrote:

>
> People will do it anyway. And it's not obvious or easy to find that in
> code when they do.
>
> Yes, but pretty much every way to do that violates that C++ standard.
>

I don't think specializing a templated function is technically a violation,
but I will agree that most of them are.


> That's up to the reflection people. Personally, I would prefer it if
> reflection would restrict your access based on where you were when you
> initiated the reflection (P0194's get_all_data_members could not be invoked
> on a type unless your code directly had private access, for example). But
> that's for them to decide, based on the needs of reflection.
>

Suppose you have a class with generated copy/move constructor/assignment
operators, destructor and relation operators (assuming that makes it into
C++17 and the version is opt-out, so no syntax required to get it).  There
is a very good chance that a library using reflection could very easily
generate a correct hash function, (de)serialization function, etc.  The
question becomes:  should we just allow it to work, or must it be opt-in?
Some folks do have a burden where they may not be allowed to edit existing
header files (for both technical and non-technical reasons).


> For example, I may want to serialize std::string the way it has been
>> implemented to preserve any optimizations such as small buffer optimization.
>>
>
Wanting to reflect on the standard library may be disallowed by the
standard.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  +1-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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BOKZUjS1fPAORz-MdEVfXHw%3DKFtby8YJ2nFtOGvaFSM5A%40mail.gmail.com.

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

<div dir=3D"ltr">On 25 April 2016 at 13:25, Nicol Bolas <span dir=3D"ltr">&=
lt;<a href=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail=
..com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmai=
l_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span class=3D""><=
br>People will do it anyway. And it&#39;s not obvious or easy to find that =
in code when they do.<br></span><div><br>Yes, but pretty much every way to =
do that violates that C++ standard.<br></div></div></blockquote><div><br></=
div><div>I don&#39;t think specializing a templated function is technically=
 a violation, but I will agree that most of them are.</div><div>=C2=A0</div=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>That&#39;s up to the =
reflection people. Personally, I would prefer it if reflection would restri=
ct your access based on where you were when you initiated the reflection (P=
0194&#39;s get_all_data_members could not be invoked on a type unless your =
code directly had private access, for example). But that&#39;s for them to =
decide, based on the needs of reflection.<br></div></div></blockquote><div>=
<br></div><div>Suppose you have a class with generated copy/move constructo=
r/assignment operators, destructor and relation operators (assuming that ma=
kes it into C++17 and the version is opt-out, so no syntax required to get =
it).=C2=A0 There is a very good chance that a library using reflection coul=
d very easily generate a correct hash function, (de)serialization function,=
 etc.=C2=A0 The question becomes: =C2=A0should we just allow it to work, or=
 must it be opt-in?=C2=A0 Some folks do have a burden where they may not be=
 allowed to edit existing header files (for both technical and non-technica=
l reasons).</div><div>=C2=A0</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"><span class=3D""><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><div class=3D"gmail_quote"><div><div>For example, I may =
want to serialize std::string the way it has been implemented to preserve a=
ny optimizations such as small buffer optimization.<br></div></div></div></=
div></div></div></blockquote></span></div></blockquote><div><br></div><div>=
Wanting to reflect on the standard library may be disallowed by the standar=
d.</div></div>-- <br><div class=3D"gmail_signature"><div dir=3D"ltr"><div><=
div dir=3D"ltr"><div>=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+1-847-691-1404</div></div></div></div></div>
</div></div>

<p></p>

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

--001a1134cff2cd82bb053154d3a3--

.

On 25 April 2016 at 22:49, Ricardo Fabiano de Andrade
<ricardofabianodeandrade@gmail.com> wrote:
> Hi Ville,
> That said, my concerns is that this reflection proposal introduces a new,
> standard way to violate encapsulation.

A way that is easy to find and ban, though.

> However, it has some costs both in terms of computing resources - time to
> compile, program size - and human resources - time to learn reflection and
> template meta-programming and apply these effectively and consistently.
> Which may lead to people ditching it and keep using the existing "dirty"
> ways, which are difficult to identify in the code.

I fail to see why that's such a concern. Bypassing access controls is indeed not
the main reason for reflection.

> Using Nicol's argument in the opposite direction, reflection does exist to
> violate encapsulation but it will be used with this purpose.

I presume that sentence is missing a "not".

> Then comes the question that maybe it would be better to allow this to be
> done outside of the context of reflection (so reflection would not be used
> when it's not necessary).
> Being also the main reason why this is not being discussed in the SG7 group.

I don't know what you think is not being discussed in SG7.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUa7b5RLP8BM_E%2B%3DguCi9hpKTLU7u1CQo054y_CEzdcoZg%40mail.gmail.com.

.

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

On Mon, Apr 25, 2016 at 3:27 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:

> On 25 April 2016 at 22:49, Ricardo Fabiano de Andrade
> <ricardofabianodeandrade@gmail.com> wrote:
> > Hi Ville,
> > That said, my concerns is that this reflection proposal introduces a new,
> > standard way to violate encapsulation.
>
> A way that is easy to find and ban, though.
>
>
Agreed. I don't think any alternative should be different.


> > However, it has some costs both in terms of computing resources - time to
> > compile, program size - and human resources - time to learn reflection
> and
> > template meta-programming and apply these effectively and consistently.
> > Which may lead to people ditching it and keep using the existing "dirty"
> > ways, which are difficult to identify in the code.
>
> I fail to see why that's such a concern. Bypassing access controls is
> indeed not
> the main reason for reflection.
>
>
For me it's a concern because either people will use it for this purpose
(making it easy to find and ban).
Or because it's relatively more difficult to be done, people will not use
it and the old ways will prevail (making it hard to find and nearly
impossible to ban).

> Using Nicol's argument in the opposite direction, reflection does exist to
> > violate encapsulation but it will be used with this purpose.
>
> I presume that sentence is missing a "not".
>

Correct, my apologies.


>
> > Then comes the question that maybe it would be better to allow this to be
> > done outside of the context of reflection (so reflection would not be
> used
> > when it's not necessary).
> > Being also the main reason why this is not being discussed in the SG7
> group.
>
> I don't know what you think is not being discussed in SG7.
>
>
I didn't make myself clear on that one.

You're right, this matter is being actively discussed by the SG7 in the
context of reflection.

My question is whether it should or not be discussed outside of the SG7 as
well (that's why I posted here).
And additionally, if a "good" (as costly as the alternatives, easy to find
and ban) mechanism for subverting access rights exists, there's no need to
add another one in reflection.
Not having this "functionality" in the reflection proposal (implicitly or
explicitly) also make it cleaner.


> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUa7b5RLP8BM_E%2B%3DguCi9hpKTLU7u1CQo054y_CEzdcoZg%40mail.gmail.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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BfGSbO_K50BSu-g%2BY76DeOSwdwATtc4DeHGB80z_mpgsCdgag%40mail.gmail.com.

--94eb2c04137cc275ba053156b020
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 M=
on, Apr 25, 2016 at 3:27 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" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(2=
04,204,204);border-left-style:solid;padding-left:1ex">On 25 April 2016 at 2=
2:49, Ricardo Fabiano de Andrade<br>
&lt;<a href=3D"mailto:ricardofabianodeandrade@gmail.com">ricardofabianodean=
drade@gmail.com</a>&gt; wrote:<br>
&gt; Hi Ville,<br>
&gt; That said, my concerns is that this reflection proposal introduces a n=
ew,<br>
&gt; standard way to violate encapsulation.<br>
<br>
A way that is easy to find and ban, though.<br>
<br></blockquote><div><br></div><div>Agreed. I don&#39;t think any alternat=
ive should be different.</div><div>=C2=A0<br></div><blockquote class=3D"gma=
il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-le=
ft-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
&gt; However, it has some costs both in terms of computing resources - time=
 to<br>
&gt; compile, program size - and human resources - time to learn reflection=
 and<br>
&gt; template meta-programming and apply these effectively and consistently=
..<br>
&gt; Which may lead to people ditching it and keep using the existing &quot=
;dirty&quot;<br>
&gt; ways, which are difficult to identify in the code.<br>
<br>
I fail to see why that&#39;s such a concern. Bypassing access controls is i=
ndeed not<br>
the main reason for reflection.<br>
<br></blockquote><div><br></div><div>For me it&#39;s a concern because=C2=
=A0either=C2=A0people will use it for this purpose (making it easy to find =
and ban).</div><div>Or because it&#39;s relatively more difficult to be don=
e, people will not use it and the old ways will prevail (making it hard to =
find and nearly impossible to ban).</div><div><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;bo=
rder-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
&gt; Using Nicol&#39;s argument in the opposite direction, reflection does =
exist to<br>
&gt; violate encapsulation but it will be used with this purpose.<br>
<br>
I presume that sentence is missing a &quot;not&quot;.<br></blockquote><div>=
<br></div><div>Correct, my apologies.</div><div>=C2=A0</div><blockquote cla=
ss=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=
">
<br>
&gt; Then comes the question that maybe it would be better to allow this to=
 be<br>
&gt; done outside of the context of reflection (so reflection would not be =
used<br>
&gt; when it&#39;s not necessary).<br>
&gt; Being also the main reason why this is not being discussed in the SG7 =
group.<br>
<br>
I don&#39;t know what you think is not being discussed in SG7.<br>
<span class=3D""><font color=3D"#888888"><br></font></span></blockquote><di=
v><br></div><div>I didn&#39;t make myself clear on that one.</div><div><br>=
</div><div>You&#39;re right, this matter is being actively discussed by the=
 SG7 in the context of reflection.</div><div><br></div><div>My question is =
whether=C2=A0it should=C2=A0or not be discussed outside of the SG7 as well =
(that&#39;s why I posted here).</div><div>And additionally, if a &quot;good=
&quot; (as costly as the alternatives, easy to find and ban) mechanism for =
subverting access rights exists, there&#39;s no need to add another one in =
reflection.</div><div>Not having this &quot;functionality&quot; in the refl=
ection proposal (implicitly or explicitly) also make it cleaner.</div><div>=
=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-le=
ft-style:solid;padding-left:1ex"><span class=3D""><font color=3D"#888888">
--<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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAFk2RUa7b5RLP8BM_E%2B%3DguCi9hpKTLU7=
u1CQo054y_CEzdcoZg%40mail.gmail.com" rel=3D"noreferrer" target=3D"_blank">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUa7b5RLP8=
BM_E%2B%3DguCi9hpKTLU7u1CQo054y_CEzdcoZg%40mail.gmail.com</a>.<br>
</font></span></blockquote></div><br></div></div>

<p></p>

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

--94eb2c04137cc275ba053156b020--

.

<html><head></head><body lang=3D"en-US" style=3D"background-color: rgb(255,=
 255, 255); line-height: initial;">                                        =
                                              <div style=3D"width: 100%; fo=
nt-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif=
; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, =
255, 255);">IMO:</div><div style=3D"width: 100%; font-size: initial; font-f=
amily: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125=
); text-align: initial; background-color: rgb(255, 255, 255);">- reflection=
 should not subvert access rights</div><div style=3D"width: 100%; font-size=
: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color=
: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 25=
5);">- neither should anything else</div><div style=3D"width: 100%; font-si=
ze: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; col=
or: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, =
255);"><br></div><div style=3D"width: 100%; font-size: initial; font-family=
: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); te=
xt-align: initial; background-color: rgb(255, 255, 255);">If the number one=
 reason is serialization, let's make some easier serialization library.&nbs=
p;</div><div style=3D"width: 100%; font-size: initial; font-family: Calibri=
, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align:=
 initial; background-color: rgb(255, 255, 255);"><br></div><div style=3D"wi=
dth: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-seri=
f, sans-serif; color: rgb(31, 73, 125); text-align: initial; background-col=
or: rgb(255, 255, 255);">I've had to support code that couldn't be changed =
because someone (someone important) was subverting access rights, and thus =
we couldn't break that code.&nbsp;</div><div style=3D"width: 100%; font-siz=
e: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; colo=
r: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 2=
55);"><br></div><div style=3D"width: 100%; font-size: initial; font-family:=
 Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); tex=
t-align: initial; background-color: rgb(255, 255, 255);">Think of the troub=
le DOS emulators need to go through due to people relying on undocumented h=
acks. Sure this will always exist, but do you want more of it or less?</div=
>                                                                          =
                                                           <div style=3D"wi=
dth: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-seri=
f, sans-serif; color: rgb(31, 73, 125); text-align: initial; background-col=
or: rgb(255, 255, 255);"><br style=3D"display:initial"></div>              =
                                                                           =
                                                                           =
                               <div style=3D"font-size: initial; font-famil=
y: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); t=
ext-align: initial; background-color: rgb(255, 255, 255);">Sent&nbsp;from&n=
bsp;my&nbsp;BlackBerry&nbsp;portable&nbsp;Babbage&nbsp;Device</div>        =
                                                                           =
                                                                           =
                    <table width=3D"100%" style=3D"background-color:white;b=
order-spacing:0px;"> <tbody><tr><td colspan=3D"2" style=3D"font-size: initi=
al; text-align: initial; background-color: rgb(255, 255, 255);">           =
                <div style=3D"border-style: solid none none; border-top-col=
or: rgb(181, 196, 223); border-top-width: 1pt; padding: 3pt 0in 0in; font-f=
amily: Tahoma, 'BB Alpha Sans', 'Slate Pro'; font-size: 10pt;">  <div><b>Fr=
om: </b>Ricardo Fabiano de Andrade</div><div><b>Sent: </b>Monday, April 25,=
 2016 6:28 PM</div><div><b>To: </b>std-proposals@isocpp.org</div><div><b>Re=
ply To: </b>std-proposals@isocpp.org</div><div><b>Subject: </b>Re: [std-pro=
posals] Re: About subverting access rights</div></div></td></tr></tbody></t=
able><div style=3D"border-style: solid none none; border-top-color: rgb(186=
, 188, 209); border-top-width: 1pt; font-size: initial; text-align: initial=
; background-color: rgb(255, 255, 255);"></div><br><div id=3D"_originalCont=
ent" style=3D""><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"g=
mail_quote">On Mon, Apr 25, 2016 at 3:27 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"g=
mail_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">On 25=
 April 2016 at 22:49, Ricardo Fabiano de Andrade<br>
&lt;<a href=3D"mailto:ricardofabianodeandrade@gmail.com">ricardofabianodean=
drade@gmail.com</a>&gt; wrote:<br>
&gt; Hi Ville,<br>
&gt; That said, my concerns is that this reflection proposal introduces a n=
ew,<br>
&gt; standard way to violate encapsulation.<br>
<br>
A way that is easy to find and ban, though.<br>
<br></blockquote><div><br></div><div>Agreed. I don't think any alternative =
should be different.</div><div>&nbsp;<br></div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-c=
olor:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
&gt; However, it has some costs both in terms of computing resources - time=
 to<br>
&gt; compile, program size - and human resources - time to learn reflection=
 and<br>
&gt; template meta-programming and apply these effectively and consistently=
..<br>
&gt; Which may lead to people ditching it and keep using the existing "dirt=
y"<br>
&gt; ways, which are difficult to identify in the code.<br>
<br>
I fail to see why that's such a concern. Bypassing access controls is indee=
d not<br>
the main reason for reflection.<br>
<br></blockquote><div><br></div><div>For me it's a concern because&nbsp;eit=
her&nbsp;people will use it for this purpose (making it easy to find and ba=
n).</div><div>Or because it's relatively more difficult to be done, people =
will not use it and the old ways will prevail (making it hard to find and n=
early impossible to ban).</div><div><br></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-co=
lor:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
&gt; Using Nicol's argument in the opposite direction, reflection does exis=
t to<br>
&gt; violate encapsulation but it will be used with this purpose.<br>
<br>
I presume that sentence is missing a "not".<br></blockquote><div><br></div>=
<div>Correct, my apologies.</div><div>&nbsp;</div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-lef=
t-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
&gt; Then comes the question that maybe it would be better to allow this to=
 be<br>
&gt; done outside of the context of reflection (so reflection would not be =
used<br>
&gt; when it's not necessary).<br>
&gt; Being also the main reason why this is not being discussed in the SG7 =
group.<br>
<br>
I don't know what you think is not being discussed in SG7.<br>
<span class=3D""><font color=3D"#888888"><br></font></span></blockquote><di=
v><br></div><div>I didn't make myself clear on that one.</div><div><br></di=
v><div>You're right, this matter is being actively discussed by the SG7 in =
the context of reflection.</div><div><br></div><div>My question is whether&=
nbsp;it should&nbsp;or not be discussed outside of the SG7 as well (that's =
why I posted here).</div><div>And additionally, if a "good" (as costly as t=
he alternatives, easy to find and ban) mechanism for subverting access righ=
ts exists, there's no need to add another one in reflection.</div><div>Not =
having this "functionality" in the reflection proposal (implicitly or expli=
citly) also make it cleaner.</div><div>&nbsp;<br></div><blockquote class=3D=
"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;borde=
r-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><sp=
an class=3D""><font color=3D"#888888">
--<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">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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAFk2RUa7b5RLP8BM_E%2B%3DguCi9hpKTLU7=
u1CQo054y_CEzdcoZg%40mail.gmail.com" rel=3D"noreferrer" target=3D"_blank">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUa7b5RLP8=
BM_E%2B%3DguCi9hpKTLU7u1CQo054y_CEzdcoZg%40mail.gmail.com</a>.<br>
</font></span></blockquote></div><br></div></div>

<p></p>

-- <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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CA%2BfGSbO_K50BSu-g%2BY76DeOSwdwATtc4=
DeHGB80z_mpgsCdgag%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoo=
ter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BfGSb=
O_K50BSu-g%2BY76DeOSwdwATtc4DeHGB80z_mpgsCdgag%40mail.gmail.com</a>.<br>
<br><!--end of _originalContent --></div></body></html>

<p></p>

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

.

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

Hi Tony, your comments are much appreciated. Here are some arguments though.


On Mon, Apr 25, 2016 at 9:19 PM, Tony V E <tvaneerd@gmail.com> wrote:

> IMO:
> - reflection should not subvert access rights
> - neither should anything else
>
>
In theory this is desired, but let's face it, there's 35+ years of legacy
code (when we get reflection probably 40) which will not get rewritten or
even touched any time soon.
It's not a perfect world. Non-invasive techniques and language support for
them (such as reflection) are very valuable in this context.


> If the number one reason is serialization, let's make some easier
> serialization library.
>
>
I assume you're suggesting an invasive serialization library.
In general, that requires adding some (definitely tedious/potentially slow)
boilerplate code and/or modifying existing code to add serialization
support.

Reflection can definitely help in both cases but it really shines when you
think about a non-invasive approach.
Up to the point where you run into a situation where you'll be required to
access a private/protected member, then the choice is either making a class
member public or getting your hands dirty.
Breaking into the class can potentially offer a much tighter and granular
control over this access and tends to be a safer bet than making things
public to everyone.


> I've had to support code that couldn't be changed because someone (someone
> important) was subverting access rights, and thus we couldn't break that
> code.
>
>
You're luck there was someone to tell you about the existence of that hack.
You could at least find it in the code.
In the other hand, I've experienced situations where someone retrofitted an
invasive serialization library.
The results were either scattered serialization code across the business
logic or for each class there was an accompanying serializable "adapter".
Needless to say both options have their problems.

And serialization is just one use case.
Another example is a unit test framework where protected/private member
functions can be freely called to verify the internal behavior of a class.

Think of the trouble DOS emulators need to go through due to people relying
> on undocumented hacks. Sure this will always exist, but do you want more of
> it or less?
>
>
We already have undocumented hacks and no new proposal need to be done for
that.

The discussion here is if we want a very well documented standard way of
accessing any class members under *special circumstances* and what should
be the costs both in terms of developer time and computational resources.

As a C++ developer I'd like to have the power to decide what's best for my
code, assuming the risks and paying for the costs of my decision. Better if
the language offers a way to express clearly my intentions for others.



> Sent from my BlackBerry portable Babbage Device
> *From: *Ricardo Fabiano de Andrade
> *Sent: *Monday, April 25, 2016 6:28 PM
> *To: *std-proposals@isocpp.org
> *Reply To: *std-proposals@isocpp.org
> *Subject: *Re: [std-proposals] Re: About subverting access rights
>
> On Mon, Apr 25, 2016 at 3:27 PM, Ville Voutilainen <
> ville.voutilainen@gmail.com> wrote:
>
>> On 25 April 2016 at 22:49, Ricardo Fabiano de Andrade
>> <ricardofabianodeandrade@gmail.com> wrote:
>> > Hi Ville,
>> > That said, my concerns is that this reflection proposal introduces a
>> new,
>> > standard way to violate encapsulation.
>>
>> A way that is easy to find and ban, though.
>>
>>
> Agreed. I don't think any alternative should be different.
>
>
>> > However, it has some costs both in terms of computing resources - time
>> to
>> > compile, program size - and human resources - time to learn reflection
>> and
>> > template meta-programming and apply these effectively and consistently.
>> > Which may lead to people ditching it and keep using the existing "dirty"
>> > ways, which are difficult to identify in the code.
>>
>> I fail to see why that's such a concern. Bypassing access controls is
>> indeed not
>> the main reason for reflection.
>>
>>
> For me it's a concern because either people will use it for this purpose
> (making it easy to find and ban).
> Or because it's relatively more difficult to be done, people will not use
> it and the old ways will prevail (making it hard to find and nearly
> impossible to ban).
>
> > Using Nicol's argument in the opposite direction, reflection does exist
>> to
>> > violate encapsulation but it will be used with this purpose.
>>
>> I presume that sentence is missing a "not".
>>
>
> Correct, my apologies.
>
>
>>
>> > Then comes the question that maybe it would be better to allow this to
>> be
>> > done outside of the context of reflection (so reflection would not be
>> used
>> > when it's not necessary).
>> > Being also the main reason why this is not being discussed in the SG7
>> group.
>>
>> I don't know what you think is not being discussed in SG7.
>>
>>
> I didn't make myself clear on that one.
>
> You're right, this matter is being actively discussed by the SG7 in the
> context of reflection.
>
> My question is whether it should or not be discussed outside of the SG7 as
> well (that's why I posted here).
> And additionally, if a "good" (as costly as the alternatives, easy to find
> and ban) mechanism for subverting access rights exists, there's no need to
> add another one in reflection.
> Not having this "functionality" in the reflection proposal (implicitly or
> explicitly) also make it cleaner.
>
>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> To view this discussion on the web visit
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUa7b5RLP8BM_E%2B%3DguCi9hpKTLU7u1CQo054y_CEzdcoZg%40mail.gmail.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.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BfGSbO_K50BSu-g%2BY76DeOSwdwATtc4DeHGB80z_mpgsCdgag%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BfGSbO_K50BSu-g%2BY76DeOSwdwATtc4DeHGB80z_mpgsCdgag%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/20160426021923.4898897.72532.10230%40gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/20160426021923.4898897.72532.10230%40gmail.com?utm_medium=email&utm_source=footer>
> .
>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BfGSbOkRpb1XZ1v2GTYn6bkDXY0A1JQ%2BMskuDou9C7hZpywGQ%40mail.gmail.com.

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

<div dir=3D"ltr">Hi Tony, your comments are much appreciated. Here are some=
 arguments though.<div><br><div class=3D"gmail_extra"><br><div class=3D"gma=
il_quote">On Mon, Apr 25, 2016 at 9:19 PM, Tony V E <span dir=3D"ltr">&lt;<=
a href=3D"mailto:tvaneerd@gmail.com" target=3D"_blank">tvaneerd@gmail.com</=
a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);b=
order-left-style:solid;padding-left:1ex"><div lang=3D"en-US" style=3D"line-=
height:initial;background-color:rgb(255,255,255)">                         =
                                                             <div style=3D"=
width:100%;font-size:initial;font-family:Calibri,&#39;Slate Pro&#39;,sans-s=
erif,sans-serif;color:rgb(31,73,125);text-align:initial;background-color:rg=
b(255,255,255)">IMO:</div><div style=3D"width:100%;font-size:initial;font-f=
amily:Calibri,&#39;Slate Pro&#39;,sans-serif,sans-serif;color:rgb(31,73,125=
);text-align:initial;background-color:rgb(255,255,255)">- reflection should=
 not subvert access rights</div><div style=3D"width:100%;font-size:initial;=
font-family:Calibri,&#39;Slate Pro&#39;,sans-serif,sans-serif;color:rgb(31,=
73,125);text-align:initial;background-color:rgb(255,255,255)">- neither sho=
uld anything else</div><div style=3D"width:100%;font-size:initial;font-fami=
ly:Calibri,&#39;Slate Pro&#39;,sans-serif,sans-serif;color:rgb(31,73,125);t=
ext-align:initial;background-color:rgb(255,255,255)"><br></div></div></bloc=
kquote><div>=C2=A0</div><div>In theory this is desired, but let&#39;s face =
it, there&#39;s 35+ years=C2=A0of legacy code=C2=A0(when we get reflection =
probably 40) which will not get rewritten or even touched any time soon.</d=
iv><div>It&#39;s not a perfect world. Non-invasive techniques and language =
support for them (such as reflection) are very valuable in this context.</d=
iv><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);borde=
r-left-style:solid;padding-left:1ex"><div lang=3D"en-US" style=3D"line-heig=
ht:initial;background-color:rgb(255,255,255)"><div style=3D"width:100%;font=
-size:initial;font-family:Calibri,&#39;Slate Pro&#39;,sans-serif,sans-serif=
;color:rgb(31,73,125);text-align:initial;background-color:rgb(255,255,255)"=
></div><div style=3D"width:100%;font-size:initial;font-family:Calibri,&#39;=
Slate Pro&#39;,sans-serif,sans-serif;color:rgb(31,73,125);text-align:initia=
l;background-color:rgb(255,255,255)">If the number one reason is serializat=
ion, let&#39;s make some easier serialization library.=C2=A0</div><div styl=
e=3D"width:100%;font-size:initial;font-family:Calibri,&#39;Slate Pro&#39;,s=
ans-serif,sans-serif;color:rgb(31,73,125);text-align:initial;background-col=
or:rgb(255,255,255)"><br></div></div></blockquote><div><br></div><div>I ass=
ume you&#39;re suggesting an invasive serialization library.</div><div>In g=
eneral, that requires adding some (definitely tedious/potentially slow) boi=
lerplate code and/or modifying existing code to add serialization support.<=
/div><div><br></div><div>Reflection can definitely help in both cases but i=
t really shines when you think about a non-invasive approach.</div><div>Up =
to the point where you run into a situation where you&#39;ll be required to=
 access a private/protected member, then the choice is either making a clas=
s member public or getting your hands dirty.<br></div><div>Breaking into th=
e class can potentially offer a much tighter and granular control over this=
 access and tends to be a safer bet than making things public to everyone.<=
/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);bor=
der-left-style:solid;padding-left:1ex"><div lang=3D"en-US" style=3D"line-he=
ight:initial;background-color:rgb(255,255,255)"><div style=3D"width:100%;fo=
nt-size:initial;font-family:Calibri,&#39;Slate Pro&#39;,sans-serif,sans-ser=
if;color:rgb(31,73,125);text-align:initial;background-color:rgb(255,255,255=
)"></div><div style=3D"width:100%;font-size:initial;font-family:Calibri,&#3=
9;Slate Pro&#39;,sans-serif,sans-serif;color:rgb(31,73,125);text-align:init=
ial;background-color:rgb(255,255,255)">I&#39;ve had to support code that co=
uldn&#39;t be changed because someone (someone important) was subverting ac=
cess rights, and thus we couldn&#39;t break that code.=C2=A0</div><div styl=
e=3D"width:100%;font-size:initial;font-family:Calibri,&#39;Slate Pro&#39;,s=
ans-serif,sans-serif;color:rgb(31,73,125);text-align:initial;background-col=
or:rgb(255,255,255)"><br></div></div></blockquote><div><br></div><div>You&#=
39;re luck there was someone to tell you about the existence of that hack. =
You could at least find it in the code.=C2=A0</div><div>In the other hand, =
I&#39;ve experienced situations where someone retrofitted=C2=A0an invasive=
=C2=A0serialization library.</div><div>The results were either scattered se=
rialization code across the business logic or for each class there was an a=
ccompanying serializable &quot;adapter&quot;.</div><div>Needless to say bot=
h options have their problems.</div><div><div><br></div><div>And serializat=
ion is just one use case.</div><div>Another example is a unit test framewor=
k where protected/private member functions can be freely called to verify t=
he internal behavior of a class.</div></div><div><br></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;b=
order-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"=
><div lang=3D"en-US" style=3D"line-height:initial;background-color:rgb(255,=
255,255)"><div style=3D"width:100%;font-size:initial;font-family:Calibri,&#=
39;Slate Pro&#39;,sans-serif,sans-serif;color:rgb(31,73,125);text-align:ini=
tial;background-color:rgb(255,255,255)"></div><div style=3D"width:100%;font=
-size:initial;font-family:Calibri,&#39;Slate Pro&#39;,sans-serif,sans-serif=
;color:rgb(31,73,125);text-align:initial;background-color:rgb(255,255,255)"=
>Think of the trouble DOS emulators need to go through due to people relyin=
g on undocumented hacks. Sure this will always exist, but do you want more =
of it or less?</div>                                                       =
                                                                           =
   <div style=3D"width:100%;font-size:initial;font-family:Calibri,&#39;Slat=
e Pro&#39;,sans-serif,sans-serif;color:rgb(31,73,125);text-align:initial;ba=
ckground-color:rgb(255,255,255)"><br style=3D"display:initial"></div></div>=
</blockquote><div><br></div><div>We already have undocumented hacks and no =
new proposal need to be done for that.</div><div><br></div><div>The discuss=
ion here is if we want a very well documented standard way of accessing any=
 class members under <i>special circumstances</i>=C2=A0and what should be t=
he costs both in terms of developer time and computational resources.</div>=
<div><br></div><div>As a C++ developer I&#39;d like to have the power to de=
cide what&#39;s best for my code, assuming the risks and paying for the cos=
ts of my decision. Better if the language offers a way to express clearly m=
y intentions for others.</div><div><br></div><div>=C2=A0<br></div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-widt=
h:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-le=
ft:1ex"><div lang=3D"en-US" style=3D"line-height:initial;background-color:r=
gb(255,255,255)"><div style=3D"width:100%;font-size:initial;font-family:Cal=
ibri,&#39;Slate Pro&#39;,sans-serif,sans-serif;color:rgb(31,73,125);text-al=
ign:initial;background-color:rgb(255,255,255)"></div>                      =
                                                                           =
                                                                           =
                       <div style=3D"font-size:initial;font-family:Calibri,=
&#39;Slate Pro&#39;,sans-serif,sans-serif;color:rgb(31,73,125);text-align:i=
nitial;background-color:rgb(255,255,255)">Sent=C2=A0from=C2=A0my=C2=A0Black=
Berry=C2=A0portable=C2=A0Babbage=C2=A0Device</div>                         =
                                                                           =
                                                                           =
   <table width=3D"100%" style=3D"border-spacing:0px;background-color:white=
"> <tbody><tr><td colspan=3D"2" style=3D"font-size:initial;text-align:initi=
al;background-color:rgb(255,255,255)">                           <div style=
=3D"border-style:solid none none;border-top-color:rgb(181,196,223);border-t=
op-width:1pt;padding:3pt 0in 0in;font-family:Tahoma,&#39;BB Alpha Sans&#39;=
,&#39;Slate Pro&#39;;font-size:10pt">  <div><b>From: </b>Ricardo Fabiano de=
 Andrade</div><div><b>Sent: </b>Monday, April 25, 2016 6:28 PM</div><div><b=
>To: </b><a href=3D"mailto:std-proposals@isocpp.org" target=3D"_blank">std-=
proposals@isocpp.org</a></div><div><b>Reply To: </b><a href=3D"mailto:std-p=
roposals@isocpp.org" target=3D"_blank">std-proposals@isocpp.org</a></div><d=
iv><b>Subject: </b>Re: [std-proposals] Re: About subverting access rights</=
div></div></td></tr></tbody></table><div style=3D"border-style:solid none n=
one;border-top-color:rgb(186,188,209);border-top-width:1pt;font-size:initia=
l;text-align:initial;background-color:rgb(255,255,255)"></div><br><div><div=
 dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On Mon, =
Apr 25, 2016 at 3:27 PM, Ville Voutilainen <span dir=3D"ltr">&lt;<a href=3D=
"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilainen@gm=
ail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,2=
04,204);border-left-style:solid;padding-left:1ex">On 25 April 2016 at 22:49=
, Ricardo Fabiano de Andrade<br>
&lt;<a href=3D"mailto:ricardofabianodeandrade@gmail.com" target=3D"_blank">=
ricardofabianodeandrade@gmail.com</a>&gt; wrote:<br>
&gt; Hi Ville,<br>
&gt; That said, my concerns is that this reflection proposal introduces a n=
ew,<br>
&gt; standard way to violate encapsulation.<br>
<br>
A way that is easy to find and ban, though.<br>
<br></blockquote><div><br></div><div>Agreed. I don&#39;t think any alternat=
ive should be different.</div><div>=C2=A0<br></div><blockquote class=3D"gma=
il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-le=
ft-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
&gt; However, it has some costs both in terms of computing resources - time=
 to<br>
&gt; compile, program size - and human resources - time to learn reflection=
 and<br>
&gt; template meta-programming and apply these effectively and consistently=
..<br>
&gt; Which may lead to people ditching it and keep using the existing &quot=
;dirty&quot;<br>
&gt; ways, which are difficult to identify in the code.<br>
<br>
I fail to see why that&#39;s such a concern. Bypassing access controls is i=
ndeed not<br>
the main reason for reflection.<br>
<br></blockquote><div><br></div><div>For me it&#39;s a concern because=C2=
=A0either=C2=A0people will use it for this purpose (making it easy to find =
and ban).</div><div>Or because it&#39;s relatively more difficult to be don=
e, people will not use it and the old ways will prevail (making it hard to =
find and nearly impossible to ban).</div><div><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;bo=
rder-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
&gt; Using Nicol&#39;s argument in the opposite direction, reflection does =
exist to<br>
&gt; violate encapsulation but it will be used with this purpose.<br>
<br>
I presume that sentence is missing a &quot;not&quot;.<br></blockquote><div>=
<br></div><div>Correct, my apologies.</div><div>=C2=A0</div><blockquote cla=
ss=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=
">
<br>
&gt; Then comes the question that maybe it would be better to allow this to=
 be<br>
&gt; done outside of the context of reflection (so reflection would not be =
used<br>
&gt; when it&#39;s not necessary).<br>
&gt; Being also the main reason why this is not being discussed in the SG7 =
group.<br>
<br>
I don&#39;t know what you think is not being discussed in SG7.<br>
<span><font color=3D"#888888"><br></font></span></blockquote><div><br></div=
><div>I didn&#39;t make myself clear on that one.</div><div><br></div><div>=
You&#39;re right, this matter is being actively discussed by the SG7 in the=
 context of reflection.</div><div><br></div><div>My question is whether=C2=
=A0it should=C2=A0or not be discussed outside of the SG7 as well (that&#39;=
s why I posted here).</div><div>And additionally, if a &quot;good&quot; (as=
 costly as the alternatives, easy to find and ban) mechanism for subverting=
 access rights exists, there&#39;s no need to add another one in reflection=
..</div><div>Not having this &quot;functionality&quot; in the reflection pro=
posal (implicitly or explicitly) also make it cleaner.</div><div>=C2=A0<br>=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:s=
olid;padding-left:1ex"><span><font color=3D"#888888">
--<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" 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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAFk2RUa7b5RLP8BM_E%2B%3DguCi9hpKTLU7=
u1CQo054y_CEzdcoZg%40mail.gmail.com" rel=3D"noreferrer" target=3D"_blank">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUa7b5RLP8=
BM_E%2B%3DguCi9hpKTLU7u1CQo054y_CEzdcoZg%40mail.gmail.com</a>.<span class=
=3D""><font color=3D"#888888"><br>
</font></span></font></span></blockquote></div><span class=3D""><font color=
=3D"#888888"><br></font></span></div></div><span class=3D""><font color=3D"=
#888888">

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" 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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CA%2BfGSbO_K50BSu-g%2BY76DeOSwdwATtc4=
DeHGB80z_mpgsCdgag%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoo=
ter" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-p=
roposals/CA%2BfGSbO_K50BSu-g%2BY76DeOSwdwATtc4DeHGB80z_mpgsCdgag%40mail.gma=
il.com</a>.<br>
<br></font></span></div></div><span class=3D""><font color=3D"#888888">

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" 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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/20160426021923.4898897.72532.10230%40=
gmail.com?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/20160426021923.48=
98897.72532.10230%40gmail.com</a>.<br>
</font></span></blockquote></div><br></div></div></div>

<p></p>

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

--001a113eccbeb516e105315bfe1c--

.

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

On Mon, Apr 25, 2016 at 1:25 PM, Nicol Bolas <jmckesson@gmail.com> wrote:

>
>
> On Monday, April 25, 2016 at 1:12:49 PM UTC-4, Ricardo Andrade wrote:
>>
>> Hi Nicol, I knew those would be your answers :)
>> I appreciate you reply and I'll leave a few additional comments.
>>
>> On Mon, Apr 25, 2016 at 10:47 AM, Nicol Bolas <jmck...@gmail.com> wrote:
>>
>>> On Monday, April 25, 2016 at 12:16:40 AM UTC-4, Ricardo Andrade wrote:
>>>>
>>>> Quoting Herb Sutter's "GotW #76"[1] this is about "*liars, cheats,
>>>> pickpockets, and thieves*" (but have Robin Hood in mind) and "*protecting
>>>> against Murphy vs. protecting against Machiavelli*".
>>>>
>>>> A few "inflammatory" questions:
>>>>
>>>> 1) Should C++ have a standard (obvious) way to subvert the defined
>>>> access right of given class?
>>>>
>>>
>>> No.
>>>
>>
>> People will do it anyway. And it's not obvious or easy to find that in
>> code when they do.
>>
>
> Yes, but pretty much every way to do that violates that C++ standard.
>

Correct, I'd like to have a way that is adherent to the standard, but
clearer so we can avoid using the hacks.


>
> At least having a standard way would make it easier for humans and tools
>> to deal with that.
>> It's just easier to maintain code that clearly states the programmer
>> intentions (without having to rely in comments).
>>
>
> We shouldn't do something just because a certain class of programmers
> choose to do it in spite of the standard. There are things that we
> shouldn't make "easier to maintain".
>
>
We shouldn't standardize bad code.
>

>
2) If no, access rights should be followed strictly, does that also applies
>>>> to a future reflection support?
>>>>
>>>
>>> Reflection does not exist to break access controls. It has to be able to
>>> do that in order for it to do its job, but that isn't its purpose, nor
>>> would it be an "obvious" way to break access controls.
>>>
>>
>> Agreed. But are you implying C++ reflection should allow it then?
>>
>
> That's up to the reflection people. Personally, I would prefer it if
> reflection would restrict your access based on where you were when you
> initiated the reflection (P0194's get_all_data_members could not be invoked
> on a type unless your code directly had private access, for example). But
> that's for them to decide, based on the needs of reflection.
>

It's very likely that will decide against your preference.


>
>
What C++ should not have is a facility who's primary purpose is to violate
> access controls.
>
> 3) If yes, reflection should be the way to do it, why using the standard
>>>> way (in this case reflection) should cost more than the non-standard
>>>> options? (in this case, potentially adding some compile-time cost).
>>>>
>>>
>>> Because we shouldn't make it easy for people to do stupid things.
>>>
>>
>> I also agree, but...
>> const_cast, reinterpret_cast, or getting pointers to internal references
>> returned by members, etc.
>> All stupid things easy to be done while having no cost in terms of
>> compilation time, resource usage.
>>
>
> That sounds like a very good and convincing argument for not to *adding*
> to that list.
>
>
But I bet you run into situations where they were your only/best options
and you never have to think that without them you'd have to resort to void*
and C-style casts.


> Oh sure, you may be able to access the *values*, writing them to a file
>>> and read them back. But without knowing the *meaning* of them (and no,
>>> the type is not sufficient), you have *no clue* if merely reading those
>>> values back will actually accomplish the goal of creating a functional
>>> object, with all of that class's invariants intact.
>>>
>>>
>> As a simple example, what if there's a class that has a `int`. You might
>>> just write that out and read it back later. But what if this value is
>>> sourced from a monotonically increasing value somewhere? And thus, when you
>>> recreate it, you shouldn't just read the value you wrote. You have to talk
>>> to the monotonically increasing value and regenerate this number at
>>> deserialization time.
>>>
>>>
>> Like I said, it depends how much you know about the code. So sometimes
>> you know the meaning and you can trust that.
>>
>
> And sometimes you don't know the meaning. And sometimes, people think they
> do but actually don't. And sometimes, people just don't think at all and
> simply believe that the tool that worked on all these other types will work
> on this new type too.
>
> Fragile code is fragile.
>
>
And still, if people want to do a stupid thing they will do it anyway and
it will be pain to figure it out when and where they have done it even if
it works flawlessly.
Maybe you're looking at this discussion with the eyes of a user of the
language that just found a funny new feature and wants to abuse of it.
My perspective is of the code reviewer, the maintainer. I want to know if
the code has such unsafe construction, where and why.



> There's also the question of doing certain operations such as
>> serialization in a non-invasive manner. Or "make it public for just this
>> operation".
>> For example, I may want to serialize std::string the way it has been
>> implemented to preserve any optimizations such as small buffer optimization.
>> Definitely, no one will make these implementation-specific members public.
>> Creating my own serialization-aware type just blow away my goals of
>> preserving the characteristics of the original type I wanted to serialize.
>>
>
> Let's take your example at face value. You have intimate knowledge of how
> that `basic_string` implementation works. You know well what it does and
> how to interact with it. It uses SSO, and you know exactly how many
> characters it uses.
>
> What does your serialized data look like? It has to have a sequence of
> characters and it has to have a length. So what more exactly is it that you
> plan on serializing? Do you need to write how many SSO characters the
> buffer has? No; you can't use that information when reading it back, since
> it's a *static* property of the particular instantiation of
> `basic_string`. The only thing you would do when serializing it back is
> check the string's length and use the SSO buffer if it's below that length.
>
> Which `basic_string`'s constructor will do for you.
>
>
Who said I'll be using the provided constructors? ;)
I can default construct and put the data back were I found it directly
(evil laughter).
My point is, people can get real crazy with the power, but at least I can
easily find the signs of their madness.


> In short, the *only data* you need to write when serializing a
> `basic_string`, with SSO and so forth intact, are the array of characters
> and its length. All of which are public information and both of which can
> be provided to a `basic_string` constructor.
>
> So why do you need to look at `basic_string`'s privates?
>
>
99.9% of time no one needs to know. Honestly, I hope I never have to.

Let's suppose a future reflection support gives me such power.
>> Suppose that dissecting std::string with reflection having the goal of
>> serialization in mind incurs an horrendous compile time cost and then I
>> just resort to other non-standard ways.
>> I just made a complex piece of code even more complex and less
>> maintainable because the language "got in my way".
>>
>
> No, the language did not "got in my way." A *person* got in your way.
>
> You do not have the right to access the private members of an object. *That's
> what private members are for!* For the language to make it easy to
> violate this completely defeats the purpose of the construct.
>
> If I declare something to be `private`, I want it to be *private*. If you
> want it to not be private, I have no problem with you having to resort to
> ugly non-standard hacks or template metaprogramming. That's what
> encapsulation is for. It's not a *guarantee*, but you must commit a
> deliberate and clear act of perfidy to do so.
>

Correct. I just want to give a standard name for this act.


>
> We should not standardize *perfidy*.
>


Avoiding the problem doesn't make it any better.


>
> Whether you have access to a type's privates or not, you *cannot*
>>> effectively serialize a type without that type's knowledge or *explicit
>>> consent*.
>>> So users of the language shouldn't be "resorting to dirty tricks" to
>>> serialize other people's types at all. It simply is non-functional in the
>>> general case.
>>>
>>> This technically sound, but it may be not practical. Forcing people that
>> way is just asking for having workarounds that are a lot of boilerplate
>> code or a collection of dirty tricks.
>>
>
> You say that as if it's a bad thing. Dirty things should look dirty.
> Unsafe code should look unsafe.
>
>
reinterpret_cast is sufficiently dirty for me, but the compiler knows what
we are doing as well others reading the code.


> And a serialization system built on the idea that it can serialize
> anything without that types knowledge is unsafe. It may work in many cases.
> But so does naked use of `new` and `delete`.
>
>
Serialization is just one example.
I've floated here the idea of a unit test framework with access to the
private/protected member functions.
Can you relate with this example?


> IMO, there must be a balance between theory and practice in a programming
>> language.
>> Trying find the right balance for this specific matter with this
>> discussion.
>>
>
> I don't see what's wrong with the current balance.
>


It's not about the current balance, but the future where reflection is in
the picture.


>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/37a4f22c-4c74-4398-ae2f-b4b5b90e3796%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/37a4f22c-4c74-4398-ae2f-b4b5b90e3796%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BfGSbPzd617gx7%2BZH1fkOc82OMMW30mwcGxi8Qviro%2BoUjyEQ%40mail.gmail.com.

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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Mon, Apr 25, 2016 at 1:25 PM, Nicol Bolas <span dir=3D"ltr">&lt;<a h=
ref=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a=
>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br>=
<br>On Monday, April 25, 2016 at 1:12:49 PM UTC-4, Ricardo Andrade wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-=
left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Hi Nicol, I knew tho=
se would be your answers :)<div>I appreciate you reply and I&#39;ll leave a=
 few additional comments.</div><div><br></div><div><div><div class=3D"gmail=
_quote">On Mon, Apr 25, 2016 at 10:47 AM, Nicol Bolas <span dir=3D"ltr">&lt=
;<a rel=3D"nofollow">jmck...@gmail.com</a>&gt;</span> wrote:<br><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">On Monday, April 25, 2016 at 12:16:40 AM UTC-4, Rica=
rdo Andrade wrote:<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">Quoting Herb Sutter&#39=
;s &quot;GotW #76&quot;[1] this is abou<span style=3D"background-color:rgb(=
255,255,255)">t &quot;<i style=3D"color:rgb(0,0,0);font-family:Arial,Arial,=
Helvetica;font-size:13.3333px">liars, cheats, pickpockets, and thieves</i>&=
quot; (but have Robin Hood in mind) and &quot;<span style=3D"color:rgb(0,0,=
0);font-family:Arial,Arial,Helvetica;font-size:13.3333px"><i>protecting aga=
inst Murphy vs. protecting against Machiavelli</i></span>&quot;.</span><div=
><span style=3D"background-color:rgb(255,255,255)"><br></span></div><div><s=
pan style=3D"background-color:rgb(255,255,255)">A few &quot;inflammatory&qu=
ot;=C2=A0questions:</span></div><div><span style=3D"background-color:rgb(25=
5,255,255)"><br></span></div><div><span style=3D"background-color:rgb(255,2=
55,255)">1) Should C++ have a standard (obvious) way to subvert the defined=
 access right of given class?</span></div></div></blockquote><div><br>No.<b=
r></div></div></blockquote><div><br></div><div>People will do it anyway. An=
d it&#39;s not obvious or easy to find that in code when they do.</div></di=
v></div></div></div></blockquote><div><br>Yes, but pretty much every way to=
 do that violates that C++ standard.<br></div></div></blockquote><div><br><=
/div><div>Correct, I&#39;d like to have a way that is adherent to the stand=
ard, but clearer so we can avoid using the hacks.</div><div>=C2=A0</div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><br></div><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"><div><div><div class=3D"gmail_quo=
te"><div>At least having a standard way would make it easier for humans and=
 tools to deal with that.<br></div><div>It&#39;s just easier to maintain co=
de that clearly states the programmer intentions (without having to rely in=
 comments).</div></div></div></div></div></blockquote><div><br>We shouldn&#=
39;t do something just because a certain class of programmers choose to do =
it in spite of the standard. There are things that we shouldn&#39;t make &q=
uot;easier to maintain&quot;.<br>=C2=A0<br></div></div></blockquote><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div dir=3D"ltr"><div>We shouldn&#39;t standardize =
bad code.=C2=A0</div></div></blockquote><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div=
 dir=3D"ltr"><div>=C2=A0<br></div></div></blockquote><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><div dir=3D"ltr"><div></div><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"><div><div><div class=3D"gmail_quote"><div></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-wid=
th:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-l=
eft:1ex"><div dir=3D"ltr"><div></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(2=
04,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div=
><span style=3D"background-color:rgb(255,255,255)"></span></div><div><span =
style=3D"background-color:rgb(255,255,255)">2) If no, access rights should =
be followed strictly, does that also applies to a future reflection support=
?</span></div></div></blockquote><div><br>Reflection does not exist to brea=
k access controls. It has to be able to do that in order for it to do its j=
ob, but that isn&#39;t its purpose, nor would it be an &quot;obvious&quot; =
way to break access controls.<br></div></div></blockquote><div><br></div><d=
iv>Agreed. But are you implying C++ reflection should allow it then?</div><=
/div></div></div></div></blockquote><div><br>That&#39;s up to the reflectio=
n people. Personally, I would prefer it if reflection would restrict your a=
ccess based on where you were when you initiated the reflection (P0194&#39;=
s get_all_data_members could not be invoked on a type unless your code dire=
ctly had private access, for example). But that&#39;s for them to decide, b=
ased on the needs of reflection.<br></div></div></blockquote><div><br></div=
><div>It&#39;s very likely that will decide against your preference.</div><=
div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>=C2=A0=
<br></div></div></blockquote><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr=
"><div>What C++ should not have is a facility who&#39;s primary purpose is =
to violate access controls.<br><br></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><div class=3D"gmail_quote"><div></div><blo=
ckquote 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;paddi=
ng-left:1ex"><div dir=3D"ltr"><div></div></div></blockquote><blockquote cla=
ss=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"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 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></div><div><span =
style=3D"background-color:rgb(255,255,255)">3) If yes, reflection should be=
 the way to do it, why using the standard way (in this case reflection) sho=
uld cost more than the non-standard options? (in this case, potentially add=
ing some compile-time cost).</span></div></div></blockquote><div><br>Becaus=
e we shouldn&#39;t make it easy for people to do stupid things.<br></div></=
div></blockquote><div><br></div><div>I also agree, but...</div><div>const_c=
ast, reinterpret_cast, or getting pointers to internal references returned =
by members, etc.</div><div>All stupid things easy to be done while having n=
o cost in terms of compilation time, resource usage.<br></div></div></div><=
/div></div></blockquote><div><br>That sounds like a very good and convincin=
g argument for not to <i>adding</i> to that list.<br><br></div></div></bloc=
kquote><div>=C2=A0</div><div>But I bet you run into situations where they w=
ere your only/best options and you never have to think that without them yo=
u&#39;d have to resort to void* and C-style casts.</div><div>=C2=A0</div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex"><div dir=3D"ltr"><div></div><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"><div><div><div class=3D"gmail_quote=
"><div></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></div></blockquote></div></div></div></d=
iv></blockquote><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"><d=
iv><div><div class=3D"gmail_quote"><div></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-co=
lor:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"=
ltr"><div>Oh sure, you may be able to access the <i>values</i>, writing the=
m to a file and read them back. But without knowing the <i>meaning</i> of t=
hem (and no, the type is not sufficient), you have <i>no clue</i> if merely=
 reading those values back will actually accomplish the goal of creating a =
functional object, with all of that class&#39;s invariants intact.<br>=C2=
=A0<br></div></div></blockquote><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,20=
4,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div>As a=
 simple example, what if there&#39;s a class that has a `int`. You might ju=
st write that out and read it back later. But what if this value is sourced=
 from a monotonically increasing value somewhere? And thus, when you recrea=
te it, you shouldn&#39;t just read the value you wrote. You have to talk to=
 the monotonically increasing value and regenerate this number at deseriali=
zation time.<br><br></div></div></blockquote><div><br></div><div><div>Like =
I said, it depends how much you know about the code. So sometimes you know =
the meaning and you can trust that.</div></div></div></div></div></div></bl=
ockquote><div><br>And sometimes you don&#39;t know the meaning. And sometim=
es, people think they do but actually don&#39;t. And sometimes, people just=
 don&#39;t think at all and simply believe that the tool that worked on all=
 these other types will work on this new type too.<br><br>Fragile code is f=
ragile.<br><br></div></div></blockquote><div><br></div><div>And still, if p=
eople want to do a stupid thing they will do it anyway and it will be pain =
to figure it out when and where they have done it even if it works flawless=
ly.</div><div>Maybe you&#39;re looking at this discussion with the eyes of =
a user of the language that just found a funny new feature and wants to abu=
se of it.</div><div>My perspective is of the code reviewer, the maintainer.=
 I want to know if the code has such unsafe construction, where and why.</d=
iv><div>=C2=A0<br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" =
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><di=
v dir=3D"ltr"><div></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><div class=3D"gmail_quote"><div><div></div><div>There&#3=
9;s also the question of doing certain operations such as serialization in =
a non-invasive manner. Or &quot;make it public for just this operation&quot=
;.</div><div>For example, I may want to serialize std::string the way it ha=
s been implemented to preserve any optimizations such as small buffer optim=
ization.<br></div><div>Definitely, no one will make these implementation-sp=
ecific members public.</div><div>Creating my own serialization-aware type j=
ust blow away my goals of preserving the characteristics of the original ty=
pe I wanted to serialize.<br></div></div></div></div></div></div></blockquo=
te><div><br>Let&#39;s take your example at face value. You have intimate kn=
owledge of how that `basic_string` implementation works. You know well what=
 it does and how to interact with it. It uses SSO, and you know exactly how=
 many characters it uses.<br><br>What does your serialized data look like? =
It has to have a sequence of characters and it has to have a length. So wha=
t more exactly is it that you plan on serializing? Do you need to write how=
 many SSO characters the buffer has? No; you can&#39;t use that information=
 when reading it back, since it&#39;s a <i>static</i> property of the parti=
cular instantiation of `basic_string`. The only thing you would do when ser=
ializing it back is check the string&#39;s length and use the SSO buffer if=
 it&#39;s below that length.<br><br>Which `basic_string`&#39;s constructor =
will do for you.<br><br></div></div></blockquote><div><br></div><div>Who sa=
id I&#39;ll be using the provided constructors? ;)</div><div>I can default =
construct and put the data back were I found it directly (evil laughter).</=
div><div>My point is, people can get real crazy with the power, but at leas=
t I can easily find the signs of their madness.</div><div>=C2=A0<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"><div>In short, the <i>only d=
ata</i> you need to write when serializing a `basic_string`, with SSO and s=
o forth intact, are the array of characters and its length. All of which ar=
e public information and both of which can be provided to a `basic_string` =
constructor.<br><br>So why do you need to look at `basic_string`&#39;s priv=
ates?<br><br></div></div></blockquote><div><br></div><div>99.9% of time no =
one needs to know. Honestly, I hope I never have to.</div><div><br></div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex"><div dir=3D"ltr"><div></div><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"><div><div><div class=3D"gmail_quote=
"><div><div></div><div></div><div>Let&#39;s suppose a future reflection sup=
port gives me such power.<br></div><div>Suppose that dissecting std::string=
 with reflection having the goal of serialization in mind incurs an horrend=
ous compile time cost and then I just resort to other non-standard ways.</d=
iv><div>I just made a complex piece of code even more complex and less main=
tainable because the language &quot;got in my way&quot;.</div></div></div><=
/div></div></div></blockquote><div><br>No, the language did not &quot;got i=
n my way.&quot; A <i>person</i> got in your way.<br><br>You do not have the=
 right to access the private members of an object. <i>That&#39;s what priva=
te members are for!</i> For the language to make it easy to violate this co=
mpletely defeats the purpose of the construct.<br><br>If I declare somethin=
g to be `private`, I want it to be <i>private</i>. If you want it to not be=
 private, I have no problem with you having to resort to ugly non-standard =
hacks or template metaprogramming. That&#39;s what encapsulation is for. It=
&#39;s not a <i>guarantee</i>, but you must commit a deliberate and clear a=
ct of perfidy to do so.<br></div></div></blockquote><div><br></div><div>Cor=
rect. I just want to give a standard name for this act.<br></div><div>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><br>We should=
 not standardize <i>perfidy</i>.<br></div></div></blockquote><div><br></div=
><div><br></div><div>Avoiding the problem doesn&#39;t make it any better.</=
div><div>=C2=A0</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"><div><=
br></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=
><div class=3D"gmail_quote"><div></div><blockquote class=3D"gmail_quote" st=
yle=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"><d=
iv>Whether you have access to a type&#39;s privates or not, you <i>cannot</=
i> effectively serialize a type without that type&#39;s knowledge or <i>exp=
licit consent</i>.<br><div dir=3D"ltr">So users of the language shouldn&#39=
;t be &quot;resorting to dirty tricks&quot; to serialize other people&#39;s=
 types at all. It simply is non-functional in the general case.<span><font =
color=3D"#888888"><br></font></span></div><span><font color=3D"#888888"><p>=
</p></font></span></div></div></blockquote><div>This technically sound, but=
 it may be not practical. Forcing people that way is just asking for having=
 workarounds that are a lot of boilerplate code or a collection of dirty tr=
icks.<br></div></div></div></div></div></blockquote><div><br>You say that a=
s if it&#39;s a bad thing. Dirty things should look dirty. Unsafe code shou=
ld look unsafe.<br><br></div></div></blockquote><div><br></div><div>reinter=
pret_cast is sufficiently dirty for me, but the compiler knows what we are =
doing as well others reading the code.</div><div>=C2=A0</div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex"><div dir=3D"ltr"><div>And a serialization system built on =
the idea that it can serialize anything without that types knowledge is uns=
afe. It may work in many cases. But so does naked use of `new` and `delete`=
..<br><br></div></div></blockquote><div><br></div><div>Serialization is just=
 one example.</div><div>I&#39;ve floated here the idea of a unit test frame=
work with access to the private/protected member functions.</div><div>Can y=
ou relate with this example?</div><div>=C2=A0</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></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><div class=3D"gmail_quote"><div></div><div></di=
v><div>IMO, there must be a balance between theory and practice in a progra=
mming language.</div><div>Trying find the right balance for this specific m=
atter with this discussion.<br></div></div></div></div></div></blockquote><=
div><br>I don&#39;t see what&#39;s wrong with the current balance.</div></d=
iv></blockquote><div><br></div><div><br></div><div>It&#39;s not about the c=
urrent balance, but the future where reflection is in the picture.</div><di=
v>=C2=A0</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"><div><span cl=
ass=3D"HOEnZb"><font color=3D"#888888"><br></font></span></div></div><span =
class=3D"HOEnZb"><font color=3D"#888888">

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" 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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/37a4f22c-4c74-4398-ae2f-b4b5b90e3796%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/37a4f22c-4c74-=
4398-ae2f-b4b5b90e3796%40isocpp.org</a>.<br>
</font></span></blockquote></div><br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CA%2BfGSbPzd617gx7%2BZH1fkOc82OMMW30m=
wcGxi8Qviro%2BoUjyEQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BfGSbPz=
d617gx7%2BZH1fkOc82OMMW30mwcGxi8Qviro%2BoUjyEQ%40mail.gmail.com</a>.<br />

--001a113d19a89714ba05315d20d6--

.

------=_Part_628_164568227.1461685332913
Content-Type: multipart/alternative;
 boundary="----=_Part_629_567130492.1461685332914"

------=_Part_629_567130492.1461685332914
Content-Type: text/plain; charset=UTF-8

On Tuesday, April 26, 2016 at 12:47:50 AM UTC-4, Ricardo Andrade wrote:
>
> Hi Tony, your comments are much appreciated. Here are some arguments
> though.
> On Mon, Apr 25, 2016 at 9:19 PM, Tony V E <tvan...@gmail.com <javascript:>
> > wrote:
>
>> IMO:
>> - reflection should not subvert access rights
>> - neither should anything else
>>
>>
> In theory this is desired, but let's face it, there's 35+ years of legacy
> code (when we get reflection probably 40) which will not get rewritten or
> even touched any time soon.
> It's not a perfect world. Non-invasive techniques and language support for
> them (such as reflection) are very valuable in this context.
>
>
>> If the number one reason is serialization, let's make some easier
>> serialization library.
>>
>>
> I assume you're suggesting an invasive serialization library.
> In general, that requires adding some (definitely tedious/potentially
> slow) boilerplate code and/or modifying existing code to add serialization
> support.
>
> Reflection can definitely help in both cases but it really shines when you
> think about a non-invasive approach.
> Up to the point where you run into a situation where you'll be required to
> access a private/protected member, then the choice is either making a class
> member public or getting your hands dirty.
> Breaking into the class can potentially offer a much tighter and granular
> control over this access and tends to be a safer bet than making things
> public to everyone.
>
>
>> I've had to support code that couldn't be changed because someone
>> (someone important) was subverting access rights, and thus we couldn't
>> break that code.
>>
>>
> You're luck there was someone to tell you about the existence of that
> hack. You could at least find it in the code.
> In the other hand, I've experienced situations where someone
> retrofitted an invasive serialization library.
> The results were either scattered serialization code across the business
> logic or for each class there was an accompanying serializable "adapter".
> Needless to say both options have their problems.
>
> And serialization is just one use case.
> Another example is a unit test framework where protected/private member
> functions can be freely called to verify the internal behavior of a class.
>
> Think of the trouble DOS emulators need to go through due to people
>> relying on undocumented hacks. Sure this will always exist, but do you want
>> more of it or less?
>>
>>
> We already have undocumented hacks and no new proposal need to be done for
> that.
>
> The discussion here is if we want a very well documented standard way of
> accessing any class members under *special circumstances* and what should
> be the costs both in terms of developer time and computational resources.
>
> As a C++ developer I'd like to have the power to decide what's best for my
> code, assuming the risks and paying for the costs of my decision. Better if
> the language offers a way to express clearly my intentions for others.
>
>
>
>> Sent from my BlackBerry portable Babbage Device
>> *From: *Ricardo Fabiano de Andrade
>> *Sent: *Monday, April 25, 2016 6:28 PM
>> *To: *std-pr...@isocpp.org <javascript:>
>> *Reply To: *std-pr...@isocpp.org <javascript:>
>> *Subject: *Re: [std-proposals] Re: About subverting access rights
>>
>> On Mon, Apr 25, 2016 at 3:27 PM, Ville Voutilainen <ville.vo...@gmail.com
>> <javascript:>> wrote:
>>
>>> On 25 April 2016 at 22:49, Ricardo Fabiano de Andrade
>>> <ricardofabi...@gmail.com <javascript:>> wrote:
>>> > Hi Ville,
>>> > That said, my concerns is that this reflection proposal introduces a
>>> new,
>>> > standard way to violate encapsulation.
>>>
>>> A way that is easy to find and ban, though.
>>>
>>>
>> Agreed. I don't think any alternative should be different.
>>
>>
>>> > However, it has some costs both in terms of computing resources - time
>>> to
>>> > compile, program size - and human resources - time to learn reflection
>>> and
>>> > template meta-programming and apply these effectively and consistently.
>>> > Which may lead to people ditching it and keep using the existing
>>> "dirty"
>>> > ways, which are difficult to identify in the code.
>>>
>>> I fail to see why that's such a concern. Bypassing access controls is
>>> indeed not
>>> the main reason for reflection.
>>>
>>>
>> For me it's a concern because either people will use it for this purpose
>> (making it easy to find and ban).
>> Or because it's relatively more difficult to be done, people will not use
>> it and the old ways will prevail (making it hard to find and nearly
>> impossible to ban).
>>
>> > Using Nicol's argument in the opposite direction, reflection does exist
>>> to
>>> > violate encapsulation but it will be used with this purpose.
>>>
>>> I presume that sentence is missing a "not".
>>>
>>
>> Correct, my apologies.
>>
>>
>>>
>>> > Then comes the question that maybe it would be better to allow this to
>>> be
>>> > done outside of the context of reflection (so reflection would not be
>>> used
>>> > when it's not necessary).
>>> > Being also the main reason why this is not being discussed in the SG7
>>> group.
>>>
>>> I don't know what you think is not being discussed in SG7.
>>>
>>>
>> I didn't make myself clear on that one.
>>
>> You're right, this matter is being actively discussed by the SG7 in the
>> context of reflection.
>>
>> My question is whether it should or not be discussed outside of the SG7
>> as well (that's why I posted here).
>> And additionally, if a "good" (as costly as the alternatives, easy to
>> find and ban) mechanism for subverting access rights exists, there's no
>> need to add another one in reflection.
>> Not having this "functionality" in the reflection proposal (implicitly or
>> explicitly) also make it cleaner.
>>
>
>
Here's the fundamental problem with what you suggest.

Your basic argument is that, if we had a standard supported way of
subverting access rights, then we could search our code for people who are
using it.

But the fact is that's not true. Why? Because the old, non-standard way of
subverting access rights *will still exist*. It is therefore up to each
individual user to decide if they want to use the new, standard way or keep
their old code around.

And generally speaking, people will opt to keep their old code around. It
still works, after all.

So while in theory this might be helpful, in practice it won't be. If you
search your codebase for the standard access subversion methods, you still
won't find the non-standard ones.

The illusion of safety is still an illusion.

Also, I take issue with the idea that we can't search the code for such
cases. Generally speaking, they will involve unsafe casts that a good
static analyzer can detect and warn you about. Also, such a static analyzer
can find other problems.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/472a15d5-4591-4bd1-9233-01c8550c5c6f%40isocpp.org.

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

<div dir=3D"ltr">On Tuesday, April 26, 2016 at 12:47:50 AM UTC-4, Ricardo A=
ndrade wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
Hi Tony, your comments are much appreciated. Here are some arguments though=
..<div><div><div class=3D"gmail_quote">On Mon, Apr 25, 2016 at 9:19 PM, Tony=
 V E <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-ob=
fuscated-mailto=3D"uTCemTn9BwAJ" rel=3D"nofollow" onmousedown=3D"this.href=
=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascri=
pt:&#39;;return true;">tvan...@gmail.com</a>&gt;</span> wrote:<br><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-widt=
h:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-le=
ft:1ex"><div style=3D"line-height:initial;background-color:rgb(255,255,255)=
" lang=3D"en-US">                                                          =
                            <div style=3D"width:100%;font-size:initial;font=
-family:Calibri,&#39;Slate Pro&#39;,sans-serif,sans-serif;color:rgb(31,73,1=
25);text-align:initial;background-color:rgb(255,255,255)">IMO:</div><div st=
yle=3D"width:100%;font-size:initial;font-family:Calibri,&#39;Slate Pro&#39;=
,sans-serif,sans-serif;color:rgb(31,73,125);text-align:initial;background-c=
olor:rgb(255,255,255)">- reflection should not subvert access rights</div><=
div style=3D"width:100%;font-size:initial;font-family:Calibri,&#39;Slate Pr=
o&#39;,sans-serif,sans-serif;color:rgb(31,73,125);text-align:initial;backgr=
ound-color:rgb(255,255,255)">- neither should anything else</div><div style=
=3D"width:100%;font-size:initial;font-family:Calibri,&#39;Slate Pro&#39;,sa=
ns-serif,sans-serif;color:rgb(31,73,125);text-align:initial;background-colo=
r:rgb(255,255,255)"><br></div></div></blockquote><div>=C2=A0</div><div>In t=
heory this is desired, but let&#39;s face it, there&#39;s 35+ years=C2=A0of=
 legacy code=C2=A0(when we get reflection probably 40) which will not get r=
ewritten or even touched any time soon.</div><div>It&#39;s not a perfect wo=
rld. Non-invasive techniques and language support for them (such as reflect=
ion) are very valuable in this context.</div><div>=C2=A0</div><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1p=
x;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1=
ex"><div style=3D"line-height:initial;background-color:rgb(255,255,255)" la=
ng=3D"en-US"><div style=3D"width:100%;font-size:initial;font-family:Calibri=
,&#39;Slate Pro&#39;,sans-serif,sans-serif;color:rgb(31,73,125);text-align:=
initial;background-color:rgb(255,255,255)"></div><div style=3D"width:100%;f=
ont-size:initial;font-family:Calibri,&#39;Slate Pro&#39;,sans-serif,sans-se=
rif;color:rgb(31,73,125);text-align:initial;background-color:rgb(255,255,25=
5)">If the number one reason is serialization, let&#39;s make some easier s=
erialization library.=C2=A0</div><div style=3D"width:100%;font-size:initial=
;font-family:Calibri,&#39;Slate Pro&#39;,sans-serif,sans-serif;color:rgb(31=
,73,125);text-align:initial;background-color:rgb(255,255,255)"><br></div></=
div></blockquote><div><br></div><div>I assume you&#39;re suggesting an inva=
sive serialization library.</div><div>In general, that requires adding some=
 (definitely tedious/potentially slow) boilerplate code and/or modifying ex=
isting code to add serialization support.</div><div><br></div><div>Reflecti=
on can definitely help in both cases but it really shines when you think ab=
out a non-invasive approach.</div><div>Up to the point where you run into a=
 situation where you&#39;ll be required to access a private/protected membe=
r, then the choice is either making a class member public or getting your h=
ands dirty.<br></div><div>Breaking into the class can potentially offer a m=
uch tighter and granular control over this access and tends to be a safer b=
et than making things public to everyone.</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 style=3D"line-height:initial;background-color:rgb(255,255,255)" =
lang=3D"en-US"><div style=3D"width:100%;font-size:initial;font-family:Calib=
ri,&#39;Slate Pro&#39;,sans-serif,sans-serif;color:rgb(31,73,125);text-alig=
n:initial;background-color:rgb(255,255,255)"></div><div style=3D"width:100%=
;font-size:initial;font-family:Calibri,&#39;Slate Pro&#39;,sans-serif,sans-=
serif;color:rgb(31,73,125);text-align:initial;background-color:rgb(255,255,=
255)">I&#39;ve had to support code that couldn&#39;t be changed because som=
eone (someone important) was subverting access rights, and thus we couldn&#=
39;t break that code.=C2=A0</div><div style=3D"width:100%;font-size:initial=
;font-family:Calibri,&#39;Slate Pro&#39;,sans-serif,sans-serif;color:rgb(31=
,73,125);text-align:initial;background-color:rgb(255,255,255)"><br></div></=
div></blockquote><div><br></div><div>You&#39;re luck there was someone to t=
ell you about the existence of that hack. You could at least find it in the=
 code.=C2=A0</div><div>In the other hand, I&#39;ve experienced situations w=
here someone retrofitted=C2=A0an invasive=C2=A0serialization library.</div>=
<div>The results were either scattered serialization code across the busine=
ss logic or for each class there was an accompanying serializable &quot;ada=
pter&quot;.</div><div>Needless to say both options have their problems.</di=
v><div><div><br></div><div>And serialization is just one use case.</div><di=
v>Another example is a unit test framework where protected/private member f=
unctions can be freely called to verify the internal behavior of a class.</=
div></div><div><br></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 style=3D"line-height:initial=
;background-color:rgb(255,255,255)" lang=3D"en-US"><div style=3D"width:100%=
;font-size:initial;font-family:Calibri,&#39;Slate Pro&#39;,sans-serif,sans-=
serif;color:rgb(31,73,125);text-align:initial;background-color:rgb(255,255,=
255)"></div><div style=3D"width:100%;font-size:initial;font-family:Calibri,=
&#39;Slate Pro&#39;,sans-serif,sans-serif;color:rgb(31,73,125);text-align:i=
nitial;background-color:rgb(255,255,255)">Think of the trouble DOS emulator=
s need to go through due to people relying on undocumented hacks. Sure this=
 will always exist, but do you want more of it or less?</div>              =
                                                                           =
                                            <div style=3D"width:100%;font-s=
ize:initial;font-family:Calibri,&#39;Slate Pro&#39;,sans-serif,sans-serif;c=
olor:rgb(31,73,125);text-align:initial;background-color:rgb(255,255,255)"><=
br style=3D"display:initial"></div></div></blockquote><div><br></div><div>W=
e already have undocumented hacks and no new proposal need to be done for t=
hat.</div><div><br></div><div>The discussion here is if we want a very well=
 documented standard way of accessing any class members under <i>special ci=
rcumstances</i>=C2=A0and what should be the costs both in terms of develope=
r time and computational resources.</div><div><br></div><div>As a C++ devel=
oper I&#39;d like to have the power to decide what&#39;s best for my code, =
assuming the risks and paying for the costs of my decision. Better if the l=
anguage offers a way to express clearly my intentions for others.</div><div=
><br></div><div>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,20=
4,204);border-left-style:solid;padding-left:1ex"><div style=3D"line-height:=
initial;background-color:rgb(255,255,255)" lang=3D"en-US"><div style=3D"wid=
th:100%;font-size:initial;font-family:Calibri,&#39;Slate Pro&#39;,sans-seri=
f,sans-serif;color:rgb(31,73,125);text-align:initial;background-color:rgb(2=
55,255,255)"></div>                                                        =
                                                                           =
                                                                <div style=
=3D"font-size:initial;font-family:Calibri,&#39;Slate Pro&#39;,sans-serif,sa=
ns-serif;color:rgb(31,73,125);text-align:initial;background-color:rgb(255,2=
55,255)">Sent=C2=A0from=C2=A0my=C2=A0BlackBerry=C2=A0<wbr>portable=C2=A0Bab=
bage=C2=A0Device</div>                                                     =
                                                                           =
                                                  <table style=3D"border-sp=
acing:0px;background-color:white" width=3D"100%"> <tbody><tr><td colspan=3D=
"2" style=3D"font-size:initial;text-align:initial;background-color:rgb(255,=
255,255)">                           <div style=3D"border-style:solid none =
none;border-top-color:rgb(181,196,223);border-top-width:1pt;padding:3pt 0in=
 0in;font-family:Tahoma,&#39;BB Alpha Sans&#39;,&#39;Slate Pro&#39;;font-si=
ze:10pt">  <div><b>From: </b>Ricardo Fabiano de Andrade</div><div><b>Sent: =
</b>Monday, April 25, 2016 6:28 PM</div><div><b>To: </b><a href=3D"javascri=
pt:" target=3D"_blank" gdf-obfuscated-mailto=3D"uTCemTn9BwAJ" rel=3D"nofoll=
ow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=
=3D"this.href=3D&#39;javascript:&#39;;return true;">std-pr...@isocpp.org</a=
></div><div><b>Reply To: </b><a href=3D"javascript:" target=3D"_blank" gdf-=
obfuscated-mailto=3D"uTCemTn9BwAJ" rel=3D"nofollow" onmousedown=3D"this.hre=
f=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascr=
ipt:&#39;;return true;">std-pr...@isocpp.org</a></div><div><b>Subject: </b>=
Re: [std-proposals] Re: About subverting access rights</div></div></td></tr=
></tbody></table><div style=3D"border-style:solid none none;border-top-colo=
r:rgb(186,188,209);border-top-width:1pt;font-size:initial;text-align:initia=
l;background-color:rgb(255,255,255)"></div><br><div><div dir=3D"ltr"><div><=
div class=3D"gmail_quote">On Mon, Apr 25, 2016 at 3:27 PM, Ville Voutilaine=
n <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfus=
cated-mailto=3D"uTCemTn9BwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&=
#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&=
#39;;return true;">ville.vo...@gmail.com</a>&gt;</span> wrote:<br><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-widt=
h:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-le=
ft:1ex">On 25 April 2016 at 22:49, Ricardo Fabiano de Andrade<br>
&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"uTCe=
mTn9BwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;=
;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;">r=
icardofabi...@<wbr>gmail.com</a>&gt; wrote:<br>
&gt; Hi Ville,<br>
&gt; That said, my concerns is that this reflection proposal introduces a n=
ew,<br>
&gt; standard way to violate encapsulation.<br>
<br>
A way that is easy to find and ban, though.<br>
<br></blockquote><div><br></div><div>Agreed. I don&#39;t think any alternat=
ive should be different.</div><div>=C2=A0<br></div><blockquote class=3D"gma=
il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-le=
ft-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
&gt; However, it has some costs both in terms of computing resources - time=
 to<br>
&gt; compile, program size - and human resources - time to learn reflection=
 and<br>
&gt; template meta-programming and apply these effectively and consistently=
..<br>
&gt; Which may lead to people ditching it and keep using the existing &quot=
;dirty&quot;<br>
&gt; ways, which are difficult to identify in the code.<br>
<br>
I fail to see why that&#39;s such a concern. Bypassing access controls is i=
ndeed not<br>
the main reason for reflection.<br>
<br></blockquote><div><br></div><div>For me it&#39;s a concern because=C2=
=A0either=C2=A0people will use it for this purpose (making it easy to find =
and ban).</div><div>Or because it&#39;s relatively more difficult to be don=
e, people will not use it and the old ways will prevail (making it hard to =
find and nearly impossible to ban).</div><div><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;bo=
rder-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
&gt; Using Nicol&#39;s argument in the opposite direction, reflection does =
exist to<br>
&gt; violate encapsulation but it will be used with this purpose.<br>
<br>
I presume that sentence is missing a &quot;not&quot;.<br></blockquote><div>=
<br></div><div>Correct, my apologies.</div><div>=C2=A0</div><blockquote cla=
ss=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=
">
<br>
&gt; Then comes the question that maybe it would be better to allow this to=
 be<br>
&gt; done outside of the context of reflection (so reflection would not be =
used<br>
&gt; when it&#39;s not necessary).<br>
&gt; Being also the main reason why this is not being discussed in the SG7 =
group.<br>
<br>
I don&#39;t know what you think is not being discussed in SG7.<br>
<span><font color=3D"#888888"><br></font></span></blockquote><div><br></div=
><div>I didn&#39;t make myself clear on that one.</div><div><br></div><div>=
You&#39;re right, this matter is being actively discussed by the SG7 in the=
 context of reflection.</div><div><br></div><div>My question is whether=C2=
=A0it should=C2=A0or not be discussed outside of the SG7 as well (that&#39;=
s why I posted here).</div><div>And additionally, if a &quot;good&quot; (as=
 costly as the alternatives, easy to find and ban) mechanism for subverting=
 access rights exists, there&#39;s no need to add another one in reflection=
..</div><div>Not having this &quot;functionality&quot; in the reflection pro=
posal (implicitly or explicitly) also make it cleaner.<br></div></div></div=
></div></div></div></blockquote></div><br></div></div></div></blockquote><d=
iv><br>Here&#39;s the fundamental problem with what you suggest.<br><br>You=
r basic argument is that, if we had a standard supported way of subverting =
access rights, then we could search our code for people who are using it.<b=
r><br>But the fact is that&#39;s not true. Why? Because the old, non-standa=
rd way of subverting access rights <i>will still exist</i>. It is therefore=
 up to each individual user to decide if they want to use the new, standard=
 way or keep their old code around.<br><br>And generally speaking, people w=
ill opt to keep their old code around. It still works, after all.<br><br>So=
 while in theory this might be helpful, in practice it won&#39;t be. If you=
 search your codebase for the standard access subversion methods, you still=
 won&#39;t find the non-standard ones.<br><br>The illusion of safety is sti=
ll an illusion.<br><br>Also, I take issue with the idea that we can&#39;t s=
earch the code for such cases. Generally speaking, they will involve unsafe=
 casts that a good static analyzer can detect and warn you about. Also, suc=
h a static analyzer can find other problems.<br></div></div>

<p></p>

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

------=_Part_629_567130492.1461685332914--
------=_Part_628_164568227.1461685332913--

.

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

On Tue, Apr 26, 2016 at 10:42 AM, Nicol Bolas <jmckesson@gmail.com> wrote:

> On Tuesday, April 26, 2016 at 12:47:50 AM UTC-4, Ricardo Andrade wrote:
>>
>> Hi Tony, your comments are much appreciated. Here are some arguments
>> though.
>> On Mon, Apr 25, 2016 at 9:19 PM, Tony V E <tvan...@gmail.com> wrote:
>>
>>> IMO:
>>> - reflection should not subvert access rights
>>> - neither should anything else
>>>
>>>
>> In theory this is desired, but let's face it, there's 35+ years of legacy
>> code (when we get reflection probably 40) which will not get rewritten or
>> even touched any time soon.
>> It's not a perfect world. Non-invasive techniques and language support
>> for them (such as reflection) are very valuable in this context.
>>
>>
>>> If the number one reason is serialization, let's make some easier
>>> serialization library.
>>>
>>>
>> I assume you're suggesting an invasive serialization library.
>> In general, that requires adding some (definitely tedious/potentially
>> slow) boilerplate code and/or modifying existing code to add serialization
>> support.
>>
>> Reflection can definitely help in both cases but it really shines when
>> you think about a non-invasive approach.
>> Up to the point where you run into a situation where you'll be required
>> to access a private/protected member, then the choice is either making a
>> class member public or getting your hands dirty.
>> Breaking into the class can potentially offer a much tighter and granular
>> control over this access and tends to be a safer bet than making things
>> public to everyone.
>>
>>
>>> I've had to support code that couldn't be changed because someone
>>> (someone important) was subverting access rights, and thus we couldn't
>>> break that code.
>>>
>>>
>> You're luck there was someone to tell you about the existence of that
>> hack. You could at least find it in the code.
>> In the other hand, I've experienced situations where someone
>> retrofitted an invasive serialization library.
>> The results were either scattered serialization code across the business
>> logic or for each class there was an accompanying serializable "adapter".
>> Needless to say both options have their problems.
>>
>> And serialization is just one use case.
>> Another example is a unit test framework where protected/private member
>> functions can be freely called to verify the internal behavior of a class.
>>
>> Think of the trouble DOS emulators need to go through due to people
>>> relying on undocumented hacks. Sure this will always exist, but do you want
>>> more of it or less?
>>>
>>>
>> We already have undocumented hacks and no new proposal need to be done
>> for that.
>>
>> The discussion here is if we want a very well documented standard way of
>> accessing any class members under *special circumstances* and what
>> should be the costs both in terms of developer time and computational
>> resources.
>>
>> As a C++ developer I'd like to have the power to decide what's best for
>> my code, assuming the risks and paying for the costs of my decision. Better
>> if the language offers a way to express clearly my intentions for others.
>>
>>
>>
>>> Sent from my BlackBerry portable Babbage Device
>>> *From: *Ricardo Fabiano de Andrade
>>> *Sent: *Monday, April 25, 2016 6:28 PM
>>> *To: *std-pr...@isocpp.org
>>> *Reply To: *std-pr...@isocpp.org
>>> *Subject: *Re: [std-proposals] Re: About subverting access rights
>>>
>>> On Mon, Apr 25, 2016 at 3:27 PM, Ville Voutilainen <
>>> ville.vo...@gmail.com> wrote:
>>>
>>>> On 25 April 2016 at 22:49, Ricardo Fabiano de Andrade
>>>> <ricardofabi...@gmail.com> wrote:
>>>> > Hi Ville,
>>>> > That said, my concerns is that this reflection proposal introduces a
>>>> new,
>>>> > standard way to violate encapsulation.
>>>>
>>>> A way that is easy to find and ban, though.
>>>>
>>>>
>>> Agreed. I don't think any alternative should be different.
>>>
>>>
>>>> > However, it has some costs both in terms of computing resources -
>>>> time to
>>>> > compile, program size - and human resources - time to learn
>>>> reflection and
>>>> > template meta-programming and apply these effectively and
>>>> consistently.
>>>> > Which may lead to people ditching it and keep using the existing
>>>> "dirty"
>>>> > ways, which are difficult to identify in the code.
>>>>
>>>> I fail to see why that's such a concern. Bypassing access controls is
>>>> indeed not
>>>> the main reason for reflection.
>>>>
>>>>
>>> For me it's a concern because either people will use it for this purpose
>>> (making it easy to find and ban).
>>> Or because it's relatively more difficult to be done, people will not
>>> use it and the old ways will prevail (making it hard to find and nearly
>>> impossible to ban).
>>>
>>> > Using Nicol's argument in the opposite direction, reflection does
>>>> exist to
>>>> > violate encapsulation but it will be used with this purpose.
>>>>
>>>> I presume that sentence is missing a "not".
>>>>
>>>
>>> Correct, my apologies.
>>>
>>>
>>>>
>>>> > Then comes the question that maybe it would be better to allow this
>>>> to be
>>>> > done outside of the context of reflection (so reflection would not be
>>>> used
>>>> > when it's not necessary).
>>>> > Being also the main reason why this is not being discussed in the SG7
>>>> group.
>>>>
>>>> I don't know what you think is not being discussed in SG7.
>>>>
>>>>
>>> I didn't make myself clear on that one.
>>>
>>> You're right, this matter is being actively discussed by the SG7 in the
>>> context of reflection.
>>>
>>> My question is whether it should or not be discussed outside of the SG7
>>> as well (that's why I posted here).
>>> And additionally, if a "good" (as costly as the alternatives, easy to
>>> find and ban) mechanism for subverting access rights exists, there's no
>>> need to add another one in reflection.
>>> Not having this "functionality" in the reflection proposal (implicitly
>>> or explicitly) also make it cleaner.
>>>
>>
>>
> Here's the fundamental problem with what you suggest.
>
> Your basic argument is that, if we had a standard supported way of
> subverting access rights, then we could search our code for people who are
> using it.
>
> But the fact is that's not true. Why? Because the old, non-standard way of
> subverting access rights *will still exist*. It is therefore up to each
> individual user to decide if they want to use the new, standard way or keep
> their old code around.
>
> And generally speaking, people will opt to keep their old code around. It
> still works, after all.
>
> So while in theory this might be helpful, in practice it won't be. If you
> search your codebase for the standard access subversion methods, you still
> won't find the non-standard ones.
>
> The illusion of safety is still an illusion.
>
> Also, I take issue with the idea that we can't search the code for such
> cases. Generally speaking, they will involve unsafe casts that a good
> static analyzer can detect and warn you about. Also, such a static analyzer
> can find other problems.
>

Those are indeed good arguments. And you're right, it would be just an
optional abstraction that does not make the code any safer.

What I had in mind was something like owner<T> or not_null<T> of the Core
Guidelines.
Even though people would initially keep the old habits, they would move
towards the standard solution over time. I believe it's what happened with
the C-style casts.
Unfortunately, achieving a similar effect for the access rights without
language support is difficult.

I guess reflection will get the bad reputation then.

--
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/472a15d5-4591-4bd1-9233-01c8550c5c6f%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/472a15d5-4591-4bd1-9233-01c8550c5c6f%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BfGSbMNRKoQCTsQtWmHXXMXV8qqC_KN3E-EApW6DKSDDW5GOw%40mail.gmail.com.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Tue, Apr 26, 2016 at 10:42 AM, Nicol Bolas <span dir=3D"ltr">&lt;<a href=
=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&g=
t;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);borde=
r-left-style:solid;padding-left:1ex"><div dir=3D"ltr">On Tuesday, April 26,=
 2016 at 12:47:50 AM UTC-4, Ricardo Andrade wrote:<blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-lef=
t-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir=
=3D"ltr">Hi Tony, your comments are much appreciated. Here are some argumen=
ts though.<div><div><div class=3D"gmail_quote">On Mon, Apr 25, 2016 at 9:19=
 PM, Tony V E <span dir=3D"ltr">&lt;<a rel=3D"nofollow">tvan...@gmail.com</=
a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);b=
order-left-style:solid;padding-left:1ex"><div style=3D"line-height:initial;=
background-color:rgb(255,255,255)" lang=3D"en-US">                         =
                                                             <div style=3D"=
width:100%;font-size:initial;font-family:Calibri,&#39;Slate Pro&#39;,sans-s=
erif,sans-serif;color:rgb(31,73,125);text-align:initial;background-color:rg=
b(255,255,255)">IMO:</div><div style=3D"width:100%;font-size:initial;font-f=
amily:Calibri,&#39;Slate Pro&#39;,sans-serif,sans-serif;color:rgb(31,73,125=
);text-align:initial;background-color:rgb(255,255,255)">- reflection should=
 not subvert access rights</div><div style=3D"width:100%;font-size:initial;=
font-family:Calibri,&#39;Slate Pro&#39;,sans-serif,sans-serif;color:rgb(31,=
73,125);text-align:initial;background-color:rgb(255,255,255)">- neither sho=
uld anything else</div><div style=3D"width:100%;font-size:initial;font-fami=
ly:Calibri,&#39;Slate Pro&#39;,sans-serif,sans-serif;color:rgb(31,73,125);t=
ext-align:initial;background-color:rgb(255,255,255)"><br></div></div></bloc=
kquote><div>=C2=A0</div><div>In theory this is desired, but let&#39;s face =
it, there&#39;s 35+ years=C2=A0of legacy code=C2=A0(when we get reflection =
probably 40) which will not get rewritten or even touched any time soon.</d=
iv><div>It&#39;s not a perfect world. Non-invasive techniques and language =
support for them (such as reflection) are very valuable in this context.</d=
iv><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);borde=
r-left-style:solid;padding-left:1ex"><div style=3D"line-height:initial;back=
ground-color:rgb(255,255,255)" lang=3D"en-US"><div style=3D"width:100%;font=
-size:initial;font-family:Calibri,&#39;Slate Pro&#39;,sans-serif,sans-serif=
;color:rgb(31,73,125);text-align:initial;background-color:rgb(255,255,255)"=
></div><div style=3D"width:100%;font-size:initial;font-family:Calibri,&#39;=
Slate Pro&#39;,sans-serif,sans-serif;color:rgb(31,73,125);text-align:initia=
l;background-color:rgb(255,255,255)">If the number one reason is serializat=
ion, let&#39;s make some easier serialization library.=C2=A0</div><div styl=
e=3D"width:100%;font-size:initial;font-family:Calibri,&#39;Slate Pro&#39;,s=
ans-serif,sans-serif;color:rgb(31,73,125);text-align:initial;background-col=
or:rgb(255,255,255)"><br></div></div></blockquote><div><br></div><div>I ass=
ume you&#39;re suggesting an invasive serialization library.</div><div>In g=
eneral, that requires adding some (definitely tedious/potentially slow) boi=
lerplate code and/or modifying existing code to add serialization support.<=
/div><div><br></div><div>Reflection can definitely help in both cases but i=
t really shines when you think about a non-invasive approach.</div><div>Up =
to the point where you run into a situation where you&#39;ll be required to=
 access a private/protected member, then the choice is either making a clas=
s member public or getting your hands dirty.<br></div><div>Breaking into th=
e class can potentially offer a much tighter and granular control over this=
 access and tends to be a safer bet than making things public to everyone.<=
/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);bor=
der-left-style:solid;padding-left:1ex"><div style=3D"line-height:initial;ba=
ckground-color:rgb(255,255,255)" lang=3D"en-US"><div style=3D"width:100%;fo=
nt-size:initial;font-family:Calibri,&#39;Slate Pro&#39;,sans-serif,sans-ser=
if;color:rgb(31,73,125);text-align:initial;background-color:rgb(255,255,255=
)"></div><div style=3D"width:100%;font-size:initial;font-family:Calibri,&#3=
9;Slate Pro&#39;,sans-serif,sans-serif;color:rgb(31,73,125);text-align:init=
ial;background-color:rgb(255,255,255)">I&#39;ve had to support code that co=
uldn&#39;t be changed because someone (someone important) was subverting ac=
cess rights, and thus we couldn&#39;t break that code.=C2=A0</div><div styl=
e=3D"width:100%;font-size:initial;font-family:Calibri,&#39;Slate Pro&#39;,s=
ans-serif,sans-serif;color:rgb(31,73,125);text-align:initial;background-col=
or:rgb(255,255,255)"><br></div></div></blockquote><div><br></div><div>You&#=
39;re luck there was someone to tell you about the existence of that hack. =
You could at least find it in the code.=C2=A0</div><div>In the other hand, =
I&#39;ve experienced situations where someone retrofitted=C2=A0an invasive=
=C2=A0serialization library.</div><div>The results were either scattered se=
rialization code across the business logic or for each class there was an a=
ccompanying serializable &quot;adapter&quot;.</div><div>Needless to say bot=
h options have their problems.</div><div><div><br></div><div>And serializat=
ion is just one use case.</div><div>Another example is a unit test framewor=
k where protected/private member functions can be freely called to verify t=
he internal behavior of a class.</div></div><div><br></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;b=
order-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"=
><div style=3D"line-height:initial;background-color:rgb(255,255,255)" lang=
=3D"en-US"><div style=3D"width:100%;font-size:initial;font-family:Calibri,&=
#39;Slate Pro&#39;,sans-serif,sans-serif;color:rgb(31,73,125);text-align:in=
itial;background-color:rgb(255,255,255)"></div><div style=3D"width:100%;fon=
t-size:initial;font-family:Calibri,&#39;Slate Pro&#39;,sans-serif,sans-seri=
f;color:rgb(31,73,125);text-align:initial;background-color:rgb(255,255,255)=
">Think of the trouble DOS emulators need to go through due to people relyi=
ng on undocumented hacks. Sure this will always exist, but do you want more=
 of it or less?</div>                                                      =
                                                                           =
    <div style=3D"width:100%;font-size:initial;font-family:Calibri,&#39;Sla=
te Pro&#39;,sans-serif,sans-serif;color:rgb(31,73,125);text-align:initial;b=
ackground-color:rgb(255,255,255)"><br style=3D"display:initial"></div></div=
></blockquote><div><br></div><div>We already have undocumented hacks and no=
 new proposal need to be done for that.</div><div><br></div><div>The discus=
sion here is if we want a very well documented standard way of accessing an=
y class members under <i>special circumstances</i>=C2=A0and what should be =
the costs both in terms of developer time and computational resources.</div=
><div><br></div><div>As a C++ developer I&#39;d like to have the power to d=
ecide what&#39;s best for my code, assuming the risks and paying for the co=
sts of my decision. Better if the language offers a way to express clearly =
my intentions for others.</div><div><br></div><div>=C2=A0<br></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-wid=
th:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-l=
eft:1ex"><div style=3D"line-height:initial;background-color:rgb(255,255,255=
)" lang=3D"en-US"><div style=3D"width:100%;font-size:initial;font-family:Ca=
libri,&#39;Slate Pro&#39;,sans-serif,sans-serif;color:rgb(31,73,125);text-a=
lign:initial;background-color:rgb(255,255,255)"></div>                     =
                                                                           =
                                                                           =
                        <div style=3D"font-size:initial;font-family:Calibri=
,&#39;Slate Pro&#39;,sans-serif,sans-serif;color:rgb(31,73,125);text-align:=
initial;background-color:rgb(255,255,255)">Sent=C2=A0from=C2=A0my=C2=A0Blac=
kBerry=C2=A0portable=C2=A0Babbage=C2=A0Device</div>                        =
                                                                           =
                                                                           =
    <table style=3D"border-spacing:0px;background-color:white" width=3D"100=
%"> <tbody><tr><td colspan=3D"2" style=3D"font-size:initial;text-align:init=
ial;background-color:rgb(255,255,255)">                           <div styl=
e=3D"border-style:solid none none;border-top-color:rgb(181,196,223);border-=
top-width:1pt;padding:3pt 0in 0in;font-family:Tahoma,&#39;BB Alpha Sans&#39=
;,&#39;Slate Pro&#39;;font-size:10pt">  <div><b>From: </b>Ricardo Fabiano d=
e Andrade</div><div><b>Sent: </b>Monday, April 25, 2016 6:28 PM</div><div><=
b>To: </b><a rel=3D"nofollow">std-pr...@isocpp.org</a></div><div><b>Reply T=
o: </b><a rel=3D"nofollow">std-pr...@isocpp.org</a></div><div><b>Subject: <=
/b>Re: [std-proposals] Re: About subverting access rights</div></div></td><=
/tr></tbody></table><div style=3D"border-style:solid none none;border-top-c=
olor:rgb(186,188,209);border-top-width:1pt;font-size:initial;text-align:ini=
tial;background-color:rgb(255,255,255)"></div><br><div><div dir=3D"ltr"><di=
v><div class=3D"gmail_quote">On Mon, Apr 25, 2016 at 3:27 PM, Ville Voutila=
inen <span dir=3D"ltr">&lt;<a rel=3D"nofollow">ville.vo...@gmail.com</a>&gt=
;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border=
-left-style:solid;padding-left:1ex">On 25 April 2016 at 22:49, Ricardo Fabi=
ano de Andrade<br>
&lt;<a rel=3D"nofollow">ricardofabi...@gmail.com</a>&gt; wrote:<br>
&gt; Hi Ville,<br>
&gt; That said, my concerns is that this reflection proposal introduces a n=
ew,<br>
&gt; standard way to violate encapsulation.<br>
<br>
A way that is easy to find and ban, though.<br>
<br></blockquote><div><br></div><div>Agreed. I don&#39;t think any alternat=
ive should be different.</div><div>=C2=A0<br></div><blockquote class=3D"gma=
il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-le=
ft-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
&gt; However, it has some costs both in terms of computing resources - time=
 to<br>
&gt; compile, program size - and human resources - time to learn reflection=
 and<br>
&gt; template meta-programming and apply these effectively and consistently=
..<br>
&gt; Which may lead to people ditching it and keep using the existing &quot=
;dirty&quot;<br>
&gt; ways, which are difficult to identify in the code.<br>
<br>
I fail to see why that&#39;s such a concern. Bypassing access controls is i=
ndeed not<br>
the main reason for reflection.<br>
<br></blockquote><div><br></div><div>For me it&#39;s a concern because=C2=
=A0either=C2=A0people will use it for this purpose (making it easy to find =
and ban).</div><div>Or because it&#39;s relatively more difficult to be don=
e, people will not use it and the old ways will prevail (making it hard to =
find and nearly impossible to ban).</div><div><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;bo=
rder-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
&gt; Using Nicol&#39;s argument in the opposite direction, reflection does =
exist to<br>
&gt; violate encapsulation but it will be used with this purpose.<br>
<br>
I presume that sentence is missing a &quot;not&quot;.<br></blockquote><div>=
<br></div><div>Correct, my apologies.</div><div>=C2=A0</div><blockquote cla=
ss=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=
">
<br>
&gt; Then comes the question that maybe it would be better to allow this to=
 be<br>
&gt; done outside of the context of reflection (so reflection would not be =
used<br>
&gt; when it&#39;s not necessary).<br>
&gt; Being also the main reason why this is not being discussed in the SG7 =
group.<br>
<br>
I don&#39;t know what you think is not being discussed in SG7.<br>
<span><font color=3D"#888888"><br></font></span></blockquote><div><br></div=
><div>I didn&#39;t make myself clear on that one.</div><div><br></div><div>=
You&#39;re right, this matter is being actively discussed by the SG7 in the=
 context of reflection.</div><div><br></div><div>My question is whether=C2=
=A0it should=C2=A0or not be discussed outside of the SG7 as well (that&#39;=
s why I posted here).</div><div>And additionally, if a &quot;good&quot; (as=
 costly as the alternatives, easy to find and ban) mechanism for subverting=
 access rights exists, there&#39;s no need to add another one in reflection=
..</div><div>Not having this &quot;functionality&quot; in the reflection pro=
posal (implicitly or explicitly) also make it cleaner.<br></div></div></div=
></div></div></div></blockquote></div><br></div></div></div></blockquote><d=
iv><br>Here&#39;s the fundamental problem with what you suggest.<br><br>You=
r basic argument is that, if we had a standard supported way of subverting =
access rights, then we could search our code for people who are using it.<b=
r><br>But the fact is that&#39;s not true. Why? Because the old, non-standa=
rd way of subverting access rights <i>will still exist</i>. It is therefore=
 up to each individual user to decide if they want to use the new, standard=
 way or keep their old code around.<br><br>And generally speaking, people w=
ill opt to keep their old code around. It still works, after all.<br><br>So=
 while in theory this might be helpful, in practice it won&#39;t be. If you=
 search your codebase for the standard access subversion methods, you still=
 won&#39;t find the non-standard ones.<br><br>The illusion of safety is sti=
ll an illusion.<br><br>Also, I take issue with the idea that we can&#39;t s=
earch the code for such cases. Generally speaking, they will involve unsafe=
 casts that a good static analyzer can detect and warn you about. Also, suc=
h a static analyzer can find other problems.</div></div></blockquote><div><=
br></div><div>Those are indeed good arguments. And you&#39;re right, it wou=
ld be just an optional abstraction that does not make the code any safer.</=
div><div><br></div><div>What I had in mind was something like owner&lt;T&gt=
; or not_null&lt;T&gt; of the Core Guidelines.</div><div>Even though people=
 would initially keep the old habits, they would move towards the standard =
solution over time. I believe it&#39;s what happened with the C-style casts=
..</div><div>Unfortunately, achieving a similar effect for the access rights=
=C2=A0without language support=C2=A0is difficult.</div><div><br></div><div>=
I guess reflection will get the bad reputation then.</div><div><br></div><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"><span class=3D""><font color=3D"#888888">-- <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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/472a15d5-4591-4bd1-9233-01c8550c5c6f%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/472a15d5-4591-=
4bd1-9233-01c8550c5c6f%40isocpp.org</a>.<br>
</font></span></blockquote></div><br></div></div>

<p></p>

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

--94eb2c1246e0c8525b053166fde7--

.

------=_Part_6066_797349029.1461695408028
Content-Type: multipart/alternative;
 boundary="----=_Part_6067_851162963.1461695408028"

------=_Part_6067_851162963.1461695408028
Content-Type: text/plain; charset=UTF-8

On Tuesday, April 26, 2016 at 1:54:59 PM UTC-4, Ricardo Andrade wrote:
>
> On Tue, Apr 26, 2016 at 10:42 AM, Nicol Bolas <jmck...@gmail.com
> <javascript:>> wrote:
>
I guess reflection will get the bad reputation then.
>

I fail to see how reflection's reputation will be in any way affected by
people who want to violate encapsulation.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2257513b-f4d8-44ed-8ccf-1da1ff1e4ac5%40isocpp.org.

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

<div dir=3D"ltr">On Tuesday, April 26, 2016 at 1:54:59 PM UTC-4, Ricardo An=
drade wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><=
div><div>On Tue, Apr 26, 2016 at 10:42 AM, Nicol Bolas <span dir=3D"ltr">&l=
t;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"LrzuBi=
4oCAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;r=
eturn true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;">jmc=
k...@gmail.com</a>&gt;</span> wrote: <br></div></div></div></blockquote><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><div class=
=3D"gmail_quote"><div></div><div>I guess reflection will get the bad reputa=
tion then.<br></div></div></div></div></blockquote><div><br>I fail to see h=
ow reflection&#39;s reputation will be in any way affected by people who wa=
nt to violate encapsulation.<br></div></div>

<p></p>

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

------=_Part_6067_851162963.1461695408028--
------=_Part_6066_797349029.1461695408028--

.

I do not understand all this fuzz about subversion of access rights.
Let us face it:
*) The purpose of access privileges is to protect the programmer from
doing something stupid, such as using an
    object in a way it way not designed to be used. It has never been
the purpose of access privileges to e.g. protect
    a system from an intruder or something in that direction.
*) There are already ways in C++ to get access to the private parts of
an object. Having one more way to do so is not
   a problem.
That being said, I believe that getting the access should be
difficult: it should be blatantly clear that you are doing
something dangerous - just as it is with e.g. reinterpret_cast. Also,
I fail to see the advantage of having this access.
I am in the camp that believes that e.g. serialization is perfectly
feasible without knowledge of the inner details about
how such a class is defined.
My biggest concern about a reflection library would thus not be if it
would allow you to subvert the access rights.
Instead, it would be if it prevented you from doing so by accident.

/Peter

On Tue, Apr 26, 2016 at 8:30 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
> On Tuesday, April 26, 2016 at 1:54:59 PM UTC-4, Ricardo Andrade wrote:
>>
>> On Tue, Apr 26, 2016 at 10:42 AM, Nicol Bolas <jmck...@gmail.com> wrote:
>>
>> I guess reflection will get the bad reputation then.
>
>
> I fail to see how reflection's reputation will be in any way affected by
> people who want to violate encapsulation.
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2257513b-f4d8-44ed-8ccf-1da1ff1e4ac5%40isocpp.org.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANPtknxLtKDGP7ShScB33LoC_PxBBGPx%3D_jSo8kj9f_Z-42FxA%40mail.gmail.com.

.

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

Let me summarize the whole point of starting this discussion...
- We cannot prevent people from circumventing encapsulation.
- Reflection is likely to add yet another way to do it.
- This will be the first "standard" way for this purpose.
- It has the benefit of being easy to spot in the code (currently as
get_all_data_members in P0194R0).
- But there's a chance it will be costly in terms of compile time and
complexity.
- People may end up not using it and sticking with the old "non-standard"
ways - here goes the benefit.
- In the other hand, if people do use it, reflection gets the bad
reputation of being "the corner of the language reserved for evil" - as it
does in the other languages.
- Now that you mentioned accidents, get_all_data_members vs.
get_data_members don't contribute much to prevent those, but there's still
time to work that out - I'll mentioned that to the author of P0194R0.

That said, comes the question:
Wouldn't be better to provide a "reinterpret_cast"-like mechanism (or
anything else) just for this purpose?

- Reflection would be the "mechanism to list declarations and infer their
characteristics", the way to use them that's up to you.
- It would be easy and obvious to find such violations in the code. Then
violators can be caught.
- If a proposed solution has equivalent performance of the hacky
alternatives but it states clearly the intentions, people will prefer to
use it (or they would be so ashamed of having such ideas and avoid it).
- A dedicated language solution is more likely to find a better balance for
safety, freedom and clarity than something buried deep down in reflection.

I bet there are several ideas that could work out but first we need to go
over this feeling that people will use whatever is proposed everyday and
break everything.
People stay away from "reinterpret_cast" already because is too 'dark' and
bet people would think twice before using something called
"violate_access_cast".

That's it.

On Wed, Apr 27, 2016 at 4:13 PM, Peter Koch Larsen <
peter.koch.larsen@gmail.com> wrote:

> I do not understand all this fuzz about subversion of access rights.
> Let us face it:
> *) The purpose of access privileges is to protect the programmer from
> doing something stupid, such as using an
>     object in a way it way not designed to be used. It has never been
> the purpose of access privileges to e.g. protect
>     a system from an intruder or something in that direction.
> *) There are already ways in C++ to get access to the private parts of
> an object. Having one more way to do so is not
>    a problem.
> That being said, I believe that getting the access should be
> difficult: it should be blatantly clear that you are doing
> something dangerous - just as it is with e.g. reinterpret_cast. Also,
> I fail to see the advantage of having this access.
> I am in the camp that believes that e.g. serialization is perfectly
> feasible without knowledge of the inner details about
> how such a class is defined.
> My biggest concern about a reflection library would thus not be if it
> would allow you to subvert the access rights.
> Instead, it would be if it prevented you from doing so by accident.
>
> /Peter
>
> On Tue, Apr 26, 2016 at 8:30 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
> > On Tuesday, April 26, 2016 at 1:54:59 PM UTC-4, Ricardo Andrade wrote:
> >>
> >> On Tue, Apr 26, 2016 at 10:42 AM, Nicol Bolas <jmck...@gmail.com>
> wrote:
> >>
> >> I guess reflection will get the bad reputation then.
> >
> >
> > I fail to see how reflection's reputation will be in any way affected by
> > people who want to violate encapsulation.
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "ISO C++ Standard - Future Proposals" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to std-proposals+unsubscribe@isocpp.org.
> > To post to this group, send email to std-proposals@isocpp.org.
> > To view this discussion on the web visit
> >
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2257513b-f4d8-44ed-8ccf-1da1ff1e4ac5%40isocpp.org
> .
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANPtknxLtKDGP7ShScB33LoC_PxBBGPx%3D_jSo8kj9f_Z-42FxA%40mail.gmail.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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BfGSbNdikEoZ7TXz_9JS862Sa5ZL%2BUJC%3DVQBXOr0%2BGpp4%3D1LA%40mail.gmail.com.

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

<div dir=3D"ltr">Let me summarize the whole point of starting this discussi=
on...<div>- We cannot prevent people from circumventing encapsulation.</div=
><div>- Reflection is likely to add yet another way to do it.</div><div>- T=
his will be the first &quot;standard&quot; way for this purpose.</div><div>=
- It has the benefit of being easy to spot in the code (currently as get_al=
l_data_members in P0194R0).</div><div>- But there&#39;s a chance it will be=
 costly in terms of compile time and complexity.</div><div>- People may end=
 up not using it and sticking with the old &quot;non-standard&quot; ways - =
here goes the benefit.</div><div>- In the other hand, if people do use it, =
reflection gets the bad reputation of being &quot;the corner of the languag=
e reserved for evil&quot; - as it does in the other languages.</div><div>- =
Now that you mentioned accidents, get_all_data_members vs. get_data_members=
 don&#39;t contribute much to prevent those, but there&#39;s still time to =
work that out - I&#39;ll mentioned that to the author of P0194R0.</div><div=
><br></div><div>That said, comes the question:</div><div>Wouldn&#39;t be be=
tter to provide a &quot;reinterpret_cast&quot;-like mechanism (or anything =
else) just for this purpose?</div><div><br></div><div>- Reflection would be=
 the &quot;mechanism to list declarations and infer their characteristics&q=
uot;, the way to use them that&#39;s up to you.</div><div>- It would be eas=
y and obvious to find such violations in the code. Then violators can be ca=
ught.</div><div>- If a proposed solution has equivalent performance of the =
hacky alternatives but it states clearly the intentions, people will prefer=
 to use it (or they would be so ashamed of having such ideas and avoid it).=
</div><div>- A dedicated language solution is more likely to find a better =
balance for safety, freedom and clarity than something buried deep down in =
reflection.</div><div><br></div><div>I bet there are several ideas that cou=
ld work out but first we need to go over this feeling that people will use =
whatever is proposed everyday and break everything.</div><div>People stay a=
way from &quot;reinterpret_cast&quot; already because is too &#39;dark&#39;=
 and bet people would think twice before using something called &quot;viola=
te_access_cast&quot;.</div><div><br></div><div>That&#39;s it.<br></div><div=
><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Wed, Apr 27, =
2016 at 4:13 PM, Peter Koch Larsen <span dir=3D"ltr">&lt;<a href=3D"mailto:=
peter.koch.larsen@gmail.com" target=3D"_blank">peter.koch.larsen@gmail.com<=
/a>&gt;</span> wrote:<br><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">I do not understand all this fuzz=
 about subversion of access rights.<br>
Let us face it:<br>
*) The purpose of access privileges is to protect the programmer from<br>
doing something stupid, such as using an<br>
=C2=A0 =C2=A0 object in a way it way not designed to be used. It has never =
been<br>
the purpose of access privileges to e.g. protect<br>
=C2=A0 =C2=A0 a system from an intruder or something in that direction.<br>
*) There are already ways in C++ to get access to the private parts of<br>
an object. Having one more way to do so is not<br>
=C2=A0 =C2=A0a problem.<br>
That being said, I believe that getting the access should be<br>
difficult: it should be blatantly clear that you are doing<br>
something dangerous - just as it is with e.g. reinterpret_cast. Also,<br>
I fail to see the advantage of having this access.<br>
I am in the camp that believes that e.g. serialization is perfectly<br>
feasible without knowledge of the inner details about<br>
how such a class is defined.<br>
My biggest concern about a reflection library would thus not be if it<br>
would allow you to subvert the access rights.<br>
Instead, it would be if it prevented you from doing so by accident.<br>
<br>
/Peter<br>
<br>
On Tue, Apr 26, 2016 at 8:30 PM, Nicol Bolas &lt;<a href=3D"mailto:jmckesso=
n@gmail.com">jmckesson@gmail.com</a>&gt; wrote:<br>
&gt; On Tuesday, April 26, 2016 at 1:54:59 PM UTC-4, Ricardo Andrade wrote:=
<br>
&gt;&gt;<br>
&gt;&gt; On Tue, Apr 26, 2016 at 10:42 AM, Nicol Bolas &lt;<a href=3D"mailt=
o:jmck...@gmail.com">jmck...@gmail.com</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; I guess reflection will get the bad reputation then.<br>
&gt;<br>
&gt;<br>
&gt; I fail to see how reflection&#39;s reputation will be in any way affec=
ted by<br>
&gt; people who want to violate encapsulation.<br>
<span class=3D""><font color=3D"#888888">&gt;<br>
&gt; --<br>
&gt; You received this message because you are subscribed to the Google Gro=
ups<br>
&gt; &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
&gt; To unsubscribe from this group and stop receiving emails from it, send=
 an<br>
&gt; email to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std=
-proposals+unsubscribe@isocpp.org</a>.<br>
&gt; To post to this group, send email to <a href=3D"mailto:std-proposals@i=
socpp.org">std-proposals@isocpp.org</a>.<br>
&gt; To view this discussion on the web visit<br>
&gt; <a href=3D"https://groups.google.com/a/isocpp.org/d/msgid/std-proposal=
s/2257513b-f4d8-44ed-8ccf-1da1ff1e4ac5%40isocpp.org" rel=3D"noreferrer" tar=
get=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals=
/2257513b-f4d8-44ed-8ccf-1da1ff1e4ac5%40isocpp.org</a>.<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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CANPtknxLtKDGP7ShScB33LoC_PxBBGPx%3D_=
jSo8kj9f_Z-42FxA%40mail.gmail.com" rel=3D"noreferrer" target=3D"_blank">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANPtknxLtKDGP7Sh=
ScB33LoC_PxBBGPx%3D_jSo8kj9f_Z-42FxA%40mail.gmail.com</a>.<br>
</font></span></blockquote></div><br></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CA%2BfGSbNdikEoZ7TXz_9JS862Sa5ZL%2BUJ=
C%3DVQBXOr0%2BGpp4%3D1LA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Df=
ooter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BfG=
SbNdikEoZ7TXz_9JS862Sa5ZL%2BUJC%3DVQBXOr0%2BGpp4%3D1LA%40mail.gmail.com</a>=
..<br />

--001a114263acc0ca5b053184e3e5--

.

------=_Part_6238_147938797.1461869324789
Content-Type: multipart/alternative;
 boundary="----=_Part_6239_456387032.1461869324789"

------=_Part_6239_456387032.1461869324789
Content-Type: text/plain; charset=UTF-8

On Thursday, April 28, 2016 at 1:35:11 AM UTC-4, Ricardo Andrade wrote:
>
> Let me summarize the whole point of starting this discussion...
> - We cannot prevent people from circumventing encapsulation.
>

It depends on what you mean by that. As a practical matter on real
implementations, you are correct.

As a matter of standard-sanctioned behavior, we very much can.

Something can be illegal, yet people will still do it. That fact alone does
not mean the law should be changed to permit it.

- Reflection is likely to add yet another way to do it.
>

Quite likely.

- This will be the first "standard" way for this purpose.
>

Yes.

- It has the benefit of being easy to spot in the code (currently as
> get_all_data_members in P0194R0).
>

Kinda. Yes, you can spot that someone is calling `get_all_data_members`,
but knowing exactly which objects this is being employed upon will be much
more difficult. Especially in a deeply-nested template function.

- But there's a chance it will be costly in terms of compile time and
> complexity.
>

.... I suppose that's possible. I mean, I don't know of a way to iterate
through the unknown privates of a type at compile time that *wouldn't*
involve template metaprogramming. But it's possible you could craft such a
mechanism, and therefore it would be faster at compile time than reflection.

- People may end up not using it and sticking with the old "non-standard"
> ways
>

That's a good thing. We do not want people to use reflection for the
specific purpose of violating access controls.

- In the other hand, if people do use it, reflection gets the bad
> reputation of being "the corner of the language reserved for evil" - as it
> does in the other languages.
>

Wait, what? How does that logically follow? You just claimed that people
won't use reflection to violate access controls because it's slow. If
that's true, why would it gain this bad reputation you speak of?

So either this statement or the one before it is false. Or both. But they
can't both be true.

Oh, and do you have any basis for the claim that reflection in other
languages is seen as "the corner of the language reserved for evil"? I was
under the impression that reflection in C# was used fairly heavily by XAML,
for example. I did a quick search for "C# reflection evil", and the most I
got were warnings about the *performance* of reflecting, not the concept
itself.

So it seems that in other languages, there is not such a rash of people
using reflection to violate encapsulation that people consider reflection a
priori perfidious.


> - Now that you mentioned accidents, get_all_data_members vs.
> get_data_members don't contribute much to prevent those, but there's still
> time to work that out - I'll mentioned that to the author of P0194R0.
>
> That said, comes the question:
> Wouldn't be better to provide a "reinterpret_cast"-like mechanism (or
> anything else) just for this purpose?
>

No. We don't want to regularize bad behavior. And violating encapsulation
is *always* bad behavior.

FYI: `reinterpret_cast` is not regularizing bad behavior; it's simply a
tool that can be easily abused.

- Reflection would be the "mechanism to list declarations and infer their
> characteristics", the way to use them that's up to you.
>

That's not what reflection is. Reflection also allows you to call methods,
access data members, and so forth. And in any case, if reflection allows
violation of access controls, it must still do so even with whatever other
method you want to add.

- It would be easy and obvious to find such violations in the code. Then
> violators can be caught.
>

Only if they are used consistently.

- If a proposed solution has equivalent performance of the hacky
> alternatives but it states clearly the intentions, people will prefer to
> use it (or they would be so ashamed of having such ideas and avoid it).
>

Only if they are writing new code. Old code isn't automatically going to be
changed.

- A dedicated language solution is more likely to find a better balance for
> safety, freedom and clarity than something buried deep down in reflection.
>

Reflection does not allow private access because it is attempting to
improve "freedom" or "clarity" or whatever. It's doing it because
reflection needs to in order to be a proper tool.

Also, your statement presupposes that the current "balance" is problematic.
It isn't. Just because some people break laws doesn't make those laws wrong.

I bet there are several ideas that could work out but first we need to go
> over this feeling that people will use whatever is proposed everyday and
> break everything.
>

Sanctioning the violation of encapsulation is, and of a right ought to be,
a hard sell.

Encapsulation should be a binary concept. Either it is accessible without
perfidy or it is not. Saying that it isn't accessible unless you do this
slightly inconvenient thing means that it is *accessible*. And therefore
not encapsulated.


> People stay away from "reinterpret_cast" already
>

That's because they use C-style casts.


> because is too 'dark' and bet people would think twice before using
> something called "violate_access_cast".
>
> That's it.
>
> On Wed, Apr 27, 2016 at 4:13 PM, Peter Koch Larsen <peter.ko...@gmail.com
> <javascript:>> wrote:
>
>> I do not understand all this fuzz about subversion of access rights.
>> Let us face it:
>> *) The purpose of access privileges is to protect the programmer from
>> doing something stupid, such as using an
>>     object in a way it way not designed to be used. It has never been
>> the purpose of access privileges to e.g. protect
>>     a system from an intruder or something in that direction.
>> *) There are already ways in C++ to get access to the private parts of
>> an object. Having one more way to do so is not
>>    a problem.
>>
>
Neither of those is a justification for doing what you suggest.


> That being said, I believe that getting the access should be
>> difficult: it should be blatantly clear that you are doing
>> something dangerous - just as it is with e.g. reinterpret_cast.
>
>
`reinterpret_cast` is not "difficult".

Also,
>> I fail to see the advantage of having this access.
>> I am in the camp that believes that e.g. serialization is perfectly
>> feasible without knowledge of the inner details about
>> how such a class is defined.
>>
>
So... what you're telling me is that you want to write crappy, fragile
code. You want to violate standard rules about data hiding based on a
premise that has been *proven faulty* (all it takes is one counter-example
and I provided it). Also, even if we allowed you private access, you still
couldn't properly construct such objects, because the only way to start the
lifetime of an object in a piece of memory is to use placement `new`. Which
must call a constructor. So your prospective unintrusive serialization
library still has to use extra-standard methods (an illegal cast to `T*` or
`T&` at some point).

You are basically proving exactly why we *shouldn't* let you do what you
want. Because if you give people a standard-sanctioned tool for breaking
encapsulation, people like you will *misuse it*. Since you have clearly and
unequivocally stated your intent to do so.

Really, the only thing you've convinced me of is that reflection should
have *additional* controls, for the sole purpose of preventing people like
you from writing the library you want to write. That there should be some
mechanism to prevent `get_all_data_members` and its ilk from working unless
you are in code that has private access already. Perhaps the MetaObject
type generated for reflection purposes should have Public, Protected, and
Private versions. If you're in code with private access to the class and
you get a MetaObject for it, then you get the Private MetaObject type.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/4a4c2fe7-397e-4ca0-bdbe-04e77f075cee%40isocpp.org.

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

<div dir=3D"ltr">On Thursday, April 28, 2016 at 1:35:11 AM UTC-4, Ricardo A=
ndrade wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
Let me summarize the whole point of starting this discussion...<div>- We ca=
nnot prevent people from circumventing encapsulation.</div></div></blockquo=
te><div><br>It depends on what you mean by that. As a practical matter on r=
eal implementations, you are correct.<br><br>As a matter of standard-sancti=
oned behavior, we very much can.<br><br>Something can be illegal, yet peopl=
e will still do it. That fact alone does not mean the law should be changed=
 to permit it.<br><br></div><blockquote class=3D"gmail_quote" style=3D"marg=
in: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><d=
iv dir=3D"ltr"><div>- Reflection is likely to add yet another way to do it.=
</div></div></blockquote><div><br>Quite likely.<br><br></div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px =
#ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>- This will be the fir=
st &quot;standard&quot; way for this purpose.</div></div></blockquote><div>=
<br>Yes.<br><br></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>- It has the benefit of being easy to spot in the code (curre=
ntly as get_all_data_members in P0194R0).</div></div></blockquote><div><br>=
Kinda. Yes, you can spot that someone is calling `get_all_data_members`, bu=
t knowing exactly which objects this is being employed upon will be much mo=
re difficult. Especially in a deeply-nested template function.<br><br></div=
><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"><div>- But t=
here&#39;s a chance it will be costly in terms of compile time and complexi=
ty.</div></div></blockquote><div><br>... I suppose that&#39;s possible. I m=
ean, I don&#39;t know of a way to iterate through the unknown privates of a=
 type at compile time that <i>wouldn&#39;t</i> involve template metaprogram=
ming. But it&#39;s possible you could craft such a mechanism, and therefore=
 it would be faster at compile time than reflection.<br><br></div><blockquo=
te 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>- People may end =
up not using it and sticking with the old &quot;non-standard&quot; ways</di=
v></div></blockquote><div><br>That&#39;s a good thing. We do not want peopl=
e to use reflection for the specific purpose of violating access controls.<=
br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
<div>- In the other hand, if people do use it, reflection gets the bad repu=
tation of being &quot;the corner of the language reserved for evil&quot; - =
as it does in the other languages.</div></div></blockquote><div><br>Wait, w=
hat? How does that logically follow? You just claimed that people won&#39;t=
 use reflection to violate access controls because it&#39;s slow. If that&#=
39;s true, why would it gain this bad reputation you speak of?<br><br>So ei=
ther this statement or the one before it is false. Or both. But they can&#3=
9;t both be true.<br></div><div><br>Oh, and do you have any basis for the c=
laim that reflection in other languages is seen as &quot;the corner of the =
language reserved for evil&quot;? I was under the impression that reflectio=
n in C# was used fairly heavily by XAML, for example. I did a quick search =
for &quot;C# reflection evil&quot;, and the most I got were warnings about =
the <i>performance</i> of reflecting, not the concept itself.<br><br>So it =
seems that in other languages, there is not such a rash of people using ref=
lection to violate encapsulation that people consider reflection a priori p=
erfidious.<br>=C2=A0</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>- Now that you mentioned accidents, get_all_data_members =
vs. get_data_members don&#39;t contribute much to prevent those, but there&=
#39;s still time to work that out - I&#39;ll mentioned that to the author o=
f P0194R0.</div><div><br></div><div>That said, comes the question:</div><di=
v>Wouldn&#39;t be better to provide a &quot;reinterpret_cast&quot;-like mec=
hanism (or anything else) just for this purpose?</div></div></blockquote><d=
iv><br>No. We don&#39;t want to regularize bad behavior. And violating enca=
psulation is <i>always</i> bad behavior.<br><br>FYI: `reinterpret_cast` is =
not regularizing bad behavior; it&#39;s simply a tool that can be easily ab=
used.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D=
"ltr"><div></div><div>- Reflection would be the &quot;mechanism to list dec=
larations and infer their characteristics&quot;, the way to use them that&#=
39;s up to you.</div></div></blockquote><div><br>That&#39;s not what reflec=
tion is. Reflection also allows you to call methods, access data members, a=
nd so forth. And in any case, if reflection allows violation of access cont=
rols, it must still do so even with whatever other method you want to add.<=
br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
<div>- It would be easy and obvious to find such violations in the code. Th=
en violators can be caught.</div></div></blockquote><div><br>Only if they a=
re used consistently.<br><br></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>- If a proposed solution has equivalent perform=
ance of the hacky alternatives but it states clearly the intentions, people=
 will prefer to use it (or they would be so ashamed of having such ideas an=
d avoid it).</div></div></blockquote><div><br>Only if they are writing new =
code. Old code isn&#39;t automatically going to be changed.<br><br></div><b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>- A dedica=
ted language solution is more likely to find a better balance for safety, f=
reedom and clarity than something buried deep down in reflection.</div></di=
v></blockquote><div><br>Reflection does not allow private access because it=
 is attempting to improve &quot;freedom&quot; or &quot;clarity&quot; or wha=
tever. It&#39;s doing it because reflection needs to in order to be a prope=
r tool.<br><br>Also, your statement presupposes that the current &quot;bala=
nce&quot; is problematic. It isn&#39;t. Just because some people break laws=
 doesn&#39;t make those laws wrong.<br><br></div><blockquote class=3D"gmail=
_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;p=
adding-left: 1ex;"><div dir=3D"ltr"><div></div><div>I bet there are several=
 ideas that could work out but first we need to go over this feeling that p=
eople will use whatever is proposed everyday and break everything.</div></d=
iv></blockquote><div><br>Sanctioning the violation of encapsulation is, and=
 of a right ought to be, a hard sell.<br><br>Encapsulation should be a bina=
ry concept. Either it is accessible without perfidy or it is not. Saying th=
at it isn&#39;t accessible unless you do this slightly inconvenient thing m=
eans that it is <i>accessible</i>. And therefore not encapsulated.<br>=C2=
=A0</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=
>People stay away from &quot;reinterpret_cast&quot; already</div></div></bl=
ockquote><div><br>That&#39;s because they use C-style casts.<br>=C2=A0</div=
><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"><div> becaus=
e is too &#39;dark&#39; and bet people would think twice before using somet=
hing called &quot;violate_access_cast&quot;.</div><div><br></div><div>That&=
#39;s it.<br></div><div><div><br><div class=3D"gmail_quote">On Wed, Apr 27,=
 2016 at 4:13 PM, Peter Koch Larsen <span dir=3D"ltr">&lt;<a href=3D"javasc=
ript:" target=3D"_blank" gdf-obfuscated-mailto=3D"pUbkQ_icCAAJ" rel=3D"nofo=
llow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclic=
k=3D"this.href=3D&#39;javascript:&#39;;return true;">peter.ko...@gmail.com<=
/a>&gt;</span> wrote:<br><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">I do not understand all this fuzz=
 about subversion of access rights.<br>
Let us face it:<br>
*) The purpose of access privileges is to protect the programmer from<br>
doing something stupid, such as using an<br>
=C2=A0 =C2=A0 object in a way it way not designed to be used. It has never =
been<br>
the purpose of access privileges to e.g. protect<br>
=C2=A0 =C2=A0 a system from an intruder or something in that direction.<br>
*) There are already ways in C++ to get access to the private parts of<br>
an object. Having one more way to do so is not<br>
=C2=A0 =C2=A0a problem.<br></blockquote></div></div></div></div></blockquot=
e><div><br>Neither of those is a justification for doing what you suggest.<=
br>=C2=A0</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><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" st=
yle=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">
That being said, I believe that getting the access should be<br>
difficult: it should be blatantly clear that you are doing<br>
something dangerous - just as it is with e.g. reinterpret_cast.</blockquote=
></div></div></div></div></blockquote><div><br>`reinterpret_cast` is not &q=
uot;difficult&quot;.<br><br></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><div class=3D"gmail_quote"><blockquote cla=
ss=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=
"> Also,<br>
I fail to see the advantage of having this access.<br>
I am in the camp that believes that e.g. serialization is perfectly<br>
feasible without knowledge of the inner details about<br>
how such a class is defined.<br></blockquote></div></div></div></div></bloc=
kquote><div><br>So... what you&#39;re telling me is that you want to write =
crappy, fragile code. You want to violate standard rules about data hiding =
based on a premise that has been <i>proven faulty</i> (all it takes is one =
counter-example and I provided it). Also, even if we allowed you private ac=
cess, you still couldn&#39;t properly construct such objects, because the o=
nly way to start the lifetime of an object in a piece of memory is to use p=
lacement `new`. Which must call a constructor. So your prospective unintrus=
ive serialization library still has to use extra-standard methods (an illeg=
al cast to `T*` or `T&amp;` at some point).<br><br>You are basically provin=
g exactly why we <i>shouldn&#39;t</i> let you do what you want. Because if =
you give people a standard-sanctioned tool for breaking encapsulation, peop=
le like you will <i>misuse it</i>. Since you have clearly and unequivocally=
 stated your intent to do so.<br><br>Really, the only thing you&#39;ve conv=
inced me of is that reflection should have <i>additional</i> controls, for =
the sole purpose of preventing people like you from writing the library you=
 want to write. That there should be some mechanism to prevent `get_all_dat=
a_members` and its ilk from working unless you are in code that has private=
 access already. Perhaps the MetaObject type generated for reflection purpo=
ses should have Public, Protected, and Private versions. If you&#39;re in c=
ode with private access to the class and you get a MetaObject for it, then =
you get the Private MetaObject type.<br></div></div>

<p></p>

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

------=_Part_6239_456387032.1461869324789--
------=_Part_6238_147938797.1461869324789--

.

------=_Part_88_1007297698.1461997879268
Content-Type: multipart/alternative;
 boundary="----=_Part_89_931050265.1461997879269"

------=_Part_89_931050265.1461997879269
Content-Type: text/plain; charset=UTF-8

Nicol, I honestly, I don't aim to change your mind, which seems pretty much
set to be against it, but I hope others are reading this and forming their
own opinions.
Since there's no particular interest in a proposal here I focus my efforts
in helping on the reflection proposal.
Below my parting words for this post.

On Thursday, April 28, 2016 at 1:48:45 PM UTC-5, Nicol Bolas wrote:
>
> On Thursday, April 28, 2016 at 1:35:11 AM UTC-4, Ricardo Andrade wrote:
>>
>> Let me summarize the whole point of starting this discussion...
>> - We cannot prevent people from circumventing encapsulation.
>>
>
> It depends on what you mean by that. As a practical matter on real
> implementations, you are correct.
>
> As a matter of standard-sanctioned behavior, we very much can.
>
> Something can be illegal, yet people will still do it. That fact alone
> does not mean the law should be changed to permit it.
>
>
But the gray area of our C++ laws (the standard) already makes it legal but
not obvious.


> - Reflection is likely to add yet another way to do it.
>>
>
> Quite likely.
>
> - This will be the first "standard" way for this purpose.
>>
>
> Yes.
>

Let me correct myself: reflection will provide the first "obvious" way to
do it according to the standard.


>
> - It has the benefit of being easy to spot in the code (currently as
>> get_all_data_members in P0194R0).
>>
>
> Kinda. Yes, you can spot that someone is calling `get_all_data_members`,
> but knowing exactly which objects this is being employed upon will be much
> more difficult. Especially in a deeply-nested template function.
>
>
Correct. That's why I wanted something that clearly states the intention to
circumvent the access rights.
Then there will be two distinct steps: `get_all_data_members` and what you
do them.


> - But there's a chance it will be costly in terms of compile time and
>> complexity.
>>
>
> ... I suppose that's possible. I mean, I don't know of a way to iterate
> through the unknown privates of a type at compile time that *wouldn't*
> involve template metaprogramming.
>

Me neither. Which brings another point, I may not want to iterate over
anything. In this situation, reflection just add extra steps, making it
hard to spot. People will use other ways.
But I agree there's virtually no reason to violate encapsulation outside of
the context of reflection unless you desperately have to.


> But it's possible you could craft such a mechanism, and therefore it would
> be faster at compile time than reflection.
>
>
But it would not be standard or if it was, possibly not obvious.


> - People may end up not using it and sticking with the old "non-standard"
>> ways
>>
>
> That's a good thing. We do not want people to use reflection for the
> specific purpose of violating access controls.
>
>
Me neither. I'd rather have something *intentionally designed* for this
purpose.


> - In the other hand, if people do use it, reflection gets the bad
>> reputation of being "the corner of the language reserved for evil" - as it
>> does in the other languages.
>>
>
> Wait, what? How does that logically follow? You just claimed that people
> won't use reflection to violate access controls because it's slow. If
> that's true, why would it gain this bad reputation you speak of?
>
>
Because if you want do to it the obvious, standard way, reflection will be
your only choice.
If someone really decides to do it, for whatever (really bad) reason, s/he
has to decide between ugly/fast (hack/template) or readable/slow
(reflection).


> So either this statement or the one before it is false. Or both. But they
> can't both be true.
>
>
If there's a decision to be made, if each solution has a different balance,
some will go one way, some will go the other way and in this case both will
be true.
How much people will go to each side? Well, we're discussion violating
encapsulation, they should go neither way. Good luck figuring out they way
they went...
I would rather having one clear choice.


> Oh, and do you have any basis for the claim that reflection in other
> languages is seen as "the corner of the language reserved for evil"?
>

If reflection in C++ will be the only place where certain dangerous
constructions are possible even though they look innocent, that will be a
fact.


> I was under the impression that reflection in C# was used fairly heavily
> by XAML, for example.
>

Correct. Along so many other things.


> I did a quick search for "C# reflection evil", and the most I got were
> warnings about the *performance* of reflecting, not the concept itself.
>
>
You're right, the concept of reflection is a wonderful thing. Enables
really powerful stuff along with a good dose of DRY.

But mix reflection with C#'s `unsafe` and then you may get a better picture
how much evil can be done. That will be C++ reflection.
Can we prevent people from abusing this? Certainly not 100%, that's why at
least we could know where/when the abuses are happening.


> So it seems that in other languages, there is not such a rash of people
> using reflection to violate encapsulation that people consider reflection a
> priori perfidious.
>
>

You're right, reflection is not perceived as bad thing by itself and it has
many uses.

But those languages and their object oriented mindset force the action of
violating encapsulation to be in reflection in part because it does not fit
any other object or package.
What has been done with reflection in other languages seems to be one
reason behind the design of C++ reflection. In the other hand, C++ has
never impose such OOP design restrictions, on the contrary.


> - Now that you mentioned accidents, get_all_data_members vs.
>> get_data_members don't contribute much to prevent those, but there's still
>> time to work that out - I'll mentioned that to the author of P0194R0.
>>
>> That said, comes the question:
>> Wouldn't be better to provide a "reinterpret_cast"-like mechanism (or
>> anything else) just for this purpose?
>>
>
> No. We don't want to regularize bad behavior. And violating encapsulation
> is *always* bad behavior.
>
>
Is friend bad behavior?
Then you say: oh, but the author of the class has designed the friendship
to improve encapsulation!
Then I say: you cannot predict all uses of your class in the wild, it may
be missing a friend. I need to be friend of your class.
Then you say: you don't know how my class works, don't touch its guts.
Then I say: for *very practical* reasons (time constraints, performance
legacy code, compatibility whatever), I'll have to and I want to assume all
the risks. I did my homework, there's no other way.
Then you say: good luck. This is code is fragile. You should not be doing
this.
Then I say: I well aware of. Thanks.

Now is the point where the design of the language begins to make a
difference:
- Does the language prevent me from doing such thing? Too bad, next time
will think twice before using it.
- Does the solution offered not a part of the language standard? Well,
better employed than being a language lawyer. Block of comments, good luck
finding them.
- Does the solution offered part of the language but tricky? Better be the
language lawyer that knows it! Huge block of comments...
- Does the language offer a way but it imposes a penalty (such as using
reflection+metaprogramming)? If I can't pay the cost I'll find another way.
Too bad, non-standard. Block of comments...
- Does the language offer reasonable a way but it makes so obvious I'm
doing something which I shouldn't at the point of making me think twice?
Shame on me for using that, no comments needed.
At this point, if I decide to cover my tracks with a hack, then I'm asking
for trouble.


> FYI: `reinterpret_cast` is not regularizing bad behavior; it's simply a
> tool that can be easily abused.
>
>
I'm just asking for another tool as powerful as this for violating
encapsulation, but please don't make it so easy to abuse.
Instead, make me think twice. Naming is a powerful thing.


> - Reflection would be the "mechanism to list declarations and infer their
>> characteristics", the way to use them that's up to you.
>>
>
> That's not what reflection is. Reflection also allows you to call methods,
> access data members, and so forth. And in any case, if reflection allows
> violation of access controls, it must still do so even with whatever other
> method you want to add.
>
>
The language allows you to call methods and access data members. Reflection
is the mechanism to find which is the right method/member to use indirectly.


> - It would be easy and obvious to find such violations in the code. Then
>> violators can be caught.
>>
>
> Only if they are used consistently.
>

Finding the right way to offer the functionality contributes greatly for
the consistency.


>
> - If a proposed solution has equivalent performance of the hacky
>> alternatives but it states clearly the intentions, people will prefer to
>> use it (or they would be so ashamed of having such ideas and avoid it).
>>
>
> Only if they are writing new code. Old code isn't automatically going to
> be changed.
>

Reflection -the major use case for violating encapsulation- will be only
available in the new code.
But some refactoring to adopt standard solutions is always welcome.


> - A dedicated language solution is more likely to find a better balance
>> for safety, freedom and clarity than something buried deep down in
>> reflection.
>>
>
> Reflection does not allow private access because it is attempting to
> improve "freedom" or "clarity" or whatever. It's doing it because
> reflection needs to in order to be a proper tool.
>

Correct. Reflection has its use cases for it. I want the language to be a
better tool for violating access rights when *utterly necessary* with or
without reflection.


>
> Also, your statement presupposes that the current "balance" is
> problematic. It isn't. Just because some people break laws doesn't make
> those laws wrong.
>
>
I hope you never happen to have the language laws working against you.


> I bet there are several ideas that could work out but first we need to go
>> over this feeling that people will use whatever is proposed everyday and
>> break everything.
>>
>
> Sanctioning the violation of encapsulation is, and of a right ought to be,
> a hard sell.
>
>
I never thought it would be easy to convince people to go with this idea of
a separate language construction for unrestricted class member access.
And even if all this don't convince anyone, there's enough information here
to decide how to better implement it in reflection.


> Encapsulation should be a binary concept. Either it is accessible without
> perfidy or it is not. Saying that it isn't accessible unless you do this
> slightly inconvenient thing means that it is *accessible*. And therefore
> not encapsulated.
>
>

Isn't that already the case?
People against the concept of friend tell kind of the same thing.


> People stay away from "reinterpret_cast" already
>>
>
> That's because they use C-style casts.
>
>

I meant, people think twice before suggesting reinterpret_cast as a
solution to a problem. Even if it's the only one.
It's such a situation where one say: "what others will think of me if I
tell them 'use reinterpret_cast'?"


> because is too 'dark' and bet people would think twice before using
>> something called "violate_access_cast".
>>
>> That's it.
>>
>> On Wed, Apr 27, 2016 at 4:13 PM, Peter Koch Larsen <peter.ko...@gmail.com
>> > wrote:
>>
>>> I do not understand all this fuzz about subversion of access rights.
>>> Let us face it:
>>> *) The purpose of access privileges is to protect the programmer from
>>> doing something stupid, such as using an
>>>     object in a way it way not designed to be used. It has never been
>>> the purpose of access privileges to e.g. protect
>>>     a system from an intruder or something in that direction.
>>> *) There are already ways in C++ to get access to the private parts of
>>> an object. Having one more way to do so is not
>>>    a problem.
>>>
>>
> Neither of those is a justification for doing what you suggest.
>

Correct. The justification is: it will be done, in this case I want people
to always to the same way, I want to know when/where they have done,
preferably I wouldn't make reflection responsible for it.

>
>
>> That being said, I believe that getting the access should be
>>> difficult: it should be blatantly clear that you are doing
>>> something dangerous - just as it is with e.g. reinterpret_cast.
>>
>>
> `reinterpret_cast` is not "difficult".
>

Certainly it's not on the C++ 101 class. Neither would be anything that
violates encapsulation.
Which is another reason for nothing having it in reflection, because some
of reflection should be in this 101 class.

Also,
>>> I fail to see the advantage of having this access.
>>> I am in the camp that believes that e.g. serialization is perfectly
>>> feasible without knowledge of the inner details about
>>> how such a class is defined.
>>>
>>
> So... what you're telling me is that you want to write crappy, fragile
> code.
>

Crappy, definitely. No decent software professional should be satisfied
with him/herself after *having to* write code that goes against a principle
of the software engineering.
Fragile? Debatable. There's a lot of crappy code (in general, simply
because there's no other way) very well tested and beautifully
encapsulated, so no one don't have to be worried about the dirty tricks
used internally. Boost has a few examples...


> You want to violate standard rules about data hiding based on a premise
> that has been *proven faulty* (all it takes is one counter-example and I
> provided it).
>

Correct. I would rather know that something probably bad has been done than
sweeping it under the rug.


> Also, even if we allowed you private access, you still couldn't properly
> construct such objects, because the only way to start the lifetime of an
> object in a piece of memory is to use placement `new`. Which must call a
> constructor. So your prospective unintrusive serialization library still
> has to use extra-standard methods (an illegal cast to `T*` or `T&` at some
> point).
>
>
I'm lost. What prevents reflection from giving me the signature type of the
constructors from which I could create a factory functions (i.e. make_...)
which in turn call new and return an instance of the right type?
I don't see a need for casts and magic here... unless the constructor is
private/protected.


> You are basically proving exactly why we *shouldn't* let you do what you
> want. Because if you give people a standard-sanctioned tool for breaking
> encapsulation, people like you will *misuse it*. Since you have clearly
> and unequivocally stated your intent to do so.
>
>
I don't want to use it, I won't recommend it. Actually, I personally gain
nothing discussing this subject here. I may be losing though.
But if I'm forced to use such thing, I hope 1) the language don't get in my
way 2) the language help me state my (bad) intentions clearly, so whoever
maintains the code can understand it and if possible remove the hack ASAP.

Really, the only thing you've convinced me of is that reflection should
> have *additional* controls, for the sole purpose of preventing people
> like you from writing the library you want to write. That there should be
> some mechanism to prevent `get_all_data_members` and its ilk from working
> unless you are in code that has private access already. Perhaps the
> MetaObject type generated for reflection purposes should have Public,
> Protected, and Private versions. If you're in code with private access to
> the class and you get a MetaObject for it, then you get the Private
> MetaObject type.
>

That limits the applicability of reflection, but if you convince people
that nothing, not even reflection, should have unrestricted access to class
members, then yes, there's no point to offer a standard mechanism for
violating encapsulation.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/c4f04705-f290-495a-a053-4d55dec32ccd%40isocpp.org.

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

<div dir=3D"ltr">Nicol, I honestly, I don&#39;t aim to change your mind, wh=
ich seems pretty much set to be against it, but I hope others are reading t=
his and forming their own opinions.<div>Since there&#39;s no particular int=
erest in a proposal here I focus my efforts in helping on the reflection pr=
oposal.</div><div>Below my parting words for this post.<br><div><br>On Thur=
sday, April 28, 2016 at 1:48:45 PM UTC-5, Nicol Bolas 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">On Thursday, April 28, 2016 =
at 1:35:11 AM UTC-4, Ricardo Andrade 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">Let me summarize the whole point of starting this =
discussion...<div>- We cannot prevent people from circumventing encapsulati=
on.</div></div></blockquote><div><br>It depends on what you mean by that. A=
s a practical matter on real implementations, you are correct.<br><br>As a =
matter of standard-sanctioned behavior, we very much can.<br><br>Something =
can be illegal, yet people will still do it. That fact alone does not mean =
the law should be changed to permit it.<br><br></div></div></blockquote><di=
v><br></div><div>But the gray area of our C++ laws (the standard) already m=
akes it legal but not obvious.</div><div>=C2=A0<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div dir=3D"ltr"><div></div><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"><div>- Reflection is likely to add =
yet another way to do it.</div></div></blockquote><div><br>Quite likely.<br=
><br></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>- =
This will be the first &quot;standard&quot; way for this purpose.</div></di=
v></blockquote><div><br>Yes.<br></div></div></blockquote><div><br></div><di=
v>Let me correct myself: reflection will provide the first &quot;obvious&qu=
ot; way to do it according to the standard.</div><div>=C2=A0</div><blockquo=
te 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></div><blockq=
uote 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>- It has the benefit=
 of being easy to spot in the code (currently as get_all_data_members in P0=
194R0).</div></div></blockquote><div><br>Kinda. Yes, you can spot that some=
one is calling `get_all_data_members`, but knowing exactly which objects th=
is is being employed upon will be much more difficult. Especially in a deep=
ly-nested template function.<br><br></div></div></blockquote><div><br></div=
><div>Correct. That&#39;s why I wanted something that clearly states the in=
tention to circumvent the access rights.</div><div>Then there will be two d=
istinct steps: `get_all_data_members` and what you do them.</div><div>=C2=
=A0</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><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8e=
x;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>- But =
there&#39;s a chance it will be costly in terms of compile time and complex=
ity.</div></div></blockquote><div><br>... I suppose that&#39;s possible. I =
mean, I don&#39;t know of a way to iterate through the unknown privates of =
a type at compile time that <i>wouldn&#39;t</i> involve template metaprogra=
mming. </div></div></blockquote><div><br></div><div>Me neither. Which bring=
s another point, I may not want to iterate over anything. In this situation=
, reflection just add extra steps, making it hard to spot. People will use =
other ways.</div><div>But I agree there&#39;s virtually no reason to violat=
e encapsulation outside of the context of reflection unless you desperately=
 have to.</div><div>=C2=A0</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>But it&#39;s possible you could craft such a mechan=
ism, and therefore it would be faster at compile time than reflection.<br><=
br></div></div></blockquote><div><br></div><div>But it would not be standar=
d or if it was, possibly not obvious.</div><div>=C2=A0</div><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"><div></div><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"><div>- People may end up not using =
it and sticking with the old &quot;non-standard&quot; ways</div></div></blo=
ckquote><div><br>That&#39;s a good thing. We do not want people to use refl=
ection for the specific purpose of violating access controls.<br><br></div>=
</div></blockquote><div><br></div><div>Me neither. I&#39;d rather have some=
thing <i>intentionally designed</i>=C2=A0for this purpose.</div><div>=C2=A0=
</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div></=
div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>- In the =
other hand, if people do use it, reflection gets the bad reputation of bein=
g &quot;the corner of the language reserved for evil&quot; - as it does in =
the other languages.</div></div></blockquote><div><br>Wait, what? How does =
that logically follow? You just claimed that people won&#39;t use reflectio=
n to violate access controls because it&#39;s slow. If that&#39;s true, why=
 would it gain this bad reputation you speak of?<br><br></div></div></block=
quote><div><br></div><div>Because if you want do to it the obvious, standar=
d way, reflection will be your only choice.</div><div>If someone really dec=
ides to do it, for whatever (really bad) reason, s/he has to decide between=
 ugly/fast (hack/template) or readable/slow (reflection).</div><div>=C2=A0<=
/div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>So =
either this statement or the one before it is false. Or both. But they can&=
#39;t both be true.<br></div><div><br></div></div></blockquote><div><br></d=
iv><div>If there&#39;s a decision to be made, if each solution has a differ=
ent balance, some will go one way, some will go the other way and in this c=
ase both will be true.</div><div>How much people will go to each side? Well=
, we&#39;re discussion violating encapsulation, they should go neither way.=
 Good luck figuring out they way they went...</div><div>I would rather havi=
ng one clear choice.</div><div>=C2=A0<br></div><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"><div>Oh, and do you have any basis for th=
e claim that reflection in other languages is seen as &quot;the corner of t=
he language reserved for evil&quot;?</div></div></blockquote><div><br></div=
><div>If reflection in C++ will be the only place where certain dangerous c=
onstructions are possible even though they look innocent, that will be a fa=
ct.</div><div>=C2=A0</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>I was under the impression that reflection in C# was used=
 fairly heavily by XAML, for example.</div></div></blockquote><div><br></di=
v><div>Correct. Along so many other things.</div><div>=C2=A0</div><blockquo=
te 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 a quick se=
arch for &quot;C# reflection evil&quot;, and the most I got were warnings a=
bout the <i>performance</i> of reflecting, not the concept itself.<br><br><=
/div></div></blockquote><div><br></div><div>You&#39;re right, the concept o=
f reflection is a wonderful thing. Enables really powerful stuff along with=
 a good dose of DRY.</div><div><br></div><div>But mix reflection with C#&#3=
9;s `unsafe` and then you may get a better picture how much evil can be don=
e. That will be C++ reflection.</div><div>Can we prevent people from abusin=
g this? Certainly not 100%, that&#39;s why at least we could know where/whe=
n the abuses are happening.</div><div>=C2=A0</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>So it seems that in other languag=
es, there is not such a rash of people using reflection to violate encapsul=
ation that people consider reflection a priori perfidious.<br>=C2=A0</div><=
/div></blockquote><div><br></div><div>You&#39;re right, reflection is not p=
erceived as bad thing by itself and it has many uses.</div><div><br></div><=
div>But those languages and their object oriented mindset force the action =
of violating encapsulation to be in reflection in part because it does not =
fit any other object or package.</div><div>What has been done with reflecti=
on in other languages seems to be one reason behind the design of C++ refle=
ction. In the other hand, C++ has never impose such OOP design restrictions=
, on the contrary.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" =
style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-l=
eft: 1ex;"><div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"marg=
in:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div di=
r=3D"ltr"><div>- Now that you mentioned accidents, get_all_data_members vs.=
 get_data_members don&#39;t contribute much to prevent those, but there&#39=
;s still time to work that out - I&#39;ll mentioned that to the author of P=
0194R0.</div><div><br></div><div>That said, comes the question:</div><div>W=
ouldn&#39;t be better to provide a &quot;reinterpret_cast&quot;-like mechan=
ism (or anything else) just for this purpose?</div></div></blockquote><div>=
<br>No. We don&#39;t want to regularize bad behavior. And violating encapsu=
lation is <i>always</i> bad behavior.<br><br></div></div></blockquote><div>=
=C2=A0</div><div>Is friend bad behavior?</div><div>Then you say: oh, but th=
e author of the class has designed the friendship to improve encapsulation!=
</div><div>Then I say: you cannot predict all uses of your class in the wil=
d, it may be missing a friend. I need to be friend of your class.</div><div=
>Then you say: you don&#39;t know how my class works, don&#39;t touch its g=
uts.</div><div>Then I say: for <i>very practical</i> reasons (time constrai=
nts, performance legacy code, compatibility whatever), I&#39;ll have to and=
 I want to assume all the risks. I did my homework, there&#39;s no other wa=
y.</div><div>Then you say: good luck. This is code is fragile. You should n=
ot be doing this.</div><div>Then I say: I well aware of. Thanks.</div><div>=
<br>Now is the point where the design of the language begins to make a diff=
erence:</div><div>- Does the language prevent me from doing such thing? Too=
 bad, next time will think twice before using it.</div><div>-=C2=A0Does=C2=
=A0the solution offered not a part of the language standard? Well, better e=
mployed than being a language lawyer. Block of comments, good luck finding =
them.</div><div>-=C2=A0Does=C2=A0the solution offered part of the language =
but tricky? Better be the language lawyer that knows it! Huge block of comm=
ents...</div><div>-=C2=A0Does=C2=A0the language offer a way but it imposes =
a penalty (such as using reflection+metaprogramming)? If I can&#39;t pay th=
e cost I&#39;ll find another way. Too bad, non-standard. Block of comments.=
...</div><div>-=C2=A0Does=C2=A0the language offer reasonable a way but it ma=
kes so obvious I&#39;m doing something which I shouldn&#39;t at the point o=
f making me think twice? Shame on me for using that, no comments needed.</d=
iv><div>At this point, if I decide to cover my tracks with a hack, then I&#=
39;m asking for trouble.</div><div>=C2=A0</div><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"><div>FYI: `reinterpret_cast` is not regul=
arizing bad behavior; it&#39;s simply a tool that can be easily abused.<br>=
<br></div></div></blockquote><div><br></div><div>I&#39;m just asking for an=
other tool as powerful as this for violating encapsulation, but please don&=
#39;t make it so easy to abuse.</div><div>Instead, make me think twice. Nam=
ing is a powerful thing.</div><div>=C2=A0</div><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"><div></div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-=
left:1ex"><div dir=3D"ltr"><div></div><div>- Reflection would be the &quot;=
mechanism to list declarations and infer their characteristics&quot;, the w=
ay to use them that&#39;s up to you.</div></div></blockquote><div><br>That&=
#39;s not what reflection is. Reflection also allows you to call methods, a=
ccess data members, and so forth. And in any case, if reflection allows vio=
lation of access controls, it must still do so even with whatever other met=
hod you want to add.<br><br></div></div></blockquote><div><br></div><div>Th=
e language allows you to call methods and access data members. Reflection i=
s the mechanism to find which is the right method/member to use indirectly.=
</div><div>=C2=A0</div><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"><div></div><blockquote class=3D"gmail_quote" style=3D"margin:0;ma=
rgin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"lt=
r"><div>- It would be easy and obvious to find such violations in the code.=
 Then violators can be caught.</div></div></blockquote><div><br>Only if the=
y are used consistently.<br></div></div></blockquote><div><br></div><div>Fi=
nding the right way to offer the functionality contributes greatly for the =
consistency.</div><div>=C2=A0</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></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1e=
x"><div dir=3D"ltr"><div>- If a proposed solution has equivalent performanc=
e of the hacky alternatives but it states clearly the intentions, people wi=
ll prefer to use it (or they would be so ashamed of having such ideas and a=
void it).</div></div></blockquote><div><br>Only if they are writing new cod=
e. Old code isn&#39;t automatically going to be changed.<br></div></div></b=
lockquote><div><br></div><div>Reflection -the major use case for violating =
encapsulation- will be only available in the new code.</div><div>But some r=
efactoring to adopt standard solutions is always welcome.</div><div><br></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><br><=
/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>- A dedi=
cated language solution is more likely to find a better balance for safety,=
 freedom and clarity than something buried deep down in reflection.</div></=
div></blockquote><div><br>Reflection does not allow private access because =
it is attempting to improve &quot;freedom&quot; or &quot;clarity&quot; or w=
hatever. It&#39;s doing it because reflection needs to in order to be a pro=
per tool.<br></div></div></blockquote><div><br></div><div>Correct. Reflecti=
on has its use cases for it. I want the language to be a better tool for vi=
olating access rights when <i>utterly necessary</i> with or without reflect=
ion.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v dir=3D"ltr"><div><br>Also, your statement presupposes that the current &q=
uot;balance&quot; is problematic. It isn&#39;t. Just because some people br=
eak laws doesn&#39;t make those laws wrong.<br><br></div></div></blockquote=
><div><br></div><div>I hope you never happen to have the language laws work=
ing against you.</div><div>=C2=A0</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><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"><div></div><div>I bet there are several ideas that could=
 work out but first we need to go over this feeling that people will use wh=
atever is proposed everyday and break everything.</div></div></blockquote><=
div><br>Sanctioning the violation of encapsulation is, and of a right ought=
 to be, a hard sell.<br><br></div></div></blockquote><div><br></div><div>I =
never thought it would be easy to convince people to go with this idea of a=
 separate language construction for unrestricted class member access.</div>=
<div>And even if all this don&#39;t convince anyone, there&#39;s enough inf=
ormation here to decide how to better implement it in reflection.</div><div=
>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
<div>Encapsulation should be a binary concept. Either it is accessible with=
out perfidy or it is not. Saying that it isn&#39;t accessible unless you do=
 this slightly inconvenient thing means that it is <i>accessible</i>. And t=
herefore not encapsulated.<br>=C2=A0</div></div></blockquote><div><br></div=
><div>Isn&#39;t that already the case?</div><div>People against the concept=
 of friend tell kind of the same thing.</div><div>=C2=A0</div><blockquote c=
lass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px=
 #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><blockquote class=3D"gmail=
_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr"><div>People stay away from &quot;reinterpret=
_cast&quot; already</div></div></blockquote><div><br>That&#39;s because the=
y use C-style casts.<br>=C2=A0</div></div></blockquote><div><br></div><div>=
I meant, people think twice before suggesting reinterpret_cast as a solutio=
n to a problem. Even if it&#39;s the only one.</div><div>It&#39;s such a si=
tuation where one say: &quot;what others will think of me if I tell them &#=
39;use reinterpret_cast&#39;?&quot;</div><div>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div dir=3D"ltr"><blockquote class=3D"gmail_quo=
te" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-=
left:1ex"><div dir=3D"ltr"><div> because is too &#39;dark&#39; and bet peop=
le would think twice before using something called &quot;violate_access_cas=
t&quot;.</div><div><br></div><div>That&#39;s it.<br></div><div><div><br><di=
v class=3D"gmail_quote">On Wed, Apr 27, 2016 at 4:13 PM, Peter Koch Larsen =
<span dir=3D"ltr">&lt;<a rel=3D"nofollow">peter.ko...@gmail.com</a>&gt;</sp=
an> wrote:<br><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">I do not understand all this fuzz about subv=
ersion of access rights.<br>
Let us face it:<br>
*) The purpose of access privileges is to protect the programmer from<br>
doing something stupid, such as using an<br>
=C2=A0 =C2=A0 object in a way it way not designed to be used. It has never =
been<br>
the purpose of access privileges to e.g. protect<br>
=C2=A0 =C2=A0 a system from an intruder or something in that direction.<br>
*) There are already ways in C++ to get access to the private parts of<br>
an object. Having one more way to do so is not<br>
=C2=A0 =C2=A0a problem.<br></blockquote></div></div></div></div></blockquot=
e><div><br>Neither of those is a justification for doing what you suggest.<=
br></div></div></blockquote><div><br></div><div>Correct. The justification =
is: it will be done, in this case I want people to always to the same way, =
I want to know when/where they have done, preferably I wouldn&#39;t make re=
flection responsible for it.</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>=C2=A0</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><div><div class=3D"gmail_quote"><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;b=
order-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"=
>
That being said, I believe that getting the access should be<br>
difficult: it should be blatantly clear that you are doing<br>
something dangerous - just as it is with e.g. reinterpret_cast.</blockquote=
></div></div></div></div></blockquote><div><br>`reinterpret_cast` is not &q=
uot;difficult&quot;.<br></div></div></blockquote><div><br></div><div>Certai=
nly it&#39;s not on the C++ 101 class. Neither would be anything that viola=
tes encapsulation.</div><div>Which is another reason for nothing having it =
in reflection, because some of reflection should be in this 101 class.=C2=
=A0</div><div><br></div><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"><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><d=
iv><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,=
204);border-left-style:solid;padding-left:1ex">Also,<br>
I fail to see the advantage of having this access.<br>
I am in the camp that believes that e.g. serialization is perfectly<br>
feasible without knowledge of the inner details about<br>
how such a class is defined.<br></blockquote></div></div></div></div></bloc=
kquote><div><br>So... what you&#39;re telling me is that you want to write =
crappy, fragile code.</div></div></blockquote><div><br></div><div>Crappy, d=
efinitely. No decent software professional should be satisfied with him/her=
self after <i><b>having to</b></i> write code that goes against a principle=
 of the software engineering.</div><div>Fragile? Debatable. There&#39;s a l=
ot of crappy code (in general, simply because there&#39;s no other way) ver=
y well tested and beautifully encapsulated, so no one don&#39;t have to be =
worried about the dirty tricks used internally. Boost has a few examples...=
</div><div>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v dir=3D"ltr"><div>You want to violate standard rules about data hiding bas=
ed on a premise that has been <i>proven faulty</i> (all it takes is one cou=
nter-example and I provided it).</div></div></blockquote><div><br></div><di=
v>Correct. I would rather know that something probably bad has been done th=
an sweeping it under the rug.</div><div>=C2=A0</div><blockquote class=3D"gm=
ail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc soli=
d;padding-left: 1ex;"><div dir=3D"ltr"><div>Also, even if we allowed you pr=
ivate access, you still couldn&#39;t properly construct such objects, becau=
se the only way to start the lifetime of an object in a piece of memory is =
to use placement `new`. Which must call a constructor. So your prospective =
unintrusive serialization library still has to use extra-standard methods (=
an illegal cast to `T*` or `T&amp;` at some point).<br><br></div></div></bl=
ockquote><div>=C2=A0</div><div>I&#39;m lost. What prevents reflection from =
giving me the signature type of the constructors from which I could create =
a factory functions (i.e. make_...) which in turn call new and return an in=
stance of the right type?<br>I don&#39;t see a need for casts and magic her=
e... unless the constructor is private/protected.</div><div>=C2=A0</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>You are bas=
ically proving exactly why we <i>shouldn&#39;t</i> let you do what you want=
.. Because if you give people a standard-sanctioned tool for breaking encaps=
ulation, people like you will <i>misuse it</i>. Since you have clearly and =
unequivocally stated your intent to do so.<br><br></div></div></blockquote>=
<div><br></div><div>I don&#39;t want to use it, I won&#39;t recommend it. A=
ctually, I personally gain nothing discussing this subject here. I may be l=
osing though.</div><div>But if I&#39;m forced to use such thing, I hope 1) =
the language don&#39;t get in my way 2) the language help me state my (bad)=
 intentions clearly, so whoever maintains the code can understand it and if=
 possible remove the hack ASAP.</div><div><br></div><blockquote class=3D"gm=
ail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc soli=
d;padding-left: 1ex;"><div dir=3D"ltr"><div>Really, the only thing you&#39;=
ve convinced me of is that reflection should have <i>additional</i> control=
s, for the sole purpose of preventing people like you from writing the libr=
ary you want to write. That there should be some mechanism to prevent `get_=
all_data_members` and its ilk from working unless you are in code that has =
private access already. Perhaps the MetaObject type generated for reflectio=
n purposes should have Public, Protected, and Private versions. If you&#39;=
re in code with private access to the class and you get a MetaObject for it=
, then you get the Private MetaObject type.<br></div></div></blockquote><di=
v><br></div><div>That limits the applicability of reflection, but if you co=
nvince people that nothing, not even reflection, should have unrestricted a=
ccess to class members, then yes, there&#39;s no point to offer a standard =
mechanism for violating encapsulation.</div></div></div></div>

<p></p>

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

------=_Part_89_931050265.1461997879269--
------=_Part_88_1007297698.1461997879268--

.

On 2016-04-28 14:48, Nicol Bolas wrote:
> Perhaps the MetaObject type generated for reflection purposes should
> have Public, Protected, and Private versions. If you're in code with
> private access to the class and you get a MetaObject for it, then you
> get the Private MetaObject type.

I sort of feel like I was under the impression that this would be the case.

There is some "leaking" that can come in to play here, in that if I have
private access that I use to obtain the "Private MetaObject" which I
then pass to someone else that shouldn't have private access, they can
obtain it, but that seems mostly harmless. (After all, I could already
e.g. pass a reference to a private data member in a similar manner. This
still involves someone who already legitimately has protected or private
access *actively* extending that access to someone else.)

If necessary, this could even work like POSIX ulimits, i.e. the
MetaObject has all parts of the class, always, but also an internal
state that says which it will tell you about (e.g. if different
MetaObject's of the same type need to be "identical") that can be
downgraded but never upgraded.

With or without that, it might also be useful to have a way to make a
copy of a MetaObject with downgraded access.

--
Matthew

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/ngai7u%24vrj%241%40ger.gmane.org.

.

<html><head></head><body lang=3D"en-US" style=3D"background-color: rgb(255,=
 255, 255); line-height: initial;">                                        =
                                              <div style=3D"width: 100%; fo=
nt-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif=
; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, =
255, 255);">Catching up on this email thread. Some thoughts:</div><div styl=
e=3D"width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sa=
ns-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; backgro=
und-color: rgb(255, 255, 255);"><br></div><div style=3D"width: 100%; font-s=
ize: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; co=
lor: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255,=
 255);">- overall, I think your arguments are compelling, but I still don't=
 like the idea. Even if you name it std::bad_idea_dont_do_this(), it still =
elevates it one 'level' in acceptability, and I worry about that.&nbsp;</di=
v><div style=3D"width: 100%; font-size: initial; font-family: Calibri, 'Sla=
te Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initi=
al; background-color: rgb(255, 255, 255);"><br></div><div style=3D"width: 1=
00%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, san=
s-serif; color: rgb(31, 73, 125); text-align: initial; background-color: rg=
b(255, 255, 255);">- reflection in some languages (ie java) is definitely t=
ainted by it being used =E2=80=8Eto subvert access rights. I would prefer C=
++ reflection just didn't allow access subversion. If the only choices were=
 do it in reflection or do it outside reflection &nbsp;with a specialized s=
td thing (as you suggest), I'd prefer outside reflection. And then those th=
at want private reflection can combine both.&nbsp;</div><div style=3D"width=
: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, =
sans-serif; color: rgb(31, 73, 125); text-align: initial; background-color:=
 rgb(255, 255, 255);"><br></div><div style=3D"width: 100%; font-size: initi=
al; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(3=
1, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);">An=
d for&nbsp;</div><div style=3D"width: 100%; font-size: initial; font-family=
: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); te=
xt-align: initial; background-color: rgb(255, 255, 255);">&gt;&nbsp;<span s=
tyle=3D"line-height: initial;">You're luck there was someone to tell you ab=
out the existence of that hack. You could at least find it in the code.&nbs=
p;</span></div><div style=3D"width: 100%; font-size: initial; font-family: =
Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text=
-align: initial; background-color: rgb(255, 255, 255);"><span style=3D"line=
-height: initial;"><br></span></div><div style=3D"width: 100%; font-size: i=
nitial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: r=
gb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);=
"><span style=3D"line-height: initial;">Hahaha. Not even close. Had to figu=
re out what was going on ourselves, and couldn't see the 3rd party code. Ju=
st had an exe that crashed. I was on the OS side, and had to 'fix' my side =
to make that exe not crash. </span></div><div style=3D"width: 100%; font-si=
ze: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; col=
or: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, =
255);"><br></div><div style=3D"width: 100%; font-size: initial; font-family=
: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); te=
xt-align: initial; background-color: rgb(255, 255, 255);"><br></div><div st=
yle=3D"width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', =
sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; backg=
round-color: rgb(255, 255, 255);"><span style=3D"font-size: initial; text-a=
lign: initial; line-height: initial;"><br></span></div><div style=3D"width:=
 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, s=
ans-serif; color: rgb(31, 73, 125); text-align: initial; background-color: =
rgb(255, 255, 255);"><span style=3D"font-size: initial; text-align: initial=
; line-height: initial;"><br></span></div>                                 =
                                                                           =
                                                                           =
            <div style=3D"font-size: initial; font-family: Calibri, 'Slate =
Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial;=
 background-color: rgb(255, 255, 255);">Sent&nbsp;from&nbsp;my&nbsp;BlackBe=
rry&nbsp;portable&nbsp;Babbage&nbsp;Device</div>                           =
                                                                           =
                                                                           =
 <table width=3D"100%" style=3D"background-color:white;border-spacing:0px;"=
> <tbody><tr><td colspan=3D"2" style=3D"font-size: initial; text-align: ini=
tial; background-color: rgb(255, 255, 255);">                           <di=
v style=3D"border-style: solid none none; border-top-color: rgb(181, 196, 2=
23); border-top-width: 1pt; padding: 3pt 0in 0in; font-family: Tahoma, 'BB =
Alpha Sans', 'Slate Pro'; font-size: 10pt;">  <div><b>From: </b>Ricardo Fab=
iano de Andrade</div><div><b>Sent: </b>Tuesday, April 26, 2016 12:47 AM</di=
v><div><b>To: </b>std-proposals@isocpp.org</div><div><b>Reply To: </b>std-p=
roposals@isocpp.org</div><div><b>Subject: </b>Re: [std-proposals] Re: About=
 subverting access rights</div></div></td></tr></tbody></table><div style=
=3D"border-style: solid none none; border-top-color: rgb(186, 188, 209); bo=
rder-top-width: 1pt; font-size: initial; text-align: initial; background-co=
lor: rgb(255, 255, 255);"></div><br><div id=3D"_originalContent" style=3D""=
><div dir=3D"ltr">Hi Tony, your comments are much appreciated. Here are som=
e arguments though.<div><br><div class=3D"gmail_extra"><br><div class=3D"gm=
ail_quote">On Mon, Apr 25, 2016 at 9:19 PM, Tony V E <span dir=3D"ltr">&lt;=
<a href=3D"mailto:tvaneerd@gmail.com" target=3D"_blank">tvaneerd@gmail.com<=
/a>&gt;</span> wrote:<br><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 lang=3D"en-US" style=3D"line=
-height:initial;background-color:rgb(255,255,255)">                        =
                                                              <div style=3D=
"width:100%;font-size:initial;font-family:Calibri,'Slate Pro',sans-serif,sa=
ns-serif;color:rgb(31,73,125);text-align:initial;background-color:rgb(255,2=
55,255)">IMO:</div><div style=3D"width:100%;font-size:initial;font-family:C=
alibri,'Slate Pro',sans-serif,sans-serif;color:rgb(31,73,125);text-align:in=
itial;background-color:rgb(255,255,255)">- reflection should not subvert ac=
cess rights</div><div style=3D"width:100%;font-size:initial;font-family:Cal=
ibri,'Slate Pro',sans-serif,sans-serif;color:rgb(31,73,125);text-align:init=
ial;background-color:rgb(255,255,255)">- neither should anything else</div>=
<div style=3D"width:100%;font-size:initial;font-family:Calibri,'Slate Pro',=
sans-serif,sans-serif;color:rgb(31,73,125);text-align:initial;background-co=
lor:rgb(255,255,255)"><br></div></div></blockquote><div>&nbsp;</div><div>In=
 theory this is desired, but let's face it, there's 35+ years&nbsp;of legac=
y code&nbsp;(when we get reflection probably 40) which will not get rewritt=
en or even touched any time soon.</div><div>It's not a perfect world. Non-i=
nvasive techniques and language support for them (such as reflection) are v=
ery valuable in this context.</div><div>&nbsp;</div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-l=
eft-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div l=
ang=3D"en-US" style=3D"line-height:initial;background-color:rgb(255,255,255=
)"><div style=3D"width:100%;font-size:initial;font-family:Calibri,'Slate Pr=
o',sans-serif,sans-serif;color:rgb(31,73,125);text-align:initial;background=
-color:rgb(255,255,255)"></div><div style=3D"width:100%;font-size:initial;f=
ont-family:Calibri,'Slate Pro',sans-serif,sans-serif;color:rgb(31,73,125);t=
ext-align:initial;background-color:rgb(255,255,255)">If the number one reas=
on is serialization, let's make some easier serialization library.&nbsp;</d=
iv><div style=3D"width:100%;font-size:initial;font-family:Calibri,'Slate Pr=
o',sans-serif,sans-serif;color:rgb(31,73,125);text-align:initial;background=
-color:rgb(255,255,255)"><br></div></div></blockquote><div><br></div><div>I=
 assume you're suggesting an invasive serialization library.</div><div>In g=
eneral, that requires adding some (definitely tedious/potentially slow) boi=
lerplate code and/or modifying existing code to add serialization support.<=
/div><div><br></div><div>Reflection can definitely help in both cases but i=
t really shines when you think about a non-invasive approach.</div><div>Up =
to the point where you run into a situation where you'll be required to acc=
ess a private/protected member, then the choice is either making a class me=
mber public or getting your hands dirty.<br></div><div>Breaking into the cl=
ass can potentially offer a much tighter and granular control over this acc=
ess and tends to be a safer bet than making things public to everyone.</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-=
left-style:solid;padding-left:1ex"><div lang=3D"en-US" style=3D"line-height=
:initial;background-color:rgb(255,255,255)"><div style=3D"width:100%;font-s=
ize:initial;font-family:Calibri,'Slate Pro',sans-serif,sans-serif;color:rgb=
(31,73,125);text-align:initial;background-color:rgb(255,255,255)"></div><di=
v style=3D"width:100%;font-size:initial;font-family:Calibri,'Slate Pro',san=
s-serif,sans-serif;color:rgb(31,73,125);text-align:initial;background-color=
:rgb(255,255,255)">I've had to support code that couldn't be changed becaus=
e someone (someone important) was subverting access rights, and thus we cou=
ldn't break that code.&nbsp;</div><div style=3D"width:100%;font-size:initia=
l;font-family:Calibri,'Slate Pro',sans-serif,sans-serif;color:rgb(31,73,125=
);text-align:initial;background-color:rgb(255,255,255)"><br></div></div></b=
lockquote><div><br></div><div>You're luck there was someone to tell you abo=
ut the existence of that hack. You could at least find it in the code.&nbsp=
;</div><div>In the other hand, I've experienced situations where someone re=
trofitted&nbsp;an invasive&nbsp;serialization library.</div><div>The result=
s were either scattered serialization code across the business logic or for=
 each class there was an accompanying serializable "adapter".</div><div>Nee=
dless to say both options have their problems.</div><div><div><br></div><di=
v>And serialization is just one use case.</div><div>Another example is a un=
it test framework where protected/private member functions can be freely ca=
lled to verify the internal behavior of a class.</div></div><div><br></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 lang=3D"en-US" style=3D"line-height:initial;backgroun=
d-color:rgb(255,255,255)"><div style=3D"width:100%;font-size:initial;font-f=
amily:Calibri,'Slate Pro',sans-serif,sans-serif;color:rgb(31,73,125);text-a=
lign:initial;background-color:rgb(255,255,255)"></div><div style=3D"width:1=
00%;font-size:initial;font-family:Calibri,'Slate Pro',sans-serif,sans-serif=
;color:rgb(31,73,125);text-align:initial;background-color:rgb(255,255,255)"=
>Think of the trouble DOS emulators need to go through due to people relyin=
g on undocumented hacks. Sure this will always exist, but do you want more =
of it or less?</div>                                                       =
                                                                           =
   <div style=3D"width:100%;font-size:initial;font-family:Calibri,'Slate Pr=
o',sans-serif,sans-serif;color:rgb(31,73,125);text-align:initial;background=
-color:rgb(255,255,255)"><br style=3D"display:initial"></div></div></blockq=
uote><div><br></div><div>We already have undocumented hacks and no new prop=
osal need to be done for that.</div><div><br></div><div>The discussion here=
 is if we want a very well documented standard way of accessing any class m=
embers under <i>special circumstances</i>&nbsp;and what should be the costs=
 both in terms of developer time and computational resources.</div><div><br=
></div><div>As a C++ developer I'd like to have the power to decide what's =
best for my code, assuming the risks and paying for the costs of my decisio=
n. Better if the language offers a way to express clearly my intentions for=
 others.</div><div><br></div><div>&nbsp;<br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-lef=
t-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div lan=
g=3D"en-US" style=3D"line-height:initial;background-color:rgb(255,255,255)"=
><div style=3D"width:100%;font-size:initial;font-family:Calibri,'Slate Pro'=
,sans-serif,sans-serif;color:rgb(31,73,125);text-align:initial;background-c=
olor:rgb(255,255,255)"></div>                                              =
                                                                           =
                                                                          <=
div style=3D"font-size:initial;font-family:Calibri,'Slate Pro',sans-serif,s=
ans-serif;color:rgb(31,73,125);text-align:initial;background-color:rgb(255,=
255,255)">Sent&nbsp;from&nbsp;my&nbsp;BlackBerry&nbsp;portable&nbsp;Babbage=
&nbsp;Device</div>                                                         =
                                                                           =
                                              <table width=3D"100%" style=
=3D"border-spacing:0px;background-color:white"> <tbody><tr><td colspan=3D"2=
" style=3D"font-size:initial;text-align:initial;background-color:rgb(255,25=
5,255)">                           <div style=3D"border-style:solid none no=
ne;border-top-color:rgb(181,196,223);border-top-width:1pt;padding:3pt 0in 0=
in;font-family:Tahoma,'BB Alpha Sans','Slate Pro';font-size:10pt">  <div><b=
>From: </b>Ricardo Fabiano de Andrade</div><div><b>Sent: </b>Monday, April =
25, 2016 6:28 PM</div><div><b>To: </b><a href=3D"mailto:std-proposals@isocp=
p.org" target=3D"_blank">std-proposals@isocpp.org</a></div><div><b>Reply To=
: </b><a href=3D"mailto:std-proposals@isocpp.org" target=3D"_blank">std-pro=
posals@isocpp.org</a></div><div><b>Subject: </b>Re: [std-proposals] Re: Abo=
ut subverting access rights</div></div></td></tr></tbody></table><div style=
=3D"border-style:solid none none;border-top-color:rgb(186,188,209);border-t=
op-width:1pt;font-size:initial;text-align:initial;background-color:rgb(255,=
255,255)"></div><br><div><div dir=3D"ltr"><div class=3D"gmail_extra"><div c=
lass=3D"gmail_quote">On Mon, Apr 25, 2016 at 3:27 PM, Ville Voutilainen <sp=
an 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 c=
lass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1p=
x;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1=
ex">On 25 April 2016 at 22:49, Ricardo Fabiano de Andrade<br>
&lt;<a href=3D"mailto:ricardofabianodeandrade@gmail.com" target=3D"_blank">=
ricardofabianodeandrade@gmail.com</a>&gt; wrote:<br>
&gt; Hi Ville,<br>
&gt; That said, my concerns is that this reflection proposal introduces a n=
ew,<br>
&gt; standard way to violate encapsulation.<br>
<br>
A way that is easy to find and ban, though.<br>
<br></blockquote><div><br></div><div>Agreed. I don't think any alternative =
should be different.</div><div>&nbsp;<br></div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-c=
olor:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
&gt; However, it has some costs both in terms of computing resources - time=
 to<br>
&gt; compile, program size - and human resources - time to learn reflection=
 and<br>
&gt; template meta-programming and apply these effectively and consistently=
..<br>
&gt; Which may lead to people ditching it and keep using the existing "dirt=
y"<br>
&gt; ways, which are difficult to identify in the code.<br>
<br>
I fail to see why that's such a concern. Bypassing access controls is indee=
d not<br>
the main reason for reflection.<br>
<br></blockquote><div><br></div><div>For me it's a concern because&nbsp;eit=
her&nbsp;people will use it for this purpose (making it easy to find and ba=
n).</div><div>Or because it's relatively more difficult to be done, people =
will not use it and the old ways will prevail (making it hard to find and n=
early impossible to ban).</div><div><br></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-co=
lor:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
&gt; Using Nicol's argument in the opposite direction, reflection does exis=
t to<br>
&gt; violate encapsulation but it will be used with this purpose.<br>
<br>
I presume that sentence is missing a "not".<br></blockquote><div><br></div>=
<div>Correct, my apologies.</div><div>&nbsp;</div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-lef=
t-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
&gt; Then comes the question that maybe it would be better to allow this to=
 be<br>
&gt; done outside of the context of reflection (so reflection would not be =
used<br>
&gt; when it's not necessary).<br>
&gt; Being also the main reason why this is not being discussed in the SG7 =
group.<br>
<br>
I don't know what you think is not being discussed in SG7.<br>
<span><font color=3D"#888888"><br></font></span></blockquote><div><br></div=
><div>I didn't make myself clear on that one.</div><div><br></div><div>You'=
re right, this matter is being actively discussed by the SG7 in the context=
 of reflection.</div><div><br></div><div>My question is whether&nbsp;it sho=
uld&nbsp;or not be discussed outside of the SG7 as well (that's why I poste=
d here).</div><div>And additionally, if a "good" (as costly as the alternat=
ives, easy to find and ban) mechanism for subverting access rights exists, =
there's no need to add another one in reflection.</div><div>Not having this=
 "functionality" in the reflection proposal (implicitly or explicitly) also=
 make it cleaner.</div><div>&nbsp;<br></div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-colo=
r:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span><font co=
lor=3D"#888888">
--<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">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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAFk2RUa7b5RLP8BM_E%2B%3DguCi9hpKTLU7=
u1CQo054y_CEzdcoZg%40mail.gmail.com" rel=3D"noreferrer" target=3D"_blank">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUa7b5RLP8=
BM_E%2B%3DguCi9hpKTLU7u1CQo054y_CEzdcoZg%40mail.gmail.com</a>.<span class=
=3D""><font color=3D"#888888"><br>
</font></span></font></span></blockquote></div><span class=3D""><font color=
=3D"#888888"><br></font></span></div></div><span class=3D""><font color=3D"=
#888888">

<p></p>

-- <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+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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CA%2BfGSbO_K50BSu-g%2BY76DeOSwdwATtc4=
DeHGB80z_mpgsCdgag%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoo=
ter" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-p=
roposals/CA%2BfGSbO_K50BSu-g%2BY76DeOSwdwATtc4DeHGB80z_mpgsCdgag%40mail.gma=
il.com</a>.<br>
<br></font></span></div></div><span class=3D""><font color=3D"#888888">

<p></p>

-- <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+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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/20160426021923.4898897.72532.10230%40=
gmail.com?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/20160426021923.48=
98897.72532.10230%40gmail.com</a>.<br>
</font></span></blockquote></div><br></div></div></div>

<p></p>

-- <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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CA%2BfGSbOkRpb1XZ1v2GTYn6bkDXY0A1JQ%2=
BMskuDou9C7hZpywGQ%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoo=
ter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BfGSb=
OkRpb1XZ1v2GTYn6bkDXY0A1JQ%2BMskuDou9C7hZpywGQ%40mail.gmail.com</a>.<br>
<br><!--end of _originalContent --></div></body></html>

<p></p>

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

.

------=_Part_2143_1057982612.1462717370291
Content-Type: multipart/alternative;
 boundary="----=_Part_2144_531475730.1462717370292"

------=_Part_2144_531475730.1462717370292
Content-Type: text/plain; charset=UTF-8



On Tuesday, May 3, 2016 at 12:05:37 PM UTC-4, Matthew Woehlke wrote:
>
> On 2016-04-28 14:48, Nicol Bolas wrote:
> > Perhaps the MetaObject type generated for reflection purposes should
> > have Public, Protected, and Private versions. If you're in code with
> > private access to the class and you get a MetaObject for it, then you
> > get the Private MetaObject type.
>
> I sort of feel like I was under the impression that this would be the
> case.
>
> There is some "leaking" that can come in to play here, in that if I have
> private access that I use to obtain the "Private MetaObject" which I
> then pass to someone else that shouldn't have private access, they can
> obtain it, but that seems mostly harmless. (After all, I could already
> e.g. pass a reference to a private data member in a similar manner. This
> still involves someone who already legitimately has protected or private
> access *actively* extending that access to someone else.)
>
> If necessary, this could even work like POSIX ulimits, i.e. the
> MetaObject has all parts of the class, always, but also an internal
> state that says which it will tell you about (e.g. if different
> MetaObject's of the same type need to be "identical") that can be
> downgraded but never upgraded.
>
> With or without that, it might also be useful to have a way to make a
> copy of a MetaObject with downgraded access.
>

I agree with all of this. Now you just need to convince the Reflection SG7
group to comply. Because P0194 doesn't follow these rules. It *could*, and
probably fairly easily. But as of yet, it does not.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b3c79007-9417-43f9-a077-fbbdb06c6a1b%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Tuesday, May 3, 2016 at 12:05:37 PM UTC-4, Matt=
hew Woehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2016-04-2=
8 14:48, Nicol Bolas wrote:
<br>&gt; Perhaps the MetaObject type generated for reflection purposes shou=
ld
<br>&gt; have Public, Protected, and Private versions. If you&#39;re in cod=
e with
<br>&gt; private access to the class and you get a MetaObject for it, then =
you
<br>&gt; get the Private MetaObject type.
<br>
<br>I sort of feel like I was under the impression that this would be the c=
ase.
<br>
<br>There is some &quot;leaking&quot; that can come in to play here, in tha=
t if I have
<br>private access that I use to obtain the &quot;Private MetaObject&quot; =
which I
<br>then pass to someone else that shouldn&#39;t have private access, they =
can
<br>obtain it, but that seems mostly harmless. (After all, I could already
<br>e.g. pass a reference to a private data member in a similar manner. Thi=
s
<br>still involves someone who already legitimately has protected or privat=
e
<br>access *actively* extending that access to someone else.)
<br>
<br>If necessary, this could even work like POSIX ulimits, i.e. the
<br>MetaObject has all parts of the class, always, but also an internal
<br>state that says which it will tell you about (e.g. if different
<br>MetaObject&#39;s of the same type need to be &quot;identical&quot;) tha=
t can be
<br>downgraded but never upgraded.
<br>
<br>With or without that, it might also be useful to have a way to make a
<br>copy of a MetaObject with downgraded access.<br></blockquote><div><br>I=
 agree with all of this. Now you just need to convince the Reflection SG7 g=
roup to comply. Because P0194 doesn&#39;t follow these rules. It <i>could</=
i>, and probably fairly easily. But as of yet, it does not. <br></div></div=
>

<p></p>

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

------=_Part_2144_531475730.1462717370292--
------=_Part_2143_1057982612.1462717370291--

.

--94eb2c123334c63f9a053256baee
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 8 May 2016 at 17:02, Tony V E <tvaneerd@gmail.com> wrote:

> Catching up on this email thread. Some thoughts:
>
> - overall, I think your arguments are compelling, but I still don't like
> the idea. Even if you name it std::bad_idea_dont_do_this(), it still
> elevates it one 'level' in acceptability, and I worry about that.
>
> - reflection in some languages (ie java) is definitely tainted by it bein=
g
> used =E2=80=8Eto subvert access rights. I would prefer C++ reflection jus=
t didn't
> allow access subversion. If the only choices were do it in reflection or =
do
> it outside reflection  with a specialized std thing (as you suggest), I'd
> prefer outside reflection. And then those that want private reflection ca=
n
> combine both.
>

Well, I don't like the ability to bypass access controls in the abstract
sense, but its motivation seems plenty compelling.
It's a tool. In codebases we control, we can decide whether it's used. With
sufficient rationale, it's much better to have
the ability to do so rather than pretending such bypassing never ever
happens. Especially since sometimes
you want to be able to bypass access controls in 3rd party code, which you
mention below. In some cases, that's just
because you want to read/dump/examine private parts of class types. In
arguably rarer cases, you want to modify
them in a "I know what I'm doing, I can't make the 3rd party type sane"
fashion. We should protect against a Murphy, not
against a Machiavelli. ;)


>
>
> And for
> > You're luck there was someone to tell you about the existence of that
> hack. You could at least find it in the code.
>
> Hahaha. Not even close. Had to figure out what was going on ourselves, an=
d
> couldn't see the 3rd party code. Just had an exe that crashed. I was on t=
he
> OS side, and had to 'fix' my side to make that exe not crash.
>
>
Right. I bet you and I both have had to circumvent unfortunate 3rd party
designs that prevent useful access to parts of class types.
Being able to do that via reflection seems superior to the outrageous hacks
we use today to do it.

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAFk2RUYE8iqub-9x3fecczG9c-PqtD%2B5%2Bi-Z557_se5=
dL2YzDw%40mail.gmail.com.

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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On 8 May 2016 at 17:02, Tony V E <span dir=3D"ltr">&lt;<a href=3D"mailt=
o:tvaneerd@gmail.com" target=3D"_blank">tvaneerd@gmail.com</a>&gt;</span> w=
rote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div style=3D"background-color:rgb(=
255,255,255);line-height:initial" lang=3D"en-US">                          =
                                                            <div style=3D"w=
idth:100%;font-size:initial;font-family:Calibri,&#39;Slate Pro&#39;,sans-se=
rif,sans-serif;color:rgb(31,73,125);text-align:initial;background-color:rgb=
(255,255,255)">Catching up on this email thread. Some thoughts:</div><div s=
tyle=3D"width:100%;font-size:initial;font-family:Calibri,&#39;Slate Pro&#39=
;,sans-serif,sans-serif;color:rgb(31,73,125);text-align:initial;background-=
color:rgb(255,255,255)"><br></div><div style=3D"width:100%;font-size:initia=
l;font-family:Calibri,&#39;Slate Pro&#39;,sans-serif,sans-serif;color:rgb(3=
1,73,125);text-align:initial;background-color:rgb(255,255,255)">- overall, =
I think your arguments are compelling, but I still don&#39;t like the idea.=
 Even if you name it std::bad_idea_dont_do_this(), it still elevates it one=
 &#39;level&#39; in acceptability, and I worry about that.=C2=A0</div><div =
style=3D"width:100%;font-size:initial;font-family:Calibri,&#39;Slate Pro&#3=
9;,sans-serif,sans-serif;color:rgb(31,73,125);text-align:initial;background=
-color:rgb(255,255,255)"><br></div><div style=3D"width:100%;font-size:initi=
al;font-family:Calibri,&#39;Slate Pro&#39;,sans-serif,sans-serif;color:rgb(=
31,73,125);text-align:initial;background-color:rgb(255,255,255)">- reflecti=
on in some languages (ie java) is definitely tainted by it being used =E2=
=80=8Eto subvert access rights. I would prefer C++ reflection just didn&#39=
;t allow access subversion. If the only choices were do it in reflection or=
 do it outside reflection =C2=A0with a specialized std thing (as you sugges=
t), I&#39;d prefer outside reflection. And then those that want private ref=
lection can combine both.=C2=A0</div></div></blockquote><div><br></div><div=
>Well, I don&#39;t like the ability to bypass access controls in the abstra=
ct sense, but its motivation seems plenty compelling.<br></div><div>It&#39;=
s a tool. In codebases we control, we can decide whether it&#39;s used. Wit=
h sufficient rationale, it&#39;s much better to have<br></div><div>the abil=
ity to do so rather than pretending such bypassing never ever happens. Espe=
cially since sometimes<br></div><div>you want to be able to bypass access c=
ontrols in 3rd party code, which you mention below. In some cases, that&#39=
;s just<br></div><div>because you want to read/dump/examine private parts o=
f class types. In arguably rarer cases, you want to modify<br></div><div>th=
em in a &quot;I know what I&#39;m doing, I can&#39;t make the 3rd party typ=
e sane&quot; fashion. We should protect against a Murphy, not<br></div><div=
>against a Machiavelli. ;)<br></div><div>=C2=A0<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><br><div style=3D"background-color:rgb(255,255,255);line-heig=
ht:initial" lang=3D"en-US"><div style=3D"width:100%;font-size:initial;font-=
family:Calibri,&#39;Slate Pro&#39;,sans-serif,sans-serif;color:rgb(31,73,12=
5);text-align:initial;background-color:rgb(255,255,255)"><br></div><div sty=
le=3D"width:100%;font-size:initial;font-family:Calibri,&#39;Slate Pro&#39;,=
sans-serif,sans-serif;color:rgb(31,73,125);text-align:initial;background-co=
lor:rgb(255,255,255)">And for=C2=A0</div><span class=3D""><div style=3D"wid=
th:100%;font-size:initial;font-family:Calibri,&#39;Slate Pro&#39;,sans-seri=
f,sans-serif;color:rgb(31,73,125);text-align:initial;background-color:rgb(2=
55,255,255)">&gt;=C2=A0<span style=3D"line-height:initial">You&#39;re luck =
there was someone to tell you about the existence of that hack. You could a=
t least find it in the code.=C2=A0</span></div><div style=3D"width:100%;fon=
t-size:initial;font-family:Calibri,&#39;Slate Pro&#39;,sans-serif,sans-seri=
f;color:rgb(31,73,125);text-align:initial;background-color:rgb(255,255,255)=
"><span style=3D"line-height:initial"><br></span></div></span><div style=3D=
"width:100%;font-size:initial;font-family:Calibri,&#39;Slate Pro&#39;,sans-=
serif,sans-serif;color:rgb(31,73,125);text-align:initial;background-color:r=
gb(255,255,255)"><span style=3D"line-height:initial">Hahaha. Not even close=
.. Had to figure out what was going on ourselves, and couldn&#39;t see the 3=
rd party code. Just had an exe that crashed. I was on the OS side, and had =
to &#39;fix&#39; my side to make that exe not crash. </span></div><span cla=
ss=3D""></span><br></div></blockquote><div><br></div><div>Right. I bet you =
and I both have had to circumvent unfortunate 3rd party designs that preven=
t useful access to parts of class types.<br></div><div>Being able to do tha=
t via reflection seems superior to the outrageous hacks we use today to do =
it. <br></div></div></div></div>

<p></p>

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

--94eb2c123334c63f9a053256baee--

.

<html><head></head><body lang=3D"en-US" style=3D"background-color: rgb(255,=
 255, 255); line-height: initial;">                                        =
                                              <div style=3D"width: 100%; fo=
nt-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif=
; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, =
255, 255);">I agree. But note in my case, I had to 'fix' my class (ie leave=
 private members that no longer made sense) because the third party was sub=
verting access to my stuff, not vice versa.&nbsp;</div><div style=3D"width:=
 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, s=
ans-serif; color: rgb(31, 73, 125); text-align: initial; background-color: =
rgb(255, 255, 255);"><br></div><div style=3D"width: 100%; font-size: initia=
l; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31=
, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);">It'=
s fine when I do it, just not when others do it. :-)</div><div style=3D"wid=
th: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif=
, sans-serif; color: rgb(31, 73, 125); text-align: initial; background-colo=
r: rgb(255, 255, 255);"><br></div>                                         =
                                                                           =
                 <div style=3D"width: 100%; font-size: initial; font-family=
: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); te=
xt-align: initial; background-color: rgb(255, 255, 255);"><br style=3D"disp=
lay:initial"></div>                                                        =
                                                                           =
                                                                <div style=
=3D"font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans=
-serif; color: rgb(31, 73, 125); text-align: initial; background-color: rgb=
(255, 255, 255);">Sent&nbsp;from&nbsp;my&nbsp;BlackBerry&nbsp;portable&nbsp=
;Babbage&nbsp;Device</div>                                                 =
                                                                           =
                                                      <table width=3D"100%"=
 style=3D"background-color:white;border-spacing:0px;"> <tbody><tr><td colsp=
an=3D"2" style=3D"font-size: initial; text-align: initial; background-color=
: rgb(255, 255, 255);">                           <div style=3D"border-styl=
e: solid none none; border-top-color: rgb(181, 196, 223); border-top-width:=
 1pt; padding: 3pt 0in 0in; font-family: Tahoma, 'BB Alpha Sans', 'Slate Pr=
o'; font-size: 10pt;">  <div><b>From: </b>Ville Voutilainen</div><div><b>Se=
nt: </b>Sunday, May 8, 2016 10:56 AM</div><div><b>To: </b>ISO C++ Standard =
- Future Proposals</div><div><b>Reply To: </b>std-proposals@isocpp.org</div=
><div><b>Subject: </b>Re: [std-proposals] Re: About subverting access right=
s</div></div></td></tr></tbody></table><div style=3D"border-style: solid no=
ne none; border-top-color: rgb(186, 188, 209); border-top-width: 1pt; font-=
size: initial; text-align: initial; background-color: rgb(255, 255, 255);">=
</div><br><div id=3D"_originalContent" style=3D""><div dir=3D"ltr"><br><div=
 class=3D"gmail_extra"><br><div class=3D"gmail_quote">On 8 May 2016 at 17:0=
2, Tony V E <span dir=3D"ltr">&lt;<a href=3D"mailto:tvaneerd@gmail.com" tar=
get=3D"_blank">tvaneerd@gmail.com</a>&gt;</span> wrote:<br><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex"><div style=3D"background-color:rgb(255,255,255);line-height:=
initial" lang=3D"en-US">                                                   =
                                   <div style=3D"width:100%;font-size:initi=
al;font-family:Calibri,'Slate Pro',sans-serif,sans-serif;color:rgb(31,73,12=
5);text-align:initial;background-color:rgb(255,255,255)">Catching up on thi=
s email thread. Some thoughts:</div><div style=3D"width:100%;font-size:init=
ial;font-family:Calibri,'Slate Pro',sans-serif,sans-serif;color:rgb(31,73,1=
25);text-align:initial;background-color:rgb(255,255,255)"><br></div><div st=
yle=3D"width:100%;font-size:initial;font-family:Calibri,'Slate Pro',sans-se=
rif,sans-serif;color:rgb(31,73,125);text-align:initial;background-color:rgb=
(255,255,255)">- overall, I think your arguments are compelling, but I stil=
l don't like the idea. Even if you name it std::bad_idea_dont_do_this(), it=
 still elevates it one 'level' in acceptability, and I worry about that.&nb=
sp;</div><div style=3D"width:100%;font-size:initial;font-family:Calibri,'Sl=
ate Pro',sans-serif,sans-serif;color:rgb(31,73,125);text-align:initial;back=
ground-color:rgb(255,255,255)"><br></div><div style=3D"width:100%;font-size=
:initial;font-family:Calibri,'Slate Pro',sans-serif,sans-serif;color:rgb(31=
,73,125);text-align:initial;background-color:rgb(255,255,255)">- reflection=
 in some languages (ie java) is definitely tainted by it being used =E2=80=
=8Eto subvert access rights. I would prefer C++ reflection just didn't allo=
w access subversion. If the only choices were do it in reflection or do it =
outside reflection &nbsp;with a specialized std thing (as you suggest), I'd=
 prefer outside reflection. And then those that want private reflection can=
 combine both.&nbsp;</div></div></blockquote><div><br></div><div>Well, I do=
n't like the ability to bypass access controls in the abstract sense, but i=
ts motivation seems plenty compelling.<br></div><div>It's a tool. In codeba=
ses we control, we can decide whether it's used. With sufficient rationale,=
 it's much better to have<br></div><div>the ability to do so rather than pr=
etending such bypassing never ever happens. Especially since sometimes<br><=
/div><div>you want to be able to bypass access controls in 3rd party code, =
which you mention below. In some cases, that's just<br></div><div>because y=
ou want to read/dump/examine private parts of class types. In arguably rare=
r cases, you want to modify<br></div><div>them in a "I know what I'm doing,=
 I can't make the 3rd party type sane" fashion. We should protect against a=
 Murphy, not<br></div><div>against a Machiavelli. ;)<br></div><div>&nbsp;<b=
r></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex"><br><div style=3D"background-color:r=
gb(255,255,255);line-height:initial" lang=3D"en-US"><div style=3D"width:100=
%;font-size:initial;font-family:Calibri,'Slate Pro',sans-serif,sans-serif;c=
olor:rgb(31,73,125);text-align:initial;background-color:rgb(255,255,255)"><=
br></div><div style=3D"width:100%;font-size:initial;font-family:Calibri,'Sl=
ate Pro',sans-serif,sans-serif;color:rgb(31,73,125);text-align:initial;back=
ground-color:rgb(255,255,255)">And for&nbsp;</div><span class=3D""><div sty=
le=3D"width:100%;font-size:initial;font-family:Calibri,'Slate Pro',sans-ser=
if,sans-serif;color:rgb(31,73,125);text-align:initial;background-color:rgb(=
255,255,255)">&gt;&nbsp;<span style=3D"line-height:initial">You're luck the=
re was someone to tell you about the existence of that hack. You could at l=
east find it in the code.&nbsp;</span></div><div style=3D"width:100%;font-s=
ize:initial;font-family:Calibri,'Slate Pro',sans-serif,sans-serif;color:rgb=
(31,73,125);text-align:initial;background-color:rgb(255,255,255)"><span sty=
le=3D"line-height:initial"><br></span></div></span><div style=3D"width:100%=
;font-size:initial;font-family:Calibri,'Slate Pro',sans-serif,sans-serif;co=
lor:rgb(31,73,125);text-align:initial;background-color:rgb(255,255,255)"><s=
pan style=3D"line-height:initial">Hahaha. Not even close. Had to figure out=
 what was going on ourselves, and couldn't see the 3rd party code. Just had=
 an exe that crashed. I was on the OS side, and had to 'fix' my side to mak=
e that exe not crash. </span></div><span class=3D""></span><br></div></bloc=
kquote><div><br></div><div>Right. I bet you and I both have had to circumve=
nt unfortunate 3rd party designs that prevent useful access to parts of cla=
ss types.<br></div><div>Being able to do that via reflection seems superior=
 to the outrageous hacks we use today to do it. <br></div></div></div></div=
>

<p></p>

-- <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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAFk2RUYE8iqub-9x3fecczG9c-PqtD%2B5%2=
Bi-Z557_se5dL2YzDw%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoo=
ter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUYE=
8iqub-9x3fecczG9c-PqtD%2B5%2Bi-Z557_se5dL2YzDw%40mail.gmail.com</a>.<br>
<br><!--end of _originalContent --></div></body></html>

<p></p>

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

.

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

On 8 May 2016 at 18:59, Tony V E <tvaneerd@gmail.com> wrote:

> I agree. But note in my case, I had to 'fix' my class (ie leave private
> members that no longer made sense) because the third party was subverting
> access to my stuff, not vice versa.
>
> It's fine when I do it, just not when others do it. :-)
>
>
>
Indeed. Even so, providing sane people tools is better than trying to
desperately prevent insane people from becoming more insane. :)
And on a more serious note, as The Great Lakos has taught us, even private
members can be significant as far as the physical interface
of a type is concerned, regardless of whether they can be or are accessed
outside normal 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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUa8JmVd77q%2B0E0M4JDd3RihexnA9Dt8rJfaFHs7_LoBfA%40mail.gmail.com.

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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On 8 May 2016 at 18:59, Tony V E <span dir=3D"ltr">&lt;<a href=3D"mailt=
o:tvaneerd@gmail.com" target=3D"_blank">tvaneerd@gmail.com</a>&gt;</span> w=
rote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div style=3D"background-color:rgb(=
255,255,255);line-height:initial" lang=3D"en-US">                          =
                                                            <div style=3D"w=
idth:100%;font-size:initial;font-family:Calibri,&#39;Slate Pro&#39;,sans-se=
rif,sans-serif;color:rgb(31,73,125);text-align:initial;background-color:rgb=
(255,255,255)">I agree. But note in my case, I had to &#39;fix&#39; my clas=
s (ie leave private members that no longer made sense) because the third pa=
rty was subverting access to my stuff, not vice versa.=C2=A0</div><div styl=
e=3D"width:100%;font-size:initial;font-family:Calibri,&#39;Slate Pro&#39;,s=
ans-serif,sans-serif;color:rgb(31,73,125);text-align:initial;background-col=
or:rgb(255,255,255)"><br></div><div style=3D"width:100%;font-size:initial;f=
ont-family:Calibri,&#39;Slate Pro&#39;,sans-serif,sans-serif;color:rgb(31,7=
3,125);text-align:initial;background-color:rgb(255,255,255)">It&#39;s fine =
when I do it, just not when others do it. :-)</div><span class=3D""><div st=
yle=3D"width:100%;font-size:initial;font-family:Calibri,&#39;Slate Pro&#39;=
,sans-serif,sans-serif;color:rgb(31,73,125);text-align:initial;background-c=
olor:rgb(255,255,255)"><br><br></div></span></div></blockquote><div><br></d=
iv><div>Indeed. Even so, providing sane people tools is better than trying =
to desperately prevent insane people from becoming more insane. :) <br></di=
v><div>And on a more serious note, as The Great Lakos has taught us, even p=
rivate members can be significant as far as the physical interface<br></div=
><div>of a type is concerned, regardless of whether they can be or are acce=
ssed outside normal access.<br></div></div><br></div></div>

<p></p>

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

--001a114304566dd8710532572d42--

.

------=_Part_2398_1227687047.1462727680768
Content-Type: multipart/alternative;
 boundary="----=_Part_2399_1249476582.1462727680768"

------=_Part_2399_1249476582.1462727680768
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sunday, May 8, 2016 at 11:56:07 AM UTC-4, Ville Voutilainen wrote:
>
> On 8 May 2016 at 17:02, Tony V E <tvan...@gmail.com <javascript:>> wrote:
>
>> Catching up on this email thread. Some thoughts:
>>
>> - overall, I think your arguments are compelling, but I still don't like=
=20
>> the idea. Even if you name it std::bad_idea_dont_do_this(), it still=20
>> elevates it one 'level' in acceptability, and I worry about that.=20
>>
>> - reflection in some languages (ie java) is definitely tainted by it=20
>> being used =E2=80=8Eto subvert access rights. I would prefer C++ reflect=
ion just=20
>> didn't allow access subversion. If the only choices were do it in=20
>> reflection or do it outside reflection  with a specialized std thing (as=
=20
>> you suggest), I'd prefer outside reflection. And then those that want=20
>> private reflection can combine both.=20
>>
>
> Well, I don't like the ability to bypass access controls in the abstract=
=20
> sense, but its motivation seems plenty compelling.
> It's a tool. In codebases we control, we can decide whether it's used.=20
> With sufficient rationale, it's much better to have
> the ability to do so rather than pretending such bypassing never ever=20
> happens. Especially since sometimes
> you want to be able to bypass access controls in 3rd party code, which yo=
u=20
> mention below. In some cases, that's just
> because you want to read/dump/examine private parts of class types. In=20
> arguably rarer cases, you want to modify
> them in a "I know what I'm doing, I can't make the 3rd party type sane"=
=20
> fashion. We should protect against a Murphy, not
> against a Machiavelli. ;)
>

But what you're suggesting offers zero protection against Murphy at all.=20
The moment you allow people to violate access controls trivially, people=20
will use it incorrectly. A lot.

Take the current thread. Serializing arbitrary data structures without=20
their knowledge or consent is a *terrible idea*, for reasons that have been=
=20
explained. And yet, you have someone here who desperately wants to do this=
=20
despite knowing that it's a bad idea.

He is Murphy *personified*. And what you want will *enable* him.

Right now, the only thing that prevents people like him from writing=20
so-called "serialization" systems is the fact that accessing private data=
=20
is *difficult*. Subverting access controls requires invoking undefined=20
behavior. It requires relying on the specific behavior of compilers, which=
=20
can change from platform to platform, thus making platform-neutral code=20
even more complex. It requires doing a bunch of things that the average C++=
=20
programmer cannot look up in a text book or cppreference.com. Therefore,=20
the only people who will even make the attempt will be people who are far=
=20
more likely to "know what I'm doing".

The current system protects from Murphy to a great degree, while not making=
=20
Machiavelli completely impossible.

At least with reflection, the purpose of reflection is not to access=20
privates; it's to access the type's properties. As such, accessing privates=
=20
is made *inconvenient*, since it's bound up in a generic interface. This=20
higher bar of entry helps ensure that the people who are able to use it=20
will also know what they're doing (hopefully).

Once it becomes `private_cast(t).privateVariable`, there is no private data=
=20
anymore. We may want to not protect against Machiavelli, but with this,=20
we're not getting *any protection* against Murphy at all. Because the=20
moment someone gets a "cannot access private variable" error, these "you're=
=20
not the boss of ME!" types will instantly whip out a `private_cast`,=20
because they think their minor inconvenience is clearly a reason to use=20
that.

And if we're getting no protection against Murphy, what's the point of=20
private variables at all? Let's just do what Python does and have=20
everything be public, but we put an underscore in front of variables that=
=20
you're not supposed to touch. That's good enough, right?

You're going to get two kinds of behaviors from this. There will be people=
=20
who basically abandoning access controls, since it's sufficiently trivial=
=20
to violate them that they are not at all effective. And you'll get people=
=20
inventing all kinds of ways to defeat your access-control violation method.

They could employ pimpl or just use pointers/references to incomplete types=
=20
and a namespace-scoped interface. They could employ `aligned_storage` to=20
store their privates data, using a private internal struct to store the=20
actual values. Or perhaps they'll use a private `tuple`, since accessing=20
that is at least inconvenient. They may even start not using=20
pointers/references at all. Instead, they could use integers, which are=20
internally converted into addresses like OpenGL does with object names.

If you weaken `private`, then people will just find more secure ways to=20
make their data private. And thus, you've gained nothing; all you've lost=
=20
is making it easy to make data reasonable encapsulated.

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/fa6f5d6d-d8da-449e-b37d-5252ae179f50%40isocpp.or=
g.

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

<div dir=3D"ltr">On Sunday, May 8, 2016 at 11:56:07 AM UTC-4, Ville Voutila=
inen 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"><d=
iv><div class=3D"gmail_quote">On 8 May 2016 at 17:02, Tony V E <span dir=3D=
"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=
=3D"VN6EoNJgBwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascri=
pt:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return =
true;">tvan...@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex"><div style=3D"background-color:rgb(255,255,255);line-height:initial" =
lang=3D"en-US">                                                            =
                          <div style=3D"width:100%;font-size:initial;font-f=
amily:Calibri,&#39;Slate Pro&#39;,sans-serif,sans-serif;color:rgb(31,73,125=
);text-align:initial;background-color:rgb(255,255,255)">Catching up on this=
 email thread. Some thoughts:</div><div style=3D"width:100%;font-size:initi=
al;font-family:Calibri,&#39;Slate Pro&#39;,sans-serif,sans-serif;color:rgb(=
31,73,125);text-align:initial;background-color:rgb(255,255,255)"><br></div>=
<div style=3D"width:100%;font-size:initial;font-family:Calibri,&#39;Slate P=
ro&#39;,sans-serif,sans-serif;color:rgb(31,73,125);text-align:initial;backg=
round-color:rgb(255,255,255)">- overall, I think your arguments are compell=
ing, but I still don&#39;t like the idea. Even if you name it std::bad_idea=
_dont_do_this(), it still elevates it one &#39;level&#39; in acceptability,=
 and I worry about that.=C2=A0</div><div style=3D"width:100%;font-size:init=
ial;font-family:Calibri,&#39;Slate Pro&#39;,sans-serif,sans-serif;color:rgb=
(31,73,125);text-align:initial;background-color:rgb(255,255,255)"><br></div=
><div style=3D"width:100%;font-size:initial;font-family:Calibri,&#39;Slate =
Pro&#39;,sans-serif,sans-serif;color:rgb(31,73,125);text-align:initial;back=
ground-color:rgb(255,255,255)">- reflection in some languages (ie java) is =
definitely tainted by it being used =E2=80=8Eto subvert access rights. I wo=
uld prefer C++ reflection just didn&#39;t allow access subversion. If the o=
nly choices were do it in reflection or do it outside reflection =C2=A0with=
 a specialized std thing (as you suggest), I&#39;d prefer outside reflectio=
n. And then those that want private reflection can combine both.=C2=A0</div=
></div></blockquote><div><br></div><div>Well, I don&#39;t like the ability =
to bypass access controls in the abstract sense, but its motivation seems p=
lenty compelling.<br></div><div>It&#39;s a tool. In codebases we control, w=
e can decide whether it&#39;s used. With sufficient rationale, it&#39;s muc=
h better to have<br></div><div>the ability to do so rather than pretending =
such bypassing never ever happens. Especially since sometimes<br></div><div=
>you want to be able to bypass access controls in 3rd party code, which you=
 mention below. In some cases, that&#39;s just<br></div><div>because you wa=
nt to read/dump/examine private parts of class types. In arguably rarer cas=
es, you want to modify<br></div><div>them in a &quot;I know what I&#39;m do=
ing, I can&#39;t make the 3rd party type sane&quot; fashion. We should prot=
ect against a Murphy, not<br></div><div>against a Machiavelli. ;)<br></div>=
</div></div></div></blockquote><div><br>But what you&#39;re suggesting offe=
rs zero protection against Murphy at all. The moment you allow people to vi=
olate access controls trivially, people will use it incorrectly. A lot.<br>=
<br>Take the current thread. Serializing arbitrary data structures without =
their knowledge or consent is a <i>terrible idea</i>, for reasons that have=
 been explained. And yet, you have someone here who desperately wants to do=
 this despite knowing that it&#39;s a bad idea.<br><br>He is Murphy <i>pers=
onified</i>. And what you want will <i>enable</i> him.<br><br>Right now, th=
e only thing that prevents people like him from writing so-called &quot;ser=
ialization&quot; systems is the fact that accessing private data is <i>diff=
icult</i>. Subverting access controls requires invoking undefined behavior.=
 It requires relying on the specific behavior of compilers, which can chang=
e from platform to platform, thus making platform-neutral code even more co=
mplex. It requires doing a bunch of things that the average C++ programmer =
cannot look up in a text book or cppreference.com. Therefore, the only peop=
le who will even make the attempt will be people who are far more likely to=
 &quot;know what I&#39;m doing&quot;.<br><br>The current system protects fr=
om Murphy to a great degree, while not making Machiavelli completely imposs=
ible.<br><br>At least with reflection, the purpose of reflection is not to =
access privates; it&#39;s to access the type&#39;s properties. As such, acc=
essing privates is made <i>inconvenient</i>, since it&#39;s bound up in a g=
eneric interface. This higher bar of entry helps ensure that the people who=
 are able to use it will also know what they&#39;re doing (hopefully).<br><=
br>Once it becomes `private_cast(t).privateVariable`, there is no private d=
ata anymore. We may want to not protect against Machiavelli, but with this,=
 we&#39;re not getting <i>any protection</i> against Murphy at all. Because=
 the moment someone gets a &quot;cannot access private variable&quot; error=
, these &quot;you&#39;re not the boss of ME!&quot; types will instantly whi=
p out a `private_cast`, because they think their minor inconvenience is cle=
arly a reason to use that.<br><br>And if we&#39;re getting no protection ag=
ainst Murphy, what&#39;s the point of private variables at all? Let&#39;s j=
ust do what Python does and have everything be public, but we put an unders=
core in front of variables that you&#39;re not supposed to touch. That&#39;=
s good enough, right?<br><br>You&#39;re going to get two kinds of behaviors=
 from this. There will be people who basically abandoning access controls, =
since it&#39;s sufficiently trivial to violate them that they are not at al=
l effective. And you&#39;ll get people inventing all kinds of ways to defea=
t your access-control violation method.<br><br>They could employ pimpl or j=
ust use pointers/references to incomplete types and a namespace-scoped inte=
rface. They could employ `aligned_storage` to store their privates data, us=
ing a private internal struct to store the actual values. Or perhaps they&#=
39;ll use a private `tuple`, since accessing that is at least inconvenient.=
 They may even start not using pointers/references at all. Instead, they co=
uld use integers, which are internally converted into addresses like OpenGL=
 does with object names.<br><br>If you weaken `private`, then people will j=
ust find more secure ways to make their data private. And thus, you&#39;ve =
gained nothing; all you&#39;ve lost is making it easy to make data reasonab=
le encapsulated.<br></div></div>

<p></p>

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

------=_Part_2399_1249476582.1462727680768--
------=_Part_2398_1227687047.1462727680768--

.

On 8 May 2016 at 20:14, Nicol Bolas <jmckesson@gmail.com> wrote:
> But what you're suggesting offers zero protection against Murphy at all. The

That's a misuse of the term "at all".

> moment you allow people to violate access controls trivially, people will

There's no triviality involved, because access control violations will
not happen
unless asked for, and such violations can be, to abuse your abuse of the term,
trivially easily be caught in code review.

> Take the current thread. Serializing arbitrary data structures without their
> knowledge or consent is a terrible idea, for reasons that have been

Well, you're free to think so, but we have practical users who can
demonstrate it's
a great idea.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUa1aQYFGBkhxj_nZHNT8RT3J99BuaQNdTXDxcD95O4-5Q%40mail.gmail.com.

.

------=_Part_2215_1925012293.1462730555379
Content-Type: multipart/alternative;
 boundary="----=_Part_2216_1237304012.1462730555380"

------=_Part_2216_1237304012.1462730555380
Content-Type: text/plain; charset=UTF-8

On Sunday, May 8, 2016 at 1:26:57 PM UTC-4, Ville Voutilainen wrote:
>
> On 8 May 2016 at 20:14, Nicol Bolas <jmck...@gmail.com <javascript:>>
> wrote:
> > But what you're suggesting offers zero protection against Murphy at all.
> The
>
> That's a misuse of the term "at all".
>
> > moment you allow people to violate access controls trivially, people
> will
>
> There's no triviality involved, because access control violations will
> not happen
> unless asked for, and such violations can be, to abuse your abuse of the
> term,
> trivially easily be caught in code review.
>

That assumes:

1) Code review is a thing that happens. A lot of C++ is written under the
honor system.

2) The only code review that matters is your own. If you're writing a
client application, sure. But if you're writing a library, this also means
that clients get to theoretically violate access controls for your types.
And your code review cannot detect or stop them from doing so, as evidenced
by the issue Tony had.

3) That your code reviewers all agree that such code is not acceptable
unless well-justified. And that your definition of "well-justified" is a
good one. And if you think that this is hyperbole, remember that there are
plenty of things that most coders consider bad ideas which various
organizations will gladly let past code review.

If code review were enough to keep people from doing bad things, we
wouldn't need encapsulation as a language feature, would we?

> Take the current thread. Serializing arbitrary data structures without
> their
> > knowledge or consent is a terrible idea, for reasons that have been
>
> Well, you're free to think so, but we have practical users who can
> demonstrate it's
> a great idea.
>

It's a great idea, as long as you don't put certain types into it. Types
which no concept or metaprogramming technique can check for, so it's
impossible to know at compile-time if you've done something wrong. It's a
great idea to make a system that claims to be able to work on any type
which cannot in fact work on any type.

In fact, it can't even work on *the* `any` type ;)

The fact that some people can use a system that is easily broken doesn't
make it a good system. Just like the fact that people can use naked
pointers without leaking memory doesn't mean that using smart pointers
isn't a better idea.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/555d472a-3c8b-400e-a052-5b722ae0f71e%40isocpp.org.

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

<div dir=3D"ltr">On Sunday, May 8, 2016 at 1:26:57 PM UTC-4, Ville Voutilai=
nen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 8 May 2016 at 20:=
14, Nicol Bolas &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscate=
d-mailto=3D"mPhQjcdlBwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;=
javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;=
;return true;">jmck...@gmail.com</a>&gt; wrote:
<br>&gt; But what you&#39;re suggesting offers zero protection against Murp=
hy at all. The
<br>
<br>That&#39;s a misuse of the term &quot;at all&quot;.
<br>
<br>&gt; moment you allow people to violate access controls trivially, peop=
le will
<br>
<br>There&#39;s no triviality involved, because access control violations w=
ill
<br>not happen
<br>unless asked for, and such violations can be, to abuse your abuse of th=
e term,
<br>trivially easily be caught in code review.<br></blockquote><div><br>Tha=
t assumes:<br><br>1) Code review is a thing that happens. A lot of C++ is w=
ritten under the honor system.<br><br>2) The only code review that matters =
is your own. If you&#39;re writing a client application, sure. But if you&#=
39;re writing a library, this also means that clients get to theoretically =
violate access controls for your types. And your code review cannot detect =
or stop them from doing so, as evidenced by the issue Tony had.<br><br>3) T=
hat your code reviewers all agree that such code is not acceptable unless w=
ell-justified. And that your definition of &quot;well-justified&quot; is a =
good one. And if you think that this is hyperbole, remember that there are =
plenty of things that most coders consider bad ideas which various organiza=
tions will gladly let past code review.<br><br>If code review were enough t=
o keep people from doing bad things, we wouldn&#39;t need encapsulation as =
a language feature, would we?<br><br></div><blockquote class=3D"gmail_quote=
" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding=
-left: 1ex;">
&gt; Take the current thread. Serializing arbitrary data structures without=
 their
<br>&gt; knowledge or consent is a terrible idea, for reasons that have bee=
n
<br>
<br>Well, you&#39;re free to think so, but we have practical users who can
<br>demonstrate it&#39;s
<br>a great idea.
<br></blockquote><div><br>It&#39;s a great idea, as long as you don&#39;t p=
ut certain types into it. Types which no concept or metaprogramming techniq=
ue can check for, so it&#39;s impossible to know at compile-time if you&#39=
;ve done something wrong. It&#39;s a great idea to make a system that claim=
s to be able to work on any type which cannot in fact work on any type.<br>=
<br>In fact, it can&#39;t even work on <i>the</i> `any` type ;)<br><br>The =
fact that some people can use a system that is easily broken doesn&#39;t ma=
ke it a good system. Just like the fact that people can use naked pointers =
without leaking memory doesn&#39;t mean that using smart pointers isn&#39;t=
 a better idea.<br></div></div>

<p></p>

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

------=_Part_2216_1237304012.1462730555380--
------=_Part_2215_1925012293.1462730555379--

.

On 8 May 2016 at 21:02, Nicol Bolas <jmckesson@gmail.com> wrote:
> On Sunday, May 8, 2016 at 1:26:57 PM UTC-4, Ville Voutilainen wrote:
>>
>> On 8 May 2016 at 20:14, Nicol Bolas <jmck...@gmail.com> wrote:
>> > But what you're suggesting offers zero protection against Murphy at all.
>> > The
>>
>> That's a misuse of the term "at all".
>>
>> > moment you allow people to violate access controls trivially, people
>> > will
>>
>> There's no triviality involved, because access control violations will
>> not happen
>> unless asked for, and such violations can be, to abuse your abuse of the
>> term,
>> trivially easily be caught in code review.
>
>
> That assumes:
>
> 1) Code review is a thing that happens.

Yeah, a very good assumption, as far as I am concerned, and as far as
serious code is concerned.

>A lot of C++ is written under the
> honor system.

Beats me what that means.

> 2) The only code review that matters is your own. If you're writing a client
> application, sure. But if you're writing a library, this also means that
> clients get to theoretically violate access controls for your types. And
> your code review cannot detect or stop them from doing so, as evidenced by
> the issue Tony had.

In some cases it can't, in some cases it can.

> If code review were enough to keep people from doing bad things, we wouldn't
> need encapsulation as a language feature, would we?

Hard to say, because code reviews tend to recommend good uses of encapsulation.

>> Well, you're free to think so, but we have practical users who can
>> demonstrate it's
>> a great idea.
> It's a great idea, as long as you don't put certain types into it. Types

Then by all means don't.

> which no concept or metaprogramming technique can check for, so it's
> impossible to know at compile-time if you've done something wrong. It's a

That doesn't constitute a sufficient reason to prevent people who need
to look at private
members from doing so.

> In fact, it can't even work on the `any` type ;)

Doesn't seem like a show-stopper to me.

> The fact that some people can use a system that is easily broken doesn't
> make it a good system. Just like the fact that people can use naked pointers
> without leaking memory doesn't mean that using smart pointers isn't a better
> idea.


No disagreement there, but that doesn't mean we should not have naked
pointers, 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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUZmVXLTMDEreMXDoWpwwNCSz70_yYnoDHqJNMZuGpm1-g%40mail.gmail.com.

.