No if you read through the whole thing, I think you will find a proposal th=
ere.=C2=A0

Basically, he wants to declare a member function, then later define it, *al=
l within the class definition*

ie

class Foo {
public:
=C2=A0 =C2=A0 int func();

//...=C2=A0
private:
//...
=C2=A0 =C2=A0 Int func() { return 17; }
};

Which might help particularly with templates.=C2=A0

I think the private/public might be a problem. I would expect from compiler=
 error about redeclaration. But if you switched back to public, I'd be OK w=
ith that.


Sent=C2=A0from=C2=A0my=C2=A0BlackBerry=C2=A0portable=C2=A0Babbage=C2=A0Devi=
ce
=C2=A0 Original Message =C2=A0
From: Larry Evans
Sent: Saturday, November 14, 2015 4:43 PM
To: std-proposals@isocpp.org
Reply To: std-proposals@isocpp.org
Subject: [std-proposals] Re: Small contribution to readability (of at least=
 my code)

On 11/14/2015 01:14 PM, John Yates wrote:
> I attempt to have one class per header. This allows me to follow a
> file-wide organizing principle.
>=20
Hi John,

I'd guess This topic is better covered in other newsgroups.
Try googling "c++.moderated coding style" to find a better
place to post you message.

BTW, I like your idea:

a name should be introduced before being described

which is a rule I use.

-regards,
Larry



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

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

.

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

Hi Larry,

Thanks for the reply.  I posted to this list because my proposal is not a
request for help but rather a suggestion for a (small) language change.  It
adds no functionality so my note attempted to show how it might improve the
presentation of source.  Apparently I failed to convey that clearly enough
in my previous post.

In the following only the declaration followed by definition within a class
scope is disallowed:

// global scope
struct S;
struct S { int i; };
int f();
int f() { return 0; }  // OK

// within a namespace scope
namespace N {
  struct S;
  struct S { int i; };
  int f();
  int f() { return 0; }  // OK
}

// within a class scope
class C {
  struct S;
  struct S { int i; };
  int f();
  int f() { return 0; }  // ERROR!
};

I am proposing to allow that last case.

/john


On Sat, Nov 14, 2015 at 4:42 PM, Larry Evans <cppljevans@suddenlink.net>
wrote:

> On 11/14/2015 01:14 PM, John Yates wrote:
> > I attempt to have one class per header.  This allows me to follow a
> > file-wide organizing principle.
> >
> Hi John,
>
> I'd guess This topic is better covered in other newsgroups.
> Try googling "c++.moderated coding style" to find a better
> place to post you message.
>
> BTW, I like your idea:
>
>   a name should be introduced before being described
>
> which is a rule I use.
>
> -regards,
> Larry
>
>
>
> --
>
> ---
> 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/.

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

<div dir=3D"ltr">Hi Larry,<div><br></div><div>Thanks for the reply.=C2=A0 I=
 posted to this list because my proposal is not a request for help but rath=
