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

This is about the old and boring problem "private members are part of the
class interface".

The idea that I want to propose is the following one: make it possible to
omit the declaration of private member functions inside a class definition.

I.e., do something like this

// header file
struct A
{
    void B();
    void C();
private:
    int p;
}

// implementation file
private void A::Q(int x)
{
    p = x;
}

void A::B()
{
    Q(1);
}

void A::C()
{
    Q(2);
}

The private keyword as used above introduces a hidden private member
function. Because it is private, it can only be called by other members or
friends, so, ultimately, it can only be called by the code that has full
access to the class anyway. One cannot just define such a private member to
break the encapsulation.

Hidden private members cannot be virtual.

So this is an attempt to make it possible to remove *some* of the
implementation out of the interface. It does not try to remove everything,
notably data, that is private. A typical use case would involve some common
logic that needs to be called by multiple public members; then the common
logic can be put together in such a private member, re-phrasing the same
thing, this will make it possible to refactor the implementation without
changing the interface files.

It is quite possible that this has been proposed and discussed earlier;
please point me to the relevant discussions in that case.

Cheers,
V.

--
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/CAA7YVg0C0HbCzcqSUaraAPQ4dW-rtDnaZ7MqP8zk6kNP4W2hgA%40mail.gmail.com.

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

<div dir=3D"ltr">This is about the old and boring problem &quot;private mem=
bers are part of the class interface&quot;.<div><br></div><div>The idea tha=
t I want to propose is the following one: make it possible to omit the decl=
aration of private member functions inside a class definition.</div><div><b=
r></div><div>I.e., do something like this</div><div><br></div><div>// heade=
r file</div><div>struct A</div><div>{</div><div>=C2=A0 =C2=A0 void B();</di=
v><div>=C2=A0 =C2=A0 void C();<br></div><div>private:</div><div>=C2=A0 =C2=
=A0 int p;</div><div>}</div><div><br></div><div>// implementation file</div=
><div>private void A::Q(int x)</div><div>{</div><div>=C2=A0 =C2=A0 p =3D x;=
</div><div>}</div><div><br></div><div>void A::B()</div><div>{</div><div>=C2=
=A0 =C2=A0 Q(1);</div><div>}</div><div><br></div><div>void A::C()</div><div=
>{</div><div>=C2=A0 =C2=A0 Q(2);</div><div>}</div><div><br></div><div>The p=
rivate keyword as used above introduces a hidden private member function. B=
ecause it is private, it can only be called by other members or friends, so=
, ultimately, it can only be called by the code that has full access to the=
 class anyway. One cannot just define such a private member to break the en=
capsulation.</div><div><br></div><div>Hidden private members cannot be virt=
ual.</div><div><br></div><div>So this is an attempt to make it possible to =
remove <i>some</i>=C2=A0of the implementation out of the interface. It does=
 not try to remove everything, notably data, that is private. A typical use=
 case would involve some common logic that needs to be called by multiple p=
ublic members; then the common logic can be put together in such a private =
member, re-phrasing the same thing, this will make it possible to refactor =
the implementation without changing the interface files.</div><div><br></di=
v><div>It is quite possible that this has been proposed and discussed earli=
er; please point me to the relevant discussions in that case.<br></div><div=
><br></div><div>Cheers,</div><div>V.</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/CAA7YVg0C0HbCzcqSUaraAPQ4dW-rtDnaZ7Mq=
P8zk6kNP4W2hgA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg0C0HbCzcqS=
UaraAPQ4dW-rtDnaZ7MqP8zk6kNP4W2hgA%40mail.gmail.com</a>.<br />

--f403045ec286124f920543009242--

.

------=_Part_2458_1317091247.1481048628212
Content-Type: multipart/alternative;
 boundary="----=_Part_2459_1323808405.1481048628212"

------=_Part_2459_1323808405.1481048628212
Content-Type: text/plain; charset=UTF-8

You can already do something like this. Consider:

// A.h
struct A {
    struct B;
    friend struct B;

        void setX();
        int getX() const;

    private:
        int x;
};

// A.cpp
#include "a.h"

struct A::B {
    void foo(A& a) {
        a.x = 4;
    }
};

void A::setX() {
    B().foo(*this);
}

int A::getX() const {
    return x;
}



On Tuesday, December 6, 2016 at 6:16:56 PM UTC+1, Viacheslav Usov wrote:
>
> This is about the old and boring problem "private members are part of the
> class interface".
>
> The idea that I want to propose is the following one: make it possible to
> omit the declaration of private member functions inside a class definition.
>
> I.e., do something like this
>
> // header file
> struct A
> {
>     void B();
>     void C();
> private:
>     int p;
> }
>
> // implementation file
> private void A::Q(int x)
> {
>     p = x;
> }
>
> void A::B()
> {
>     Q(1);
> }
>
> void A::C()
> {
>     Q(2);
> }
>
> The private keyword as used above introduces a hidden private member
> function. Because it is private, it can only be called by other members or
> friends, so, ultimately, it can only be called by the code that has full
> access to the class anyway. One cannot just define such a private member to
> break the encapsulation.
>
> Hidden private members cannot be virtual.
>
> So this is an attempt to make it possible to remove *some* of the
> implementation out of the interface. It does not try to remove everything,
> notably data, that is private. A typical use case would involve some common
> logic that needs to be called by multiple public members; then the common
> logic can be put together in such a private member, re-phrasing the same
> thing, this will make it possible to refactor the implementation without
> changing the interface files.
>
> It is quite possible that this has been proposed and discussed earlier;
> please point me to the relevant discussions in that case.
>
> Cheers,
> V.
>

