------=_Part_6056_1458957909.1516043701757
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

The current access specifier system makes a lot of sense due to the common =
practice of writing out the interface for a class separately in a header fi=
le. Header files tend to be written for potential users of the class: publi=
c stuff at the top (since that=E2=80=99s what users will be using), then pr=
otected and finally private. Being able to write =E2=80=9Cpublic:=E2=80=9D =
once at the top and have all following declarations made automatically publ=
ic is very convenient.

With the proposed module system, it becomes feasible for small projects to =
adopt the single file approach and forego writing a separate file for an in=
terface. With the single file approach, class members won=E2=80=99t necessa=
rily be grouped by access (because it=E2=80=99s no longer being written jus=
t for a user). However it=E2=80=99s fairly cumbersome and error prone to fr=
equently change access types with the current access specifier system, and =
it adds a lot of noise to the code.

E.g:

    class MyClass {
        public:
             void somethingPublic() { }
        private:
             void somethingPrivate() { }
        public:
             void anotherPublicThing() { }
    };

I propose being able to write that as:

    class MyClass {
        public void somethingPublic() { }
        private void somethingPrivate() { }
        public void anotherPublicThing() { }
    };

This has the added benefit of being familiar to people coming from other la=
nguages (Java, C#, Swift, lots of others).

As a purely additive change, I don=E2=80=99t see this breaking any existing=
 code.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/92dfd2f1-5c52-4efe-b383-5f22742c41d5%40isocpp.or=
g.

------=_Part_6056_1458957909.1516043701757--

.

--001a1140b5762cdb2b0562d59396
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Jan 15, 2018 at 1:15 PM, <hamza_sood@me.com> wrote:

> With the proposed module system, it becomes feasible for small projects t=
o
> adopt the single file approach and forego writing a separate file for an
> interface. With the single file approach, class members won=E2=80=99t nec=
essarily
> be grouped by access (because it=E2=80=99s no longer being written just f=
or a
> user). However it=E2=80=99s fairly cumbersome and error prone to frequent=
ly change
> access types with the current access specifier system, and it adds a lot =
of
> noise to the code.
>
> E.g:
>
>     class MyClass {
>         public:
>              void somethingPublic() { }
>         private:
>              void somethingPrivate() { }
>         public:
>              void anotherPublicThing() { }
>     };
>

Or, written w/o extra newlines:

    class MyClass {
        public*:* void somethingPublic() { }
        private*:* void somethingPrivate() { }
        public*:* void anotherPublicThing() { }
    };


> I propose being able to write that as:
>
>     class MyClass {
>         public void somethingPublic() { }
>         private void somethingPrivate() { }
>         public void anotherPublicThing() { }
>     };
>

This seems to boil down to saying that '*:*' adds a lot of noise to the
code.
--=20
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  +1-847-691-1404
<(847)%20691-1404>

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

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

<div dir=3D"ltr">On Mon, Jan 15, 2018 at 1:15 PM,  <span dir=3D"ltr">&lt;<a=
 href=3D"mailto:hamza_sood@me.com" target=3D"_blank">hamza_sood@me.com</a>&=
gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote">=
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);p=
adding-left:1ex">With the proposed module system, it becomes feasible for s=
mall projects to adopt the single file approach and forego writing a separa=
te file for an interface. With the single file approach, class members won=
=E2=80=99t necessarily be grouped by access (because it=E2=80=99s no longer=
 being written just for a user). However it=E2=80=99s fairly cumbersome and=
 error prone to frequently change access types with the current access spec=
ifier system, and it adds a lot of noise to the code.<br>
<br>
E.g:<br>
<br>
=C2=A0 =C2=A0 class MyClass {<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 public:<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0void somethingPublic() { }<=
br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 private:<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0void somethingPrivate() { }=
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 public:<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0void anotherPublicThing() {=
 }<br>
=C2=A0 =C2=A0 };<br></blockquote><div><br></div><div>Or, written w/o extra =
newlines:</div><div><br></div><div><span style=3D"font-family:monospace,mon=
ospace;font-size:x-small">=C2=A0 =C2=A0 class MyClass {</span><br style=3D"=
font-family:monospace,monospace"><span style=3D"font-family:monospace,monos=
pace;font-size:x-small">=C2=A0 =C2=A0 =C2=A0 =C2=A0 public</span><b style=
=3D"font-family:monospace,monospace">:</b><span style=3D"font-family:monosp=
ace,monospace;font-size:x-small">=C2=A0void somethingPublic() { }</span><br=
 style=3D"font-family:monospace,monospace"><span style=3D"font-family:monos=
pace,monospace;font-size:x-small">=C2=A0 =C2=A0 =C2=A0 =C2=A0 private</span=
><b style=3D"font-family:monospace,monospace">:</b><span style=3D"font-fami=
ly:monospace,monospace;font-size:x-small">=C2=A0void somethingPrivate() { }=
</span><br style=3D"font-family:monospace,monospace"><span style=3D"font-fa=
mily:monospace,monospace;font-size:x-small">=C2=A0 =C2=A0 =C2=A0 =C2=A0 pub=
lic</span><b style=3D"font-family:monospace,monospace">:</b><span style=3D"=
font-family:monospace,monospace;font-size:x-small">=C2=A0void anotherPublic=
Thing() { }</span><br style=3D"font-family:monospace,monospace"><span style=
=3D"font-family:monospace,monospace;font-size:x-small">=C2=A0 =C2=A0 };</sp=
an><br style=3D"font-family:monospace,monospace"></div><div>=C2=A0</div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-lef=
t-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padd=
ing-left:1ex">I propose being able to write that as:<br>
<br>
=C2=A0 =C2=A0 class MyClass {<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 public void somethingPublic() { }<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 private void somethingPrivate() { }<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 public void anotherPublicThing() { }<br>
=C2=A0 =C2=A0 };<br></blockquote><div><br></div><div>This seems to boil dow=
n to saying that &#39;<b><font face=3D"monospace, monospace">:</font></b>&#=
39; adds a lot of noise to the code.<br></div></div>-- <br><div class=3D"m_=
2987411383630546880gmail_signature"><div dir=3D"ltr"><div><div dir=3D"ltr">=
<div>=C2=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt;mailto:<a href=3D"mailto:n=
evin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a><wbr>&gt=
; =C2=A0<a href=3D"tel:(847)%20691-1404" value=3D"+18476911404" target=3D"_=
blank">+1-847-691-1404</a></div></div></div></div></div>
</div></div>

<p></p>

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

--001a1140b5762cdb2b0562d59396--

.