er a suggestion for a (small) language change.=C2=A0 It adds no functionali=
ty so my note attempted to show how it might improve the presentation of so=
urce.=C2=A0 Apparently I failed to convey that clearly enough in my previou=
s post.</div><div><br></div><div>In the following only the declaration foll=
owed by definition within a class scope is disallowed:</div><div><br></div>=
<div><div><font face=3D"monospace, monospace">// global scope</font></div><=
div><font face=3D"monospace, monospace">struct S;</font></div><div><font fa=
ce=3D"monospace, monospace">struct S { int i; };</font></div><div><font fac=
e=3D"monospace, monospace">int f();</font></div><div><font face=3D"monospac=
e, monospace">int f() { return 0; } =C2=A0// OK</font></div><div><font face=
=3D"monospace, monospace"><br></font></div><div><font face=3D"monospace, mo=
nospace">// within a namespace scope</font></div><div><font face=3D"monospa=
ce, monospace">namespace N {</font></div><div><font face=3D"monospace, mono=
space">=C2=A0 struct S;</font></div><div><font face=3D"monospace, monospace=
">=C2=A0 struct S { int i; };</font></div><div><font face=3D"monospace, mon=
ospace">=C2=A0 int f();</font></div><div><font face=3D"monospace, monospace=
">=C2=A0 int f() { return 0; } =C2=A0// OK</font></div><div><font face=3D"m=
onospace, monospace">}</font></div><div><font face=3D"monospace, monospace"=
><br></font></div><div><font face=3D"monospace, monospace">// within a clas=
s scope</font></div><div><font face=3D"monospace, monospace">class C {</fon=
t></div><div><font face=3D"monospace, monospace">=C2=A0 struct S;</font></d=
iv><div><font face=3D"monospace, monospace">=C2=A0 struct S { int i; };</fo=
nt></div><div><font face=3D"monospace, monospace">=C2=A0 int f();</font></d=
iv><div><font face=3D"monospace, monospace">=C2=A0 int f() { return 0; } =
=C2=A0// ERROR!</font></div><div><font face=3D"monospace, monospace">};</fo=
nt></div></div><div><br></div><div>I am proposing to allow that last case.<=
/div><div><br></div><div>/john</div><div><br></div></div><div class=3D"gmai=
l_extra"><br><div class=3D"gmail_quote">On Sat, Nov 14, 2015 at 4:42 PM, La=
rry Evans <span dir=3D"ltr">&lt;<a href=3D"mailto:cppljevans@suddenlink.net=
" target=3D"_blank">cppljevans@suddenlink.net</a>&gt;</span> wrote:<br><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><span class=3D"">On 11/14/2015 01:14 PM, John Ya=
tes wrote:<br>
&gt; I attempt to have one class per header.=C2=A0 This allows me to follow=
 a<br>
&gt; file-wide organizing principle.<br>
&gt;<br>
</span>Hi John,<br>
<br>
I&#39;d guess This topic is better covered in other newsgroups.<br>
Try googling &quot;c++.moderated coding style&quot; to find a better<br>
place to post you message.<br>
<br>
BTW, I like your idea:<br>
<span class=3D""><br>
=C2=A0 a name should be introduced before being described<br>
<br>
</span>which is a rule I use.<br>
<br>
-regards,<br>
Larry<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
<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>

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

--047d7b15b215a51469052487422a--

.

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

I think there is a good idea in here.

Rather than making this narrow change, I'd prefer to see a larger proposal
for allowing a separate forward declaration of the public interface of a
class from the definition of the class.

Perhaps something like:

public class MyClass {
  MyClass(int = 0);

  int val() const;
  void val(int);
};

class MyClass {
public:
  MyClass(int = 0) { ... }

  int val() const { ... }
  void val(int) { ... }

private:
  int val_;
};

The compiler would check that the public interface forward declaration
matches the later class definition.  Consequently a human reader of the
header file only needs to read the public interface declaration, and isn't
distracted by implementation details, like inline function bodies and the
private section.  The interface documentation comments could be placed on
this forward declared public interface.

This is motivated by separating out interface specification from
implementation specification, which are fundamentally separate design
activities in software engineering.



On Sat, Nov 14, 2015 at 10:57 PM, John Yates <john@yates-sheets.org> wrote:

> Hi Larry,
>
> Thanks for the reply.  I posted to this list because my proposal is not a
> request for help but rather a suggestion for a (small) language change.  It
> adds no functionality so my note attempted to show how it might improve the
> presentation of source.  Apparently I failed to convey that clearly enough
> in my previous post.
>
> In the following only the declaration followed by definition within a
> class scope is disallowed:
>
> // global scope
> struct S;
> struct S { int i; };
> int f();
> int f() { return 0; }  // OK
>
> // within a namespace scope
> namespace N {
>   struct S;
>   struct S { int i; };
>   int f();
>   int f() { return 0; }  // OK
> }
>
> // within a class scope
> class C {
>   struct S;
>   struct S { int i; };
>   int f();
>   int f() { return 0; }  // ERROR!
> };
>
> I am proposing to allow that last case.
>
> /john
>
>
> On Sat, Nov 14, 2015 at 4:42 PM, Larry Evans <cppljevans@suddenlink.net>
> wrote:
>
>> On 11/14/2015 01:14 PM, John Yates wrote:
>> > I attempt to have one class per header.  This allows me to follow a
>> > file-wide organizing principle.
>> >
>> Hi John,
>>
>> I'd guess This topic is better covered in other newsgroups.
>> Try googling "c++.moderated coding style" to find a better
>> place to post you message.
>>
>> BTW, I like your idea:
>>
>>   a name should be introduced before being described
>>
>> which is a rule I use.
>>
>> -regards,
>> Larry
>>
>>
>>
>> --
>>
>> ---
>> 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/.
>

--

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

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

<div dir=3D"ltr">I think there is a good idea in here.<div><br></div><div>R=
ather than making this narrow change, I&#39;d prefer to see a larger propos=
al for allowing a separate forward declaration of the public interface of a=
 class from the definition of the class.</div><div><br></div><div>Perhaps s=
omething like:</div><div><br></div><div><font face=3D"monospace, monospace"=
 style=3D"font-size:12.8px">public class=C2=A0</font><span style=3D"font-si=
ze:12.8px;font-family:monospace,monospace">MyClass=C2=A0</span><span style=
=3D"font-size:12.8px;font-family:monospace,monospace">{</span><br></div><di=
v class=3D"gmail_extra"><div style=3D"font-size:12.8px"><font face=3D"monos=
pace, monospace" style=3D"font-size:12.8px">=C2=A0=C2=A0</font><span style=
=3D"font-size:12.8px;font-family:monospace,monospace">MyClass</span><span s=
tyle=3D"font-size:12.8px;font-family:monospace,monospace">(int =3D 0);</spa=
n><br></div><div style=3D"font-size:12.8px"><font face=3D"monospace, monosp=
ace"><br></font></div><div style=3D"font-size:12.8px"><font face=3D"monospa=
ce, monospace">=C2=A0 int val() const;</font></div><div style=3D"font-size:=
12.8px"><font face=3D"monospace, monospace">=C2=A0 void val(int);</font></d=
iv><div style=3D"font-size:12.8px">};</div><div style=3D"font-size:12.8px">=
<br></div><div style=3D"font-size:12.8px"><div style=3D"font-size:12.8px"><=
font face=3D"monospace, monospace">class=C2=A0</font><span style=3D"font-fa=
mily:monospace,monospace">MyClass=C2=A0</span><span style=3D"font-family:mo=
nospace,monospace;font-size:12.8px">{</span></div><div style=3D"font-size:1=
2.8px"><font face=3D"monospace, monospace">public:</font></div><div style=
=3D"font-size:12.8px"><font face=3D"monospace, monospace">=C2=A0=C2=A0</fon=
t><span style=3D"font-family:monospace,monospace">MyClass</span><span style=
=3D"font-family:monospace,monospace">(int =3D 0) { ... }</span></div><div s=
tyle=3D"font-size:12.8px"><font face=3D"monospace, monospace"><br></font></=
div><div style=3D"font-size:12.8px"><font face=3D"monospace, monospace">=C2=
=A0 int val() const { ... }</font></div><div style=3D"font-size:12.8px"><fo=
nt face=3D"monospace, monospace">=C2=A0 void val(int) { ... }</font></div><=
div style=3D"font-size:12.8px"><font face=3D"monospace, monospace"><br></fo=
nt></div><div style=3D"font-size:12.8px"><span style=3D"font-family:monospa=
ce,monospace;font-size:12.8px">private:</span><br></div><div style=3D"font-=
size:12.8px"><font face=3D"monospace, monospace">=C2=A0 int val_;</font></d=
iv><div style=3D"font-size:12.8px"><span style=3D"font-family:monospace,mon=
ospace;font-size:12.8px">};</span><br></div></div><div style=3D"font-size:1=
2.8px"><br></div><div style=3D"font-size:12.8px">The compiler would check t=
hat the public interface forward declaration matches the later class defini=
tion.=C2=A0 Consequently a human reader of the header file only needs to re=
ad the public interface declaration, and isn&#39;t distracted by implementa=
tion details, like inline function bodies and the private section.=C2=A0 Th=
e interface documentation comments could be placed on this forward declared=
 public interface.</div><div style=3D"font-size:12.8px"><br></div><div styl=
e=3D"font-size:12.8px">This is motivated by separating out interface specif=
ication from implementation specification, which are fundamentally separate=
 design activities in software engineering.</div><div style=3D"font-size:12=
..8px"><br></div><div style=3D"font-size:12.8px"><br></div><div style=3D"fon=
t-size:12.8px"><br></div></div><div class=3D"gmail_extra"><div class=3D"gma=
il_quote">On Sat, Nov 14, 2015 at 10:57 PM, John Yates <span dir=3D"ltr">&l=
t;<a href=3D"mailto:john@yates-sheets.org" target=3D"_blank">john@yates-she=
ets.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,2=
04,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr">Hi Larry=
,<div><br></div><div>Thanks for the reply.=C2=A0 I posted to this list beca=
use my proposal is not a request for help but rather a suggestion for a (sm=
all) language change.=C2=A0 It adds no functionality so my note attempted t=
o show how it might improve the presentation of source.=C2=A0 Apparently I =
failed to convey that clearly enough in my previous post.</div><div><br></d=
iv><div>In the following only the declaration followed by definition within=
 a class scope is disallowed:</div><div><br></div><div><div><font face=3D"m=
onospace, monospace">// global scope</font></div><div><font face=3D"monospa=
ce, monospace">struct S;</font></div><div><font face=3D"monospace, monospac=
e">struct S { int i; };</font></div><div><font face=3D"monospace, monospace=
">int f();</font></div><div><font face=3D"monospace, monospace">int f() { r=
eturn 0; } =C2=A0// OK</font></div><div><font face=3D"monospace, monospace"=
><br></font></div><div><font face=3D"monospace, monospace">// within a name=
space scope</font></div><div><font face=3D"monospace, monospace">namespace =
N {</font></div><div><font face=3D"monospace, monospace">=C2=A0 struct S;</=
font></div><div><font face=3D"monospace, monospace">=C2=A0 struct S { int i=
; };</font></div><div><font face=3D"monospace, monospace">=C2=A0 int f();</=
font></div><div><font face=3D"monospace, monospace">=C2=A0 int f() { return=
 0; } =C2=A0// OK</font></div><div><font face=3D"monospace, monospace">}</f=
ont></div><div><font face=3D"monospace, monospace"><br></font></div><div><f=
ont face=3D"monospace, monospace">// within a class scope</font></div><div>=
<font face=3D"monospace, monospace">class C {</font></div><div><font face=
=3D"monospace, monospace">=C2=A0 struct S;</font></div><div><font face=3D"m=
onospace, monospace">=C2=A0 struct S { int i; };</font></div><div><font fac=
e=3D"monospace, monospace">=C2=A0 int f();</font></div><div><font face=3D"m=
onospace, monospace">=C2=A0 int f() { return 0; } =C2=A0// ERROR!</font></d=
iv><div><font face=3D"monospace, monospace">};</font></div></div><div><br><=
/div><div>I am proposing to allow that last case.</div><span><font color=3D=
"#888888"><div><br></div><div>/john</div><div><br></div></font></span></div=
><div><div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Sat=
, Nov 14, 2015 at 4:42 PM, Larry Evans <span dir=3D"ltr">&lt;<a href=3D"mai=
lto:cppljevans@suddenlink.net" target=3D"_blank">cppljevans@suddenlink.net<=
/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>On 11/14/2015 01:14 PM, Joh=
n Yates wrote:<br>
&gt; I attempt to have one class per header.=C2=A0 This allows me to follow=
 a<br>
&gt; file-wide organizing principle.<br>
&gt;<br>
</span>Hi John,<br>
<br>
I&#39;d guess This topic is better covered in other newsgroups.<br>
Try googling &quot;c++.moderated coding style&quot; to find a better<br>
place to post you message.<br>
<br>
BTW, I like your idea:<br>
<span><br>
=C2=A0 a name should be introduced before being described<br>
<br>
</span>which is a rule I use.<br>
<br>
-regards,<br>
Larry<br>
<span><font color=3D"#888888"><br>
<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>
</font></span></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" 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 />

--001a1143c04e4052a3052491b1d4--

.

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

On Sat, Nov 14, 2015 at 4:51 PM, Tony V E <tvaneerd@gmail.com> wrote:

> I think the private/public might be a problem. I would expect from
> compiler error about redeclaration. But if you switched back to public, I'd
> be OK with that.
>

Indeed.  After experimenting with the following fragment I conclude that
requiring consistent access is current behavior.

class C {
// public introduction, definition in private section
public:
  struct Public;
private:
  struct Public { int i; };  // Error: redeclared with different access

// private introduction, definition in public section
private:
  struct Private;
public:
  struct Private { int i; };  // Error: redeclared with different access
};

/john

--

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

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
at, Nov 14, 2015 at 4:51 PM, Tony V E <span dir=3D"ltr">&lt;<a href=3D"mail=
to:tvaneerd@gmail.com" target=3D"_blank">tvaneerd@gmail.com</a>&gt;</span> =
wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8=
ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-sty=
le:solid;padding-left:1ex">I think the private/public might be a problem. I=
 would expect from compiler error about redeclaration. But if you switched =
back to public, I&#39;d be OK with that.<br></blockquote><div><br></div><di=
v>Indeed.=C2=A0 After experimenting with the following fragment I conclude =
that requiring consistent access is current behavior.=C2=A0</div><div><br><=
/div><div><font face=3D"monospace, monospace">class C {</font></div><div><f=
ont face=3D"monospace, monospace">// public introduction, definition in pri=
vate section</font></div><div><font face=3D"monospace, monospace">public:</=
font></div><div><font face=3D"monospace, monospace">=C2=A0 struct Public;</=
font></div><div><font face=3D"monospace, monospace">private:</font></div><d=
iv><font face=3D"monospace, monospace">=C2=A0 struct Public { int i; }; =C2=
=A0// Error: redeclared with different access</font></div><div><font face=
=3D"monospace, monospace"><br></font></div><div><font face=3D"monospace, mo=
nospace">// private introduction, definition in public section</font></div>=
<div><font face=3D"monospace, monospace">private:</font></div><div><font fa=
ce=3D"monospace, monospace">=C2=A0 struct Private;</font></div><div><font f=
ace=3D"monospace, monospace">public:</font></div><div><font face=3D"monospa=
ce, monospace">=C2=A0 struct Private { int i; };</font><span style=3D"font-=
family:monospace,monospace">=C2=A0</span><span style=3D"font-family:monospa=
ce,monospace">=C2=A0// Error:</span><span style=3D"font-family:monospace,mo=
nospace">=C2=A0</span><span style=3D"font-family:monospace,monospace">redec=
lared with different access</span></div><div><font face=3D"monospace, monos=
pace">};</font></div><div><br></div><div>/john</div><div><br></div></div></=
div></div>

<p></p>

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

--047d7b163235efcbd00524954a64--

.

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

On Sun, Nov 15, 2015 at 5:24 AM, Andrew Tomazos <andrewtomazos@gmail.com>
wrote:

> I'd prefer to see a larger proposal for allowing a separate forward
> declaration of the public interface of a class from the definition of the
> class.
>

My proposal feels like a very minor tweak to regularizes a small corner of
the language.  Given some mentoring I am willing to take a crack at turning
the suggestion into an official proposal.

I lack both the expertise and the bandwidth to develop such a more
ambitious proposal.

Sure, a true concept of interfaces in C++ might be nice but I am loath to
allow "better to be the enemy of good.".  My small suggestion addresses my
personal itch.

/john

--

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

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
un, Nov 15, 2015 at 5:24 AM, Andrew Tomazos <span dir=3D"ltr">&lt;<a href=
=3D"mailto:andrewtomazos@gmail.com" target=3D"_blank">andrewtomazos@gmail.c=
om</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,20=
4);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div>I&#39;d =
prefer to see a larger proposal for allowing a separate forward declaration=
 of the public interface of a class from the definition of the class.<br></=
div></div></blockquote><div><br></div><div>My proposal feels like a very mi=
nor tweak to regularizes a small corner of the language.=C2=A0 Given some m=
entoring I am willing to take a crack at turning the suggestion into an off=
icial proposal.<br></div><div><br></div><div><div>I lack both the expertise=
 and the bandwidth to develop such a more ambitious proposal.</div><div><br=
></div><div>Sure, a true concept of interfaces in C++ might be nice but I a=
m loath to allow &quot;better to be the enemy of good.&quot;.=C2=A0 My smal=
l suggestion addresses my personal itch.</div></div><div><br></div><div>/jo=
hn</div><div><br></div><div><br></div></div></div></div>

<p></p>

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

--047d7b2e3de8d26185052495690b--

.

On 15 November 2015 at 17:05, Nicol Bolas <jmckesson@gmail.com> wrote:
> Here's my feeling on this.
>
> Normally in C++, you aren't allowed to talk about a name before it gets
> used. If a name appears later in a file, too bad; you have to forward
> declare it or you get a compiler error.
>
> This is true everywhere... except in a class definition. There, you are
> allowed to talk about names that appear later in the class. This was
> specifically added to the language, because nowhere else does the language
> work this way. Adding this feature made compilers rather more difficult to
> write. But it makes code much easier to write, since you don't have to
> declare every member before writing the definitions of those member
> functions. Not to mention, it makes things like CRTP-mixins possible, where
> a base class can cast itself to the derived class type and access its
> members; that would not be possible if C++ didn't allow delayed name lookup.
>
> In short, it is a very good thing that C++ allows this.

Being able to declare member functions multiple times would not change that.

However, allowing multiple declarations increases implementation complexity.
This case is fairly easy:

struct X
{
    X();
    X();
};

as is this case:

struct X
{
    X();
    X() {}
};

this case adds complexity:

struct X
{
    X();
    X() = default;
};

Now, presumably, the in-class-definition default is to be handled the same way
as a defaulted definition outside the class definition. The icky part of that is
that the meaning of such a defaulted definition depends on whether there was
a previous declaration or not. That hurts code readability and being able to
reason about in-class defaulted definitions. In case some wonder whether
the meaning should be as it is for an in-class defaulted definition, then the
meaning of the first declaration depends on whether there's a
defaulted definition
later in the class definition.

Regarding the "easy cases" I mentioned, currently, gcc for instance diagnoses
completely identical overloads with the same code as it uses to
diagnose overloads
that have identical parameters but different return types. That does also mean
that it doesn't even try to check whether two identical declarations
in a class have
identical definitions; it doesn't need to, because it will reject the
overload. Consider:

struct X
{
    X() {}
    X() {} // should this be allowed? Should it be checked that the
definitions are identical?
};

None of these problems are insurmountable, but the motivation for
allowing multiple
identical declarations inside a class definition seems weak. I'd
expect very few programmers
to use it, and while the added implementation complexity isn't
necessarily huge, the
cost/benefit ratio doesn't seem to be very good.

--

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

.

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

On Mon, Nov 16, 2015 at 4:13 PM, Matthew Woehlke <mwoehlke.floss@gmail.com>
wrote:

> On 2015-11-15 05:24, Andrew Tomazos wrote:
> > I think there is a good idea in here.
> >
> > Rather than making this narrow change, I'd prefer to see a larger
> proposal
> > for allowing a separate forward declaration of the public interface of a
> > class from the definition of the class.
> >
> > Perhaps something like:
> >
> > public class MyClass {
> >   MyClass(int = 0);
> >
> >   int val() const;
> >   void val(int);
> > };
> >
> > class MyClass {
> > public:
> >   MyClass(int = 0) { ... }
> >
> >   int val() const { ... }
> >   void val(int) { ... }
> >
> > private:
> >   int val_;
> > };
>
> I don't think this will work. The size of the class needs to be known
> publicly. Adding NSDM's after the fact will break things. (And adding
> any other members opens a can of worms to abuse / circumvention of
> access protections.)
>