--
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/23872a0c-e0f1-4b00-b3a4-e214a627ffa1%40isocpp.org.

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

<div dir=3D"ltr">You can already do something like this. Consider:<br><br>/=
/ A.h<br>struct A {<br>=C2=A0=C2=A0=C2=A0 struct B;<br>=C2=A0=C2=A0=C2=A0 f=
riend struct B;<br><br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 void setX=
();<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 int getX() const;<br><br>=
=C2=A0=C2=A0=C2=A0 private:<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 i=
nt x;<br>};<br><br>// A.cpp<br>#include &quot;a.h&quot;<br><br>struct A::B =
{<br>=C2=A0=C2=A0=C2=A0 void foo(A&amp; a) {<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 a.x =3D 4;<br>=C2=A0=C2=A0=C2=A0 }<br>};<br><br>void A::set=
X() {<br>=C2=A0=C2=A0=C2=A0 B().foo(*this);<br>}<br><br>int A::getX() const=
 {<br>=C2=A0=C2=A0=C2=A0 return x;<br>}<br><br><br><br>On Tuesday, December=
 6, 2016 at 6:16:56 PM UTC+1, Viacheslav Usov wrote:<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">This is about the old and boring pro=
blem &quot;private members are part of the class interface&quot;.<div><br><=
/div><div>The idea that I want to propose is the following one: make it pos=
sible to omit the declaration of private member functions inside a class de=
finition.</div><div><br></div><div>I.e., do something like this</div><div><=
br></div><div>// header file</div><div>struct A</div><div>{</div><div>=C2=
=A0 =C2=A0 void B();</div><div>=C2=A0 =C2=A0 void C();<br></div><div>privat=
e:</div><div>=C2=A0 =C2=A0 int p;</div><div>}</div><div><br></div><div>// i=
mplementation file</div><div>private void A::Q(int x)</div><div>{</div><div=
>=C2=A0 =C2=A0 p =3D x;</div><div>}</div><div><br></div><div>void A::B()</d=
iv><div>{</div><div>=C2=A0 =C2=A0 Q(1);</div><div>}</div><div><br></div><di=
v>void A::C()</div><div>{</div><div>=C2=A0 =C2=A0 Q(2);</div><div>}</div><d=
iv><br></div><div>The private keyword as used above introduces a hidden pri=
vate member function. Because it is private, it can only be called by other=
 members or friends, so, ultimately, it can only be called by the code that=
 has full access to the class anyway. One cannot just define such a private=
 member to break the encapsulation.</div><div><br></div><div>Hidden private=
 members cannot be virtual.</div><div><br></div><div>So this is an attempt =
to make it possible to remove <i>some</i>=C2=A0of the implementation out of=
 the interface. It does not try to remove everything, notably data, that is=
 private. A typical use case would involve some common logic that needs to =
be called by multiple public members; then the common logic can be put toge=
ther in such a private member, re-phrasing the same thing, this will make i=
t possible to refactor the implementation without changing the interface fi=
les.</div><div><br></div><div>It is quite possible that this has been propo=
sed and discussed earlier; please point me to the relevant discussions in t=
hat case.<br></div><div><br></div><div>Cheers,</div><div>V.</div></div>
</blockquote></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/23872a0c-e0f1-4b00-b3a4-e214a627ffa1%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/23872a0c-e0f1-4b00-b3a4-e214a627ffa1=
%40isocpp.org</a>.<br />

------=_Part_2459_1323808405.1481048628212--

------=_Part_2458_1317091247.1481048628212--

.

I think this thread is required reading before any change to this can
be discussed:

http://softwareengineering.stackexchange.com/questions/239171/why-do-we
-put-private-member-functions-in-headers

I particularly like the rationale that Sutter gave:

http://softwareengineering.stackexchange.com/a/324450/192238

IMO any proposal for changing this would need to address the various
factors brought up in that thread.

At the very least, this would presumably require something like
modules, in order to ensure that only the person who originally
declared the class can augment it later with 'hidden private members' -
not just any passerby with a cpp file.

--
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/1481050669.2083.1.camel%40gmail.com.

.

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

On Tue, Dec 6, 2016 at 7:57 PM, Daniel Boles <db0451@gmail.com> wrote:

> IMO any proposal for changing this would need to address the various
factors brought up in that thread.

Thanks for the pointer. I'd say the only issue relevant for my proposal is
its potential to make name lookup ambiguous. But this one issue make this
proposal pretty much unacceptable. Oh well.

Cheers,
V.

--
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/CAA7YVg1393V1WUinRSLDVJ_6hqZqMQ7YvcYk5-mo_-7zgqba6Q%40mail.gmail.com.

--f403045ec2867dbcf705431400bf
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 T=
ue, Dec 6, 2016 at 7:57 PM, Daniel Boles <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:db0451@gmail.com" target=3D"_blank">db0451@gmail.com</a>&gt;</span> w=
rote:<br><div><br></div><div>&gt; IMO any proposal for changing this would =
need to address the various factors brought up in that thread.</div><div><b=
r></div><div>Thanks for the pointer. I&#39;d say the only issue relevant fo=
r my proposal is its potential to make name lookup ambiguous. But this one =
issue make this proposal pretty much unacceptable. Oh well.</div><div><br><=
/div><div>Cheers,</div><div>V.</div><div><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/CAA7YVg1393V1WUinRSLDVJ_6hqZqMQ7YvcYk=
5-mo_-7zgqba6Q%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg1393V1WUin=
RSLDVJ_6hqZqMQ7YvcYk5-mo_-7zgqba6Q%40mail.gmail.com</a>.<br />

