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

C++ has three access levels for members of class types:

    public
    private
    protected

We propose a forth access level:

    namespace

Members with namespace access level are accessible by classes and functions
in the same namespace:

namespace N {

    class X {
      namespace:
        static void f();
    };

    class Y {
      Y() {
        X::f(); // OK
      }
    };

    void g() {
       X::f(); // OK
    }

}  // namespace N

namespace M {

    class Z {
      Z() {
        N::X::f(); // ERROR
      }
    };

    void h() {
       N::X::f(); // ERROR
    }

}  // namespace M

Many times a library of related classes and functions are grouped together
in a common namespace, and many times there are members that are desired to
be exposed to each other (library internal) but not to the outside world.

--

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

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

<div dir=3D"ltr">C++ has three access levels for members of class types:<di=
v><br></div><div>=C2=A0 =C2=A0 public</div><div>=C2=A0 =C2=A0 private</div>=
<div>=C2=A0 =C2=A0 protected</div><div><br></div><div>We propose a forth ac=
cess level:</div><div><br></div><div>=C2=A0 =C2=A0 namespace</div><div><br>=
</div><div>Members with namespace access level are accessible by classes an=
d functions in the same namespace:</div><div><br></div><div>namespace N {</=
div><div><br></div><div>=C2=A0 =C2=A0 class X {</div><div>=C2=A0 =C2=A0 =C2=
=A0 namespace:</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 static void f();</div>=
<div>=C2=A0 =C2=A0 };</div><div><br></div><div>=C2=A0 =C2=A0 class Y {</div=
><div>=C2=A0 =C2=A0 =C2=A0 Y() {</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 X::f=
(); // OK</div><div>=C2=A0 =C2=A0 =C2=A0 }<br></div><div>=C2=A0 =C2=A0 };</=
div><div><br></div><div>=C2=A0 =C2=A0 void g() {</div><div>=C2=A0 =C2=A0 =
=C2=A0 =C2=A0X::f(); // OK</div><div>=C2=A0 =C2=A0 }</div><div><br></div><d=
iv>} =C2=A0// namespace N</div><div><br></div><div>namespace M {</div><div>=
<br></div><div><div>=C2=A0 =C2=A0 class Z {</div><div>=C2=A0 =C2=A0 =C2=A0 =
Z() {</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 N::X::f(); // ERROR</div><div>=
=C2=A0 =C2=A0 =C2=A0 }<br></div><div>=C2=A0 =C2=A0 };</div><div><br></div><=
div>=C2=A0 =C2=A0 void h() {</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0N::X::f()=
; // ERROR</div><div>=C2=A0 =C2=A0 }</div></div><div><br></div><div>} =C2=
=A0// namespace M</div><div><br></div><div>Many times a library of related =
classes and functions are grouped together in a common namespace, and many =
times there are members that are desired to be exposed to each other (libra=
ry internal) but not to the outside world.</div><div><br></div></div>

<p></p>

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

--089e0103f058b6a25b0523a9b67d--

.

On Tue, Nov 03, 2015 at 10:38:25PM +0100, Andrew Tomazos wrote:
> C++ has three access levels for members of class types:
>
>     public
>     private
>     protected
>
> We propose a forth access level:
>
>     namespace
>
> Members with namespace access level are accessible by classes and functions
> in the same namespace:

How would it interact with inline namespaces?

> Many times a library of related classes and functions are grouped together
> in a common namespace, and many times there are members that are desired to
> be exposed to each other (library internal) but not to the outside world.

This is obviously more open than protected, especially given that one always
could reopen a namespace but if the idea is to protect against mistakes and
not malice then this might be a nice feature.

/MF

--

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

.

------=_Part_1333_1953466097.1446595730802
Content-Type: multipart/alternative;
 boundary="----=_Part_1334_788990452.1446595730802"

------=_Part_1334_788990452.1446595730802
Content-Type: text/plain; charset=UTF-8

Or we could just get modules, which allows isolation of "related classes
and functions".

--

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

------=_Part_1334_788990452.1446595730802
Content-Type: text/html; charset=UTF-8

<div dir="ltr">Or we could just get modules, which allows isolation of &quot;related classes and functions&quot;.<br></div>

<p></p>

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

------=_Part_1334_788990452.1446595730802--
------=_Part_1333_1953466097.1446595730802--

.

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

On Tue, Nov 3, 2015 at 4:08 PM, Nicol Bolas <jmckesson@gmail.com> wrote:

> Or we could just get modules, which allows isolation of "related classes
> and functions".
>

+1

That namespaces are open makes namespace access level questionable to me
(I'm personally not even a fan of protected). Modules are more likely to
provide a proper solution to this problem, and until then, there is the
workaround (though one that leaves a lot to be desired) of making a "friend
struct" and declaring types/templates/functions there, bringing them out
with using or forwarding. I don't really like that hack, but I do think
waiting for modules is best.

--

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

--001a113685e28020c00523abfcda
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, Nov 3, 2015 at 4:08 PM, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</sp=
an> 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">Or we could j=
ust get modules, which allows isolation of &quot;related classes and functi=
ons&quot;.</div></blockquote><div><br></div><div>+1</div><div><br></div><di=
v>That namespaces are open makes namespace access level questionable to me =
(I&#39;m personally not even a fan of protected). Modules are more likely t=
o provide a proper solution to this problem, and until then, there is the w=
orkaround (though one that leaves a lot to be desired) of making a &quot;fr=
iend struct&quot; and declaring types/templates/functions there, bringing t=
hem out with using or forwarding. I don&#39;t really like that hack, but I =
do think waiting for modules is best.</div></div></div></div>

<p></p>

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

--001a113685e28020c00523abfcda--

.

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

Use-cases exist for protected. Not that many, granted, but we do need it.

For namespace:, I'm not convinced; anyone could join in, so it looks like
free lunch to me. Maybe there's a convincing argument?

2015-11-03 19:21 GMT-05:00 'Matt Calabrese' via ISO C++ Standard - Future
Proposals <std-proposals@isocpp.org>:

> On Tue, Nov 3, 2015 at 4:08 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
>
>> Or we could just get modules, which allows isolation of "related classes
>> and functions".
>>
>
> +1
>
> That namespaces are open makes namespace access level questionable to me
> (I'm personally not even a fan of protected). Modules are more likely to
> provide a proper solution to this problem, and until then, there is the
> workaround (though one that leaves a lot to be desired) of making a "friend
> struct" and declaring types/templates/functions there, bringing them out
> with using or forwarding. I don't really like that hack, but I do think
> waiting for modules is best.
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

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

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

<div dir=3D"ltr"><div>Use-cases exist for protected. Not that many, granted=
, but we do need it.<br><br></div>For namespace:, I&#39;m not convinced; an=
yone could join in, so it looks like free lunch to me. Maybe there&#39;s a =
convincing argument?<br></div><div class=3D"gmail_extra"><br><div class=3D"=
gmail_quote">2015-11-03 19:21 GMT-05:00 &#39;Matt Calabrese&#39; via ISO C+=
+ Standard - Future Proposals <span dir=3D"ltr">&lt;<a href=3D"mailto:std-p=
roposals@isocpp.org" target=3D"_blank">std-proposals@isocpp.org</a>&gt;</sp=
an>:<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"><div class=3D"gmail=
_extra"><div class=3D"gmail_quote"><span class=3D"">On Tue, Nov 3, 2015 at =
4:08 PM, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"mailto:jmckesson@gmai=
l.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</span> wrote:<br><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc=
c solid;padding-left:1ex"><div dir=3D"ltr">Or we could just get modules, wh=
ich allows isolation of &quot;related classes and functions&quot;.</div></b=
lockquote><div><br></div></span><div>+1</div><div><br></div><div>That names=
paces are open makes namespace access level questionable to me (I&#39;m per=
sonally not even a fan of protected). Modules are more likely to provide a =
proper solution to this problem, and until then, there is the workaround (t=
hough one that leaves a lot to be desired) of making a &quot;friend struct&=
quot; and declaring types/templates/functions there, bringing them out with=
 using or forwarding. I don&#39;t really like that hack, but I do think wai=
ting for modules is best.</div></div></div></div><div class=3D"HOEnZb"><div=
 class=3D"h5">

<p></p>

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

<p></p>

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

--001a11c3db70a38edb0523b04c0a--

.

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

On Wed, Nov 4, 2015 at 1:08 AM, Nicol Bolas <jmckesson@gmail.com> wrote:

> Or we could just get modules, which allows isolation of "related classes
> and functions".
>
> Oops, *facepalm* I completely forgot that modules are going to solve all
the worlds problems. *cheeky grin*

But seriously, it's not the same thing.  The proposal doesn't isolate
entire classes and functions to namespace scope (a "private" section for
namespaces).  The proposal isolates certain class members to namespace
scope (a "namespace-access" section for classes).  The classes continue to
have public interfaces.

The former is unrelated to the later.  The former is for creating a private
section of namespaces.  The later is for exposing class members within a
namespace, rather than the whole world.

This is similar to protected, but rather than restricting access based on
the inheritance hierarchy, we are restricting access based on the namespace
hierarchy.

Yes, you can open and place entities in the namespace just to break in.
This is the same as subclassing a class just to break in to its protected
members.  It is also the same as placing "#define private public" before a
#include.  Access protection is an advisory lock, it protects against
negligence not malevolence.

--

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

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Nov 4, 2015 at 1:08 AM, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</sp=
an> 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">Or we could j=
ust get modules, which allows isolation of &quot;related classes and functi=
ons&quot;.<br></div><div class=3D"HOEnZb"><div class=3D"h5">

<p></p></div></div></blockquote></div>Oops, *facepalm* I completely forgot =
that modules are going to solve all the worlds problems. *cheeky grin*</div=
><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">But seriou=
sly, it&#39;s not the same thing.=C2=A0 The proposal doesn&#39;t isolate en=
tire classes and functions to namespace scope (a &quot;private&quot; sectio=
n for namespaces).=C2=A0 The proposal isolates certain class members to nam=
espace scope (a &quot;namespace-access&quot; section for classes).=C2=A0 Th=
e classes continue to have public interfaces.</div><div class=3D"gmail_extr=
a"><br></div><div class=3D"gmail_extra">The former is unrelated to the late=
r.=C2=A0 The former is for creating a private section of namespaces.=C2=A0 =
The later is for exposing class members within a namespace, rather than the=
 whole world.</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail=
_extra">This is similar to protected, but rather than restricting access ba=
sed on the inheritance hierarchy, we are restricting access based on the na=
mespace hierarchy.</div><div class=3D"gmail_extra"><br></div><div class=3D"=
gmail_extra">Yes, you can open and place entities in the namespace just to =
break in.=C2=A0 This is the same as subclassing a class just to break in to=
 its protected members.=C2=A0 It is also the same as placing &quot;#define =
private public&quot; before a #include.=C2=A0 Access protection is an advis=
ory lock, it protects against negligence not malevolence.</div><div class=
=3D"gmail_extra"><br></div></div>

<p></p>

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

--001a114449380af7f10523b3dcb4--

.

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

On 4 November 2015 at 03:44, Andrew Tomazos <andrewtomazos@gmail.com> wrote:

>
> Yes, you can open and place entities in the namespace just to break in.
> This is the same as subclassing a class just to break in to its protected
> members.
>

I don't understand why you are calling that "break in", given that is the
entire point of of protected visibility.  Inheritance has a closed, finite
set of things it can look at in the base classes.


>   It is also the same as placing "#define private public" before a
> #include.
>

You are saying it is the same as writing code that is forbidden by the
standard??  See [macro.names] for more details.

It is problematic to go from a closed set of things to an open set of
things.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--

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

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

<div dir=3D"ltr">On 4 November 2015 at 03:44, Andrew Tomazos <span dir=3D"l=
tr">&lt;<a href=3D"mailto:andrewtomazos@gmail.com" target=3D"_blank">andrew=
tomazos@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div =
class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div =
class=3D"gmail_extra"><span class=3D""><div class=3D"gmail_quote"><br></div=
></span></div><div class=3D"gmail_extra">Yes, you can open and place entiti=
es in the namespace just to break in.=C2=A0 This is the same as subclassing=
 a class just to break in to its protected members.</div></div></blockquote=
><div><br></div><div>I don&#39;t understand why you are calling that &quot;=
break in&quot;, given that is the entire point of of protected visibility.=
=C2=A0 Inheritance has a closed, finite set of things it can look at in the=
 base classes.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div di=
r=3D"ltr"><div class=3D"gmail_extra">=C2=A0 It is also the same as placing =
&quot;#define private public&quot; before a #include.</div></div></blockquo=
te><div><br></div><div>You are saying it is the same as writing code that i=
s forbidden by the standard??=C2=A0 See [macro.names] for more details.</di=
v><div><br></div><div>It is problematic to go from a closed set of things t=
o an open set of things.</div></div>-- <br><div class=3D"gmail_signature">=
=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 (8=
47) 691-1404</div>
</div></div>

<p></p>

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

--001a1143f92e02f78c0523b99bf4--

.

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

On Wed, Nov 4, 2015 at 5:35 PM, Nevin Liber <nevin@eviloverlord.com> wrote:

> On 4 November 2015 at 03:44, Andrew Tomazos <andrewtomazos@gmail.com>
> wrote:
>
>>
>> Yes, you can open and place entities in the namespace just to break in.
>> This is the same as subclassing a class just to break in to its protected
>> members.
>>
>
> I don't understand why you are calling that "break in", given that is the
> entire point of of protected visibility.  Inheritance has a closed, finite
> set of things it can look at in the base classes.
>

What I mean is that you can always create another derived class to obtain
access to protected members from a new place, in much the same way as you
can add another class to a namespace to obtain access to namespace-access
members from a new place.

  It is also the same as placing "#define private public" before a #include.
>>
>
> You are saying it is the same as writing code that is forbidden by the
> standard??  See [macro.names] for more details.
>

Sure, that's different, fine.


> It is problematic to go from a closed set of things to an open set of
> things.
>

I'm not sure if I understand you correctly - but it sounds like you are
saying that protected visibility is "closed" where as the proposed
namespace visibility is "open".

They are both "closed" in the sense that the set of members of a class that
have that visibility level cannot be added to once the class definition is
complete.

They are both "open" in the sense that both (a) the set of derived classes;
and (b) the set of entities in the same namespace; can be added to at any
time from any translation unit.

--

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

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Nov 4, 2015 at 5:35 PM, Nevin Liber <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&g=
t;</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"><span c=
lass=3D"">On 4 November 2015 at 03:44, Andrew Tomazos <span dir=3D"ltr">&lt=
;<a href=3D"mailto:andrewtomazos@gmail.com" target=3D"_blank">andrewtomazos=
@gmail.com</a>&gt;</span> wrote:<br></span><div class=3D"gmail_extra"><div =
class=3D"gmail_quote"><span class=3D""><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div =
dir=3D"ltr"><div class=3D"gmail_extra"><span><div class=3D"gmail_quote"><br=
></div></span></div><div class=3D"gmail_extra">Yes, you can open and place =
entities in the namespace just to break in.=C2=A0 This is the same as subcl=
assing a class just to break in to its protected members.</div></div></bloc=
kquote><div><br></div></span><div>I don&#39;t understand why you are callin=
g that &quot;break in&quot;, given that is the entire point of of protected=
 visibility.=C2=A0 Inheritance has a closed, finite set of things it can lo=
ok at in the base classes.</div></div></div></div></blockquote><div><br></d=
iv><div>What I mean is that you can always create another derived class to =
obtain access to protected members from a new place, in much the same way a=
s you can add another class to a namespace to obtain access to namespace-ac=
cess members from a new place.</div><div><br></div><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quot=
e"><span class=3D""><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 cl=
ass=3D"gmail_extra">=C2=A0 It is also the same as placing &quot;#define pri=
vate public&quot; before a #include.</div></div></blockquote><div><br></div=
></span><div>You are saying it is the same as writing code that is forbidde=
n by the standard??=C2=A0 See [macro.names] for more details.</div></div></=
div></div></blockquote><div><br></div><div>Sure, that&#39;s different, fine=
..</div><div>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"=
><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div></div><div>It i=
s problematic to go from a closed set of things to an open set of things.</=
div></div></div></div></blockquote><div>=C2=A0</div></div>I&#39;m not sure =
if I understand you correctly - but it sounds like you are saying that prot=
ected visibility is &quot;closed&quot; where as the proposed namespace visi=
bility is &quot;open&quot;.</div><div class=3D"gmail_extra"><br></div><div =
class=3D"gmail_extra">They are both &quot;closed&quot; in the sense that th=
e set of members of a class that have that visibility level cannot be added=
 to once the class definition is complete.</div><div class=3D"gmail_extra">=
<br></div><div class=3D"gmail_extra">They are both &quot;open&quot; in the =
sense that both (a) the set of derived classes; and (b) the set of entities=
 in the same namespace; can be added to at any time from any translation un=
it.</div><div class=3D"gmail_extra"><br></div></div>

<p></p>

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

--001a114425b46ee2a90523ba2cda--

.

------=_Part_32_700438127.1446667085008
Content-Type: multipart/alternative;
 boundary="----=_Part_33_83061737.1446667085008"

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

Le mercredi 4 novembre 2015 18:16:41 UTC+1, Andrew Tomazos a =C3=A9crit :
>
> On Wed, Nov 4, 2015 at 5:35 PM, Nevin Liber <ne...@eviloverlord.com=20
> <javascript:>> wrote:
>
>> On 4 November 2015 at 03:44, Andrew Tomazos <andrew...@gmail.com=20
>> <javascript:>> wrote:
>>
>>>
>>> Yes, you can open and place entities in the namespace just to break in.=
 =20
>>> This is the same as subclassing a class just to break in to its protect=
ed=20
>>> members.
>>>
>>
>> I don't understand why you are calling that "break in", given that is th=
e=20
>> entire point of of protected visibility.  Inheritance has a closed, fini=
te=20
>> set of things it can look at in the base classes.
>>
>
> What I mean is that you can always create another derived class to obtain=
=20
> access to protected members from a new place, in much the same way as you=
=20
> can add another class to a namespace to obtain access to namespace-access=
=20
> members from a new place.
>
>
I though that you could only access the protected members of your class and=
=20
their descendants, not of your siblings or of your parent.  That restrict=
=20
most possibilities of abuse.

--=20
Jean-Marc

--=20

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

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

Le mercredi 4 novembre 2015 18:16:41 UTC+1, Andrew Tomazos a =C3=A9crit=C2=
=A0:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div=
 class=3D"gmail_quote">On Wed, Nov 4, 2015 at 5:35 PM, Nevin Liber <span di=
r=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mail=
to=3D"bxKi8BIUFQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javasc=
ript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;retur=
n true;">ne...@eviloverlord.com</a>&gt;</span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr"><span>On 4 November 2015 at 03:44, Andrew To=
mazos <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-o=
bfuscated-mailto=3D"bxKi8BIUFQAJ" rel=3D"nofollow" onmousedown=3D"this.href=
=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascri=
pt:&#39;;return true;">andrew...@gmail.com</a>&gt;</span> wrote:<br></span>=
<div><div class=3D"gmail_quote"><span><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div d=
ir=3D"ltr"><div><span><div class=3D"gmail_quote"><br></div></span></div><di=
v>Yes, you can open and place entities in the namespace just to break in.=
=C2=A0 This is the same as subclassing a class just to break in to its prot=
ected members.</div></div></blockquote><div><br></div></span><div>I don&#39=
;t understand why you are calling that &quot;break in&quot;, given that is =
the entire point of of protected visibility.=C2=A0 Inheritance has a closed=
, finite set of things it can look at in the base classes.</div></div></div=
></div></blockquote><div><br></div><div>What I mean is that you can always =
create another derived class to obtain access to protected members from a n=
ew place, in much the same way as you can add another class to a namespace =
to obtain access to namespace-access members from a new place.</div></div><=
/div><br></div></blockquote><div><br>I though that you could only access th=
e protected members of your class and their descendants, not of your siblin=
gs or of your parent.=C2=A0 That restrict most possibilities of abuse.<br><=
br>-- <br>Jean-Marc<br></div>

<p></p>

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

------=_Part_33_83061737.1446667085008--
------=_Part_32_700438127.1446667085008--

.

------=_Part_107_695417103.1446667602765
Content-Type: multipart/alternative;
 boundary="----=_Part_108_1235351808.1446667602765"

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

On Wednesday, November 4, 2015 at 2:58:05 PM UTC-5, Jean-Marc Bourguet=20
wrote:
>
> Le mercredi 4 novembre 2015 18:16:41 UTC+1, Andrew Tomazos a =C3=A9crit :
>>
>> On Wed, Nov 4, 2015 at 5:35 PM, Nevin Liber <ne...@eviloverlord.com>=20
>> wrote:
>>
>>> On 4 November 2015 at 03:44, Andrew Tomazos <andrew...@gmail.com> wrote=
:
>>>
>>>>
>>>> Yes, you can open and place entities in the namespace just to break=20
>>>> in.  This is the same as subclassing a class just to break in to its=
=20
>>>> protected members.
>>>>
>>>
>>> I don't understand why you are calling that "break in", given that is=
=20
>>> the entire point of of protected visibility.  Inheritance has a closed,=
=20
>>> finite set of things it can look at in the base classes.
>>>
>>
>> What I mean is that you can always create another derived class to obtai=
n=20
>> access to protected members from a new place, in much the same way as yo=
u=20
>> can add another class to a namespace to obtain access to namespace-acces=
s=20
>> members from a new place.
>>
>>
> I though that you could only access the protected members of your class=
=20
> and their descendants, not of your siblings or of your parent.  That=20
> restrict most possibilities of abuse.
>

If you derive from a class, you have access to the public and protected=20
members of that class. That's what protected is for: to provide an=20
interface to a derived class that only derived classes can access.

--=20

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

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

On Wednesday, November 4, 2015 at 2:58:05 PM UTC-5, Jean-Marc Bourguet wrot=
e:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;">Le mercredi 4 novembre 2015 =
18:16:41 UTC+1, Andrew Tomazos a =C3=A9crit=C2=A0:<blockquote class=3D"gmai=
l_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;pad=
ding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote">On Wed, Nov=
 4, 2015 at 5:35 PM, Nevin Liber <span dir=3D"ltr">&lt;<a rel=3D"nofollow">=
ne...@eviloverlord.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:1=
ex"><div dir=3D"ltr"><span>On 4 November 2015 at 03:44, Andrew Tomazos <spa=
n dir=3D"ltr">&lt;<a rel=3D"nofollow">andrew...@gmail.com</a>&gt;</span> wr=
ote:<br></span><div><div class=3D"gmail_quote"><span><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><span><div class=3D"gmail_quote"><br></div><=
/span></div><div>Yes, you can open and place entities in the namespace just=
 to break in.=C2=A0 This is the same as subclassing a class just to break i=
n to its protected members.</div></div></blockquote><div><br></div></span><=
div>I don&#39;t understand why you are calling that &quot;break in&quot;, g=
iven that is the entire point of of protected visibility.=C2=A0 Inheritance=
 has a closed, finite set of things it can look at in the base classes.</di=
v></div></div></div></blockquote><div><br></div><div>What I mean is that yo=
u can always create another derived class to obtain access to protected mem=
bers from a new place, in much the same way as you can add another class to=
 a namespace to obtain access to namespace-access members from a new place.=
</div></div></div><br></div></blockquote><div><br>I though that you could o=
nly access the protected members of your class and their descendants, not o=
f your siblings or of your parent.=C2=A0 That restrict most possibilities o=
f abuse.<br></div></blockquote><div><br>If you derive from a class, you hav=
e access to the public and protected members of that class. That&#39;s what=
 protected is for: to provide an interface to a derived class that only der=
ived classes can access.<br></div>

<p></p>

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

------=_Part_108_1235351808.1446667602765--
------=_Part_107_695417103.1446667602765--

.

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

On Wed, Nov 4, 2015 at 9:06 PM, Nicol Bolas <jmckesson@gmail.com> wrote:

> On Wednesday, November 4, 2015 at 2:58:05 PM UTC-5, Jean-Marc Bourguet
> wrote:
>>
>> Le mercredi 4 novembre 2015 18:16:41 UTC+1, Andrew Tomazos a =C3=A9crit =
:
>>>
>>> On Wed, Nov 4, 2015 at 5:35 PM, Nevin Liber <ne...@eviloverlord.com>
>>> wrote:
>>>
>>>> On 4 November 2015 at 03:44, Andrew Tomazos <andrew...@gmail.com>
>>>> wrote:
>>>>
>>>>>
>>>>> Yes, you can open and place entities in the namespace just to break
>>>>> in.  This is the same as subclassing a class just to break in to its
>>>>> protected members.
>>>>>
>>>>
>>>> I don't understand why you are calling that "break in", given that is
>>>> the entire point of of protected visibility.  Inheritance has a closed=
,
>>>> finite set of things it can look at in the base classes.
>>>>
>>>
>>> What I mean is that you can always create another derived class to
>>> obtain access to protected members from a new place, in much the same w=
ay
>>> as you can add another class to a namespace to obtain access to
>>> namespace-access members from a new place.
>>>
>>>
>> I though that you could only access the protected members of your class
>> and their descendants, not of your siblings or of your parent.  That
>> restrict most possibilities of abuse.
>>
>
> If you derive from a class, you have access to the public and protected
> members of that class. That's what protected is for: to provide an
> interface to a derived class that only derived classes can access.
>
> Right.  If I have a class with a protected member:

  struct X {
   protected:
    static void f();
  };

I can access it from whereever like so:

  int main() {
    struct Y : X { Y() { X::f(); } } y;
  }

Likewise for the proposed namespace-access.  If I have a class with a
namespace-access member:

  namespace N {
    struct X {
     namespace:
      static void f();
    }
  }

I can access it from whereever like so:

  namespace N { void call_f() { f(); } }

  int main() { N::call_f(); }

Regardless of whether you want to call this "open", "closed" or "breaking
in" - the point is that it is the same thing.

--=20

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

--089e0103f05836a69c0523bcb606
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 Wed, Nov 4, 2015 at 9:06 PM, Nicol Bolas <span dir=3D"ltr">&lt;<a hr=
ef=3D"mailto: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);bor=
der-left-style:solid;padding-left:1ex"><span class=3D"">On Wednesday, Novem=
ber 4, 2015 at 2:58:05 PM UTC-5, Jean-Marc Bourguet wrote:<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">=
Le mercredi 4 novembre 2015 18:16:41 UTC+1, Andrew Tomazos a =C3=A9crit=C2=
=A0:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor=
der-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:sol=
id;padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote">On We=
d, Nov 4, 2015 at 5:35 PM, Nevin Liber <span dir=3D"ltr">&lt;<a rel=3D"nofo=
llow">ne...@eviloverlord.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"><span>On 4 November 2015 at 03:44, Andrew Tomazos <span dir=3D=
"ltr">&lt;<a rel=3D"nofollow">andrew...@gmail.com</a>&gt;</span> wrote:<br>=
</span><div><div class=3D"gmail_quote"><span><blockquote class=3D"gmail_quo=
te" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-col=
or:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"l=
tr"><div><span><div class=3D"gmail_quote"><br></div></span></div><div>Yes, =
you can open and place entities in the namespace just to break in.=C2=A0 Th=
is is the same as subclassing a class just to break in to its protected mem=
bers.</div></div></blockquote><div><br></div></span><div>I don&#39;t unders=
tand why you are calling that &quot;break in&quot;, given that is the entir=
e point of of protected visibility.=C2=A0 Inheritance has a closed, finite =
set of things it can look at in the base classes.</div></div></div></div></=
blockquote><div><br></div><div>What I mean is that you can always create an=
other derived class to obtain access to protected members from a new place,=
 in much the same way as you can add another class to a namespace to obtain=
 access to namespace-access members from a new place.</div></div></div><br>=
</div></blockquote><div><br>I though that you could only access the protect=
ed members of your class and their descendants, not of your siblings or of =
your parent.=C2=A0 That restrict most possibilities of abuse.<br></div></bl=
ockquote></span><div><br>If you derive from a class, you have access to the=
 public and protected members of that class. That&#39;s what protected is f=
or: to provide an interface to a derived class that only derived classes ca=
n access.<br></div><div class=3D""><div class=3D"h5">

<p></p></div></div></blockquote></div>Right.=C2=A0 If I have a class with a=
 protected member:</div><div class=3D"gmail_extra"><br></div><div class=3D"=
gmail_extra"><div class=3D"gmail_extra">=C2=A0 struct X {</div><div class=
=3D"gmail_extra">=C2=A0 =C2=A0protected:</div><div class=3D"gmail_extra">=
=C2=A0 =C2=A0 static void f();</div><div class=3D"gmail_extra">=C2=A0 };</d=
iv><div><br></div><div>I can access it from whereever like so:</div><div><b=
r></div><div><div>=C2=A0 int main() {</div><div>=C2=A0 =C2=A0 struct Y : X =
{ Y() { X::f(); } } y;</div><div>=C2=A0 }</div></div></div><div class=3D"gm=
ail_extra"><br></div><div class=3D"gmail_extra">Likewise for the proposed n=
amespace-access.=C2=A0 If I have a class with a namespace-access member:</d=
iv><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">=C2=A0 n=
amespace N {</div><div class=3D"gmail_extra">=C2=A0 =C2=A0 struct X {</div>=
<div class=3D"gmail_extra">=C2=A0 =C2=A0 =C2=A0namespace:</div><div class=
=3D"gmail_extra">=C2=A0 =C2=A0 =C2=A0 static void f();</div><div class=3D"g=
mail_extra">=C2=A0 =C2=A0 }</div><div class=3D"gmail_extra">=C2=A0 }</div><=
div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">I can access=
 it from whereever like so:</div><div class=3D"gmail_extra"><br></div><div =
class=3D"gmail_extra">=C2=A0 namespace N { void call_f() { f(); } }</div><d=
iv class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">=C2=A0 int ma=
in() { N::call_f(); }</div><div class=3D"gmail_extra"><br></div><div class=
=3D"gmail_extra">Regardless of whether you want to call this &quot;open&quo=
t;, &quot;closed&quot; or &quot;breaking in&quot; - the point is that it is=
 the same thing.</div><div class=3D"gmail_extra"><br></div></div>

<p></p>

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

--089e0103f05836a69c0523bcb606--

.

--Apple-Mail-B850C21B-13F4-4D24-AC3A-0DBF19CAE569
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

If someone passes me an object of type 'T', I cannot access its private par=
ts.  I can construct on object of a derived class this I control that takes=
 that object in its constructor, but I will always be working on a (potenti=
ally moved) copy of that original object.

If I have a namespace access level, I can always perfectly forward that obj=
ect to my own function defined in that namespace, and use the namespace lev=
el functions directly on that object.

The ability to directly manipulate objects is the benefit/problem with the =
proposal, and is the key difference from protected.

Sent from my iPhone

> On Nov 4, 2015, at 3:18 PM, Andrew Tomazos <andrewtomazos@gmail.com> wrot=
e:
>=20
>=20
>=20
>> On Wed, Nov 4, 2015 at 9:06 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
>>> On Wednesday, November 4, 2015 at 2:58:05 PM UTC-5, Jean-Marc Bourguet =
wrote:
>>> Le mercredi 4 novembre 2015 18:16:41 UTC+1, Andrew Tomazos a =C3=A9crit=
 :
>>>>=20
>>>>> On Wed, Nov 4, 2015 at 5:35 PM, Nevin Liber <ne...@eviloverlord.com> =
wrote:
>>>>>> On 4 November 2015 at 03:44, Andrew Tomazos <andrew...@gmail.com> wr=
ote:
>>>>>=20
>>>>>>=20
>>>>>> Yes, you can open and place entities in the namespace just to break =
in.  This is the same as subclassing a class just to break in to its protec=
ted members.
>>>>>=20
>>>>> I don't understand why you are calling that "break in", given that is=
 the entire point of of protected visibility.  Inheritance has a closed, fi=
nite set of things it can look at in the base classes.
>>>>=20
>>>> What I mean is that you can always create another derived class to obt=
ain access to protected members from a new place, in much the same way as y=
ou can add another class to a namespace to obtain access to namespace-acces=
s members from a new place.
>>>=20
>>> I though that you could only access the protected members of your class=
 and their descendants, not of your siblings or of your parent.  That restr=
ict most possibilities of abuse.
>>=20
>>=20
>> If you derive from a class, you have access to the public and protected =
members of that class. That's what protected is for: to provide an interfac=
e to a derived class that only derived classes can access.
> Right.  If I have a class with a protected member:
>=20
>   struct X {
>    protected:
>     static void f();
>   };
>=20
> I can access it from whereever like so:
>=20
>   int main() {
>     struct Y : X { Y() { X::f(); } } y;
>   }
>=20
> Likewise for the proposed namespace-access.  If I have a class with a nam=
espace-access member:
>=20
>   namespace N {
>     struct X {
>      namespace:
>       static void f();
>     }
>   }
>=20
> I can access it from whereever like so:
>=20
>   namespace N { void call_f() { f(); } }
>=20
>   int main() { N::call_f(); }
>=20
> Regardless of whether you want to call this "open", "closed" or "breaking=
 in" - the point is that it is the same thing.
>=20
> --=20
>=20
> ---=20
> You received this message because you are subscribed to the Google Groups=
 "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an=
 email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at http://groups.google.com/a/isocpp.org/group/std-propo=
sals/.

--=20

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

--Apple-Mail-B850C21B-13F4-4D24-AC3A-0DBF19CAE569
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=
=3Dutf-8"></head><body dir=3D"auto"><div>If someone passes me an object of =
type 'T', I cannot access its private parts. &nbsp;I can construct on objec=
t of a derived class this I control that takes that object in its construct=
or, but I will always be working on a (potentially moved) copy of that orig=
inal object.</div><div id=3D"AppleMailSignature"><br></div><div id=3D"Apple=
MailSignature">If I have a namespace access level, I can always perfectly f=
orward that object to my own function defined in that namespace, and use th=
e namespace level functions directly on that object.</div><div id=3D"AppleM=
ailSignature"><br></div><div id=3D"AppleMailSignature">The ability to direc=
tly manipulate objects is the benefit/problem with the proposal, and is the=
 key difference from protected.<br><br>Sent from my iPhone</div><div><br>On=
 Nov 4, 2015, at 3:18 PM, Andrew Tomazos &lt;<a href=3D"mailto:andrewtomazo=
s@gmail.com">andrewtomazos@gmail.com</a>&gt; wrote:<br><br></div><blockquot=
e type=3D"cite"><div><div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><d=
iv class=3D"gmail_quote">On Wed, Nov 4, 2015 at 9:06 PM, Nicol Bolas <span =
dir=3D"ltr">&lt;<a href=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jm=
ckesson@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"><span class=3D"=
">On Wednesday, November 4, 2015 at 2:58:05 PM UTC-5, Jean-Marc Bourguet wr=
ote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor=
der-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:sol=
id;padding-left:1ex">Le mercredi 4 novembre 2015 18:16:41 UTC+1, Andrew Tom=
azos a =C3=A9crit&nbsp;:<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 dir=3D"ltr"><div><div class=
=3D"gmail_quote">On Wed, Nov 4, 2015 at 5:35 PM, Nevin Liber <span dir=3D"l=
tr">&lt;<a rel=3D"nofollow">ne...@eviloverlord.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"><span>On 4 November 2015 at 03:44, Andre=
w Tomazos <span dir=3D"ltr">&lt;<a rel=3D"nofollow">andrew...@gmail.com</a>=
&gt;</span> wrote:<br></span><div><div class=3D"gmail_quote"><span><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><span><div class=3D"gmail_quote"><br></div><=
/span></div><div>Yes, you can open and place entities in the namespace just=
 to break in.&nbsp; This is the same as subclassing a class just to break i=
n to its protected members.</div></div></blockquote><div><br></div></span><=
div>I don't understand why you are calling that "break in", given that is t=
he entire point of of protected visibility.&nbsp; Inheritance has a closed,=
 finite set of things it can look at in the base classes.</div></div></div>=
</div></blockquote><div><br></div><div>What I mean is that you can always c=
reate another derived class to obtain access to protected members from a ne=
w place, in much the same way as you can add another class to a namespace t=
o obtain access to namespace-access members from a new place.</div></div></=
div><br></div></blockquote><div><br>I though that you could only access the=
 protected members of your class and their descendants, not of your sibling=
s or of your parent.&nbsp; That restrict most possibilities of abuse.<br></=
div></blockquote></span><div><br>If you derive from a class, you have acces=
s to the public and protected members of that class. That's what protected =
is for: to provide an interface to a derived class that only derived classe=
s can access.<br></div><div class=3D""><div class=3D"h5">

<p></p></div></div></blockquote></div>Right.&nbsp; If I have a class with a=
 protected member:</div><div class=3D"gmail_extra"><br></div><div class=3D"=
gmail_extra"><div class=3D"gmail_extra">&nbsp; struct X {</div><div class=
=3D"gmail_extra">&nbsp; &nbsp;protected:</div><div class=3D"gmail_extra">&n=
bsp; &nbsp; static void f();</div><div class=3D"gmail_extra">&nbsp; };</div=
><div><br></div><div>I can access it from whereever like so:</div><div><br>=
</div><div><div>&nbsp; int main() {</div><div>&nbsp; &nbsp; struct Y : X { =
Y() { X::f(); } } y;</div><div>&nbsp; }</div></div></div><div class=3D"gmai=
l_extra"><br></div><div class=3D"gmail_extra">Likewise for the proposed nam=
espace-access.&nbsp; If I have a class with a namespace-access member:</div=
><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">&nbsp; nam=
espace N {</div><div class=3D"gmail_extra">&nbsp; &nbsp; struct X {</div><d=
iv class=3D"gmail_extra">&nbsp; &nbsp; &nbsp;namespace:</div><div class=3D"=
gmail_extra">&nbsp; &nbsp; &nbsp; static void f();</div><div class=3D"gmail=
_extra">&nbsp; &nbsp; }</div><div class=3D"gmail_extra">&nbsp; }</div><div =
class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">I can access it =
from whereever like so:</div><div class=3D"gmail_extra"><br></div><div clas=
s=3D"gmail_extra">&nbsp; namespace N { void call_f() { f(); } }</div><div c=
lass=3D"gmail_extra"><br></div><div class=3D"gmail_extra">&nbsp; int main()=
 { N::call_f(); }</div><div class=3D"gmail_extra"><br></div><div class=3D"g=
mail_extra">Regardless of whether you want to call this "open", "closed" or=
 "breaking in" - the point is that it is the same thing.</div><div class=3D=
"gmail_extra"><br></div></div>

<p></p>

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

<p></p>

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

--Apple-Mail-B850C21B-13F4-4D24-AC3A-0DBF19CAE569--

.

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

On Wed, Nov 4, 2015 at 11:03 PM, Alisdair Meredith <alisdairm@icloud.com>
wrote:

> If someone passes me an object of type 'T', I cannot access its private
> parts.  I can construct on object of a derived class this I control that
> takes that object in its constructor, but I will always be working on a
> (potentially moved) copy of that original object.
>

Sure, for protected non-static data members you can't obtain a direct
reference to that subobject given an object of the base class.

So for example this doesn't work:

struct X {
 protected:
  int i;
};

void f(X& x) {
  struct Y : X {
    static int& i(X& x) { return x.i; } // ERROR X::i is protected
  };
  int& i =3D Y::i(x);

  int j =3D i; // read
  i =3D 42; // write
}

Ok.  I'll grant that namespace-access is more "open" than protected in this
sense.

If I have a namespace access level, I can always perfectly forward that
> object to my own function defined in that namespace, and use the namespac=
e
> level functions directly on that object.


I'm not convinced it should be a deal-breaker on this proposal.  Many
codebases (particularly large ones that have many namespaces) have rules
about where you can open namespaces, usually in correspondence to the
source file system.  If those rules are enforced then namespace-access
restricts what part of the codebase you have to edit to gain access, in
much the same way as accessing private members requires editing the class
definition.

The ability to directly manipulate objects is the benefit/problem with the
> proposal, and is the key difference from protected.
>
> Sent from my iPhone
>
> On Nov 4, 2015, at 3:18 PM, Andrew Tomazos <andrewtomazos@gmail.com>
> wrote:
>
>
>
> On Wed, Nov 4, 2015 at 9:06 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
>
>> On Wednesday, November 4, 2015 at 2:58:05 PM UTC-5, Jean-Marc Bourguet
>> wrote:
>>>
>>> Le mercredi 4 novembre 2015 18:16:41 UTC+1, Andrew Tomazos a =C3=A9crit=
 :
>>>>
>>>> On Wed, Nov 4, 2015 at 5:35 PM, Nevin Liber <ne...@eviloverlord.com>
>>>> wrote:
>>>>
>>>>> On 4 November 2015 at 03:44, Andrew Tomazos <andrew...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>> Yes, you can open and place entities in the namespace just to break
>>>>>> in.  This is the same as subclassing a class just to break in to its
>>>>>> protected members.
>>>>>>
>>>>>
>>>>> I don't understand why you are calling that "break in", given that is
>>>>> the entire point of of protected visibility.  Inheritance has a close=
d,
>>>>> finite set of things it can look at in the base classes.
>>>>>
>>>>
>>>> What I mean is that you can always create another derived class to
>>>> obtain access to protected members from a new place, in much the same =
way
>>>> as you can add another class to a namespace to obtain access to
>>>> namespace-access members from a new place.
>>>>
>>>>
>>> I though that you could only access the protected members of your class
>>> and their descendants, not of your siblings or of your parent.  That
>>> restrict most possibilities of abuse.
>>>
>>
>> If you derive from a class, you have access to the public and protected
>> members of that class. That's what protected is for: to provide an
>> interface to a derived class that only derived classes can access.
>>
>> Right.  If I have a class with a protected member:
>
>   struct X {
>    protected:
>     static void f();
>   };
>
> I can access it from whereever like so:
>
>   int main() {
>     struct Y : X { Y() { X::f(); } } y;
>   }
>
> Likewise for the proposed namespace-access.  If I have a class with a
> namespace-access member:
>
>   namespace N {
>     struct X {
>      namespace:
>       static void f();
>     }
>   }
>
> I can access it from whereever like so:
>
>   namespace N { void call_f() { f(); } }
>
>   int main() { N::call_f(); }
>
> Regardless of whether you want to call this "open", "closed" or "breaking
> in" - the point is that it is the same thing.
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--=20

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

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Nov 4, 2015 at 11:03 PM, Alisdair Meredith <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:alisdairm@icloud.com" target=3D"_blank">alisdairm@icloud.com</a=
>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);bo=
rder-left-style:solid;padding-left:1ex"><div dir=3D"auto"><div>If someone p=
asses me an object of type &#39;T&#39;, I cannot access its private parts.=
=C2=A0 I can construct on object of a derived class this I control that tak=
es that object in its constructor, but I will always be working on a (poten=
tially moved) copy of that original object.</div></div></blockquote><div>=
=C2=A0</div><div>Sure, for protected non-static data members you can&#39;t =
obtain a direct reference to that subobject given an object of the base cla=
ss.</div><div><br></div><div>So for example this doesn&#39;t work:</div><di=
v><br></div><div><div>struct X {</div><div>=C2=A0protected:</div><div>=C2=
=A0 int i;</div><div>};</div><div><br></div><div>void f(X&amp; x) {</div><d=
iv>=C2=A0 struct Y : X {</div><div>=C2=A0 =C2=A0 static int&amp; i(X&amp; x=
) { return x.i; } // ERROR X::i is protected</div><div>=C2=A0 };</div><div>=
=C2=A0 int&amp; i =3D Y::i(x);</div><div><br></div><div>=C2=A0 int j =3D i;=
 // read</div><div>=C2=A0 i =3D 42; // write</div><div>}</div></div><div><b=
r></div><div>Ok.=C2=A0 I&#39;ll grant that namespace-access is more &quot;o=
pen&quot; than protected in this sense.</div><div><br></div><div><blockquot=
e 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-lef=
t:1ex">If I have a namespace access level, I can always perfectly forward t=
hat object to my own function defined in that namespace, and use the namesp=
ace level functions directly on that object.</blockquote></div><div><br></d=
iv><div>I&#39;m not convinced it should be a deal-breaker on this proposal.=
=C2=A0 Many codebases (particularly large ones that have many namespaces) h=
ave rules about where you can open namespaces, usually in correspondence to=
 the source file system.=C2=A0 If those rules are enforced then namespace-a=
ccess restricts what part of the codebase you have to edit to gain access, =
in much the same way as accessing private members requires editing the clas=
s definition.</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(20=
4,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"auto"><div=
>The ability to directly manipulate objects is the benefit/problem with the=
 proposal, and is the key difference from protected.<br><br>Sent from my iP=
hone</div><div><div class=3D"h5"><div><br>On Nov 4, 2015, at 3:18 PM, Andre=
w Tomazos &lt;<a href=3D"mailto:andrewtomazos@gmail.com" target=3D"_blank">=
andrewtomazos@gmail.com</a>&gt; wrote:<br><br></div></div></div><blockquote=
 type=3D"cite"><div><div><div class=3D"h5"><div dir=3D"ltr"><br><div class=
=3D"gmail_extra"><br><div class=3D"gmail_quote">On Wed, Nov 4, 2015 at 9:06=
 PM, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"mailto:jmckesson@gmail.co=
m" target=3D"_blank">jmckesson@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"><span>On Wednesday, November 4, 2015 at 2:58:05 PM UTC-5, Jean-Marc=
 Bourguet wrote:<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">Le mercredi 4 novembre 2015 18:16:41 UTC+1=
, Andrew Tomazos a =C3=A9crit=C2=A0:<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 class=3D"gmail_quote">On Wed, Nov 4, 2015 at 5:35 PM, Nevin Liber <spa=
n dir=3D"ltr">&lt;<a rel=3D"nofollow">ne...@eviloverlord.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-st=
yle:solid;padding-left:1ex"><div dir=3D"ltr"><span>On 4 November 2015 at 03=
:44, Andrew Tomazos <span dir=3D"ltr">&lt;<a rel=3D"nofollow">andrew...@gma=
il.com</a>&gt;</span> wrote:<br></span><div><div class=3D"gmail_quote"><spa=
n><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"><div><span><div class=3D"gmail_quote"><=
br></div></span></div><div>Yes, you can open and place entities in the name=
space just to break in.=C2=A0 This is the same as subclassing a class just =
to break in to its protected members.</div></div></blockquote><div><br></di=
v></span><div>I don&#39;t understand why you are calling that &quot;break i=
n&quot;, given that is the entire point of of protected visibility.=C2=A0 I=
nheritance has a closed, finite set of things it can look at in the base cl=
asses.</div></div></div></div></blockquote><div><br></div><div>What I mean =
is that you can always create another derived class to obtain access to pro=
tected members from a new place, in much the same way as you can add anothe=
r class to a namespace to obtain access to namespace-access members from a =
new place.</div></div></div><br></div></blockquote><div><br>I though that y=
ou could only access the protected members of your class and their descenda=
nts, not of your siblings or of your parent.=C2=A0 That restrict most possi=
bilities of abuse.<br></div></blockquote></span><div><br>If you derive from=
 a class, you have access to the public and protected members of that class=
.. That&#39;s what protected is for: to provide an interface to a derived cl=
ass that only derived classes can access.<br></div><div><div>

<p></p></div></div></blockquote></div>Right.=C2=A0 If I have a class with a=
 protected member:</div><div class=3D"gmail_extra"><br></div><div class=3D"=
gmail_extra"><div class=3D"gmail_extra">=C2=A0 struct X {</div><div class=
=3D"gmail_extra">=C2=A0 =C2=A0protected:</div><div class=3D"gmail_extra">=
=C2=A0 =C2=A0 static void f();</div><div class=3D"gmail_extra">=C2=A0 };</d=
iv><div><br></div><div>I can access it from whereever like so:</div><div><b=
r></div><div><div>=C2=A0 int main() {</div><div>=C2=A0 =C2=A0 struct Y : X =
{ Y() { X::f(); } } y;</div><div>=C2=A0 }</div></div></div><div class=3D"gm=
ail_extra"><br></div><div class=3D"gmail_extra">Likewise for the proposed n=
amespace-access.=C2=A0 If I have a class with a namespace-access member:</d=
iv><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">=C2=A0 n=
amespace N {</div><div class=3D"gmail_extra">=C2=A0 =C2=A0 struct X {</div>=
<div class=3D"gmail_extra">=C2=A0 =C2=A0 =C2=A0namespace:</div><div class=
=3D"gmail_extra">=C2=A0 =C2=A0 =C2=A0 static void f();</div><div class=3D"g=
mail_extra">=C2=A0 =C2=A0 }</div><div class=3D"gmail_extra">=C2=A0 }</div><=
div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">I can access=
 it from whereever like so:</div><div class=3D"gmail_extra"><br></div><div =
class=3D"gmail_extra">=C2=A0 namespace N { void call_f() { f(); } }</div><d=
iv class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">=C2=A0 int ma=
in() { N::call_f(); }</div><div class=3D"gmail_extra"><br></div><div class=
=3D"gmail_extra">Regardless of whether you want to call this &quot;open&quo=
t;, &quot;closed&quot; or &quot;breaking in&quot; - the point is that it is=
 the same thing.</div><div class=3D"gmail_extra"><br></div></div>

<p></p></div></div><span class=3D"">

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

<p></p>

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

<p></p>

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

--047d7beb9ec42345a10523cafe56--

.

------=_Part_530_845574072.1446733696898
Content-Type: multipart/alternative;
 boundary="----=_Part_531_270052216.1446733696898"

------=_Part_531_270052216.1446733696898
Content-Type: text/plain; charset=UTF-8

On Thursday, November 5, 2015 at 8:20:40 AM UTC-5, Andrew Tomazos wrote:
>
> On Wed, Nov 4, 2015 at 11:03 PM, Alisdair Meredith <alis...@icloud.com
> <javascript:>> wrote:
>
>> If I have a namespace access level, I can always perfectly forward that
>> object to my own function defined in that namespace, and use the namespace
>> level functions directly on that object.
>
>
> I'm not convinced it should be a deal-breaker on this proposal.  Many
> codebases (particularly large ones that have many namespaces) have rules
> about where you can open namespaces, usually in correspondence to the
> source file system.  If those rules are enforced then namespace-access
> restricts what part of the codebase you have to edit to gain access, in
> much the same way as accessing private members requires editing the class
> definition.
>

If such soft rules (ie: rules not checked by the compiler) are "enforced"
in your project, then you could just as effectively enforce rules about
which objects and function can be accessed from outside of a namespace and
which ones cannot. In both cases, your compiler will not actually enforce
this rule, so in both cases, you are equally open to a user doing the wrong
thing.

Why should the compiler provide "protection" that cannot actually be
enforced (to a reasonable degree)?

Indeed, you could attach attributes to declarations in a namespace and use
static analysis to *actually* enforce them. That is, verify that you only
access those declarations from within the namespace (or vice-versa, never
access untagged declarations from outside the namespace, depending on the
semantics). None of that requires changing the language.

--

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

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

On Thursday, November 5, 2015 at 8:20:40 AM UTC-5, Andrew Tomazos wrote:<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">On Wed, Nov 4, 2015 at 11:03 PM, Alisdair Meredith <span d=
ir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mai=
lto=3D"aklPYsZVFQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javas=
cript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;retu=
rn true;">alis...@icloud.com</a>&gt;</span> wrote:<br><div></div><div><bloc=
kquote 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;paddin=
g-left:1ex">If I have a namespace access level, I can always perfectly forw=
ard that object to my own function defined in that namespace, and use the n=
amespace level functions directly on that object.</blockquote></div><div><b=
r></div><div>I&#39;m not convinced it should be a deal-breaker on this prop=
osal.=C2=A0 Many codebases (particularly large ones that have many namespac=
es) have rules about where you can open namespaces, usually in corresponden=
ce to the source file system.=C2=A0 If those rules are enforced then namesp=
ace-access restricts what part of the codebase you have to edit to gain acc=
ess, in much the same way as accessing private members requires editing the=
 class definition.</div></div></div></div></blockquote><div><br>If such sof=
t rules (ie: rules not checked by the compiler) are &quot;enforced&quot; in=
 your project, then you could just as effectively enforce rules about which=
 objects and function can be accessed from outside of a namespace and which=
 ones cannot. In both cases, your compiler will not actually enforce this r=
ule, so in both cases, you are equally open to a user doing the wrong thing=
..<br><br>Why should the compiler provide &quot;protection&quot; that cannot=
 actually be enforced (to a reasonable degree)?<br><br>Indeed, you could at=
tach attributes to declarations in a namespace and use static analysis to <=
i>actually</i> enforce them. That is, verify that you only access those dec=
larations from within the namespace (or vice-versa, never access untagged d=
eclarations from outside the namespace, depending on the semantics). None o=
f that requires changing the language.</div>

<p></p>

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

------=_Part_531_270052216.1446733696898--
------=_Part_530_845574072.1446733696898--

.

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

On Thu, Nov 5, 2015 at 3:28 PM, Nicol Bolas <jmckesson@gmail.com> wrote:

> On Thursday, November 5, 2015 at 8:20:40 AM UTC-5, Andrew Tomazos wrote:
>>
>> On Wed, Nov 4, 2015 at 11:03 PM, Alisdair Meredith <alis...@icloud.com>
>> wrote:
>>
>>> If I have a namespace access level, I can always perfectly forward that
>>> object to my own function defined in that namespace, and use the namespace
>>> level functions directly on that object.
>>
>>
>> I'm not convinced it should be a deal-breaker on this proposal.  Many
>> codebases (particularly large ones that have many namespaces) have rules
>> about where you can open namespaces, usually in correspondence to the
>> source file system.  If those rules are enforced then namespace-access
>> restricts what part of the codebase you have to edit to gain access, in
>> much the same way as accessing private members requires editing the class
>> definition.
>>
>
> If such soft rules (ie: rules not checked by the compiler) are "enforced"
> in your project, then you could just as effectively enforce rules about
> which objects and function can be accessed from outside of a namespace and
> which ones cannot. In both cases, your compiler will not actually enforce
> this rule, so in both cases, you are equally open to a user doing the wrong
> thing.
>
> Why should the compiler provide "protection" that cannot actually be
> enforced (to a reasonable degree)?
>
> Indeed, you could attach attributes to declarations in a namespace and use
> static analysis to *actually* enforce them. That is, verify that you only
> access those declarations from within the namespace (or vice-versa, never
> access untagged declarations from outside the namespace, depending on the
> semantics). None of that requires changing the language.
>
> I think we've been distracted from the fact that it is the person that
places an entity in a namespace that it doesn't belong, just to gain
privileges, that is doing the wrong thing.  This is (at least) similar to
moving a private member to the public section of a class if it doesn't
belong there.  Yes it is "easier" in some sense, to do the former than the
later, but it is ultimately just a question of degree - and in my opinion -
a minor one.

--

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

--001a114449386b290d0523cc6906
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, Nov 5, 2015 at 3:28 PM, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</sp=
an> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex">On Thursday, November 5, 2015 =
at 8:20:40 AM UTC-5, Andrew Tomazos wrote:<span class=3D""><blockquote clas=
s=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">On=
 Wed, Nov 4, 2015 at 11:03 PM, Alisdair Meredith <span dir=3D"ltr">&lt;<a r=
el=3D"nofollow">alis...@icloud.com</a>&gt;</span> wrote:<br><div></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">If I have a namespace access level, I can always perfectl=
y forward that object to my own function defined in that namespace, and use=
 the namespace level functions directly on that object.</blockquote></div><=
div><br></div><div>I&#39;m not convinced it should be a deal-breaker on thi=
s proposal.=C2=A0 Many codebases (particularly large ones that have many na=
mespaces) have rules about where you can open namespaces, usually in corres=
pondence to the source file system.=C2=A0 If those rules are enforced then =
namespace-access restricts what part of the codebase you have to edit to ga=
in access, in much the same way as accessing private members requires editi=
ng the class definition.</div></div></div></div></blockquote></span><div><b=
r>If such soft rules (ie: rules not checked by the compiler) are &quot;enfo=
rced&quot; in your project, then you could just as effectively enforce rule=
s about which objects and function can be accessed from outside of a namesp=
ace and which ones cannot. In both cases, your compiler will not actually e=
nforce this rule, so in both cases, you are equally open to a user doing th=
e wrong thing.<br><br>Why should the compiler provide &quot;protection&quot=
; that cannot actually be enforced (to a reasonable degree)?<br><br>Indeed,=
 you could attach attributes to declarations in a namespace and use static =
analysis to <i>actually</i> enforce them. That is, verify that you only acc=
ess those declarations from within the namespace (or vice-versa, never acce=
ss untagged declarations from outside the namespace, depending on the seman=
tics). None of that requires changing the language.</div><div class=3D"HOEn=
Zb"><div class=3D"h5">

<p></p></div></div></blockquote></div>I think we&#39;ve been distracted fro=
m the fact that it is the person that places an entity in a namespace that =
it doesn&#39;t belong, just to gain privileges, that is doing the wrong thi=
ng.=C2=A0 This is (at least) similar to moving a private member to the publ=
ic section of a class if it doesn&#39;t belong there.=C2=A0 Yes it is &quot=
;easier&quot; in some sense, to do the former than the later, but it is ult=
imately just a question of degree - and in my opinion - a minor one.</div><=
div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra"><br></div></=
div>

<p></p>

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

--001a114449386b290d0523cc6906--

.

Andrew Tomazos <andrewtomazos@gmail.com> writes:

> On Wed, Nov 4, 2015 at 11:03 PM, Alisdair Meredith
> <alisdairm@icloud.com>
> wrote:
>
>> If someone passes me an object of type 'T', I cannot access its
>> private parts.  I can construct on object of a derived class this I
>> control that takes that object in its constructor, but I will always
>> be working on a (potentially moved) copy of that original object.
>>
>
> Sure, for protected non-static data members you can't obtain a direct
> reference to that subobject given an object of the base class.
>
> So for example this doesn't work:
>
> struct X {
>  protected:
>   int i;
> };
>
> void f(X& x) {
>   struct Y : X {
>     static int& i(X& x) { return x.i; } // ERROR X::i is protected
>   };
>   int& i = Y::i(x);
>
>   int j = i; // read
>   i = 42; // write
> }
>
> Ok.  I'll grant that namespace-access is more "open" than protected in
> this sense.

If you really want to "break" into the system, it's not hard to do.

    #include <iostream>

    struct base
    {

    protected:

      int m_base {42};

    public:

      int
      tell() const
      {
        return this->m_base;
      }

    };

    struct cheat : base
    {

      cheat(const base& b) : base {b}
      {
      }

      static void
      set_value(base& b, const int value)
      {
        cheat copy = b;
        copy.m_base = value;
        b = copy;
      }

    };


    int
    main()
    {
      base b {};
      std::cout << b.tell() << "\n";
      cheat::set_value(b, 43);
      std::cout << b.tell() << "\n";
    }

I'm not sure if it is the type system's job to "protect" us against such
deliberate subverting of encapsulation.  Whoever does this must be
well-aware that they are not using the system in the intended way.  Is
it really important to stop them?

I assume most people on this list will be familiar with the following
article by Herb Sutter (GotW #76):

    http://www.gotw.ca/gotw/076.htm

Note that Java has a similar concept of "package private" access.  I
don't like this access level a lot but some people apparently find it
useful.  Maybe modules will reduce the need for this even further but I
haven't seen yet how it would cause any damage.  Does it?

--

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

.

On 5 November 2015 at 18:54, Moritz Klammler <moritz.klammler@gmail.com> wrote:
> Note that Java has a similar concept of "package private" access.  I
> don't like this access level a lot but some people apparently find it
> useful.  Maybe modules will reduce the need for this even further but I
> haven't seen yet how it would cause any damage.  Does it?

A new access mode needs very strong motivation; it's not sufficient
that it doesn't cause damage, or that it would be nice for a few selected
examples. It must be of fundamental importance. Is it?

--

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

.

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

On Tue, Nov 3, 2015 at 11:37 PM, Magnus Fromreide <magfr@lysator.liu.se>
wrote:

> On Tue, Nov 03, 2015 at 10:38:25PM +0100, Andrew Tomazos wrote:
> > C++ has three access levels for members of class types:
> >
> >     public
> >     private
> >     protected
> >
> > We propose a forth access level:
> >
> >     namespace
> >
> > Members with namespace access level are accessible by classes and
> functions
> > in the same namespace:
>
> How would it interact with inline namespaces?
>

This requires some thought.  A related question is how does it interact
with nested namespaces:

namespace N {
  class X {
    namespace:
      int i;
  };

  namespace M {
    void f(X& x) {
      x.i = 42; // ok?
    }
  }  // namespace M

}  // namespace N

I think the answer should be that a namespace-access member is visible in
the smallest enclosing non-inline namespace and all descendant namespaces.

Usually the feature will be used in a non-inline leaf namespace that
logically encloses the "library" of related entities.  In those cases the
answer doesn't matter.

In cases where there are descendant namespaces (non-leaf), I imagine they
will be so-called detail namespaces and/or anonymous namespaces - which are
part of the same library.  In cases where the smallest enclosing is an
inline namespace, these are generally used for versioning parts of the next
larger enclosing non-inline namespace.  In both cases therefore access
makes sense.


> Many times a library of related classes and functions are grouped together
> > in a common namespace, and many times there are members that are desired
> to
> > be exposed to each other (library internal) but not to the outside world.
>
> This is obviously more open than protected, especially given that one
> always
> could reopen a namespace but if the idea is to protect against mistakes and
> not malice then this might be a nice feature.
>
> /MF
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

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

--001a11443a7e19f7680523d15c9a
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, Nov 3, 2015 at 11:37 PM, Magnus Fromreide <span dir=3D"ltr">&lt;<a href=
=3D"mailto:magfr@lysator.liu.se" target=3D"_blank">magfr@lysator.liu.se</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"><span class=3D"">On Tu=
e, Nov 03, 2015 at 10:38:25PM +0100, Andrew Tomazos wrote:<br>
&gt; C++ has three access levels for members of class types:<br>
&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0public<br>
&gt;=C2=A0 =C2=A0 =C2=A0private<br>
&gt;=C2=A0 =C2=A0 =C2=A0protected<br>
&gt;<br>
&gt; We propose a forth access level:<br>
&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0namespace<br>
&gt;<br>
&gt; Members with namespace access level are accessible by classes and func=
tions<br>
&gt; in the same namespace:<br>
<br>
</span>How would it interact with inline namespaces?<span class=3D""><br></=
span></blockquote><div>=C2=A0</div><div>This requires some thought.=C2=A0 A=
 related question is how does it interact with nested namespaces:</div><div=
><br></div><div>namespace N {</div><div>=C2=A0 class X {</div><div>=C2=A0 =
=C2=A0 namespace:</div><div>=C2=A0 =C2=A0 =C2=A0 int i;</div><div>=C2=A0 };=
</div><div><br></div><div>=C2=A0 namespace M {</div><div>=C2=A0 =C2=A0 void=
 f(X&amp; x) {</div><div>=C2=A0 =C2=A0 =C2=A0 x.i =3D 42; // ok?</div><div>=
=C2=A0 =C2=A0 }</div><div>=C2=A0 } =C2=A0// namespace M</div><div><br></div=
><div>} =C2=A0// namespace N</div><div><br></div><div>I think the answer sh=
ould be that a namespace-access member is visible in the smallest enclosing=
 non-inline namespace and all descendant namespaces.</div><div><br></div><d=
iv>Usually the feature will be used in a non-inline leaf namespace that log=
ically encloses the &quot;library&quot; of related entities.=C2=A0 In those=
 cases the answer doesn&#39;t matter.</div><div><br></div><div>In cases whe=
re there are descendant namespaces (non-leaf), I imagine they will be so-ca=
lled detail namespaces and/or anonymous namespaces - which are part of the =
same library.=C2=A0 In cases where the smallest enclosing is an inline name=
space, these are generally used for versioning parts of the next larger enc=
losing non-inline namespace.=C2=A0 In both cases therefore access makes sen=
se.</div><div><br></div><div><br></div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span=
 class=3D"">
&gt; Many times a library of related classes and functions are grouped toge=
ther<br>
&gt; in a common namespace, and many times there are members that are desir=
ed to<br>
&gt; be exposed to each other (library internal) but not to the outside wor=
ld.<br>
<br>
</span>This is obviously more open than protected, especially given that on=
e always<br>
could reopen a namespace but if the idea is to protect against mistakes and=
<br>
not malice then this might be a nice feature.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
/MF<br>
<br>
--<br>
<br>
---<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-propo=
sals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" rel=3D"noreferrer" target=3D"_blank">http://groups.google.c=
om/a/isocpp.org/group/std-proposals/</a>.<br>
</font></span></blockquote></div><br></div></div>

<p></p>

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

--001a11443a7e19f7680523d15c9a--

.

Ville Voutilainen <ville.voutilainen@gmail.com> writes:

> On 5 November 2015 at 18:54, Moritz Klammler <moritz.klammler@gmail.com> wrote:
>> Note that Java has a similar concept of "package private" access.  I
>> don't like this access level a lot but some people apparently find it
>> useful.  Maybe modules will reduce the need for this even further but
>> I haven't seen yet how it would cause any damage.  Does it?
>
> A new access mode needs very strong motivation; it's not sufficient
> that it doesn't cause damage, or that it would be nice for a few
> selected examples. It must be of fundamental importance. Is it?

I cannot provide such motivation, in case you've meant to ask me for it.
Personally, I'm mostly neutral about the proposed additional access
mode.  What I did want to point out is that I think that the discussion
about the proposed `namespace` access being "insecure" (or "more
insecure" than `protected` access) is somewhat misguided in my opinion.

--

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

.

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

On Fri, Nov 6, 2015 at 12:44 PM, Moritz Klammler <moritz.klammler@gmail.com>
wrote:

>
> Ville Voutilainen <ville.voutilainen@gmail.com> writes:
>
> > On 5 November 2015 at 18:54, Moritz Klammler <moritz.klammler@gmail.com>
> wrote:
> >> Note that Java has a similar concept of "package private" access.  I
> >> don't like this access level a lot but some people apparently find it
> >> useful.  Maybe modules will reduce the need for this even further but
> >> I haven't seen yet how it would cause any damage.  Does it?
> >
> > A new access mode needs very strong motivation; it's not sufficient
> > that it doesn't cause damage, or that it would be nice for a few
> > selected examples. It must be of fundamental importance. Is it?
>
> I cannot provide such motivation, in case you've meant to ask me for it.
> Personally, I'm mostly neutral about the proposed additional access
> mode.  What I did want to point out is that I think that the discussion
> about the proposed `namespace` access being "insecure" (or "more
> insecure" than `protected` access) is somewhat misguided in my opinion.
>
>
My opinion, in case anyone cares:

namespace access isn't "more insecure", but I do think that it is easier
than the hoops you need to go through for protected, and thus
- might be seen as a "correct" way to access things, particularly by
novices. ie "the API author _expects_ me to access it this way"
- might be seen at least as not a "hoop" at all, ie "this is not a hack,
stop telling me that it is"

I don't think it expresses intent very well.

And I don't think it gives enough benefit to be worth the effort.  There is
a need here, but I'm hoping modules will be the correct solution.

Tony

--

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

--001a1141028221ffd90523e8987c
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 Fri, Nov 6, 2015 at 12:44 PM, Moritz Klammler <span dir=3D"ltr">&lt;=
<a href=3D"mailto:moritz.klammler@gmail.com" target=3D"_blank">moritz.klamm=
ler@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span=
 class=3D""><br>
Ville Voutilainen &lt;<a href=3D"mailto:ville.voutilainen@gmail.com">ville.=
voutilainen@gmail.com</a>&gt; writes:<br>
<br>
&gt; On 5 November 2015 at 18:54, Moritz Klammler &lt;<a href=3D"mailto:mor=
itz.klammler@gmail.com">moritz.klammler@gmail.com</a>&gt; wrote:<br>
&gt;&gt; Note that Java has a similar concept of &quot;package private&quot=
; access.=C2=A0 I<br>
&gt;&gt; don&#39;t like this access level a lot but some people apparently =
find it<br>
&gt;&gt; useful.=C2=A0 Maybe modules will reduce the need for this even fur=
ther but<br>
&gt;&gt; I haven&#39;t seen yet how it would cause any damage.=C2=A0 Does i=
t?<br>
&gt;<br>
&gt; A new access mode needs very strong motivation; it&#39;s not sufficien=
t<br>
&gt; that it doesn&#39;t cause damage, or that it would be nice for a few<b=
r>
&gt; selected examples. It must be of fundamental importance. Is it?<br>
<br>
</span>I cannot provide such motivation, in case you&#39;ve meant to ask me=
 for it.<br>
Personally, I&#39;m mostly neutral about the proposed additional access<br>
mode.=C2=A0 What I did want to point out is that I think that the discussio=
n<br>
about the proposed `namespace` access being &quot;insecure&quot; (or &quot;=
more<br>
insecure&quot; than `protected` access) is somewhat misguided in my opinion=
..<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br></div></div></blockquote><div><=
br></div><div>My opinion, in case anyone cares:<br><br></div><div>namespace=
 access isn&#39;t &quot;more insecure&quot;, but I do think that it is easi=
er than the hoops you need to go through for protected, and thus <br></div>=
<div>- might be seen as a &quot;correct&quot; way to access things, particu=
larly by novices. ie &quot;the API author _expects_ me to access it this wa=
y&quot;<br></div><div>- might be seen at least as not a &quot;hoop&quot; at=
 all, ie &quot;this is not a hack, stop telling me that it is&quot;<br><br>=
</div><div>I don&#39;t think it expresses intent very well.<br><br></div><d=
iv>And I don&#39;t think it gives enough benefit to be worth the effort.=C2=
=A0 There is a need here, but I&#39;m hoping modules will be the correct so=
lution.<br><br></div><div>Tony<br><br></div></div></div></div>

<p></p>

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

--001a1141028221ffd90523e8987c--

.

------=_Part_82_1994386159.1446997066821
Content-Type: text/plain; charset=UTF-8

I think this proposal is vastly superior to the current workaround; the detail namspace, both from a safety perspective and from a usability and expressiveness perspective.

The proposal allows finer granularity of protection than 'detail' while forcing you to at least do something out of the ordinary to "break in".

I would like this to be fleshed out to a full proposal, but on the other hand it is not at the the top of my most wanted feature list (the number 1 position is held by variable length arrays, closely followed by modules and rtti).

--

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

------=_Part_82_1994386159.1446997066821--

.

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

I actually do not see a huge problem with following codebase conventions
for namespaces. Every time I think I've wanted some of these conventions to
be standardized, I ask myself whether everyone else will really need to
follow the same convention.

Spelling a namespace "detail" conveys something to the reader, and I don't
necessarily think it conveys anything meaningful to the compiler. Whether
you want to enforce some sort of rule external to the specification (like
via a style guide), this should be doable without having to standardize it.

On Mon, Nov 9, 2015 at 2:37 AM Bengt Gustafsson <
bengt.gustafsson@beamways.com> wrote:

> I think this proposal is vastly superior to the current workaround; the
> detail namspace, both from a safety perspective and from a usability and
> expressiveness perspective.
>
> The proposal allows finer granularity of protection than 'detail' while
> forcing you to at least do something out of the ordinary to "break in".
>
> I would like this to be fleshed out to a full proposal, but on the other
> hand it is not at the the top of my most wanted feature list (the number 1
> position is held by variable length arrays, closely followed by modules and
> rtti).
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

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

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

<div dir=3D"ltr">I actually do not see a huge problem with following codeba=
se conventions for namespaces. Every time I think I&#39;ve wanted some of t=
hese conventions to be standardized, I ask myself whether everyone else wil=
l really need to follow the same convention.<div><br></div><div>Spelling a =
namespace &quot;detail&quot; conveys something to the reader, and I don&#39=
;t necessarily think it conveys anything meaningful to the compiler. Whethe=
r you want to enforce some sort of rule external to the specification (like=
 via a style guide), this should be doable without having to standardize it=
..</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Mon, Nov 9,=
 2015 at 2:37 AM Bengt Gustafsson &lt;<a href=3D"mailto:bengt.gustafsson@be=
amways.com">bengt.gustafsson@beamways.com</a>&gt; wrote:<br></div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex">I think this proposal is vastly superior to the curre=
nt workaround; the detail namspace, both from a safety perspective and from=
 a usability and expressiveness perspective.<br>
<br>
The proposal allows finer granularity of protection than &#39;detail&#39; w=
hile forcing you to at least do something out of the ordinary to &quot;brea=
k in&quot;.<br>
<br>
I would like this to be fleshed out to a full proposal, but on the other ha=
nd it is not at the the top of my most wanted feature list (the number 1 po=
sition is held by variable length arrays, closely followed by modules and r=
tti).<br>
<br>
--<br>
<br>
---<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" rel=3D"noreferrer" target=3D"_blank">http://groups.google.c=
om/a/isocpp.org/group/std-proposals/</a>.<br>
</blockquote></div>

<p></p>

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

--089e0122ad8af9ae6005240f8ea5--

.