You've misunderstood how it works.  The class isn't complete (as usual)
until the class definition (the second thing).  The forward declaration of
the public interface doesn't complete the class type.  You still need the
definition.  You can't do anything with the public interface declaration
alone.

You can think of it as a compiler-checked description of the public
interface of the class.  The class definition then describes how the class
is implemented.  This is similar to the relationship between, say, a
template declaration and a template definition.  Yes, both (usually) need
to be in the header file.

--

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

--001a11474d1a1326a80524ab5580
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, Nov 16, 2015 at 4:13 PM, Matthew Woehlke <span dir=3D"ltr">&lt;=
<a href=3D"mailto:mwoehlke.floss@gmail.com" target=3D"_blank">mwoehlke.flos=
s@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span c=
lass=3D"">On 2015-11-15 05:24, Andrew Tomazos wrote:<br>
&gt; I think there is a good idea in here.<br>
&gt;<br>
&gt; Rather than making this narrow change, I&#39;d prefer to see a larger =
proposal<br>
&gt; for allowing a separate forward declaration of the public interface of=
 a<br>
&gt; class from the definition of the class.<br>
&gt;<br>
&gt; Perhaps something like:<br>
&gt;<br>
&gt; public class MyClass {<br>
&gt;=C2=A0 =C2=A0MyClass(int =3D 0);<br>
&gt;<br>
&gt;=C2=A0 =C2=A0int val() const;<br>
&gt;=C2=A0 =C2=A0void val(int);<br>
&gt; };<br>
&gt;<br>
&gt; class MyClass {<br>
&gt; public:<br>
&gt;=C2=A0 =C2=A0MyClass(int =3D 0) { ... }<br>
&gt;<br>
&gt;=C2=A0 =C2=A0int val() const { ... }<br>
&gt;=C2=A0 =C2=A0void val(int) { ... }<br>
&gt;<br>
&gt; private:<br>
&gt;=C2=A0 =C2=A0int val_;<br>
&gt; };<br>
<br>
</span>I don&#39;t think this will work. The size of the class needs to be =
known<br>
publicly. Adding NSDM&#39;s after the fact will break things. (And adding<b=
r>
any other members opens a can of worms to abuse / circumvention of<br>
access protections.)<br></blockquote><div><br></div><div>You&#39;ve misunde=
rstood how it works.=C2=A0 The class isn&#39;t complete (as usual) until th=
e class definition (the second thing).=C2=A0 The forward declaration of the=
 public interface doesn&#39;t complete the class type.=C2=A0 You still need=
 the definition.=C2=A0 You can&#39;t do anything with the public interface =