--f403045ec2867dbcf705431400bf--

.

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

I don't see why such functions could not have a special lookup rule, or a s=
pecial naming restriction. Possibilties:



1. A hidden private function must not have the same name as any other membe=
r function.

2. A hidden private function is only part of the overload set when the call=
 site is in another member function of the same class, and its declaration =
has been seen (as if it had been a global function).

It may be required to state clearly again that this proposal does not offer=
 any way to break the private protection as these new functions are only ca=
llable from other member functions. So while anyone can write one you'd hav=
e to change the source code of a non-private member function. If you can do=
 that, well, then you don't need a hidden private function to access the pr=
ivate data members...

--=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/8885f6fd-5501-45cc-bd89-9e156b758f8d%40isocpp.or=
g.

------=_Part_41_931159240.1481170023914--

.

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

I don't see why such functions could not have a special lookup rule, or a s=
pecial naming restriction. Possibilties:



1. A hidden private function must not have the same name as any other membe=
r function.

2. A hidden private function is only part of the overload set when the call=
 site is in another member function of the same class, and its declaration =
has been seen (as if it had been a global function).

It may be required to state clearly again that this proposal does not offer=
 any way to break the private protection as these new functions are only ca=
llable from other member functions. So while anyone can write one you'd hav=
e to change the source code of a non-private member function. If you can do=
 that, well, then you don't need a hidden private function to access the pr=
ivate data members...

--=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/4d7a6831-31cb-4778-a1ba-a280470e4cf2%40isocpp.or=
g.

------=_Part_33_1360704611.1481170022804--

.

This is a multi-part message in MIME format.
--------------4FB5BA3E641CDC8B398C7FE4
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Le 08/12/2016 =C3=A0 05:07, Bengt Gustafsson a =C3=A9crit :
> I don't see why such functions could not have a special lookup rule, or a=
 special naming restriction. Possibilties:
>
>
>
> 1. A hidden private function must not have the same name as any other mem=
ber function.
>
> 2. A hidden private function is only part of the overload set when the ca=
ll site is in another member function of the same class, and its declaratio=
n has been seen (as if it had been a global function).
>
> It may be required to state clearly again that this proposal does not off=
er any way to break the private protection as these new functions are only =
callable from other member functions. So while anyone can write one you'd h=
ave to change the source code of a non-private member function. If you can =
do that, well, then you don't need a hidden private function to access the =
private data members...
>
Hi,

Wondering if modules shouldn't solve the problem?

If it is not the case, I'm not sure we need some syntactic sugar, given=20
we have the suggested and well known private friend class idiom.

In the following example we have in comments what can be done now and=20
with a // ** one possibility for the syntactical sugar version could be.

It uses a variation of the suggested private friend class idiom in this=20
thread

// header file
struct A
{
     void B();
     void C();
private:
     int p;
     //struct implementation;
     // friend implementation;
     implementation; // **
}

I believe it is worth saying that we want to have an implementation, but=20
this could be implicit

// implementation file

//struct A::implementation
implementation struct A // **
{
// A* that;
//implementation(A* a) : that(a) {}
void Q(int x)
{
     // that->x;
     p =3D x; // **
}
void R(int x)
{
     Q(x-1); // note that here we don't use that->, as the function is=20
in the implementation friend
}

};

void A::B()
{
     //implementation(this)->Q(1);
     implementation->Q(1); // **
}

The last use of implementation is needed to ensure that we are not=20
overloading the A public functions with the private implementation=20
functions.
As notice already, an implementation function couldn't be called using=20
the same syntax than a visible function.

Of course the syntax I'm describing here is just one that makes evident=20
the idiom.

I believe the private friend class idiom doesn't introduce too much=20
noise to change the language.


Vicente

--=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/821c085c-bcb1-6a6c-b84c-57136a1761f1%40wanadoo.f=
r.

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

<html>
  <head>
    <meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div class=3D"moz-cite-prefix">Le 08/12/2016 =C3=A0 05:07, Bengt Gustaf=
sson
      a =C3=A9crit=C2=A0:<br>
    </div>
    <blockquote
      cite=3D"mid:4d7a6831-31cb-4778-a1ba-a280470e4cf2@isocpp.org"
      type=3D"cite">
      <pre wrap=3D"">I don't see why such functions could not have a specia=
l lookup rule, or a special naming restriction. Possibilties:



1. A hidden private function must not have the same name as any other membe=
r function.

2. A hidden private function is only part of the overload set when the call=
 site is in another member function of the same class, and its declaration =
has been seen (as if it had been a global function).

It may be required to state clearly again that this proposal does not offer=
 any way to break the private protection as these new functions are only ca=
llable from other member functions. So while anyone can write one you'd hav=
e to change the source code of a non-private member function. If you can do=
 that, well, then you don't need a hidden private function to access the pr=
ivate data members...

</pre>
    </blockquote>
    <p><font size=3D"+1">Hi,</font></p>
    <p><font size=3D"+1">Wondering if modules shouldn't solve the problem?<=