------=_Part_6026_1016516703.1516048019396
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Writing the specificer on the same line with a colon is an error-prone abus=
e of syntax; it isn=E2=80=99t immediately obvious that the specifier applie=
s to more than just the declaration that it shares a line with.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/ba520f87-899d-45ba-b385-7608d5ef29a2%40isocpp.or=
g.

------=_Part_6026_1016516703.1516048019396--

.

--001a1141a762c8b0d90562d68d54
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Jan 15, 2018 at 2:26 PM, <hamza_sood@me.com> wrote:

> Writing the specificer on the same line with a colon is an error-prone
> abuse of syntax; it isn=E2=80=99t immediately obvious that the specifier =
applies to
> more than just the declaration that it shares a line with.
>

Given this is supposed to be a "purely additive change" (your words), what
is the access for things declared afterwards?

It seems very error-prone to change the access based upon an accidental
presence/absence of a colon.
--=20
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  +1-847-691-1404
<(847)%20691-1404>

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

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

<div dir=3D"ltr">On Mon, Jan 15, 2018 at 2:26 PM,  <span dir=3D"ltr">&lt;<a=
 href=3D"mailto:hamza_sood@me.com" target=3D"_blank">hamza_sood@me.com</a>&=
gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote">=
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);p=
adding-left:1ex">Writing the specificer on the same line with a colon is an=
 error-prone abuse of syntax; it isn=E2=80=99t immediately obvious that the=
 specifier applies to more than just the declaration that it shares a line =
with.<br></blockquote><div><br></div><div>Given this is supposed to be a &q=
uot;<span style=3D"font-size:12.800000190734863px">purely additive change&q=
uot; (your words), what is the access for things declared afterwards?</span=
></div><div><span style=3D"font-size:12.800000190734863px"><br></span></div=
><div><span style=3D"font-size:12.800000190734863px">It seems very error-pr=
one to change the access based upon an accidental presence/absence of a col=
on.</span></div><div>--=C2=A0<br></div></div><div class=3D"m_-3269959084200=
370161gmail_signature"><div dir=3D"ltr"><div><div dir=3D"ltr"><div>=C2=A0Ne=
vin &quot;:-)&quot; Liber=C2=A0 &lt;mailto:<a href=3D"mailto:nevin@evilover=
lord.com" target=3D"_blank">nevin@eviloverlord.com</a><wbr>&gt; =C2=A0<a hr=
ef=3D"tel:(847)%20691-1404" value=3D"+18476911404" target=3D"_blank">+1-847=
-691-1404</a></div></div></div></div></div>
</div></div>

<p></p>

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

--001a1141a762c8b0d90562d68d54--

.

------=_Part_6056_633059321.1516049314838
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

It=E2=80=99d work like it does in every other language: following declarati=
ons will be unaffected.

It=E2=80=99s no more error-prone than omitting braces from an if statement =
changing a multi-line block into a single line.

if (thing)
    imInTheIf();
    iLookLikeIAmButImNotReally();

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/e0e88414-a7da-40ad-a6f4-9ab73d69c72c%40isocpp.or=
g.

------=_Part_6056_633059321.1516049314838--

.

> On 15 Jan 2018, at 20:48, hamza_sood@me.com wrote:
>=20
> It=E2=80=99d work like it does in every other language: following declara=
tions will be unaffected.
>=20
> It=E2=80=99s no more error-prone than omitting braces from an if statemen=
t changing a multi-line block into a single line.
>=20
> if (thing)
>    imInTheIf();
>    iLookLikeIAmButImNotReally();
>=20

This seems like a probable source of subtle and frustrating errors for very=
 little real gain.

> --=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.
> To view this discussion on the web visit https://groups.google.com/a/isoc=
pp.org/d/msgid/std-proposals/e0e88414-a7da-40ad-a6f4-9ab73d69c72c%40isocpp.=
org.

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

.

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

On Mon, Jan 15, 2018 at 3:48 PM, <hamza_sood@me.com> wrote:

> It=E2=80=99d work like it does in every other language: following declara=
tions
> will be unaffected.
>

ay, there's the rub.

In every other language, per-line is the _only_ way to do it.  In C++ you
would allow people to mix things:

public:
    int x;
    private int y;
    int z;

Now add a bunch of comments, etc, between those lines, and you start wonder
about the access of z.

The current way encourages you to separate public from private. What's
would the benefit be of the new way?

Do you want code that's more "per-subject"?

    private int thing;
    pubic setThing(int);

    private double otherThing;
    public setOtherThing(double);

    private string title;
    public setTitle(string);

This would allow you to more easily add/remove features from your class.
But guess what - if you have multiple features in your class, your class is
probably too big. Single Responsibility.


--=20
Be seeing you,
Tony

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

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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Mon, Jan 15, 2018 at 3:48 PM,  <span dir=3D"ltr">&lt;<a href=3D"mail=
to:hamza_sood@me.com" target=3D"_blank">hamza_sood@me.com</a>&gt;</span> wr=
ote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex=
;border-left:1px solid rgb(204,204,204);padding-left:1ex">It=E2=80=99d work=
 like it does in every other language: following declarations will be unaff=
ected.<br></blockquote><div><br></div><div>ay, there&#39;s the rub.</div><d=
iv><br></div><div>In every other language, per-line is the _only_ way to do=
 it.=C2=A0 In C++ you would allow people to mix things:</div><div><br></div=
><div>public:</div><div>=C2=A0=C2=A0=C2=A0 int x;</div><div>=C2=A0=C2=A0=C2=
=A0 private int y;</div><div>=C2=A0=C2=A0=C2=A0 int z;</div><div><br></div>=
<div>Now add a bunch of comments, etc, between those lines, and you start w=
onder about the access of z.</div><div><br></div><div>The current way encou=
rages you to separate public from private. What&#39;s would the benefit be =
of the new way?</div><div><br></div><div>Do you want code that&#39;s more &=
quot;per-subject&quot;?<br></div><div><br></div><div>=C2=A0=C2=A0=C2=A0 pri=
vate int thing;</div><div>=C2=A0=C2=A0=C2=A0 pubic setThing(int);</div><div=
><br></div><div>=C2=A0=C2=A0=C2=A0 private double otherThing;</div><div>=C2=
=A0=C2=A0=C2=A0 public setOtherThing(double);</div><div><br></div><div>=C2=
=A0=C2=A0=C2=A0 private string title;</div><div>=C2=A0=C2=A0=C2=A0 public s=
etTitle(string);</div><div><br></div><div>This would allow you to more easi=
ly add/remove features from your class.</div><div>But guess what - if you h=
ave multiple features in your class, your class is probably too big. Single=
 Responsibility.</div></div><div class=3D"gmail_quote"><br></div><br>-- <br=
><div class=3D"gmail_signature"><div dir=3D"ltr"><div>Be seeing you,<br></d=
iv>Tony<br></div></div>
</div></div>