declaration alone.</div><div><br></div><div>You can think of it as a compil=
er-checked description of the public interface of the class.=C2=A0 The clas=
s definition then describes how the class is implemented.=C2=A0 This is sim=
ilar to the relationship between, say, a template declaration and a templat=
e definition.=C2=A0 Yes, both (usually) need to be in the header file.</div=
><div><br></div></div></div></div>

<p></p>

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

--001a11474d1a1326a80524ab5580--

.

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

On Mon, Nov 16, 2015 at 6:19 PM, Matthew Woehlke <mwoehlke.floss@gmail.com>
wrote:

> On 2015-11-16 11:59, Andrew Tomazos wrote:
> > On Mon, Nov 16, 2015 at 4:13 PM, Matthew Woehlke wrote:
> >> On 2015-11-15 05:24, Andrew Tomazos wrote:
> >>> I think there is a good idea in here.
> >>>
> >>> Rather than making this narrow change, I'd prefer to see a larger
> >>> proposal for allowing a separate forward declaration of the
> >>> public interface of a class from the definition of the class.
> >>>
> >>> Perhaps something like:
> >>>
> >>> public class MyClass {
> >>>   MyClass(int = 0);
> >>>
> >>>   int val() const;
> >>>   void val(int);
> >>> };
> >>>
> >>> class MyClass {
> >>> public:
> >>>   MyClass(int = 0) { ... }
> >>>
> >>>   int val() const { ... }
> >>>   void val(int) { ... }
> >>>
> >>> private:
> >>>   int val_;
> >>> };
> >>
> >> I don't think this will work. The size of the class needs to be known
> >> publicly. Adding NSDM's after the fact will break things. (And adding
> >> any other members opens a can of worms to abuse / circumvention of
> >> access protections.)
> >
> > You've misunderstood how it works.  The class isn't complete (as usual)
> > until the class definition (the second thing).
>
> Ah. Yes, I missed that. Okay, well then, I dislike it for other reasons.
> Mainly, it does nothing to solve the redundancy when the method
> definitions are not inline in the class definition (e.g. when they are
> in a .cpp file). And yes, even for template classes, that can happen,
> either ".tpp" pattern, or due to explicit instantiation.
>

I'm not sure what you mean by "solve the redundancy".  What redundancy?  If
you mean the redundancy between an interface and implementation - that's a
feature, not a bug.

In fact, I have trouble seeing how your suggestion is in any meaningful
> way an improvement over what we have now. All you've really accomplished
> is adding a closing brace before the private members. That may look
> pretty, but it hardly seems worth a non-trivial change to both syntax
> and semantics.
>

It doesn't change any semantics.  It's more than adding a closing brace
before the private members.

In particular the forward declaration of the public interface wouldn't be
permitted to contain any definitions, it's purely a declaration.

For example, take a look at any of the class definitions of the containers
in any standard library implementation.

They are 1000+ lines long and even the public sections (plural) are 90%
implementation details.

Having the public interface separately declared at the top of the file is
better for the reader, as they don't need to wade through these
implementation details to learn the interface.  Yes, it's more work for the
writer to maintain this separate interface declaration.  As we should have
all been taught at school the reader has priority, for many reasons.

--

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

--001a11444496b9c7d40524acfed3
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, Nov 16, 2015 at 6:19 PM, Matthew Woehlke <span dir=3D"ltr">&lt;=
<a href=3D"mailto:mwoehlke.floss@gmail.com" target=3D"_blank">mwoehlke.flos=
s@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 2015=
-11-16 11:59, Andrew Tomazos wrote:<br>
<span class=3D"">&gt; On Mon, Nov 16, 2015 at 4:13 PM, Matthew Woehlke wrot=
e:<br>
&gt;&gt; On 2015-11-15 05:24, Andrew Tomazos wrote:<br>
&gt;&gt;&gt; I think there is a good idea in here.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Rather than making this narrow change, I&#39;d prefer to see a=
 larger<br>
&gt;&gt;&gt; proposal for allowing a separate forward declaration of the<br=
>
&gt;&gt;&gt; public interface of a class from the definition of the class.<=
br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Perhaps something like:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; public class MyClass {<br>
&gt;&gt;&gt;=C2=A0 =C2=A0MyClass(int =3D 0);<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;=C2=A0 =C2=A0int val() const;<br>
&gt;&gt;&gt;=C2=A0 =C2=A0void val(int);<br>
&gt;&gt;&gt; };<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; class MyClass {<br>
&gt;&gt;&gt; public:<br>
&gt;&gt;&gt;=C2=A0 =C2=A0MyClass(int =3D 0) { ... }<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;=C2=A0 =C2=A0int val() const { ... }<br>
&gt;&gt;&gt;=C2=A0 =C2=A0void val(int) { ... }<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; private:<br>
&gt;&gt;&gt;=C2=A0 =C2=A0int val_;<br>
&gt;&gt;&gt; };<br>
&gt;&gt;<br>
&gt;&gt; I don&#39;t think this will work. The size of the class needs to b=
e known<br>
&gt;&gt; publicly. Adding NSDM&#39;s after the fact will break things. (And=
 adding<br>
&gt;&gt; any other members opens a can of worms to abuse / circumvention of=
<br>
&gt;&gt; access protections.)<br>
&gt;<br>
&gt; You&#39;ve misunderstood how it works.=C2=A0 The class isn&#39;t compl=
ete (as usual)<br>
&gt; until the class definition (the second thing).<br>
<br>
</span>Ah. Yes, I missed that. Okay, well then, I dislike it for other reas=
ons.<br>
Mainly, it does nothing to solve the redundancy when the method<br>
definitions are not inline in the class definition (e.g. when they are<br>
in a .cpp file). And yes, even for template classes, that can happen,<br>
either &quot;.tpp&quot; pattern, or due to explicit instantiation.<br></blo=
ckquote><div>=C2=A0</div><div>I&#39;m not sure what you mean by &quot;solve=
 the redundancy&quot;.=C2=A0 What redundancy?=C2=A0 If you mean the redunda=