/font></p>
    <p><font size=3D"+1">If it is not the case, I'm not sure we need some
        syntactic sugar, given we have the suggested and well known
        private friend class idiom.<br>
      </font></p>
    <p>In the following example we have in comments what can be done now
      and with a // ** one possibility for the syntactical sugar version
      could be.</p>
    <p>It uses a variation of the suggested <font size=3D"+1">private
        friend class idiom in this thread<br>
      </font></p>
    <div>// header file</div>
    <div>struct A</div>
    <div>{</div>
    <div>=C2=A0 =C2=A0 void B();</div>
    <div>=C2=A0 =C2=A0 void C();<br>
    </div>
    <div>private:</div>
    <div>=C2=A0 =C2=A0 int p;<br>
      =C2=A0=C2=A0=C2=A0 //struct implementation;<br>
      =C2=A0=C2=A0=C2=A0 // friend implementation;<br>
      =C2=A0=C2=A0=C2=A0 implementation; // ** <br>
    </div>
    <div>}<br>
      <br>
      I believe it is worth saying that we want to have an
      implementation, but this could be implicit<br>
      <br>
    </div>
    <div>// implementation file<br>
      <br>
      <div>//struct A::implementation</div>
      implementation struct A // **
      <div>{<br>
        // A* that; =C2=A0=C2=A0 <br>
        //implementation(A* a) : that(a) {}<br>
      </div>
      <div>void Q(int x)</div>
      <div>{<br>
        =C2=A0=C2=A0=C2=A0 // that-&gt;x;<br>
      </div>
      <div>=C2=A0 =C2=A0 p =3D x; // **</div>
      <div>}</div>
      <div>void R(int x)</div>
      <div>{<br>
        =C2=A0 =C2=A0 Q(x-1); // note that here we don't use that-&gt;, as =
the
        function is in the implementation friend<br>
      </div>
      <div>}</div>
      <br>
      };<br>
      <br>
      <div>void A::B()</div>
      <div>{</div>
      <div>=C2=A0 =C2=A0 //implementation(this)-&gt;Q(1);</div>
      <div>=C2=A0 =C2=A0 implementation-&gt;Q(1); // **</div>
      }=C2=A0<br>
      <br>
      The last use of implementation is needed to ensure that we are not
      overloading the A public functions with the private implementation
      functions. <br>
      As notice already, an implementation function couldn't be called
      using the same syntax than a visible function.<br>
      <br>
      Of course the syntax I'm describing here is just one that makes
      evident the idiom.<br>
      <br>
      I believe the private friend class idiom doesn't introduce too
      much noise to change the language.<br>
      <br>
      <br>
      Vicente<br>
    </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/821c085c-bcb1-6a6c-b84c-57136a1761f1%=
40wanadoo.fr?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/821c085c-bcb1-6a6c-b84c-57136a1761f1=
%40wanadoo.fr</a>.<br />

--------------4FB5BA3E641CDC8B398C7FE4--

.

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

On Thu, Dec 8, 2016 at 5:07 AM, Bengt Gustafsson <
bengt.gustafsson@beamways.com> wrote:

> 1. A hidden private function must not have the same name as any other
member function.

Unfortunately, we will also need to ensure that its name is different from
any other function in all the accessible global and namespace scopes,
including those that are introduced *after* the hidden private function in
a given translation unit. And there is no way to force a particular name
resolution should the programmer want to.

> 2. A hidden private function is only part of the overload set when the
call site is in another member function of the same class, and its
declaration has been seen (as if it had been a global function).

I do not think how this changes anything. It is the other member functions
where we need name lookup to be unambiguous, because non-members cannot
access private functions anyway. So restricting overload resolution to just
member functions achieves nothing. Perhaps I misunderstood what you said.

But your response got me thinking, and I have a modified proposal.

The hidden private members shall only be resolvable via a specially
qualified name: private::name, where private is the keyword and name is the
name of a hidden private member. They are otherwise not part of the name
lookup process.

Thus, hidden private members are only accessible to members and friends,
and only when those explicitly want to use them.

Cheers,
V.

--
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/CAA7YVg3n1qYbyn4Nk4ti_XTcKnTW7Orq7EbpKq7G60XR_QsDWw%40mail.gmail.com.

--94eb2c0793246aeae6054327d65c
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 T=
hu, Dec 8, 2016 at 5:07 AM, Bengt Gustafsson <span dir=3D"ltr">&lt;<a href=
=3D"mailto:bengt.gustafsson@beamways.com" target=3D"_blank">bengt.gustafsso=
n@beamways.com</a><wbr>&gt;</span> wrote:<br><div><br></div><div>&gt; 1. A =
hidden private function must not have the same name as any other member fun=
ction.</div><div><br></div><div>Unfortunately, we will also need to ensure =
that its name is different from any other function in all the accessible gl=
obal and namespace scopes, including those that are introduced <i>after</i>=
=C2=A0the hidden private function in a given translation unit. And there is=
 no way to force a particular name resolution should the programmer want to=
..</div><div><br></div><div>&gt; 2. A hidden private function is only part o=
f the overload set when the call site is in another member function of the =
same class, and its declaration has been seen (as if it had been a global f=
unction).</div><div><br></div><div>I do not think how this changes anything=
.. It is the other member functions where we need name lookup to be unambigu=
ous, because non-members cannot access private functions anyway. So restric=
ting overload resolution to just member functions achieves nothing. Perhaps=
 I misunderstood what you said.</div><div><br></div><div>But your response =
got me thinking, and I have a modified proposal.</div><div><br></div><div>T=
he hidden private members shall only be resolvable via a specially qualifie=
d name: private::name, where private is the keyword and name is the name of=
 a hidden private member. They are otherwise not part of the name lookup pr=
ocess.</div><div><br></div><div>Thus, hidden private members are only acces=
sible to members and friends, and only when those explicitly want to use th=
em.</div><div><br></div><div>Cheers,</div><div>V.</div><div><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/CAA7YVg3n1qYbyn4Nk4ti_XTcKnTW7Orq7Ebp=
Kq7G60XR_QsDWw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg3n1qYbyn4N=
k4ti_XTcKnTW7Orq7EbpKq7G60XR_QsDWw%40mail.gmail.com</a>.<br />