<p></p>

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

--94eb2c057986515b4e0562d7c889--

.

------=_Part_6478_1318531403.1516053919804
Content-Type: multipart/alternative;
 boundary="----=_Part_6479_735477645.1516053919804"

------=_Part_6479_735477645.1516053919804
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Monday, January 15, 2018 at 2:15:01 PM UTC-5, hamza...@me.com wrote:
>
> The current access specifier system makes a lot of sense due to the commo=
n=20
> practice of writing out the interface for a class separately in a header=
=20
> file. Header files tend to be written for potential users of the class:=
=20
> public stuff at the top (since that=E2=80=99s what users will be using), =
then=20
> protected and finally private. Being able to write =E2=80=9Cpublic:=E2=80=
=9D once at the=20
> top and have all following declarations made automatically public is very=
=20
> convenient.=20
>
> With the proposed module system, it becomes feasible for small projects t=
o=20
> adopt the single file approach and forego writing a separate file for an=
=20
> interface. With the single file approach, class members won=E2=80=99t nec=
essarily=20
> be grouped by access (because it=E2=80=99s no longer being written just f=
or a=20
> user). However it=E2=80=99s fairly cumbersome and error prone to frequent=
ly change=20
> access types with the current access specifier system, and it adds a lot =
of=20
> noise to the code.=20
>

I contest the motivation here.

There are many C++ types that already put everything in a "single file".=20
Template types have to do this as a matter of course. And yet, there is no=
=20
real desire on the part of programmers to randomly interleave public and=20
private methods. Or at least, not to the extent you're talking about.

Indeed, such interleaving reduces the ease of understanding the code and=20
benefits only the writer of that code. Since code is read more often than=
=20
it is written, you should adopt a writing style that makes it easy for=20
readers of the code to understand it. Interleaving isn't doing that.

Modules will be written as much for users as for the writer of the class.

As a purely additive change, I don=E2=80=99t see this breaking any existing=
 code.


As Nevin pointed out, being "purely additive" is a problem. It means that=
=20
not typing a `:` can radically change the nature of code. As it currently=
=20
stands, not typing that `:` is a compile error. With what you want, it=20
wouldn't be anymore. Your code will just work... until it doesn't.

No. If you want each member to have an access class explicitly specified,=
=20
then do that with the existing syntax. Either way, you have to be=20
consistent about it to get the advantages you claim exist.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/15377a15-fea0-4841-9834-d9c8861dc412%40isocpp.or=
g.

------=_Part_6479_735477645.1516053919804
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Monday, January 15, 2018 at 2:15:01 PM UTC-5, hamza...@=
me.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">The current acces=
s specifier system makes a lot of sense due to the common practice of writi=
ng out the interface for a class separately in a header file. Header files =
tend to be written for potential users of the class: public stuff at the to=
p (since that=E2=80=99s what users will be using), then protected and final=
ly private. Being able to write =E2=80=9Cpublic:=E2=80=9D once at the top a=
nd have all following declarations made automatically public is very conven=
ient.
<br>
<br>With the proposed module system, it becomes feasible for small projects=
 to adopt the single file approach and forego writing a separate file for a=
n interface. With the single file approach, class members won=E2=80=99t nec=
essarily be grouped by access (because it=E2=80=99s no longer being written=
 just for a user). However it=E2=80=99s fairly cumbersome and error prone t=
o frequently change access types with the current access specifier system, =
and it adds a lot of noise to the code.
<br></blockquote><div><br></div><div>I contest the motivation here.</div><d=
iv><br></div><div>There are many C++ types that already put everything in a=
 &quot;single file&quot;. Template types have to do this as a matter of cou=
rse. And yet, there is no real desire on the part of programmers to randoml=
y interleave public and private methods. Or at least, not to the extent you=
&#39;re talking about.</div><div><br></div><div>Indeed, such interleaving r=
educes the ease of understanding the code and benefits only the writer of t=
hat code. Since code is read more often than it is written, you should adop=
t a writing style that makes it easy for readers of the code to understand =
it. Interleaving isn&#39;t doing that.</div><div><br></div><div>Modules wil=
l be written as much for users as for the writer of the class.</div><div><b=
r></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;">As a purely additive c=
hange, I don=E2=80=99t see this breaking any existing code.</blockquote><di=
v><br></div><div>As Nevin pointed out, being &quot;purely additive&quot; is=
 a problem. It means that not typing a `:` can radically change the nature =
of code. As it currently stands, not typing that `:` is a compile error. Wi=
th what you want, it wouldn&#39;t be anymore. Your code will just work... u=
ntil it doesn&#39;t.</div><div><br></div><div>No. If you want each member t=
o have an access class explicitly specified, then do that with the existing=
 syntax. Either way, you have to be consistent about it to get the advantag=
es you claim exist.</div></div>

<p></p>

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

------=_Part_6479_735477645.1516053919804--

------=_Part_6478_1318531403.1516053919804--

.

--001a1144a1a643ef300562d7dfa8
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Jan 15, 2018 at 5:05 PM, Nicol Bolas <jmckesson@gmail.com> wrote:

> On Monday, January 15, 2018 at 2:15:01 PM UTC-5, hamza...@me.com wrote:
>>
>> The current access specifier system makes a lot of sense due to the
>> common practice of writing out the interface for a class separately in a
>> header file. Header files tend to be written for potential users of the
>> class: public stuff at the top (since that=E2=80=99s what users will be =
using),
>> then protected and finally private. Being able to write =E2=80=9Cpublic:=
=E2=80=9D once at
>> the top and have all following declarations made automatically public is
>> very convenient.
>>
>> With the proposed module system, it becomes feasible for small projects
>> to adopt the single file approach and forego writing a separate file for=
 an
>> interface. With the single file approach, class members won=E2=80=99t ne=
cessarily
>> be grouped by access (because it=E2=80=99s no longer being written just =
for a
>> user). However it=E2=80=99s fairly cumbersome and error prone to frequen=
tly change
>> access types with the current access specifier system, and it adds a lot=
 of
>> noise to the code.
>>
>
> I contest the motivation here.
>
> There are many C++ types that already put everything in a "single file".
> Template types have to do this as a matter of course. And yet, there is n=
o
> real desire on the part of programmers to randomly interleave public and
> private methods. Or at least, not to the extent you're talking about.
>
> Indeed, such interleaving reduces the ease of understanding the code and
> benefits only the writer of that code. Since code is read more often than
> it is written, you should adopt a writing style that makes it easy for
> readers of the code to understand it. Interleaving isn't doing that.
>
> Modules will be written as much for users as for the writer of the class.
>
> As a purely additive change, I don=E2=80=99t see this breaking any existi=
ng code.
>
>
> As Nevin pointed out, being "purely additive" is a problem. It means that
> not typing a `:` can radically change the nature of code. As it currently
> stands, not typing that `:` is a compile error. With what you want, it
> wouldn't be anymore. Your code will just work... until it doesn't.
>