ncy between an interface and implementation - that&#39;s a feature, not a b=
ug.</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0=
 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In fact, I have trouble seeing how your suggestion is in any meaningful<br>
way an improvement over what we have now. All you&#39;ve really accomplishe=
d<br>
is adding a closing brace before the private members. That may look<br>
pretty, but it hardly seems worth a non-trivial change to both syntax<br>
and semantics.<br></blockquote><div>=C2=A0<br></div><div>It doesn&#39;t cha=
nge any semantics.=C2=A0 It&#39;s more than adding a closing brace before t=
he private members.</div><div><br></div><div>In particular the forward decl=
aration of the public interface wouldn&#39;t be permitted to contain any de=
finitions, it&#39;s purely a declaration.</div><div><br></div><div>For exam=
ple, take a look at any of the class definitions of the containers in any s=
tandard library implementation.</div><div><br></div><div>They are 1000+ lin=
es long and even the public sections (plural) are 90% implementation detail=
s.</div><div><br></div><div>Having the public interface separately declared=
 at the top of the file is better for the reader, as they don&#39;t need to=
 wade through these implementation details to learn the interface.=C2=A0 Ye=
s, it&#39;s more work for the writer to maintain this separate interface de=
claration.=C2=A0 As we should have all been taught at school the reader has=
 priority, for many reasons.</div><div><br></div></div></div></div>

<p></p>

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

--001a11444496b9c7d40524acfed3--

.

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

On Mon, Nov 16, 2015 at 8:41 PM, Matthew Woehlke <mwoehlke.floss@gmail.com>
wrote:

> On 2015-11-16 13:58, Andrew Tomazos wrote:
> > For example, take a look at any of the class definitions of the
> containers
> > in any standard library implementation.
> >
> > They are 1000+ lines long and even the public sections (plural) are 90%
> > implementation details.
>
> And why do you expect your proposal to "fix" this? That problem exists
> because library writers *don't care*.


The current technique of defining members outside the class is onerous.  In
particular you need to redeclare the enclosing class (and template) for
each member defined.  Defining members inside the class definition is much
easier because the enclosing class only needs to be declared once and is
thereafter implicit for the scope.  By providing a way to separately
declare the public interface, it allows library authors to continue to use
the class definition to conveniantly define members inline - while enabling
them to specify the public interface separately.

Given that it is less onerous, I expect it to be more popular than not
using inline member definitions.

(Note by "member definitions" I am not only thinking about inline member
functions.  I am also thinking about nested types, typedefs/aliases, member
variable initializers and member templates.)

--

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

--001a113d52e29bdee50524ba8e57
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, Nov 16, 2015 at 8:41 PM, Matthew Woehlke <span dir=3D"ltr">&lt;=
<a href=3D"mailto:mwoehlke.floss@gmail.com" target=3D"_blank">mwoehlke.flos=
s@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 2015=
-11-16 13:58, Andrew Tomazos wrote:<br><span class=3D"">&gt; For example, t=
ake a look at any of the class definitions of the containers<br>
&gt; in any standard library implementation.<br>
&gt;<br>
&gt; They are 1000+ lines long and even the public sections (plural) are 90=
%<br>
&gt; implementation details.<br>
<br>
</span>And why do you expect your proposal to &quot;fix&quot; this? That pr=
oblem exists<br>
because library writers *don&#39;t care*.=C2=A0</blockquote><div>=C2=A0</di=
v></div>The current technique of defining members outside the class is oner=
ous.=C2=A0 In particular you need to redeclare the enclosing class (and tem=
plate) for each member defined.=C2=A0 Defining members inside the class def=
inition is much easier because the enclosing class only needs to be declare=
d once and is thereafter implicit for the scope.=C2=A0 By providing a way t=
o separately declare the public interface, it allows library authors to con=
tinue to use the class definition to conveniantly define members inline - w=
hile enabling them to specify the public interface separately.</div><div cl=
ass=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Given that it is l=
ess onerous, I expect it to be more popular than not using inline member de=
finitions.</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_ex=
tra">(Note by &quot;member definitions&quot; I am not only thinking about i=
nline member functions.=C2=A0 I am also thinking about nested types, typede=
fs/aliases, member variable initializers and member templates.)</div><div c=
lass=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 />

--001a113d52e29bdee50524ba8e57--

.

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

One small issue I have with this is the current method lets you put
includes that only the inline functions rely on after the class
declaration. With this proposal this isn't possible.

The only way this case could work is with the "interface" idea:

public class MyClass {

  MyClass(int = 0);

  int val() const;

  void val(int);

};

// put includes here

class MyClass {

public:

  MyClass(int = 0) { ... }

  int val() const { ... }

  void val(int) { ... }

private:

  int val_;

};

Although I don't like that syntax. Not sure what would be best for that.

On Tue, Nov 17, 2015, 8:48 AM Matthew Woehlke <mwoehlke.floss@gmail.com>
wrote:

> On 2015-11-17 06:09, Andrew Tomazos wrote:
> > On Mon, Nov 16, 2015 at 8:41 PM, Matthew Woehlke wrote:
> >> On 2015-11-16 13:58, Andrew Tomazos wrote:
> >>> For example, take a look at any of the class definitions of the
> >>> containers in any standard library implementation.
> >>>
> >>> They are 1000+ lines long and even the public sections (plural) are 90%
> >>> implementation details.
> >>
> >> And why do you expect your proposal to "fix" this? That problem exists
> >> because library writers *don't care*.
> >
> > Defining members inside the class definition is much
> > easier because the enclosing class only needs to be declared once and is
> > thereafter implicit for the scope.
>
> ...but then you *must* provide definitions *in the header*. In
> non-template cases, this is usually a very bad thing to do. Even in some
> *template* cases it is undesirable. This makes your proposal of very
> limited utility in the majority of cases.
>
> > The current technique of defining members outside the class is onerous.
> In
> > particular you need to redeclare the enclosing class (and template) for
> > each member defined.
>
> I agree the *current* situation is less than ideal, but did you *read*
> my suggestion? Because this is *exactly* the problem I address...
>
> That said, I still have doubts that standard libraries are going to
> change. It may be onerous, but code is written once and read many times.
> If standard library authors cared about readability, they would make the
> effort, even if it is currently "onerous".
>
> For that matter, there's nothing stopping anyone from doing exactly like
> your proposal, only in a comment, right now. Again... *if* they cared.
>
> > Given that it is less onerous, I expect it to be more popular than not
> > using inline member definitions.
>
> Or... my suggestion makes *non-inline* definitions, which *are the right
> thing to do* more often than not, equally less onerous.
>
> > (Note by "member definitions" I am not only thinking about inline member
> > functions.  I am also thinking about nested types, typedefs/aliases,
> member
> > variable initializers and member templates.)
>
> Nested types can be forward declared already. How many type aliases a)
> do you *want* to be opaque, and b) have an RHS that is so long as to
> cause readability problems if they appear in the "public interface
> declaration"?
>
> (You'll note I didn't mention member initializers, even though the
> second half of the type alias argument applies here too. IMO it would be
> nice, albeit probably an orthogonal feature, if NSDM initializers could
> appear in a separate TU in the manner of SDM's. These would only be
> effective for non-default ctors whose definitions follow said
> initializers, but that shouldn't be a problem. Allowing this has similar
> benefits to non-inline member function definitions.)
>
> --
> Matthew
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> 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/.

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