--94eb2c0793246aeae6054327d65c--

.

------=_Part_708_338403727.1481327598018
Content-Type: multipart/alternative;
 boundary="----=_Part_709_1196013455.1481327598018"

------=_Part_709_1196013455.1481327598018
Content-Type: text/plain; charset=UTF-8


>
>
> > 1. A hidden private function must not have the same name as any other
> member function.
>
> Unfortunately, we will also need to ensure that its name is different from
> any other function in all the accessible global and namespace scopes,
> including those that are introduced *after* the hidden private function
> in a given translation unit. And there is no way to force a particular name
> resolution should the programmer want to.
>
While I don't really prefer the (1) solution I don't see why your
restrictions would be necessary. A method in a class hides global functions
of the same name, so whether or not there are other functions with the same
name is irrelevant as these hidden private member functions can only be
called from within other member functions of the same class (hidden or not).


>
> > 2. A hidden private function is only part of the overload set when the
> call site is in another member function of the same class, and its
> declaration has been seen (as if it had been a global function).
>
> I do not think how this changes anything. It is the other member functions
> where we need name lookup to be unambiguous, because non-members cannot
> access private functions anyway. So restricting overload resolution to just
> member functions achieves nothing. Perhaps I misunderstood what you said.
>
Ok. The original concern was that as private member functions *are* part of
the overload set when called from outside the class (causing a protection
violation if selected) private member functions can not be tucked away in a
cpp file. What I am trying to say is that if we exclude hidden private
member functions from the overload set when called from the outside it
doesn't matter that they are in a cpp file somewhere. However, to ever be
able to call them, they must of course be *included *in the overload set
when called from another member function of the same class. Furthermore, I
think that it is more logical to only let them participate in overload
resolution *after* their declaration in the same way that global functions
are.


> But your response got me thinking, and I have a modified proposal.
>
> The hidden private members shall only be resolvable via a specially
> qualified name: private::name, where private is the keyword and name is the
> name of a hidden private member. They are otherwise not part of the name
> lookup process.
>
I think you are overestimating the problem here: The case that there is
overloading *at all* between hidden and non-hidden member functions is
going to be rare. And as these functions are very private such problems can
easily be solved by changing the name of the hidden private method. To add
a requirement to prefix the call site adds unneccessary noise.

Vicente complained about not being able to explicitly select a hidden or
non-hidden method by some scoping mechanism. I think this is no worse than
the fact that you can't select between two overloaded functions in general
without casting the parameters. A hidden member function and a non-hidden
member function are both member functions of the same class according to
the original proposal and my overload-set related rule. Vicente's own
example is very hard to follow but it seems to NOT think of the hidden
private member functions as part of the same scope, which makes the feature
much closer to the current work around (which seems to be the point he
wants to prove).


>
> Thus, hidden private members are only accessible to members and friends,
> and only when those explicitly want to use them.
>
I don't see the point or logic in the "explicitly want to use them" part.
Isn't this implicit by ordering  the declarations so that the hidden
private method declaration preceeds the calling method?

[ subtopic: Should it be allowed to forward declare private hidden methods:
My reply is yes - this is parallel to free function declarations, and
required to allow them to be mutually recursive. ]


> Cheers,
> V.
>
>

--
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/abec89fb-2754-4ba2-b75b-8caa6abd0b48%40isocpp.org.

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

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div><div class=3D"gmail_quote"><div><br></div><div>&gt; 1. A hidden pr=
ivate function must not have the same name as any other member function.</d=
iv><div><br></div><div>Unfortunately, we will also need to ensure that its =
name is different from any other function in all the accessible global and =
namespace scopes, including those that are introduced <i>after</i>=C2=A0the=
 hidden private function in a given translation unit. And there is no way t=
o force a particular name resolution should the programmer want to.</div></=
div></div></div></blockquote><div>While I don&#39;t really prefer the (1) s=
olution I don&#39;t see why your restrictions would be necessary. A method =
in a class hides global functions of the same name, so whether or not there=
 are other functions with the same name is irrelevant as these hidden priva=
te member functions can only be called from within other member functions o=
f the same class (hidden or not).</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"><div><div class=3D"gmail_quote=
"><div><br></div><div>&gt; 2. A hidden private function is only part of the=
 overload set when the call site is in another member function of the same =
class, and its declaration has been seen (as if it had been a global functi=
on).</div><div><br></div><div>I do not think how this changes anything. It =
is the other member functions where we need name lookup to be unambiguous, =
because non-members cannot access private functions anyway. So restricting =
overload resolution to just member functions achieves nothing. Perhaps I mi=
sunderstood what you said.</div></div></div></div></blockquote><div>Ok. The=
 original concern was that as private member functions <i>are</i> part of t=
he overload set when called from outside the class (causing a protection vi=
olation if selected) private member functions can not be tucked away in a c=
pp file. What I am trying to say is that if we exclude hidden private membe=
r functions from the overload set when called from the outside it doesn&#39=
;t matter that they are in a cpp file somewhere. However, to ever be able t=
o call them, they must of course be <i>included </i>in the overload set whe=
n called from another member function of the same class. Furthermore, I thi=
nk that it is more logical to only let them participate in overload resolut=
ion <i>after</i>=C2=A0their declaration in the same way that global functio=
ns are.</div><div><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><div class=3D"gmail_quote"><div><br></div><div>But your=
 response got me thinking, and I have a modified proposal.</div><div><br></=
div><div>The hidden private members shall only be resolvable via a speciall=
y qualified name: private::name, where private is the keyword and name is t=
he name of a hidden private member. They are otherwise not part of the name=
 lookup process.</div></div></div></div></blockquote><div>I think you are o=