public:
   Constructor(int);
private
    int x;
    int y;
    int z;

//whoops!




> No. If you want each member to have an access class explicitly specified,
> then do that with the existing syntax. Either way, you have to be
> consistent about it to get the advantages you claim exist.
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/15377a15-fea0-4841-
> 9834-d9c8861dc412%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/15377a15-fe=
a0-4841-9834-d9c8861dc412%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>



--=20
Be seeing you,
Tony

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

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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Mon, Jan 15, 2018 at 5:05 PM, Nicol Bolas <span dir=3D"ltr">&lt;<a h=
ref=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a=
>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><spa=
n class=3D"">On Monday, January 15, 2018 at 2:15:01 PM UTC-5, <a href=3D"ma=
ilto:hamza...@me.com" target=3D"_blank">hamza...@me.com</a> wrote:<blockquo=
te class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1p=
x #ccc solid;padding-left:1ex">The current access specifier system makes a =
lot of sense due to the common practice of writing out the interface for a =
class separately in a header file. Header files tend to be written for pote=
ntial users of the class: public stuff at the top (since that=E2=80=99s wha=
t users will be using), then protected and finally private. Being able to w=
rite =E2=80=9Cpublic:=E2=80=9D once at the top and have all following decla=
rations made automatically public is very convenient.
<br>
<br>With the proposed module system, it becomes feasible for small projects=
 to adopt the single file approach and forego writing a separate file for a=
n interface. With the single file approach, class members won=E2=80=99t nec=
essarily be grouped by access (because it=E2=80=99s no longer being written=
 just for a user). However it=E2=80=99s fairly cumbersome and error prone t=
o frequently change access types with the current access specifier system, =
and it adds a lot of noise to the code.
<br></blockquote><div><br></div></span><div>I contest the motivation here.<=
/div><div><br></div><div>There are many C++ types that already put everythi=
ng in a &quot;single file&quot;. Template types have to do this as a matter=
 of course. And yet, there is no real desire on the part of programmers to =
randomly interleave public and private methods. Or at least, not to the ext=
ent you&#39;re talking about.</div><div><br></div><div>Indeed, such interle=
aving reduces the ease of understanding the code and benefits only the writ=
er of that code. Since code is read more often than it is written, you shou=
ld adopt a writing style that makes it easy for readers of the code to unde=
rstand it. Interleaving isn&#39;t doing that.</div><div><br></div><div>Modu=
les will be written as much for users as for the writer of the class.</div>=
<span class=3D""><div><br></div><blockquote class=3D"gmail_quote" style=3D"=
margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">As =
a purely additive change, I don=E2=80=99t see this breaking any existing co=
de.</blockquote><div><br></div></span><div>As Nevin pointed out, being &quo=
t;purely additive&quot; is a problem. It means that not typing a `:` can ra=
dically change the nature of code. As it currently stands, not typing that =
`:` is a compile error. With what you want, it wouldn&#39;t be anymore. You=
r code will just work... until it doesn&#39;t.</div></div></blockquote><div=
><br></div><div>public:</div><div>=C2=A0=C2=A0 Constructor(int);</div><div>=
private</div><div>=C2=A0=C2=A0=C2=A0 int x;</div><div>=C2=A0=C2=A0=C2=A0 in=
t y;</div><div>=C2=A0=C2=A0=C2=A0 int z;</div><div><br></div><div>//whoops!=
</div><div><br></div><div><br></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><br></div><div>No. If you want each member to =
have an access class explicitly specified, then do that with the existing s=
yntax. Either way, you have to be consistent about it to get the advantages=
 you claim exist.</div></div><span class=3D"">

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>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></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/15377a15-fea0-4841-9834-d9c8861dc412%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/1537=
7a15-fea0-4841-<wbr>9834-d9c8861dc412%40isocpp.org</a><wbr>.<br>
</blockquote></div><br><br clear=3D"all"><br>-- <br><div class=3D"gmail_sig=
nature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr"><div>Be seeing =
you,<br></div>Tony<br></div></div>
</div></div>

<p></p>

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

--001a1144a1a643ef300562d7dfa8--

.

------=_Part_6467_358579713.1516063399980
Content-Type: multipart/alternative;
 boundary="----=_Part_6468_1215189257.1516063399981"