<p dir=3D"ltr">One small issue I have with this is the current method lets =
you put includes that only the inline functions rely on after the class dec=
laration. With this proposal this isn&#39;t possible. </p>
<p dir=3D"ltr">The only way this case could work is with the &quot;interfac=
e&quot; idea:<br><br></p>
<p dir=3D"ltr">public class=C2=A0MyClass=C2=A0{</p>
<p dir=3D"ltr">=C2=A0=C2=A0MyClass(int =3D 0);<br></p>
<p dir=3D"ltr">=C2=A0 int val() const;</p>
<p dir=3D"ltr">=C2=A0 void val(int);</p>
<p dir=3D"ltr">};</p>
<p dir=3D"ltr">// put includes here</p>
<p dir=3D"ltr">class=C2=A0MyClass=C2=A0{</p>
<p dir=3D"ltr">public:</p>
<p dir=3D"ltr">=C2=A0=C2=A0MyClass(int =3D 0) { ... }<br></p>
<p dir=3D"ltr">=C2=A0 int val() const { ... }</p>
<p dir=3D"ltr">=C2=A0 void val(int) { ... }<br></p>
<p dir=3D"ltr">private:</p>
<p dir=3D"ltr">=C2=A0 int val_;</p>
<p dir=3D"ltr">};<br></p>
<p dir=3D"ltr">Although I don&#39;t like that syntax. Not sure what would b=
e best for that. <br></p>
<br><div class=3D"gmail_quote"><div dir=3D"ltr">On Tue, Nov 17, 2015, 8:48 =
AM=C2=A0Matthew Woehlke &lt;<a href=3D"mailto:mwoehlke.floss@gmail.com">mwo=
ehlke.floss@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
">On 2015-11-17 06:09, Andrew Tomazos wrote:<br>
&gt; On Mon, Nov 16, 2015 at 8:41 PM, Matthew Woehlke wrote:<br>
&gt;&gt; On 2015-11-16 13:58, Andrew Tomazos wrote:<br>
&gt;&gt;&gt; For example, take a look at any of the class definitions of th=
e<br>
&gt;&gt;&gt; containers in any standard library implementation.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; They are 1000+ lines long and even the public sections (plural=
) are 90%<br>
&gt;&gt;&gt; implementation details.<br>
&gt;&gt;<br>
&gt;&gt; And why do you expect your proposal to &quot;fix&quot; this? That =
problem exists<br>
&gt;&gt; because library writers *don&#39;t care*.<br>
&gt;<br>
&gt; Defining members inside the class definition is much<br>
&gt; easier because the enclosing class only needs to be declared once and =
is<br>
&gt; thereafter implicit for the scope.<br>
<br>
....but then you *must* provide definitions *in the header*. In<br>
non-template cases, this is usually a very bad thing to do. Even in some<br=
>
*template* cases it is undesirable. This makes your proposal of very<br>
limited utility in the majority of cases.<br>
<br>
&gt; The current technique of defining members outside the class is onerous=
..=C2=A0 In<br>
&gt; particular you need to redeclare the enclosing class (and template) fo=
r<br>
&gt; each member defined.<br>
<br>
I agree the *current* situation is less than ideal, but did you *read*<br>
my suggestion? Because this is *exactly* the problem I address...<br>
<br>
That said, I still have doubts that standard libraries are going to<br>
change. It may be onerous, but code is written once and read many times.<br=
>
If standard library authors cared about readability, they would make the<br=
>
effort, even if it is currently &quot;onerous&quot;.<br>
<br>
For that matter, there&#39;s nothing stopping anyone from doing exactly lik=
e<br>
your proposal, only in a comment, right now. Again... *if* they cared.<br>
<br>
&gt; Given that it is less onerous, I expect it to be more popular than not=
<br>
&gt; using inline member definitions.<br>
<br>
Or... my suggestion makes *non-inline* definitions, which *are the right<br=
>
thing to do* more often than not, equally less onerous.<br>
<br>
&gt; (Note by &quot;member definitions&quot; I am not only thinking about i=
nline member<br>
&gt; functions.=C2=A0 I am also thinking about nested types, typedefs/alias=
es, member<br>
&gt; variable initializers and member templates.)<br>
<br>
Nested types can be forward declared already. How many type aliases a)<br>
do you *want* to be opaque, and b) have an RHS that is so long as to<br>
cause readability problems if they appear in the &quot;public interface<br>
declaration&quot;?<br>
<br>
(You&#39;ll note I didn&#39;t mention member initializers, even though the<=
br>
second half of the type alias argument applies here too. IMO it would be<br=
>
nice, albeit probably an orthogonal feature, if NSDM initializers could<br>
appear in a separate TU in the manner of SDM&#39;s. These would only be<br>
effective for non-default ctors whose definitions follow said<br>
initializers, but that shouldn&#39;t be a problem. Allowing this has simila=
r<br>
benefits to non-inline member function definitions.)<br>
<br>
--<br>
Matthew<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 />

--089e0153701cf5b8840524beee6b--

.

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

I agree. This is a really good syntax, I was confused with the proposal
before.

I would really like to see this as I am creating a large library that has
one very large template class, and currently I have the functions in the
class declaration, which is sacrificing clarity.

I don't really like the use of namespace in the syntax though. It makes it
seem like it actually has to do with namespaces, which it doesn't.

-Russell

On Tue, Nov 17, 2015 at 5:10 PM Evan Teran <evan.teran@gmail.com> wrote:

>
>> Example:
>>
>>   class MyClass
>>   {
>>   public:
>>     MyClass(int = 0);
>>     int val() const;
>>     void set_val(int);
>>
>>   private:
>>     int m_val;
>>   };
>>
>>   // place "private" includes here
>>
>>   namespace class MyClass
>>   {
>>     MyClass(int) { ... }
>>     int val() const { ... }
>>     void set_val(int) { ... }
>>   }
>>
>
>
> I think this new syntax idea potentially provides real benefit. I like it
> a lot. One the motivating pain points of templates is that if you separate
> declaration from definition, you have to deal with very verbose template
> syntax. For example:
>
>
>
> template <class Ch, class Tr>
> class String {
> public:
>     void some_method();
>     void another_method();
> };
>
>
> template <class Ch, class Tr>
> void String<Ch, Tr>::some_method() {
>     // ...
> }
>
> template <class Ch, class Tr>
> void String<Ch, Tr>::another_method() {
>     // ...
> }
>
>
> If this could instead be written like the following code, then it would be
> simpler to read, write and maintain:
>
> template <class Ch, class Tr>
> class String {
> public:
>     void some_method();
> };
>
>
> template <class Ch, class Tr>
> namespace class String {
>
> void some_method() {
>     // ...
> }
>
>
> void another_method() {
>     // ...
> }
> }
>
> In my opinion this syntax or something similar to it, is:
>
> 1. easier to read, we get to drop the "noise" of the repeated template
> parameters, but it is still explicit enough to know what it means
>
> 2. easier to write, for single functions, there is a slight increase in
> code, but for a large group of functions, it can drastically reduce the
> amount of code while not sacrificing clarity.
>
> 3. easier to maintain, if a template parameter changes, we would need to
> change it far fewer places (two places instead of once per non-inline
> method)
>
> Like I said, I would very much welcome this as as option as long as the
> previous syntax doesn't get removed :-).
>
> --
>
> ---
> 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/.

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

<div dir=3D"ltr">I agree. This is a really good syntax, I was confused with=
 the proposal before.=C2=A0<div><br></div><div>I would really like to see t=
his as I am creating a large library that has one very large template class=
, and currently I have the functions in the class declaration, which is sac=
rificing clarity.=C2=A0</div><div><br></div><div>I don&#39;t really like th=
e use of namespace in the syntax though. It makes it seem like it actually =
has to do with namespaces, which it doesn&#39;t.</div><div><br></div><div>-=
Russell</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Tue, =
Nov 17, 2015 at 5:10 PM Evan Teran &lt;<a href=3D"mailto:evan.teran@gmail.c=
om">evan.teran@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail=
_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex"><div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0;m=
argin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><br>Example:
<br>
<br>=C2=A0 class MyClass
<br>=C2=A0 {
<br>=C2=A0 public:
<br>=C2=A0 =C2=A0 MyClass(int =3D 0);
<br>=C2=A0 =C2=A0 int val() const;
<br>=C2=A0 =C2=A0 void set_val(int);
<br>
<br>=C2=A0 private:
<br>=C2=A0 =C2=A0 int m_val;
<br>=C2=A0 };
<br>
<br>=C2=A0 // place &quot;private&quot; includes here
<br>
<br>=C2=A0 namespace class MyClass
<br>=C2=A0 {
<br>=C2=A0 =C2=A0 MyClass(int) { ... }
<br>=C2=A0 =C2=A0 int val() const { ... }
<br>=C2=A0 =C2=A0 void set_val(int) { ... }
<br>=C2=A0 }
<br>=C2=A0</blockquote><div><br></div></div><div dir=3D"ltr"><div>I think t=
his new syntax idea potentially provides real benefit. I like it a lot. One=
 the motivating pain points of templates is that if you separate declaratio=