verestimating the problem here: The case that there is overloading <i>at al=
l</i>=C2=A0between hidden and non-hidden member functions is going to be ra=
re. And as these functions are very private such problems can easily be sol=
ved by changing the name of the hidden private method. To add a requirement=
 to prefix the call site adds unneccessary noise.</div><div><br></div><div>=
Vicente complained about not being able to explicitly select a hidden or no=
n-hidden method by some scoping mechanism. I think this is no worse than th=
e fact that you can&#39;t select between two overloaded functions in genera=
l without casting the parameters. A hidden member function and a non-hidden=
 member function are both member functions of the same class according to t=
he original proposal and my overload-set related rule. Vicente&#39;s own ex=
ample is very hard to follow but it seems to NOT think of the hidden privat=
e member functions as part of the same scope, which makes the feature much =
closer to the current work around (which seems to be the point he wants to =
prove).</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">=
<div dir=3D"ltr"><div><div class=3D"gmail_quote"><div><br></div><div>Thus, =
hidden private members are only accessible to members and friends, and only=
 when those explicitly want to use them.</div></div></div></div></blockquot=
e><div>I don&#39;t see the point or logic in the &quot;explicitly want to u=
se them&quot; part. Isn&#39;t this implicit by ordering =C2=A0the declarati=
ons so that the hidden private method declaration preceeds the calling meth=
od?</div><div><br></div><div>[ subtopic: Should it be allowed to forward de=
clare private hidden methods: My reply is yes - this is parallel to free fu=
nction declarations, and required to allow them to be mutually recursive. ]=
</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div><div class=3D"gmail_quote"><div><br></div><div>Cheers,</div><=
div>V.</div><div><br></div></div></div></div>
</blockquote></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/abec89fb-2754-4ba2-b75b-8caa6abd0b48%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/abec89fb-2754-4ba2-b75b-8caa6abd0b48=
%40isocpp.org</a>.<br />

------=_Part_709_1196013455.1481327598018--

------=_Part_708_338403727.1481327598018--

.

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

On Sat, Dec 10, 2016 at 12:53 AM, Bengt Gustafsson <
bengt.gustafsson@beamways.com> wrote:

> While I don't really prefer the (1) solution I don't see why your
restrictions would be necessary. A method in a class hides global functions
of the same name, so whether or not there are other functions with the same
name is irrelevant as these hidden private member functions can only be
called from within other member functions of the same class (hidden or not).


> Ok. The original concern was that as private member functions *are* part
of the overload set when called from outside the class (causing a
protection violation if selected) private member functions can not be
tucked away in a cpp file. What I am trying to say is that if we exclude
hidden private member functions from the overload set when called from the
outside it doesn't matter that they are in a cpp file somewhere. However,
to ever be able to call them, they must of course be *included *in the
overload set when called from another member function of the same class.
Furthermore, I think that it is more logical to only let them participate
in overload resolution *after* their declaration in the same way that
global functions are.

I may still be misinterpreting you.

My concern is *not* that the hidden private members can be defined in a
rogue cpp file and somehow break encapsulation. As I stated in the original
message, they are only callable by members (and friends), so that's not a
concern at all. I have *not* tried to address that again in follow-up
messages.

What I did try to address is the situation when one translation unit
defines hidden private members, while another does *not*; moreover, let's
postulate that when they are defined they hide some global functions, or
they overload some other members. Then the lookup for those names (unless
modified per my second proposal) will work differently between those two
TUs, potentially breaking the program silently.

Different name lookup, while possible for non-member function even today,
is *not* possible for member functions. The latter is a strong and useful
guarantee afforded by member functions, breaking it would be very bad.
Worse still, this can even break currently valid code, which knows nothing
about hidden private members. I'm pretty sure this cannot ever pass through
the committee.

Note also that hidden member functions could, in principle, be *injected* by
a rogue include file, even though I believe it is far more likely to happen
through error rather than malice.

Which is why I think that the opt-in through private:: is necessary. Yes,
this makes things a little more verbose than I would have liked; but this
is balanced by *not* having to decorate "implementation details" in some
other way, which is frequently the case in the real-world code.

Cheers,
V.

--
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/CAA7YVg1TgGLPA%2B_9ytK12%2BJ9FRoAj6eTEdCuJu_rPZU924EhPQ%40mail.gmail.com.

--001a113fbe0e421b610543761ec9
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 S=
at, Dec 10, 2016 at 12:53 AM, Bengt Gustafsson <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:bengt.gustafsson@beamways.com" target=3D"_blank">bengt.gustafss=
on@beamways.com</a>&gt;</span> wrote:</div><div class=3D"gmail_quote"><br><=
/div><div class=3D"gmail_quote">&gt; While I don&#39;t really prefer the (1=
) solution I don&#39;t see why your restrictions would be necessary. A meth=
od in a class hides global functions of the same name, so whether or not th=
ere are other functions with the same name is irrelevant as these hidden pr=
ivate member functions can only be called from within other member function=
s of the same class (hidden or not).</div><div class=3D"gmail_quote"><br></=
div><div class=3D"gmail_quote"><div><br></div><div>&gt; Ok. The original co=
ncern was that as private member functions <i>are</i> part of the overload =
set when called from outside the class (causing a protection violation if s=
elected) private member functions can not be tucked away in a cpp file. Wha=
t I am trying to say is that if we exclude hidden private member functions =
from the overload set when called from the outside it doesn&#39;t matter th=
at they are in a cpp file somewhere. However, to ever be able to call them,=
 they must of course be <i>included </i>in the overload set when called fro=