------=_Part_6468_1215189257.1516063399981
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Probably it would be better to treat the first such single-member access=20
specifier declaration as the start of an "every declaration must have its=
=20
own access specifier" region, until the next public:, private:, or=20
protected: is seen.  I mean, since you've told the compiler you're in a C#=
=20
kind of mood, might as well stick with it till your mood changes.  The=20
compiler will helpfully hold you to it ("missing required access specifier=
=20
on line 20").  People coming from C#/Java/etc are used to that already,=20
anyway.  That said, the benefits of this do not seem overwhelming.  (I'd=20
rather see "public:" in C# and Java, really.  My eyes get tired of reading=
=20
"public" so many times.)


On Monday, January 15, 2018 at 2:09:48 PM UTC-8, Tony V E wrote:
>
>
>
> On Mon, Jan 15, 2018 at 5:05 PM, Nicol Bolas <jmck...@gmail.com=20
> <javascript:>> wrote:
>
>> On Monday, January 15, 2018 at 2:15:01 PM UTC-5, hamza...@me.com wrote:
>>>
>>> The current access specifier system makes a lot of sense due to the=20
>>> common practice of writing out the interface for a class separately in =
a=20
>>> header file. Header files tend to be written for potential users of the=
=20
>>> class: public stuff at the top (since that=E2=80=99s what users will be=
 using),=20
>>> then protected and finally private. Being able to write =E2=80=9Cpublic=
:=E2=80=9D once at=20
>>> the top and have all following declarations made automatically public i=
s=20
>>> very convenient.=20
>>>
>>> With the proposed module system, it becomes feasible for small projects=
=20
>>> to adopt the single file approach and forego writing a separate file fo=
r an=20
>>> interface. With the single file approach, class members won=E2=80=99t n=
ecessarily=20
>>> be grouped by access (because it=E2=80=99s no longer being written just=
 for a=20
>>> user). However it=E2=80=99s fairly cumbersome and error prone to freque=
ntly change=20
>>> access types with the current access specifier system, and it adds a lo=
t of=20
>>> noise to the code.=20
>>>
>>
>> I contest the motivation here.
>>
>> There are many C++ types that already put everything in a "single file".=
=20
>> Template types have to do this as a matter of course. And yet, there is =
no=20
>> real desire on the part of programmers to randomly interleave public and=
=20
>> private methods. Or at least, not to the extent you're talking about.
>>
>> Indeed, such interleaving reduces the ease of understanding the code and=
=20
>> benefits only the writer of that code. Since code is read more often tha=
n=20
>> it is written, you should adopt a writing style that makes it easy for=
=20
>> readers of the code to understand it. Interleaving isn't doing that.
>>
>> Modules will be written as much for users as for the writer of the class=
..
>>
>> As a purely additive change, I don=E2=80=99t see this breaking any exist=
ing code.
>>
>>
>> As Nevin pointed out, being "purely additive" is a problem. It means tha=
t=20
>> not typing a `:` can radically change the nature of code. As it currentl=
y=20
>> stands, not typing that `:` is a compile error. With what you want, it=
=20
>> wouldn't be anymore. Your code will just work... until it doesn't.
>>
>
> public:
>    Constructor(int);
> private
>     int x;
>     int y;
>     int z;
>
> //whoops!
>
>
>
>
>> No. If you want each member to have an access class explicitly specified=
,=20
>> then do that with the existing syntax. Either way, you have to be=20
>> consistent about it to get the advantages you claim exist.
>>
>> --=20
>> You received this message because you are subscribed to the Google Group=
s=20
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n=20
>> email to std-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> To view this discussion on the web visit=20
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/15377a15-fe=
a0-4841-9834-d9c8861dc412%40isocpp.org=20
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/15377a15-f=
ea0-4841-9834-d9c8861dc412%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoo=
ter>
>> .
>>
>
>
>
> --=20
> Be seeing you,
> Tony
>

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/7cb72293-8da5-4e4e-bdc9-c8a13a7404d0%40isocpp.or=
g.

------=_Part_6468_1215189257.1516063399981
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Probably it would be better to treat the first such single=
-member access specifier declaration as the start of an &quot;every declara=
tion must have its own access specifier&quot; region, until the next public=
:, private:, or protected: is seen.=C2=A0 I mean, since you&#39;ve told the=
 compiler you&#39;re in a C# kind of mood, might as well stick with it till=
 your mood changes.=C2=A0 The compiler will helpfully hold you to it (&quot=
;missing required access specifier on line 20&quot;).=C2=A0 People coming f=
rom C#/Java/etc are used to that already, anyway.=C2=A0 That said, the bene=
fits of this do not seem overwhelming.=C2=A0 (I&#39;d rather see &quot;publ=
ic:&quot; in C# and Java, really.=C2=A0 My eyes get tired of reading &quot;=
public&quot; so many times.)<div><br></div><div><br>On Monday, January 15, =
2018 at 2:09:48 PM UTC-8, Tony V E wrote:<blockquote class=3D"gmail_quote" =
style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-l=
eft: 1ex;"><div dir=3D"ltr"><br><div><br><div class=3D"gmail_quote">On Mon,=
 Jan 15, 2018 at 5:05 PM, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"java=
script:" target=3D"_blank" gdf-obfuscated-mailto=3D"-zaYSECuAQAJ" rel=3D"no=
follow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" oncl=
ick=3D"this.href=3D&#39;javascript:&#39;;return true;">jmck...@gmail.com</a=
>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><spa=
n>On Monday, January 15, 2018 at 2:15:01 PM UTC-5, <a>hamza...@me.com</a> w=
rote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;=
border-left:1px #ccc solid;padding-left:1ex">The current access specifier s=
ystem makes a lot of sense due to the common practice of writing out the in=
terface for a class separately in a header file. Header files tend to be wr=
itten for potential users of the class: public stuff at the top (since that=
=E2=80=99s what users will be using), then protected and finally private. B=
eing able to write =E2=80=9Cpublic:=E2=80=9D once at the top and have all f=
ollowing declarations made automatically public is very convenient.
<br>
<br>With the proposed module system, it becomes feasible for small projects=
 to adopt the single file approach and forego writing a separate file for a=
n interface. With the single file approach, class members won=E2=80=99t nec=
essarily be grouped by access (because it=E2=80=99s no longer being written=
 just for a user). However it=E2=80=99s fairly cumbersome and error prone t=
o frequently change access types with the current access specifier system, =
and it adds a lot of noise to the code.
<br></blockquote><div><br></div></span><div>I contest the motivation here.<=
/div><div><br></div><div>There are many C++ types that already put everythi=
ng in a &quot;single file&quot;. Template types have to do this as a matter=
 of course. And yet, there is no real desire on the part of programmers to =
randomly interleave public and private methods. Or at least, not to the ext=
ent you&#39;re talking about.</div><div><br></div><div>Indeed, such interle=
aving reduces the ease of understanding the code and benefits only the writ=
er of that code. Since code is read more often than it is written, you shou=
ld adopt a writing style that makes it easy for readers of the code to unde=
rstand it. Interleaving isn&#39;t doing that.</div><div><br></div><div>Modu=
les will be written as much for users as for the writer of the class.</div>=
<span><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0;ma=
rgin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">As a purely ad=
ditive change, I don=E2=80=99t see this breaking any existing code.</blockq=
uote><div><br></div></span><div>As Nevin pointed out, being &quot;purely ad=
ditive&quot; is a problem. It means that not typing a `:` can radically cha=
nge the nature of code. As it currently stands, not typing that `:` is a co=
mpile error. With what you want, it wouldn&#39;t be anymore. Your code will=
 just work... until it doesn&#39;t.</div></div></blockquote><div><br></div>=
<div>public:</div><div>=C2=A0=C2=A0 Constructor(int);</div><div>private</di=
v><div>=C2=A0=C2=A0=C2=A0 int x;</div><div>=C2=A0=C2=A0=C2=A0 int y;</div><=
div>=C2=A0=C2=A0=C2=A0 int z;</div><div><br></div><div>//whoops!</div><div>=
<br></div><div><br></div><div><br></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div=
 dir=3D"ltr"><div><br></div><div>No. If you want each member to have an acc=
ess class explicitly specified, then do that with the existing syntax. Eith=
er way, you have to be consistent about it to get the advantages you claim =
exist.</div></div><span>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
-zaYSECuAQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&=
#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true=
;">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"-zaYSECuAQAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39=
;javascript:&#39;;return true;">std-pr...@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/15377a15-fea0-4841-9834-d9c8861dc412%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank" =
rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/15377a15-fea0-4841-9834-d9c8861dc412%40i=
socpp.org?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" on=
click=3D"this.href=3D&#39;https://groups.google.com/a/isocpp.org/d/msgid/st=
d-proposals/15377a15-fea0-4841-9834-d9c8861dc412%40isocpp.org?utm_medium\x3=
demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/15377a15-fea0-4841-<wbr>9834-=
d9c8861dc412%40isocpp.org</a><wbr>.<br>
</blockquote></div><br><br clear=3D"all"><br>-- <br><div><div dir=3D"ltr"><=
div>Be seeing you,<br></div>Tony<br></div></div>
</div></div>
</blockquote></div></div>

<p></p>

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

------=_Part_6468_1215189257.1516063399981--

------=_Part_6467_358579713.1516063399980--

.

------=_Part_7246_460622089.1516094866379
Content-Type: multipart/alternative;
 boundary="----=_Part_7247_1872930786.1516094866379"

------=_Part_7247_1872930786.1516094866379
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Il giorno luned=C3=AC 15 gennaio 2018 23:03:24 UTC+1, Tony V E ha scritto:
>
>
>
> On Mon, Jan 15, 2018 at 3:48 PM, <hamza...@me.com <javascript:>> wrote:
>
>> It=E2=80=99d work like it does in every other language: following declar=
ations=20
>> will be unaffected.
>>
>
> ay, there's the rub.
>
> In every other language, per-line is the _only_ way to do it.  In C++ you=
=20
> would allow people to mix things:
>
> public:
>     int x;
>     private int y;
>     int z;
>
> =20
Who said we should allow to mix things? This is a new proposal, so we can=
=20
decide differently. Indeed, I say that as soon as the compiler detect the=
=20
use of one style of access specifiers, the rest of the class declaration=20
must abide to that style. This would greatly reduce the probability of=20
mistakes, while giving the freedom to choose between the two styles.

Just my 2 eurocent,

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/60fb70c6-dee4-4b35-ad68-b93c88a71a28%40isocpp.or=
g.

------=_Part_7247_1872930786.1516094866379
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Il giorno luned=C3=AC 15 gennaio 2018 23:03:24 UTC+1, Tony=
 V E ha scritto:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"lt=
r"><br><div><br><div class=3D"gmail_quote">On Mon, Jan 15, 2018 at 3:48 PM,=
  <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfus=
cated-mailto=3D"fz2hv-atAQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&=
#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&=
#39;;return true;">hamza...@me.com</a>&gt;</span> wrote:<br><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid =
rgb(204,204,204);padding-left:1ex">It=E2=80=99d work like it does in every =
other language: following declarations will be unaffected.<br></blockquote>=
<div><br></div><div>ay, there&#39;s the rub.</div><div><br></div><div>In ev=
ery other language, per-line is the _only_ way to do it.=C2=A0 In C++ you w=
ould allow people to mix things:</div><div><br></div><div>public:</div><div=
>=C2=A0=C2=A0=C2=A0 int x;</div><div>=C2=A0=C2=A0=C2=A0 private int y;</div=
><div>=C2=A0=C2=A0=C2=A0 int z;</div><div><br></div></div></div></div></blo=
ckquote><div>=C2=A0</div><div>Who said we should allow to mix things? This =
is a new proposal, so we can decide differently. Indeed, I say that as soon=
 as the compiler detect the use of one style of access specifiers, the rest=
 of the class declaration must abide to that style. This would greatly redu=
ce the probability of mistakes, while giving the freedom to choose between =
the two styles.</div><div><br></div><div>Just my 2 eurocent,<br></div></div=
>

<p></p>

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

------=_Part_7247_1872930786.1516094866379--

------=_Part_7246_460622089.1516094866379--

.

------=_Part_7661_918328090.1516115258486
Content-Type: multipart/alternative;
 boundary="----=_Part_7662_1786684565.1516115258486"

------=_Part_7662_1786684565.1516115258486
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



On Tuesday, January 16, 2018 at 4:27:46 AM UTC-5, Alberto Barbati wrote:
>
> Il giorno luned=C3=AC 15 gennaio 2018 23:03:24 UTC+1, Tony V E ha scritto=
:
>>
>>
>>
>> On Mon, Jan 15, 2018 at 3:48 PM, <hamza...@me.com> wrote:
>>
>>> It=E2=80=99d work like it does in every other language: following decla=
rations=20
>>> will be unaffected.
>>>
>>
>> ay, there's the rub.
>>
>> In every other language, per-line is the _only_ way to do it.  In C++ yo=
u=20
>> would allow people to mix things:
>>
>> public:
>>     int x;
>>     private int y;
>>     int z;
>>
>> =20
> Who said we should allow to mix things?
>

The OP, who said that this was "a purely additive change". It can't be=20
purely additive without the ability to mix things.=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/701cbe47-d5cc-44e5-ae01-1d9eb9460aa0%40isocpp.or=
g.

------=_Part_7662_1786684565.1516115258486
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Tuesday, January 16, 2018 at 4:27:46 AM UTC-5, =
Alberto Barbati wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr">Il giorno luned=C3=AC 15 gennaio 2018 23:03:24 UTC+1, Tony V E ha =
scritto:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><div><=
br><div class=3D"gmail_quote">On Mon, Jan 15, 2018 at 3:48 PM,  <span dir=
=3D"ltr">&lt;<a rel=3D"nofollow">hamza...@me.com</a>&gt;</span> wrote:<br><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft:1px solid rgb(204,204,204);padding-left:1ex">It=E2=80=99d work like it =
does in every other language: following declarations will be unaffected.<br=
></blockquote><div><br></div><div>ay, there&#39;s the rub.</div><div><br></=
div><div>In every other language, per-line is the _only_ way to do it.=C2=
=A0 In C++ you would allow people to mix things:</div><div><br></div><div>p=
ublic:</div><div>=C2=A0=C2=A0=C2=A0 int x;</div><div>=C2=A0=C2=A0=C2=A0 pri=
vate int y;</div><div>=C2=A0=C2=A0=C2=A0 int z;</div><div><br></div></div><=
/div></div></blockquote><div>=C2=A0</div><div>Who said we should allow to m=
ix things?</div></div></blockquote><div><br></div><div>The OP, who said tha=
t this was &quot;<span style=3D"display: inline !important; float: none; ba=
ckground-color: transparent; color: rgb(34, 34, 34); font-family: &quot;Ari=
al&quot;,&quot;Helvetica&quot;,sans-serif; font-size: 13px; font-style: nor=
mal; font-variant: normal; font-weight: 400; letter-spacing: normal; orphan=
s: 2; text-align: left; text-decoration: none; text-indent: 0px; text-trans=
form: none; -webkit-text-stroke-width: 0px; white-space: normal; word-spaci=
ng: 0px;">a purely additive change&quot;. It can&#39;t be purely additive w=
ithout the ability to mix things.</span>=C2=A0</div></div>

<p></p>

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

------=_Part_7662_1786684565.1516115258486--

------=_Part_7661_918328090.1516115258486--

.

------=_Part_127_436436560.1516116377395
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I didn=E2=80=99t phrase that particularly well. I think disallowing mixing =
is a good solution to the problems mentioned above.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/25766711-0481-41bd-a49e-24602bee3d80%40isocpp.or=
g.

------=_Part_127_436436560.1516116377395--

.

This is a multi-part message in MIME format.

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

> UTC Time: January 15, 2018 10:03 PM
> From: tvaneerd@gmail.com
>
> The current way encourages you to separate public from private. What's would the benefit be of the new way?

There is a huge benefit -- in a "patch" generated by
"diff", now you can clearly see what does the change
mean without including a context of growing length.
Local reasoning needs to apply to "patch" as well.

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent 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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7T92_SRiXOpMVxElyfIRmUsj2GZcreEN9fZxoqZu54a-r-eCYd9jHGSq-7U5XiH5sEIeyu-Mj2s3c3SotDF2Z-nNBCGMCDHqpQRdB7nycvY%3D%40miator.net.

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

<div><br></div><blockquote class=3D"protonmail_quote" type=3D"cite"><div>UT=
C Time: January 15, 2018 10:03 PM<br></div><div>From: tvaneerd@gmail.com<br=
></div><div><br></div><div dir=3D"ltr"><div class=3D"gmail_extra"><div clas=
s=3D"gmail_quote"><div>The current way encourages you to separate public fr=
om private. What's would the benefit be of the new way?<br></div></div></di=
v></div></blockquote><div><br></div><div>There is a huge benefit -- in a "p=
atch" generated by<br></div><div>"diff", now you can clearly see what does =
the change<br></div><div>mean without including a context of growing length=
..<br></div><div>Local reasoning needs to apply to "patch" as well.<br></div=
><div><br></div><div><br></div><div class=3D"protonmail_signature_block"><d=
iv class=3D"protonmail_signature_block-user"><div><div class=3D"protonmail_=
signature_block"><div class=3D"protonmail_signature_block-user"><div>--<br>=
</div><div><span>Zhihao Yuan, ID lichray<br>The best way to predict the fut=
ure is to invent it.<br>_______________________________________________</sp=
an></div></div><div class=3D"protonmail_signature_block-proton protonmail_s=
ignature_block-empty"><div><br></div></div></div></div></div></div><div><br=
></div>

<p></p>

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

--b1_2bd4016641d6b215dc98a9d20a227d46--


.

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

I don't support the proposal given that a near-as-damnit version can be
used with the addition of a colon. I always group my public, protected,
private methods up regardless of the language I'm using, and that's fairly
standard practice, so all this would do is add noise. I'm not exactly
*against* the proposal, but as I can't see any benefits I cannot support
it. I'm also biased because I originally started out with PHP, C#, Java,
and other languages that use this form, and C++ allowing grouping like this
was like a breath of fresh air. We should do more of that.

In fact I wouldn't much mind the ability to do it with inline, const,
constexpr, static, template, noexcept etc. Not to a level where it gets
ugly (which is easy to get to, and nesting might be controversial), but I
also find myself grouping these naturally anyway - and when was the last
time you wrote a class with just one const method, or just one method with
a given template?


On 16 Jan 2018 15:07, "Nicol Bolas" <jmckesson@gmail.com> wrote:

 It can't be purely additive without the ability to mix things.


Why? If it works as it currently does for classes that use "public:" etc,
but you can create new classes that strictly use the "new" approach, then
it is still only additive - surely? Allowing mixing would made debugging
awkward:

class FreeAsInSpeech{
public // whoops. Forgot the colon.
        void thing();
        void another_thing(); // not visible outside A, breaks code needing
it.
};

struct ControllingCachedCalculatorThing{
protected // whoops. Forgot the colon.
        int x;
        int y; // oh no. Exposed to the outside world. Goodbye stability.
public:
        void set_y(int new_y){
               if(ridiculous_condition(new_y)){
                      y = new_y;
                      update();
               }
        }
        void update();
};

class FortKnox{
        public: std::string try_get_info(...); //whoops. Accidental colon.
        std::string get_top_secret_info(); // amazing security setup.
10/10. Great job.
};

I'm no fan of allowing hard-to-detect problems to arise from a single
character.

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

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

<div dir=3D"auto"><div class=3D"gmail_extra" dir=3D"auto"><div class=3D"gma=
il_quote" dir=3D"auto"><div dir=3D"auto" style=3D"font-family:sans-serif">I=
 don&#39;t support the proposal given that a near-as-damnit version can be =
used with the addition of a colon. I always group my public, protected, pri=
vate methods up regardless of the language I&#39;m using, and that&#39;s fa=
irly standard practice, so all this would do is add noise. I&#39;m not exac=
tly <i>against</i>=C2=A0the proposal, but as I can&#39;t see any benefits I=
 cannot support it. I&#39;m also biased because I originally started out wi=
th PHP, C#, Java, and other languages that use this form, and C++ allowing =
grouping like this was like a breath of fresh air. We should do more of tha=
t.</div><div dir=3D"auto" style=3D"font-family:sans-serif"><br></div><div d=
ir=3D"auto" style=3D"font-family:sans-serif">In fact I wouldn&#39;t much mi=
nd the ability to do it with inline, const, constexpr, static, template, no=
except etc. Not to a level where it gets ugly (which is easy to get to, and=
 nesting might be controversial), but I also find myself grouping these nat=
urally anyway - and when was the last time you wrote a class with just one =
const method, or just one method with a given template?</div><div dir=3D"au=
to" style=3D"font-family:sans-serif"><br></div></div><div class=3D"gmail_qu=
ote" dir=3D"auto"><br></div><div class=3D"gmail_quote">On 16 Jan 2018 15:07=
, &quot;Nicol Bolas&quot; &lt;<a href=3D"mailto:jmckesson@gmail.com">jmckes=
son@gmail.com</a>&gt; wrote:<br type=3D"attribution"><blockquote class=3D"q=
uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e=
x"><div dir=3D"ltr"><div class=3D"quoted-text"><span style=3D"color:rgb(34,=
34,34);font-family:Arial,Helvetica,sans-serif;font-size:13px;font-variant-n=
umeric:normal;font-variant-east-asian:normal">=C2=A0It can&#39;t be purely =
additive without the ability to mix things.</span>=C2=A0</div></div></block=
quote></div></div><div dir=3D"auto"><br></div><div dir=3D"auto">Why? If it =
works as it currently does for classes that use &quot;public:&quot; etc, bu=
t you can create new classes that strictly use the &quot;new&quot; approach=
, then it is still only additive - surely? Allowing mixing would made debug=
ging awkward:</div><div dir=3D"auto"><br></div><div dir=3D"auto"><div dir=
=3D"auto" style=3D"font-family:sans-serif">class FreeAsInSpeech{</div><div =
dir=3D"auto" style=3D"font-family:sans-serif">public // whoops. Forgot the =
colon.</div><div dir=3D"auto" style=3D"font-family:sans-serif">=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 void thing();</div><div dir=3D"auto" style=3D"font-family=
:sans-serif">=C2=A0 =C2=A0 =C2=A0 =C2=A0 void another_thing(); // not visib=
le outside A, breaks code needing it.</div><div dir=3D"auto" style=3D"font-=
family:sans-serif">};</div><div dir=3D"auto" style=3D"font-family:sans-seri=
f"><br></div><div dir=3D"auto" style=3D"font-family:sans-serif">struct Cont=
rollingCachedCalculatorThing{</div><div dir=3D"auto" style=3D"font-family:s=
ans-serif">protected // whoops. Forgot the colon.</div><div dir=3D"auto" st=
yle=3D"font-family:sans-serif">=C2=A0 =C2=A0 =C2=A0 =C2=A0 int x;</div><div=
 dir=3D"auto" style=3D"font-family:sans-serif">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
int y; // oh no. Exposed to the outside world. Goodbye stability.</div><div=
 dir=3D"auto" style=3D"font-family:sans-serif">public:</div><div dir=3D"aut=
o" style=3D"font-family:sans-serif">=C2=A0 =C2=A0 =C2=A0 =C2=A0 void set_y(=
int new_y){</div><div dir=3D"auto" style=3D"font-family:sans-serif">=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if(ridiculous_condition(new=
_y)){</div><div dir=3D"auto" style=3D"font-family:sans-serif">=C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 y =3D new_y=
;</div><div dir=3D"auto" style=3D"font-family:sans-serif">=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 update();</div>=
<div dir=3D"auto" style=3D"font-family:sans-serif">=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}</div><div dir=3D"auto" style=3D"font-famil=
y:sans-serif">=C2=A0 =C2=A0 =C2=A0 =C2=A0 }</div><div dir=3D"auto" style=3D=
"font-family:sans-serif">=C2=A0 =C2=A0 =C2=A0 =C2=A0 void update();</div><d=
iv dir=3D"auto" style=3D"font-family:sans-serif">};</div><div dir=3D"auto" =
style=3D"font-family:sans-serif"><br></div><div dir=3D"auto" style=3D"font-=
family:sans-serif">class FortKnox{</div><div dir=3D"auto" style=3D"font-fam=
ily:sans-serif">=C2=A0 =C2=A0 =C2=A0 =C2=A0 public: std::string try_get_inf=
o(...); //whoops. Accidental colon.</div><div dir=3D"auto" style=3D"font-fa=
mily:sans-serif">=C2=A0 =C2=A0 =C2=A0 =C2=A0 std::string get_top_secret_inf=
o(); // amazing security setup. 10/10. Great job.</div><div dir=3D"auto" st=
yle=3D"font-family:sans-serif">};</div><div dir=3D"auto" style=3D"font-fami=
ly:sans-serif"><br></div><div dir=3D"auto" style=3D"font-family:sans-serif"=
>I&#39;m no fan of allowing hard-to-detect problems to arise from a single =
character.</div></div></div>

<p></p>

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

--94eb2c139dbcbba3b10562e6b3d2--

.

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

On 16 Jan 2018 15:46, "Zhihao Yuan" <zy@miator.net> wrote:


UTC Time: January 15, 2018 10:03 PM
From: tvaneerd@gmail.com

The current way encourages you to separate public from private. What's
would the benefit be of the new way?


There is a huge benefit -- in a "patch" generated by
"diff", now you can clearly see what does the change
mean without including a context of growing length.
Local reasoning needs to apply to "patch" as well.


.... okay, excellent point. Though I have to say that a patch that requires
modifying access specifiers is less of a patch and more of a structural
modification. I'd expect to see this at a new minor version of an
application rather than as a patch, so I'm not convinced that this is
common.

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

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

<div dir=3D"auto"><br><div class=3D"gmail_extra" dir=3D"auto"><br><div clas=
s=3D"gmail_quote">On 16 Jan 2018 15:46, &quot;Zhihao Yuan&quot; &lt;<a href=
=3D"mailto:zy@miator.net">zy@miator.net</a>&gt; wrote:<br type=3D"attributi=
on"><blockquote class=3D"quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex"><div><br></div><blockquote class=3D"m_-1677906=
743664031226protonmail_quote" type=3D"cite"><div>UTC Time: January 15, 2018=
 10:03 PM<br></div><div>From: <a href=3D"mailto:tvaneerd@gmail.com" target=
=3D"_blank">tvaneerd@gmail.com</a><br></div><div class=3D"quoted-text"><div=
><br></div><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_=
quote"><div>The current way encourages you to separate public from private.=
 What&#39;s would the benefit be of the new way?<br></div></div></div></div=
></div></blockquote><div><br></div><div>There is a huge benefit -- in a &qu=
ot;patch&quot; generated by<br></div><div>&quot;diff&quot;, now you can cle=
arly see what does the change<br></div><div>mean without including a contex=
t of growing length.<br></div><div>Local reasoning needs to apply to &quot;=
patch&quot; as well.</div></blockquote></div></div><div dir=3D"auto"><br></=
div><div dir=3D"auto">... okay, excellent point. Though I have to say that =
a patch that requires modifying access specifiers is less of a patch and mo=
re of a structural modification. I&#39;d expect to see this at a new minor =
version of an application rather than as a patch, so I&#39;m not convinced =
that this is common.</div><div class=3D"gmail_extra" dir=3D"auto"></div></d=
iv>

<p></p>

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

--001a1149299c325c610562e6ccff--

.

------=_Part_7812_896328116.1516118647168
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Those are some good points; I understand that the style isn=E2=80=99t going=
 to liked by everyone. However I think your last example (the FortKnox one)=
 is actually an argument for the proposal. The =E2=80=9Calmost but not quit=
e=E2=80=9D method mentioned a few times (current access specifier system bu=
t on the same line) is dangerous because makes it look like you=E2=80=99re =
applying the access spec to a single declaration but really you aren=E2=80=
=99t.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/619e09d7-1995-4023-8e3c-489c5cd41b50%40isocpp.or=
g.

------=_Part_7812_896328116.1516118647168--

.

------=_Part_7888_471897936.1516118991328
Content-Type: text/plain; charset="UTF-8"

Regarding patches, I recall seeing similar arguments for using the static keyword per definition when possible instead of an unnamed namespace. Easier for grep and diff and whatever.

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

------=_Part_7888_471897936.1516118991328--

.