n from definition, you have to deal with very verbose template syntax. For =
example:</div><div><br></div><div style=3D"border:1px solid rgb(187,187,187=
);word-wrap:break-word;background-color:rgb(250,250,250)"><code><div><span =
style=3D"color:#000"><br><br></span><span style=3D"color:#008">template</sp=
an><span style=3D"color:#000"> </span><span style=3D"color:#660">&lt;</span=
><span style=3D"color:#008">class</span><span style=3D"color:#000"> </span>=
<span style=3D"color:#606">Ch</span><span style=3D"color:#660">,</span><spa=
n style=3D"color:#000"> </span><span style=3D"color:#008">class</span><span=
 style=3D"color:#000"> </span><span style=3D"color:#606">Tr</span><span sty=
le=3D"color:#660">&gt;</span><span style=3D"color:#000"><br></span><span st=
yle=3D"color:#008">class</span><span style=3D"color:#000"> </span><span sty=
le=3D"color:#606">String</span><span style=3D"color:#000"> </span><span sty=
le=3D"color:#660">{</span><span style=3D"color:#000"><br></span><span style=
=3D"color:#008">public</span><span style=3D"color:#660">:</span><span style=
=3D"color:#000"><br>=C2=A0 =C2=A0 </span><span style=3D"color:#008">void</s=
pan><span style=3D"color:#000"> some_method</span><span style=3D"color:#660=
">();</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 </span><span style=
=3D"color:#008">void</span><span style=3D"color:#000"> another_method</span=
><span style=3D"color:#660">();</span><span style=3D"color:#000"><br></span=
><span style=3D"color:#660">};</span><span style=3D"color:#000"> <br><br><b=
r></span><span style=3D"color:#008">template</span><span style=3D"color:#00=
0"> </span><span style=3D"color:#660">&lt;</span><span style=3D"color:#008"=
>class</span><span style=3D"color:#000"> </span><span style=3D"color:#606">=
Ch</span><span style=3D"color:#660">,</span><span style=3D"color:#000"> </s=
pan><span style=3D"color:#008">class</span><span style=3D"color:#000"> </sp=
an><span style=3D"color:#606">Tr</span><span style=3D"color:#660">&gt;</spa=
n><span style=3D"color:#000"><br></span><span style=3D"color:#008">void</sp=
an><span style=3D"color:#000"> </span><span style=3D"color:#606">String</sp=
an><span style=3D"color:#660">&lt;</span><span style=3D"color:#606">Ch</spa=
n><span style=3D"color:#660">,</span><span style=3D"color:#000"> </span><sp=
an style=3D"color:#606">Tr</span><span style=3D"color:#660">&gt;::</span><s=
pan style=3D"color:#000">some_method</span><span style=3D"color:#660">()</s=
pan><span style=3D"color:#000"> </span><span style=3D"color:#660">{</span><=
span style=3D"color:#000"><br>=C2=A0 =C2=A0 </span><span style=3D"color:#80=
0">// ...</span><span style=3D"color:#000"><br></span><span style=3D"color:=
#660">}</span><span style=3D"color:#000"><br><br></span><span style=3D"colo=
r:#008">template</span><span style=3D"color:#000"> </span><span style=3D"co=
lor:#660">&lt;</span><span style=3D"color:#008">class</span><span style=3D"=
color:#000"> </span><span style=3D"color:#606">Ch</span><span style=3D"colo=
r:#660">,</span><span style=3D"color:#000"> </span><span style=3D"color:#00=
8">class</span><span style=3D"color:#000"> </span><span style=3D"color:#606=
">Tr</span><span style=3D"color:#660">&gt;</span><span style=3D"color:#000"=
><br></span><span style=3D"color:#008">void</span><span style=3D"color:#000=
"> </span><span style=3D"color:#606">String</span><span style=3D"color:#660=
">&lt;</span><span style=3D"color:#606">Ch</span><span style=3D"color:#660"=
>,</span><span style=3D"color:#000"> </span><span style=3D"color:#606">Tr</=
span><span style=3D"color:#660">&gt;::</span><span style=3D"color:#000">ano=
ther_method</span><span style=3D"color:#660">()</span><span style=3D"color:=
#000"> </span><span style=3D"color:#660">{</span><span style=3D"color:#000"=
><br>=C2=A0 =C2=A0 </span><span style=3D"color:#800">// ...</span><span sty=
le=3D"color:#000"><br></span><span style=3D"color:#660">}</span><span style=
=3D"color:#000"><br></span></div></code></div><div><br></div><div><br></div=
><div>If this could instead be written like the following code, then it wou=
ld be simpler to read, write and maintain:</div><div><br></div><div style=
=3D"border:1px solid rgb(187,187,187);word-wrap:break-word;background-color=
:rgb(250,250,250)"><code><div><span style=3D"color:#008">template</span><sp=
an style=3D"color:#000"> </span><span style=3D"color:#660">&lt;</span><span=
 style=3D"color:#008">class</span><span style=3D"color:#000"> </span><span =
style=3D"color:#606">Ch</span><span style=3D"color:#660">,</span><span styl=
e=3D"color:#000"> </span><span style=3D"color:#008">class</span><span style=
=3D"color:#000"> </span><span style=3D"color:#606">Tr</span><span style=3D"=
color:#660">&gt;</span><span style=3D"color:#000"><br></span><span style=3D=
"color:#008">class</span><span style=3D"color:#000"> </span><span style=3D"=
color:#606">String</span><span style=3D"color:#000"> </span><span style=3D"=
color:#660">{</span><span style=3D"color:#000"><br></span><span style=3D"co=
lor:#008">public</span><span style=3D"color:#660">:</span><span style=3D"co=
lor:#000"><br>=C2=A0 =C2=A0 </span><span style=3D"color:#008">void</span><s=
pan style=3D"color:#000"> some_method</span><span style=3D"color:#660">();<=
/span><span style=3D"color:#000"><br></span><span style=3D"color:#660">};</=
span><span style=3D"color:#000"> <br><br><br></span><span style=3D"color:#0=
08">template</span><span style=3D"color:#000"> </span><span style=3D"color:=
#660">&lt;</span><span style=3D"color:#008">class</span><span style=3D"colo=
r:#000"> </span><span style=3D"color:#606">Ch</span><span style=3D"color:#6=
60">,</span><span style=3D"color:#000"> </span><span style=3D"color:#008">c=
lass</span><span style=3D"color:#000"> </span><span style=3D"color:#606">Tr=
</span><span style=3D"color:#660">&gt;</span><span style=3D"color:#000"><br=
></span><span style=3D"color:#008">namespace</span><span style=3D"color:#00=
0"> </span><span style=3D"color:#008">class</span><span style=3D"color:#000=
"> </span><span style=3D"color:#606">String</span><span style=3D"color:#000=
"> </span><span style=3D"color:#660">{</span><span style=3D"color:#000"><br=
><br></span><span style=3D"color:#008">void</span><span style=3D"color:#000=
"> some_method</span><span style=3D"color:#660">()</span><span style=3D"col=
or:#000"> </span><span style=3D"color:#660">{</span><span style=3D"color:#0=
00"><br>=C2=A0 =C2=A0 </span><span style=3D"color:#800">// ...</span><span =
style=3D"color:#000"><br></span><span style=3D"color:#660">}</span><span st=
yle=3D"color:#000"><br><br><br></span><span style=3D"color:#008">void</span=
><span style=3D"color:#000"> another_method</span><span style=3D"color:#660=
">()</span><span style=3D"color:#000"> </span><span style=3D"color:#660">{<=
/span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 </span><span style=3D"co=
lor:#800">// ...</span><span style=3D"color:#000"><br></span><span style=3D=
"color:#660">}</span><span style=3D"color:#000"><br></span><span style=3D"c=
olor:#660">}</span></div></code></div><div><span style=3D"font-family:monos=
pace;color:rgb(102,102,0);background-color:rgb(250,250,250)"><br></span></d=
iv>In my opinion this syntax or something similar to it, is:<div><br></div>=
<div>1. easier to read, we get to drop the &quot;noise&quot; of the repeate=
d template parameters, but it is still explicit enough to know what it mean=
s</div><div><br></div><div>2. easier to write, for single functions, there =
is a slight increase in code, but for a large group of functions, it can dr=
astically reduce the amount of code while not sacrificing clarity.</div><di=
v><br></div><div>3. easier to maintain, if a template parameter changes, we=
 would need to change it far fewer places (two places instead of once per n=
on-inline method)</div><div><br></div><div>Like I said, I would very much w=
elcome this as as option as long as the previous syntax doesn&#39;t get rem=
oved :-).</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" 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>
</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 />