m another member function of the same class. Furthermore, I think that it i=
s more logical to only let them participate in overload resolution <i>after=
</i>=C2=A0their declaration in the same way that global functions are.</div=
><div><br></div><div>I may still be misinterpreting you.</div><div><br></di=
v><div>My concern is <i>not</i> that the hidden private members can be defi=
ned in a rogue cpp file and somehow break encapsulation. As I stated in the=
 original message, they are only callable by members (and friends), so that=
&#39;s not a concern at all. I have <i>not</i> tried to address that again =
in follow-up messages.</div><div><br></div><div>What I did try to address i=
s the situation when one translation unit defines hidden private members, w=
hile another does <i>not</i>; moreover, let&#39;s postulate that when they =
are defined they hide some global functions, or they overload some other me=
mbers. Then the lookup for those names (unless modified per my second propo=
sal) will work differently between those two TUs, potentially breaking the =
program silently.</div><div><br></div><div>Different name lookup, while pos=
sible for non-member function even today, is <i>not</i>=C2=A0possible for m=
ember functions. The latter is a strong and useful guarantee afforded by me=
mber functions, breaking it would be very bad. Worse still, this can even b=
reak currently valid code, which knows nothing about hidden private members=
.. I&#39;m pretty sure this cannot ever pass through the committee.</div><di=
v><br></div><div>Note also that hidden member functions could, in principle=
, be <i>injected</i>=C2=A0by a rogue include file, even though I believe it=
 is far more likely to happen through error rather than malice.</div><div><=
br></div><div>Which is why I think that the opt-in through private:: is nec=
essary. Yes, this makes things a little more verbose than I would have like=
d; but this is balanced by <i>not</i>=C2=A0having to decorate &quot;impleme=
ntation details&quot; in some other way, which is frequently the case in th=
e real-world code.</div><div><br></div><div>Cheers,</div><div>V.</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/CAA7YVg1TgGLPA%2B_9ytK12%2BJ9FRoAj6eT=
EdCuJu_rPZU924EhPQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg1TgGLP=
A%2B_9ytK12%2BJ9FRoAj6eTEdCuJu_rPZU924EhPQ%40mail.gmail.com</a>.<br />

--001a113fbe0e421b610543761ec9--

.

------=_Part_93_2132052188.1481791036464
Content-Type: multipart/alternative;
 boundary="----=_Part_94_1854659254.1481791036465"

------=_Part_94_1854659254.1481791036465
Content-Type: text/plain; charset=UTF-8


>
>
> My concern is *not* that the hidden private members can be defined in a
> rogue cpp file and somehow break encapsulation. As I stated in the original
> message, they are only callable by members (and friends), so that's not a
> concern at all. I have *not* tried to address that again in follow-up
> messages.
>
Sure.

>
> What I did try to address is the situation when one translation unit
> defines hidden private members, while another does *not*; moreover, let's
> postulate that when they are defined they hide some global functions, or
> they overload some other members. Then the lookup for those names (unless
> modified per my second proposal) will work differently between those two
> TUs, potentially breaking the program silently.
>
For this to happen you must subdivide implementation of methods in the same
class into different TUs which is very uncommon. I think you are chasing
very unlikely cases and in the process make your own proposal harder to
use.


> Different name lookup, while possible for non-member function even today,
> is *not* possible for member functions. The latter is a strong and useful
> guarantee afforded by member functions, breaking it would be very bad.
> Worse still, this can even break currently valid code, which knows nothing
> about hidden private members. I'm pretty sure this cannot ever pass through
> the committee.
>
I don't understand this statement, or I find it contradictory. My
suggestion avoids the breakage of currently valid code by stating that the
hidden private membder functions are not partaking in overload resolution
unless their declarations have been seen. Thus having them can't break any
(client) code that hasn't seen them.

The entire aim of the proposal is to allow hiding helper methods in the cpp
file implementing the class's regular methods. Now you seem to worry about
what would happen if you put hidden member functions between the class head
and the client using the class. But as the client is not one of the member
functions of the class it doesn't see hidden member functions even if they
are wtritten (for mysterious reasons) in a header file read by the client
code. This includes if the client is a subclass of the class having the
hidden private method, as these methods are private, not protected.

This rule allows hidden private methods to be used to implement common
functionality between inlined methods (when written below the class head)
without disrupting the rule that client code can rely on the class head to
contain "all you need to know about the class".


>
> Note also that hidden member functions could, in principle, be *injected* by
> a rogue include file, even though I believe it is far more likely to happen
> through error rather than malice.
>
> How? Ok, if you tamper with the header file and then recompile the cpp
file implementing the class methods. But in this case you obviously have
access to the cpp file so if you want to tamper it is much easier to just
change the code.

There is no way to protect against reaching in to the private data members
for instance, given that you take the liberty to change the header file. If
you don't change the header file I don't see how rouge code could be
injected except in the rare case that the original implementer opted to
implement inline methods in a totally separate header file than the class
head, which is very impractical and hence uncommon. As you can always
change the header file to do what you want C++ can never protect from
malificent usage of classes you have the header file for.



> Which is why I think that the opt-in through private:: is necessary. Yes,
> this makes things a little more verbose than I would have liked; but this
> is balanced by *not* having to decorate "implementation details" in some
> other way, which is frequently the case in the real-world code.
>
I think you are being bizarrely cautious here. Obviously an implementor
would not use hidden private methods if s/he doesn't know how they work. If
you know how they work you probably start out by not selecting the same
name as a regular member function (which makes the rest of the debate moot)
but if you do select the same name that's probably because you want the
overloading to take place. I think it would be hard to find a use case for
this, but of course there is a slight risk of inadvertent overloading, but
there are so many error sources on this level already, I don't see how this
is any worse. I also find the rule that "when the declaration of a hidden
private method is parsed it is added to the overload set for its name when
called from member functions of the same class" is logical and easy to
understand and implement.