--001a113ce72a70ab280524c8d724--

.

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

On Wed, Nov 18, 2015 at 10:26 AM, Matthew Woehlke <mwoehlke.floss@gmail.com>
wrote:

> Sure. Syntax is open for discussion; I agree the "namespace class" is
> potentially dubious (partly why I originally wrote "<block scope>"
> rather than suggesting an actual syntax).
>

I think syntax of the form

<access> [ template <...> ] class <identifier> { ... };

is unambiguous.  It clearly calls out that this is something distinct from
a class definition.  It factors out the painful naming and clearly defines
the access so that current checks can continue to be enforced.  It has the
somewhat geeky property that the 'factored' elements all appear ahead of
the class token :-)

/john

--

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

--047d7bea3f8cdbd0ba0524d344e9
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 18, 2015 at 10:26 AM, Matthew Woehlke <span dir=3D"ltr">&lt;<a href=
=3D"mailto:mwoehlke.floss@gmail.com" target=3D"_blank">mwoehlke.floss@gmail=
..com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,=
204);border-left-style:solid;padding-left:1ex">Sure. Syntax is open for dis=
cussion; I agree the &quot;namespace class&quot; is<br>
potentially dubious (partly why I originally wrote &quot;&lt;block scope&gt=
;&quot;<br>
rather than suggesting an actual syntax).<br></blockquote><div><br></div><d=
iv>I think syntax of the form<br><br></div><div><span style=3D"font-family:=
monospace,monospace">&lt;access&gt;</span><span style=3D"font-family:monosp=
ace,monospace">=C2=A0</span><font face=3D"monospace, monospace">[ template =
&lt;...&gt; ] class &lt;identifier&gt; { ... };</font></div><div><br></div>=
<div>is unambiguous.=C2=A0 It clearly calls out that this is something dist=
inct from a class definition.=C2=A0 It factors out the painful naming and c=
learly defines the access so that current checks can continue to be enforce=
d.=C2=A0 It has the somewhat geeky property that the &#39;factored&#39; ele=
ments all appear ahead of the class token :-)</div><div><br></div><div>/joh=
n</div><div><br></div></div></div></div>

<p></p>

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

--047d7bea3f8cdbd0ba0524d344e9--

.

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

On Thu, Nov 19, 2015 at 11:20 AM, Evan Teran <evan.teran@gmail.com> wrote:

> I agree with Matthew here about access specifier, I don't think it is
> useful (or simpler) to have a separate scope for each access type. As
> Matthew said, it's not a c++ namespace, but it is a namespace in
> the colloquial English sense, so it's not like it is complete nonsense.
>

Agreed.


> Perhaps this would be a good place to re-use the now defunct export
> keyword or similar? (I would have actually favored "extern" more since the
> definition of of the functions are "external". But yea, generically
> something like this is what I would prefer.
>
> [ template <...> ] <keyword> class <identifier> { ... }
>

I am comfortable with Matthew's defense of namespace being the appropriate
value for <keyword>.


> Also note, that I removed the semicolon at the end. This isn't declaring a
> class, it is defining methods of an already defined class. Similar to how
> namespace doesn't require the semicolon.
>

That make sense.  In the absence of a template prefix having the keyword
namespace first should help newcomers understand that no semicolon is
needed.  (I understand the "declarations get a semicolon, definitions get a
block" logic.  But that it not how I have internalized the syntax.  To me
it is simply aggregates get a semicolon, namespaces do not.  I suspect that
I am not the lone simpleton :-)

/john

--

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

--e89a8ff1cb18c680ea0524e78406
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 19, 2015 at 11:20 AM, Evan Teran <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:evan.teran@gmail.com" target=3D"_blank">evan.teran@gmail.com</a>&gt;<=
/span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>I agr=
ee with Matthew here about access specifier, I don&#39;t think it is useful=
 (or simpler) to have a separate scope for each access type. As Matthew sai=
d, it&#39;s not a c++ namespace, but it is a namespace in the=C2=A0colloqui=
al English sense, so it&#39;s not like it is complete nonsense.<br></div></=
div></blockquote><div><br></div><div>Agreed.</div><div>=C2=A0</div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr"><div>Perhaps this would be a good p=
lace to re-use the now defunct export keyword or similar? (I would have act=
ually favored &quot;extern&quot; more since=C2=A0the definition of of the f=
unctions are &quot;external&quot;. But yea, generically something like this=
 is what I would prefer.<br></div><div><div><br></div><div>[ template &lt;.=
...&gt; ] &lt;keyword&gt; class &lt;identifier&gt; { ... }</div></div></div>=
</blockquote><div><br></div><div>I am comfortable with Matthew&#39;s defens=
e of namespace being the appropriate value for &lt;keyword&gt;.</div><div>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Also note,=
 that I removed the semicolon at the end. This isn&#39;t declaring a class,=
 it is defining methods of an already defined class. Similar to how namespa=
ce doesn&#39;t require the semicolon.</div></div></blockquote><div><br></di=
v><div>That make sense.=C2=A0 In the absence of a template prefix having th=
e keyword namespace first should help newcomers understand that no semicolo=
n is needed. =C2=A0(I understand the &quot;declarations get a semicolon, de=
finitions get a block&quot; logic.=C2=A0 But that it not how I have interna=
lized the syntax.=C2=A0 To me it is simply aggregates get a semicolon, name=
spaces do not.=C2=A0 I suspect that I am not the lone simpleton :-)</div><d=
iv><br></div><div>/john</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 />

--e89a8ff1cb18c680ea0524e78406--

.

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

On Thu, Nov 19, 2015 at 10:39 AM, Matthew Woehlke <mwoehlke.floss@gmail.com>
wrote:

> Assuming you mean that as a syntax for my proposal, I don't like it. It
> violates DRY (making you repeat the access specification), and requires
> a separate scope block for each access level.
>

I am an ardent proponent of DRY so I am please to see you invoke
it as an argument against my suggestion.  Indeed I much prefer
not having to supply access.


> FWIW, I disagree that a class is not a namespace. I mean, obviously it's
> not exactly a "namespace" (C++ keyword), but it is a name scope (i.e.
> "name space" in colloquial English).


I agree entirely.  My suggestion was merely a groping for a solution
that eschewed namespace while introducing no new keywords.

/john

--

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

--001a11383f9c56b35e0524e98fc2
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 19, 2015 at 10:39 AM, Matthew Woehlke <span dir=3D"ltr">&lt;<a href=
=3D"mailto:mwoehlke.floss@gmail.com" target=3D"_blank">mwoehlke.floss@gmail=
..com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Assuming you m=
ean that as a syntax for my proposal, I don&#39;t like it. It<br>
violates DRY (making you repeat the access specification), and requires<br>
a separate scope block for each access level.<br></blockquote><div><br></di=
v><div>I am an ardent proponent of DRY so I am please to see you invoke</di=
v><div>it as an argument against my suggestion.=C2=A0 Indeed I much prefer<=
/div><div>not having to supply access.</div><div>=C2=A0</div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex">FWIW, I disagree that a class is not a namespace. I mean, =
obviously it&#39;s<br>
not exactly a &quot;namespace&quot; (C++ keyword), but it is a name scope (=
i.e.<br>
&quot;name space&quot; in colloquial English).</blockquote><div>=C2=A0</div=
><div>I agree entirely.=C2=A0 My suggestion was merely a groping for a solu=
tion</div><div>that eschewed namespace while introducing no new keywords.</=
div><div><br></div><div>/john</div><div><br></div><div><br></div></div></di=
v></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 />

--001a11383f9c56b35e0524e98fc2--

.