>
>

--
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/fe917515-c750-46f7-b8b7-cb4ecfaaaa93%40isocpp.org.

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

<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div class=3D=
"gmail_quote"><div><br></div><div>My concern is <i>not</i> that the hidden =
private members can be defined in a rogue cpp file and somehow break encaps=
ulation. As I stated in the original message, they are only callable by mem=
bers (and friends), so that&#39;s not a concern at all. I have <i>not</i> t=
ried to address that again in follow-up messages.</div></div></div></blockq=
uote><div>Sure.=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 class=3D"gmail_quote"><div><br></div><div>What I did try=
 to address is the situation when one translation unit defines hidden priva=
te members, while another does <i>not</i>; moreover, let&#39;s postulate th=
at when they are defined they hide some global functions, or they overload =
some other members. Then the lookup for those names (unless modified per my=
 second proposal) will work differently between those two TUs, potentially =
breaking the program silently.</div></div></div></blockquote><div>For this =
to happen you must subdivide implementation of methods in the same class in=
to different TUs which is very uncommon. I think you are chasing very unlik=
ely cases and in the process make your own proposal harder to use. =C2=A0</=
div><div><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 class=3D"gmail_quote"><div><br></div><div>Different name lookup,=
 while possible for non-member function even today, is <i>not</i>=C2=A0poss=
ible for member functions. The latter is a strong and useful guarantee affo=
rded by member functions, breaking it would be very bad. Worse still, this =
can even break currently valid code, which knows nothing about hidden priva=
te members. I&#39;m pretty sure this cannot ever pass through the committee=
..</div></div></div></blockquote><div>I don&#39;t understand this statement,=
 or I find it contradictory. My suggestion avoids the breakage of currently=
 valid code by stating that the hidden private membder functions are not pa=
rtaking in overload resolution unless their declarations have been seen. Th=
us having them can&#39;t break any (client) code that hasn&#39;t seen them.=
</div><div><br></div><div>The entire aim of the proposal is to allow hiding=
 helper methods in the cpp file implementing the class&#39;s regular method=
s. Now you seem to worry about what would happen if you put hidden member f=
unctions between the class head and the client using the class. But as the =
client is not one of the member functions of the class it doesn&#39;t see h=
idden member functions even if they are wtritten (for mysterious reasons) i=
n a header file read by the client code. This includes if the client is a s=
ubclass of the class having the hidden private method, as these methods are=
 private, not protected.</div><div><br></div><div>This rule allows hidden p=
rivate methods to be used to implement common functionality between inlined=
 methods (when written below the class head) without disrupting the rule th=
at client code can rely on the class head to contain &quot;all you need to =
know about the class&quot;.</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 class=3D"gmail_quote"><div><br></=
div><div>Note also that hidden member functions could, in principle, be <i>=
injected</i>=C2=A0by a rogue include file, even though I believe it is far =
more likely to happen through error rather than malice.</div><div><br></div=
></div></div></blockquote><div>How? Ok, if you tamper with the header file =
and then recompile the cpp file implementing the class methods. But in this=
 case you obviously have access to the cpp file so if you want to tamper it=
 is much easier to just change the code.</div><div><br></div><div>There is =
no way to protect against reaching in to the private data members for insta=
nce, given that you take the liberty to change the header file. If you don&=
#39;t change the header file I don&#39;t see how rouge code could be inject=
ed except in the rare case that the original implementer opted to implement=
 inline methods in a totally separate header file than the class head, whic=
h is very impractical and hence uncommon. As you can always change the head=
er file to do what you want C++ can never protect from malificent usage of =
classes you have the header file for.</div><div><br></div><div>=C2=A0</div>=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div class=3D=
"gmail_quote"><div></div><div>Which is why I think that the opt-in through =
private:: is necessary. Yes, this makes things a little more verbose than I=
 would have liked; but this is balanced by <i>not</i>=C2=A0having to decora=
te &quot;implementation details&quot; in some other way, which is frequentl=
y the case in the real-world code.</div></div></div></blockquote><div>I thi=
nk you are being bizarrely cautious here. Obviously an implementor would no=
t use hidden private methods if s/he doesn&#39;t know how they work. If you=
 know how they work you probably start out by not selecting the same name a=
s a regular member function (which makes the rest of the debate moot) but i=
f you do select the same name that&#39;s probably because you want the over=
loading to take place. I think it would be hard to find a use case for this=
, but of course there is a slight risk of inadvertent overloading, but ther=
e are so many error sources on this level already, I don&#39;t see how this=
 is any worse. I also find the rule that &quot;when the declaration of a hi=
dden private method is parsed it is added to the overload set for its name =
when called from member functions of the same class&quot; is logical and ea=
sy to understand and implement.</div><div>=C2=A0</div><blockquote class=3D"=
gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc so=
lid;padding-left: 1ex;"><div dir=3D"ltr"><div class=3D"gmail_quote"><br></d=
iv></div>
</blockquote>

<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/fe917515-c750-46f7-b8b7-cb4ecfaaaa93%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/fe917515-c750-46f7-b8b7-cb4ecfaaaa93=
%40isocpp.org</a>.<br />

------=_Part_94_1854659254.1481791036465--

------=_Part_93_2132052188.1481791036464--

.