Topic: Add "class namespace {" thus giving better
Author: db0451@gmail.com
Date: Fri, 8 Jul 2016 11:18:59 -0700 (PDT)
Raw View
------=_Part_641_627604005.1468001939722
Content-Type: multipart/alternative;
boundary="----=_Part_642_343191228.1468001939723"
------=_Part_642_343191228.1468001939723
Content-Type: text/plain; charset=UTF-8
Well, it's worth a shot! This is my 1st proposal, and it's very simple. My
proposal is to add an 'overload' for the class and namespace keywords to
provide an (example name) "*class namespace Thingy {*" block.
This will add enclosed definitions to the tagged class by implicitly
scoping them with Thing:: and will otherwise reflect namespaces.
As well as simply promoting DRY, this is arguably far more intuitive as it
brings semantics of namespace, with which class scoping shares syntax.
Plus, visually, it would enable better organisation and semantic grouping
of class member (functions, static variable) definitions and make
implementation files better resemble headers (again, good for organisation,
plus just convenient).
There might be a good reason why an equivalent construct doesn't already
exist! If so, please correct my ignorance. Otherwise, let's have a look at
what we currently must do:
*Thingy.hpp:*
class Thingy {
static unsigned s_instances;
int m_value;
int getValue() const;
void setValue(int);
};
*Thingy.cpp:*
unsigned Thingy::s_instances{0};
int Thingy::get_value() const { /* ... */ }
void Thingy::set_value(int const value) { /* ... */}
Personally I don't find all the typing required to scope things tooo much
of a hassle, but it clearly isn't DRY.
Additionally, users might rightly wonder why they can avoid the explicit
scoping with namespaces but not with classes. After all, the syntax is the
same, and so is the concept: you're adding definitions to an enclosing
realm.
So, what if we could combine the two? It's not only DRY: It would enable
better organisation of a file in case it has things like file-statics,
other namespaces, etc. Plus, visually, it would just look *nice*, and
intuitive.
With this ability, the resulting implementation file might look something
like this:
*Thingy.cpp:*
// unrelated stuff
// nice enclosed organisation of Thingy members, plus clear visual parallel
to the class def in header
class namespace Thingy { // means 'when defining things within these
braces, lookup/define them as members within Thingy::'
unsigned s_instances{0};
int get_value() const { /* ... */ }
void set_value(int const value) { /* ... */}
}
// other stuff
I envision it otherwise working just like namespaces, e.g. you could add
more stuff later if you really wanted. However, personally I'd probably
just keep all definitions together. But I see no reason to split them
though.
Thoughts? Is this something that's been considered and discounted for
umpteen fundamental reasons long ago? I suspect so... as it's just too
logical an extension of namespaces for it to have been overlooked ;-)
Either way, I'd love to hear any feedback.
--
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/5b830fb5-8db2-484b-8fc3-9ec0f57a6ebf%40isocpp.org.
------=_Part_642_343191228.1468001939723
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Well, it's worth a shot! This is my 1st proposal, and =
it's very simple. My proposal is to add an 'overload' for the <=
span style=3D"font-family: courier new,monospace;">class</span> and <span s=
tyle=3D"font-family: courier new,monospace;">namespace</span> keywords to p=
rovide an (example name) "<b><span style=3D"font-family: courier new,m=
onospace;">class namespace Thingy {</span></b>" block.<br>This will ad=
d enclosed definitions to the tagged class by implicitly scoping them with =
Thing:: and will otherwise reflect namespaces.<br><br>As well as simply pro=
moting DRY, this is arguably far more intuitive as it brings semantics of n=
amespace, with which class scoping shares syntax.<br>Plus, visually, it wou=
ld enable better organisation and semantic grouping of class member (functi=
ons, static variable) definitions and make implementation files better rese=
mble headers (again, good for organisation, plus just convenient).<br><br>T=
here might be a good reason why an equivalent construct doesn't already=
exist! If so, please correct my ignorance. Otherwise, let's have a loo=
k at what we currently must do:<br><br><span style=3D"color: rgb(120, 63, 4=
);"><font size=3D"2"><span style=3D"font-family: courier new,monospace;"><b=
>Thingy.hpp:</b><br><div class=3D"prettyprint" style=3D"background-color: r=
gb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: solid; b=
order-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div =
class=3D"subprettyprint"><span style=3D"color: rgb(120, 63, 4);"><font size=
=3D"2"><span style=3D"font-family: courier new,monospace;"><span style=3D"c=
olor: #008;" class=3D"styled-by-prettify">class</span><span style=3D"color:=
#000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" c=
lass=3D"styled-by-prettify">Thingy</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"styled=
-by-prettify">static</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify"=
>unsigned</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
s_instances</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br>=
=C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-pretti=
fy">int</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> m_=
value</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br>=C2=A0=
=C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-prettify">in=
t</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> getValue=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">()</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span styl=
e=3D"color: #008;" class=3D"styled-by-prettify">const</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"c=
olor: #008;" class=3D"styled-by-prettify">void</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> setValue</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #008;" cla=
ss=3D"styled-by-prettify">int</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">);</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">};</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br=
></span></span></font></span></div></code></div><br><b>Thingy.cpp:</b><br><=
div class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); bo=
rder-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; wor=
d-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subprettypri=
nt"><span style=3D"color: rgb(120, 63, 4);"><span style=3D"font-family: cou=
rier new,monospace;"><span style=3D"color: #008;" class=3D"styled-by-pretti=
fy">unsigned</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">Thingy<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify">s_instances</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span styl=
e=3D"color: #066;" class=3D"styled-by-prettify">0</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">};</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"><br><br></span><span style=3D"color: #008;" =
class=3D"styled-by-prettify">int</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"style=
d-by-prettify">Thingy</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y">get_value</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">()</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </spa=
n><span style=3D"color: #008;" class=3D"styled-by-prettify">const</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #800;" =
class=3D"styled-by-prettify">/* ... */</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">}</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"><br><br></span><span style=3D"color: #008;" class=3D"styled-by-pr=
ettify">void</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">Thingy<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify">set_value</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">int</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;=
" class=3D"styled-by-prettify">const</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> value</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span style=3D"color: #800;" class=3D"styled-by-prettify">/* ... */</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span></spa=
n></span></div></code></div></span></font></span><br>Personally I don't=
find all the typing required to scope things tooo much of a hassle, but it=
clearly isn't DRY.<br>Additionally, users might rightly wonder why the=
y can avoid the explicit scoping with namespaces but not with classes. Afte=
r all, the syntax is the same, and so is the concept: you're adding def=
initions to an enclosing realm.<br><br>So, what if we could combine the two=
? It's not only DRY: It would enable better organisation of a file in c=
ase it has things like file-statics, other namespaces, etc. Plus, visually,=
it would just look <i>nice</i>, and intuitive.<br><br>With this ability, t=
he resulting implementation file might look something like this:<br><br><sp=
an style=3D"font-family: courier new,monospace;"><span style=3D"color: rgb(=
39, 78, 19);"><b>Thingy.cpp:</b><br></span><div class=3D"prettyprint" style=
=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187);=
border-style: solid; border-width: 1px; word-wrap: break-word;"><code clas=
s=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"font-family:=
courier new,monospace;"><span style=3D"color: rgb(39, 78, 19);"><span styl=
e=3D"color: #800;" class=3D"styled-by-prettify">// unrelated stuff</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"><br><br></span><spa=
n style=3D"color: #800;" class=3D"styled-by-prettify">// nice enclosed orga=
nisation of Thingy members, plus clear visual parallel to the class def in =
header</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
</span><span style=3D"color: #008;" class=3D"styled-by-prettify">class</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span s=
tyle=3D"color: #008;" class=3D"styled-by-prettify">namespace</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"co=
lor: #606;" class=3D"styled-by-prettify">Thingy</span><span style=3D"color:=
#000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> </span><span style=3D"color: #800;" class=3D"styled-by-=
prettify">// means 'when defining things within these braces, lookup/de=
fine them as members within Thingy::'</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"colo=
r: #008;" class=3D"styled-by-prettify">unsigned</span><span style=3D"color:=
#000;" class=3D"styled-by-prettify"> s_instances</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #066;"=
class=3D"styled-by-prettify">0</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">};</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"><br><br>=C2=A0 =C2=A0 </span><span style=3D"color: #008;" clas=
s=3D"styled-by-prettify">int</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> get_value</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">()</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify"=
>const</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D=
"color: #800;" class=3D"styled-by-prettify">/* ... */</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">}</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"><br><br>=C2=A0 =C2=A0 </span><span style=3D"color:=
#008;" class=3D"styled-by-prettify">void</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> set_value</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">(</span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">int</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-pr=
ettify">const</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> value</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #800;" class=3D"styled-by-prettify">/* ... */</span><span style=3D"color:=
#660;" class=3D"styled-by-prettify">}</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">}</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br><br></span><span style=3D"color: #800;" class=3D"styled-=
by-prettify">// other stuff</span></span></span></div></code></div><br><fon=
t face=3D"arial,sans-serif">I envision it otherwise working just like names=
paces, e.g. you could add more stuff later if you really wanted. However, p=
ersonally I'd probably just keep all definitions together. But I see no=
reason to split them though.<br><br>Thoughts? Is this something that's=
been considered and discounted for umpteen fundamental reasons long ago? I=
suspect so... as it's just too logical an extension of namespaces for =
it to have been overlooked ;-)<br><br>Either way, I'd love to hear any =
feedback.<br><br></font></span></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/5b830fb5-8db2-484b-8fc3-9ec0f57a6ebf%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5b830fb5-8db2-484b-8fc3-9ec0f57a6ebf=
%40isocpp.org</a>.<br />
------=_Part_642_343191228.1468001939723--
------=_Part_641_627604005.1468001939722--
.
Author: "D. B." <db0451@gmail.com>
Date: Fri, 8 Jul 2016 11:28:00 -0700 (PDT)
Raw View
------=_Part_2_1787109321.1468002480657
Content-Type: multipart/alternative;
boundary="----=_Part_3_1280647505.1468002480658"
------=_Part_3_1280647505.1468002480658
Content-Type: text/plain; charset=UTF-8
I should clarify that I'm more than open to alternative names/keywords for
this - and I don't just mean "namespace class", which is starting to seem
better ;-) It's the concept of being able to scope member definitions this
way that interests me, not its specific name. However I thought this one
was fairly logical and not ambiguous with any existing syntax.
--
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/c563e212-c1e7-4918-b974-aecb07e940d0%40isocpp.org.
------=_Part_3_1280647505.1468002480658
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I should clarify that I'm more than open to alternativ=
e names/keywords for this - and I don't just mean "namespace class=
", which is starting to seem better ;-) It's the concept of being =
able to scope member definitions this way that interests me, not its specif=
ic name. However I thought this one was fairly logical and not ambiguous wi=
th any existing syntax.<br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/c563e212-c1e7-4918-b974-aecb07e940d0%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c563e212-c1e7-4918-b974-aecb07e940d0=
%40isocpp.org</a>.<br />
------=_Part_3_1280647505.1468002480658--
------=_Part_2_1787109321.1468002480657--
.
Author: "T. C." <rs2740@gmail.com>
Date: Fri, 8 Jul 2016 11:57:36 -0700 (PDT)
Raw View
------=_Part_802_866483929.1468004256251
Content-Type: multipart/alternative;
boundary="----=_Part_803_1557810708.1468004256251"
------=_Part_803_1557810708.1468004256251
Content-Type: text/plain; charset=UTF-8
On Friday, July 8, 2016 at 2:19:00 PM UTC-4, D. B. wrote:
>
> Well, it's worth a shot! This is my 1st proposal, and it's very simple. My
> proposal is to add an 'overload' for the class and namespace keywords to
> provide an (example name) "*class namespace Thingy {*" block.
> This will add enclosed definitions to the tagged class by implicitly
> scoping them with Thing:: and will otherwise reflect namespaces.
>
> As well as simply promoting DRY, this is arguably far more intuitive as it
> brings semantics of namespace, with which class scoping shares syntax.
> Plus, visually, it would enable better organisation and semantic grouping
> of class member (functions, static variable) definitions and make
> implementation files better resemble headers (again, good for organisation,
> plus just convenient).
>
> There might be a good reason why an equivalent construct doesn't already
> exist! If so, please correct my ignorance. Otherwise, let's have a look at
> what we currently must do:
>
> *Thingy.hpp:*
> class Thingy {
> static unsigned s_instances;
>
> int m_value;
>
> int getValue() const;
> void setValue(int);
> };
>
> *Thingy.cpp:*
> unsigned Thingy::s_instances{0};
>
> int Thingy::get_value() const { /* ... */ }
>
> void Thingy::set_value(int const value) { /* ... */}
>
> Personally I don't find all the typing required to scope things tooo much
> of a hassle, but it clearly isn't DRY.
> Additionally, users might rightly wonder why they can avoid the explicit
> scoping with namespaces but not with classes. After all, the syntax is the
> same, and so is the concept: you're adding definitions to an enclosing
> realm.
>
> So, what if we could combine the two? It's not only DRY: It would enable
> better organisation of a file in case it has things like file-statics,
> other namespaces, etc. Plus, visually, it would just look *nice*, and
> intuitive.
>
> With this ability, the resulting implementation file might look something
> like this:
>
> *Thingy.cpp:*
> // unrelated stuff
>
> // nice enclosed organisation of Thingy members, plus clear visual
> parallel to the class def in header
> class namespace Thingy { // means 'when defining things within these
> braces, lookup/define them as members within Thingy::'
> unsigned s_instances{0};
>
> int get_value() const { /* ... */ }
>
> void set_value(int const value) { /* ... */}
> }
>
> // other stuff
>
> I envision it otherwise working just like namespaces, e.g. you could add
> more stuff later if you really wanted. However, personally I'd probably
> just keep all definitions together. But I see no reason to split them
> though.
>
> Thoughts? Is this something that's been considered and discounted for
> umpteen fundamental reasons long ago? I suspect so... as it's just too
> logical an extension of namespaces for it to have been overlooked ;-)
>
> Either way, I'd love to hear any feedback.
>
>
You are a bit late to the party:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0223r0.html
--
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/f8df777f-9785-4d7e-a75e-ae53087aac2f%40isocpp.org.
------=_Part_803_1557810708.1468004256251
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Friday, July 8, 2016 at 2:19:00 PM UTC-4, D. B.=
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">Well, =
it's worth a shot! This is my 1st proposal, and it's very simple. M=
y proposal is to add an 'overload' for the <span style=3D"font-fami=
ly:courier new,monospace">class</span> and <span style=3D"font-family:couri=
er new,monospace">namespace</span> keywords to provide an (example name) &q=
uot;<b><span style=3D"font-family:courier new,monospace">class namespace Th=
ingy {</span></b>" block.<br>This will add enclosed definitions to the=
tagged class by implicitly scoping them with Thing:: and will otherwise re=
flect namespaces.<br><br>As well as simply promoting DRY, this is arguably =
far more intuitive as it brings semantics of namespace, with which class sc=
oping shares syntax.<br>Plus, visually, it would enable better organisation=
and semantic grouping of class member (functions, static variable) definit=
ions and make implementation files better resemble headers (again, good for=
organisation, plus just convenient).<br><br>There might be a good reason w=
hy an equivalent construct doesn't already exist! If so, please correct=
my ignorance. Otherwise, let's have a look at what we currently must d=
o:<br><br><span style=3D"color:rgb(120,63,4)"><font size=3D"2"><span style=
=3D"font-family:courier new,monospace"><b>Thingy.hpp:</b><br><div style=3D"=
background-color:rgb(250,250,250);border-color:rgb(187,187,187);border-styl=
e:solid;border-width:1px;word-wrap:break-word"><code><div><span style=3D"co=
lor:rgb(120,63,4)"><font size=3D"2"><span style=3D"font-family:courier new,=
monospace"><span style=3D"color:#008">class</span><span style=3D"color:#000=
"> </span><span style=3D"color:#606">Thingy</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:#008">static</span><span style=
=3D"color:#000"> </span><span style=3D"color:#008">unsigned</span><span sty=
le=3D"color:#000"> s_instances</span><span style=3D"color:#660">;</span><sp=
an style=3D"color:#000"><br><br>=C2=A0 =C2=A0 </span><span style=3D"color:#=
008">int</span><span style=3D"color:#000"> m_value</span><span style=3D"col=
or:#660">;</span><span style=3D"color:#000"><br><br>=C2=A0 =C2=A0 </span><s=
pan style=3D"color:#008">int</span><span style=3D"color:#000"> getValue</sp=
an><span style=3D"color:#660">()</span><span style=3D"color:#000"> </span><=
span style=3D"color:#008">const</span><span style=3D"color:#660">;</span><s=
pan style=3D"color:#000"><br>=C2=A0 =C2=A0 </span><span style=3D"color:#008=
">void</span><span style=3D"color:#000"> setValue</span><span style=3D"colo=
r:#660">(</span><span style=3D"color:#008">int</span><span style=3D"color:#=
660">);</span><span style=3D"color:#000"><br></span><span style=3D"color:#6=
60">};</span><span style=3D"color:#000"><br></span></span></font></span></d=
iv></code></div><br><b>Thingy.cpp:</b><br><div style=3D"background-color:rg=
b(250,250,250);border-color:rgb(187,187,187);border-style:solid;border-widt=
h:1px;word-wrap:break-word"><code><div><span style=3D"color:rgb(120,63,4)">=
<span style=3D"font-family:courier new,monospace"><span style=3D"color:#008=
">unsigned</span><span style=3D"color:#000"> </span><span style=3D"color:#6=
06">Thingy</span><span style=3D"color:#660">::</span><span style=3D"color:#=
000">s_instances</span><span style=3D"color:#660">{</span><span style=3D"co=
lor:#066">0</span><span style=3D"color:#660">};</span><span style=3D"color:=
#000"><br><br></span><span style=3D"color:#008">int</span><span style=3D"co=
lor:#000"> </span><span style=3D"color:#606">Thingy</span><span style=3D"co=
lor:#660">::</span><span style=3D"color:#000">get_value</span><span style=
=3D"color:#660">()</span><span style=3D"color:#000"> </span><span style=3D"=
color:#008">const</span><span style=3D"color:#000"> </span><span style=3D"c=
olor:#660">{</span><span style=3D"color:#000"> </span><span style=3D"color:=
#800">/* ... */</span><span style=3D"color:#000"> </span><span style=3D"col=
or:#660">}</span><span style=3D"color:#000"><br><br></span><span style=3D"c=
olor:#008">void</span><span style=3D"color:#000"> </span><span style=3D"col=
or:#606">Thingy</span><span style=3D"color:#660">::</span><span style=3D"co=
lor:#000">set_value</span><span style=3D"color:#660">(</span><span style=3D=
"color:#008">int</span><span style=3D"color:#000"> </span><span style=3D"co=
lor:#008">const</span><span style=3D"color:#000"> value</span><span style=
=3D"color:#660">)</span><span style=3D"color:#000"> </span><span style=3D"c=
olor:#660">{</span><span style=3D"color:#000"> </span><span style=3D"color:=
#800">/* ... */</span><span style=3D"color:#660">}</span></span></span></di=
v></code></div></span></font></span><br>Personally I don't find all the=
typing required to scope things tooo much of a hassle, but it clearly isn&=
#39;t DRY.<br>Additionally, users might rightly wonder why they can avoid t=
he explicit scoping with namespaces but not with classes. After all, the sy=
ntax is the same, and so is the concept: you're adding definitions to a=
n enclosing realm.<br><br>So, what if we could combine the two? It's no=
t only DRY: It would enable better organisation of a file in case it has th=
ings like file-statics, other namespaces, etc. Plus, visually, it would jus=
t look <i>nice</i>, and intuitive.<br><br>With this ability, the resulting =
implementation file might look something like this:<br><br><span style=3D"f=
ont-family:courier new,monospace"><span style=3D"color:rgb(39,78,19)"><b>Th=
ingy.cpp:</b><br></span><div style=3D"background-color:rgb(250,250,250);bor=
der-color:rgb(187,187,187);border-style:solid;border-width:1px;word-wrap:br=
eak-word"><code><div><span style=3D"font-family:courier new,monospace"><spa=
n style=3D"color:rgb(39,78,19)"><span style=3D"color:#800">// unrelated stu=
ff</span><span style=3D"color:#000"><br><br></span><span style=3D"color:#80=
0">// nice enclosed organisation of Thingy members, plus clear visual paral=
lel to the class def in header</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:#008">namespace</span><span style=3D"color:#000"> </spa=
n><span style=3D"color:#606">Thingy</span><span style=3D"color:#000"> </spa=
n><span style=3D"color:#660">{</span><span style=3D"color:#000"> </span><sp=
an style=3D"color:#800">// means 'when defining things within these bra=
ces, lookup/define them as members within Thingy::'</span><span style=
=3D"color:#000"><br>=C2=A0 =C2=A0 </span><span style=3D"color:#008">unsigne=
d</span><span style=3D"color:#000"> s_instances</span><span style=3D"color:=
#660">{</span><span style=3D"color:#066">0</span><span style=3D"color:#660"=
>};</span><span style=3D"color:#000"><br><br>=C2=A0 =C2=A0 </span><span sty=
le=3D"color:#008">int</span><span style=3D"color:#000"> get_value</span><sp=
an style=3D"color:#660">()</span><span style=3D"color:#000"> </span><span s=
tyle=3D"color:#008">const</span><span style=3D"color:#000"> </span><span st=
yle=3D"color:#660">{</span><span style=3D"color:#000"> </span><span style=
=3D"color:#800">/* ... */</span><span style=3D"color:#000"> </span><span st=
yle=3D"color:#660">}</span><span style=3D"color:#000"><br><br>=C2=A0 =C2=A0=
</span><span style=3D"color:#008">void</span><span style=3D"color:#000"> s=
et_value</span><span style=3D"color:#660">(</span><span style=3D"color:#008=
">int</span><span style=3D"color:#000"> </span><span style=3D"color:#008">c=
onst</span><span style=3D"color:#000"> value</span><span style=3D"color:#66=
0">)</span><span style=3D"color:#000"> </span><span style=3D"color:#660">{<=
/span><span style=3D"color:#000"> </span><span style=3D"color:#800">/* ... =
*/</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><b=
r></span><span style=3D"color:#800">// other stuff</span></span></span></di=
v></code></div><br><font face=3D"arial,sans-serif">I envision it otherwise =
working just like namespaces, e.g. you could add more stuff later if you re=
ally wanted. However, personally I'd probably just keep all definitions=
together. But I see no reason to split them though.<br><br>Thoughts? Is th=
is something that's been considered and discounted for umpteen fundamen=
tal reasons long ago? I suspect so... as it's just too logical an exten=
sion of namespaces for it to have been overlooked ;-)<br><br>Either way, I&=
#39;d love to hear any feedback.<br><br></font></span></div></blockquote><d=
iv><br></div><div>You are a bit late to the party:</div><div><br></div><div=
>http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0223r0.html=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" 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/f8df777f-9785-4d7e-a75e-ae53087aac2f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f8df777f-9785-4d7e-a75e-ae53087aac2f=
%40isocpp.org</a>.<br />
------=_Part_803_1557810708.1468004256251--
------=_Part_802_866483929.1468004256251--
.
Author: "D. B." <db0451@gmail.com>
Date: Fri, 8 Jul 2016 20:09:20 +0100
Raw View
--94eb2c1309d63a6da20537248a82
Content-Type: text/plain; charset=UTF-8
Haha, oh wow. I had no idea. Thanks! Great minds and all that ;-)
On Fri, Jul 8, 2016 at 7:57 PM, T. C. <rs2740@gmail.com> wrote:
>
>
> On Friday, July 8, 2016 at 2:19:00 PM UTC-4, D. B. wrote:
>>
>> Well, it's worth a shot! This is my 1st proposal, and it's very simple.
>> My proposal is to add an 'overload' for the class and namespace keywords
>> to provide an (example name) "*class namespace Thingy {*" block.
>> This will add enclosed definitions to the tagged class by implicitly
>> scoping them with Thing:: and will otherwise reflect namespaces.
>>
>> As well as simply promoting DRY, this is arguably far more intuitive as
>> it brings semantics of namespace, with which class scoping shares syntax.
>> Plus, visually, it would enable better organisation and semantic grouping
>> of class member (functions, static variable) definitions and make
>> implementation files better resemble headers (again, good for organisation,
>> plus just convenient).
>>
>> There might be a good reason why an equivalent construct doesn't already
>> exist! If so, please correct my ignorance. Otherwise, let's have a look at
>> what we currently must do:
>>
>> *Thingy.hpp:*
>> class Thingy {
>> static unsigned s_instances;
>>
>> int m_value;
>>
>> int getValue() const;
>> void setValue(int);
>> };
>>
>> *Thingy.cpp:*
>> unsigned Thingy::s_instances{0};
>>
>> int Thingy::get_value() const { /* ... */ }
>>
>> void Thingy::set_value(int const value) { /* ... */}
>>
>> Personally I don't find all the typing required to scope things tooo much
>> of a hassle, but it clearly isn't DRY.
>> Additionally, users might rightly wonder why they can avoid the explicit
>> scoping with namespaces but not with classes. After all, the syntax is the
>> same, and so is the concept: you're adding definitions to an enclosing
>> realm.
>>
>> So, what if we could combine the two? It's not only DRY: It would enable
>> better organisation of a file in case it has things like file-statics,
>> other namespaces, etc. Plus, visually, it would just look *nice*, and
>> intuitive.
>>
>> With this ability, the resulting implementation file might look something
>> like this:
>>
>> *Thingy.cpp:*
>> // unrelated stuff
>>
>> // nice enclosed organisation of Thingy members, plus clear visual
>> parallel to the class def in header
>> class namespace Thingy { // means 'when defining things within these
>> braces, lookup/define them as members within Thingy::'
>> unsigned s_instances{0};
>>
>> int get_value() const { /* ... */ }
>>
>> void set_value(int const value) { /* ... */}
>> }
>>
>> // other stuff
>>
>> I envision it otherwise working just like namespaces, e.g. you could add
>> more stuff later if you really wanted. However, personally I'd probably
>> just keep all definitions together. But I see no reason to split them
>> though.
>>
>> Thoughts? Is this something that's been considered and discounted for
>> umpteen fundamental reasons long ago? I suspect so... as it's just too
>> logical an extension of namespaces for it to have been overlooked ;-)
>>
>> Either way, I'd love to hear any feedback.
>>
>>
> You are a bit late to the party:
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0223r0.html
>
> --
> 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/f8df777f-9785-4d7e-a75e-ae53087aac2f%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f8df777f-9785-4d7e-a75e-ae53087aac2f%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhGvWcZLkN%3DAwtGcKfxrrvZ6uZ-jzAYrx1BFiBhehrsG7w%40mail.gmail.com.
--94eb2c1309d63a6da20537248a82
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Haha, oh wow. I had no idea. Thanks! Great minds and all t=
hat ;-)<br><br></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Fri, Jul 8, 2016 at 7:57 PM, T. C. <span dir=3D"ltr"><<a href=3D"=
mailto:rs2740@gmail.com" target=3D"_blank">rs2740@gmail.com</a>></span> =
wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div class=
=3D"h5"><br><br>On Friday, July 8, 2016 at 2:19:00 PM UTC-4, D. B. wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-=
left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Well, it's worth=
a shot! This is my 1st proposal, and it's very simple. My proposal is =
to add an 'overload' for the <span style=3D"font-family:courier new=
,monospace">class</span> and <span style=3D"font-family:courier new,monospa=
ce">namespace</span> keywords to provide an (example name) "<b><span s=
tyle=3D"font-family:courier new,monospace">class namespace Thingy {</span><=
/b>" block.<br>This will add enclosed definitions to the tagged class =
by implicitly scoping them with Thing:: and will otherwise reflect namespac=
es.<br><br>As well as simply promoting DRY, this is arguably far more intui=
tive as it brings semantics of namespace, with which class scoping shares s=
yntax.<br>Plus, visually, it would enable better organisation and semantic =
grouping of class member (functions, static variable) definitions and make =
implementation files better resemble headers (again, good for organisation,=
plus just convenient).<br><br>There might be a good reason why an equivale=
nt construct doesn't already exist! If so, please correct my ignorance.=
Otherwise, let's have a look at what we currently must do:<br><br><spa=
n style=3D"color:rgb(120,63,4)"><font size=3D"2"><span style=3D"font-family=
:courier new,monospace"><b>Thingy.hpp:</b><br><div style=3D"background-colo=
r:rgb(250,250,250);border-color:rgb(187,187,187);border-style:solid;border-=
width:1px;word-wrap:break-word"><code><div><span style=3D"color:rgb(120,63,=
4)"><font size=3D"2"><span style=3D"font-family:courier new,monospace"><spa=
n style=3D"color:#008">class</span><span style=3D"color:#000"> </span><span=
style=3D"color:#606">Thingy</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:#008">static</span><span style=3D"color:#000"> =
</span><span style=3D"color:#008">unsigned</span><span style=3D"color:#000"=
> s_instances</span><span style=3D"color:#660">;</span><span style=3D"color=
:#000"><br><br>=C2=A0 =C2=A0 </span><span style=3D"color:#008">int</span><s=
pan style=3D"color:#000"> m_value</span><span style=3D"color:#660">;</span>=
<span style=3D"color:#000"><br><br>=C2=A0 =C2=A0 </span><span style=3D"colo=
r:#008">int</span><span style=3D"color:#000"> getValue</span><span style=3D=
"color:#660">()</span><span style=3D"color:#000"> </span><span style=3D"col=
or:#008">const</span><span style=3D"color:#660">;</span><span style=3D"colo=
r:#000"><br>=C2=A0 =C2=A0 </span><span style=3D"color:#008">void</span><spa=
n style=3D"color:#000"> setValue</span><span style=3D"color:#660">(</span><=
span style=3D"color:#008">int</span><span style=3D"color:#660">);</span><sp=
an style=3D"color:#000"><br></span><span style=3D"color:#660">};</span><spa=
n style=3D"color:#000"><br></span></span></font></span></div></code></div><=
br><b>Thingy.cpp:</b><br><div style=3D"background-color:rgb(250,250,250);bo=
rder-color:rgb(187,187,187);border-style:solid;border-width:1px;word-wrap:b=
reak-word"><code><div><span style=3D"color:rgb(120,63,4)"><span style=3D"fo=
nt-family:courier new,monospace"><span style=3D"color:#008">unsigned</span>=
<span style=3D"color:#000"> </span><span style=3D"color:#606">Thingy</span>=
<span style=3D"color:#660">::</span><span style=3D"color:#000">s_instances<=
/span><span style=3D"color:#660">{</span><span style=3D"color:#066">0</span=
><span style=3D"color:#660">};</span><span style=3D"color:#000"><br><br></s=
pan><span style=3D"color:#008">int</span><span style=3D"color:#000"> </span=
><span style=3D"color:#606">Thingy</span><span style=3D"color:#660">::</spa=
n><span style=3D"color:#000">get_value</span><span style=3D"color:#660">()<=
/span><span style=3D"color:#000"> </span><span style=3D"color:#008">const</=
span><span style=3D"color:#000"> </span><span style=3D"color:#660">{</span>=
<span style=3D"color:#000"> </span><span style=3D"color:#800">/* ... */</sp=
an><span style=3D"color:#000"> </span><span style=3D"color:#660">}</span><s=
pan style=3D"color:#000"><br><br></span><span style=3D"color:#008">void</sp=
an><span style=3D"color:#000"> </span><span style=3D"color:#606">Thingy</sp=
an><span style=3D"color:#660">::</span><span style=3D"color:#000">set_value=
</span><span style=3D"color:#660">(</span><span style=3D"color:#008">int</s=
pan><span style=3D"color:#000"> </span><span style=3D"color:#008">const</sp=
an><span style=3D"color:#000"> value</span><span style=3D"color:#660">)</sp=
an><span style=3D"color:#000"> </span><span style=3D"color:#660">{</span><s=
pan style=3D"color:#000"> </span><span style=3D"color:#800">/* ... */</span=
><span style=3D"color:#660">}</span></span></span></div></code></div></span=
></font></span><br>Personally I don't find all the typing required to s=
cope things tooo much of a hassle, but it clearly isn't DRY.<br>Additio=
nally, users might rightly wonder why they can avoid the explicit scoping w=
ith namespaces but not with classes. After all, the syntax is the same, and=
so is the concept: you're adding definitions to an enclosing realm.<br=
><br>So, what if we could combine the two? It's not only DRY: It would =
enable better organisation of a file in case it has things like file-static=
s, other namespaces, etc. Plus, visually, it would just look <i>nice</i>, a=
nd intuitive.<br><br>With this ability, the resulting implementation file m=
ight look something like this:<br><br><span style=3D"font-family:courier ne=
w,monospace"><span style=3D"color:rgb(39,78,19)"><b>Thingy.cpp:</b><br></sp=
an><div style=3D"background-color:rgb(250,250,250);border-color:rgb(187,187=
,187);border-style:solid;border-width:1px;word-wrap:break-word"><code><div>=
<span style=3D"font-family:courier new,monospace"><span style=3D"color:rgb(=
39,78,19)"><span style=3D"color:#800">// unrelated stuff</span><span style=
=3D"color:#000"><br><br></span><span style=3D"color:#800">// nice enclosed =
organisation of Thingy members, plus clear visual parallel to the class def=
in header</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:=
#008">namespace</span><span style=3D"color:#000"> </span><span style=3D"col=
or:#606">Thingy</span><span style=3D"color:#000"> </span><span style=3D"col=
or:#660">{</span><span style=3D"color:#000"> </span><span style=3D"color:#8=
00">// means 'when defining things within these braces, lookup/define t=
hem as members within Thingy::'</span><span style=3D"color:#000"><br>=
=C2=A0 =C2=A0 </span><span style=3D"color:#008">unsigned</span><span style=
=3D"color:#000"> s_instances</span><span style=3D"color:#660">{</span><span=
style=3D"color:#066">0</span><span style=3D"color:#660">};</span><span sty=
le=3D"color:#000"><br><br>=C2=A0 =C2=A0 </span><span style=3D"color:#008">i=
nt</span><span style=3D"color:#000"> get_value</span><span style=3D"color:#=
660">()</span><span style=3D"color:#000"> </span><span style=3D"color:#008"=
>const</span><span style=3D"color:#000"> </span><span style=3D"color:#660">=
{</span><span style=3D"color:#000"> </span><span style=3D"color:#800">/* ..=
.. */</span><span style=3D"color:#000"> </span><span style=3D"color:#660">}<=
/span><span style=3D"color:#000"><br><br>=C2=A0 =C2=A0 </span><span style=
=3D"color:#008">void</span><span style=3D"color:#000"> set_value</span><spa=
n style=3D"color:#660">(</span><span style=3D"color:#008">int</span><span s=
tyle=3D"color:#000"> </span><span style=3D"color:#008">const</span><span st=
yle=3D"color:#000"> value</span><span style=3D"color:#660">)</span><span st=
yle=3D"color:#000"> </span><span style=3D"color:#660">{</span><span style=
=3D"color:#000"> </span><span style=3D"color:#800">/* ... */</span><span st=
yle=3D"color:#660">}</span><span style=3D"color:#000"><br></span><span styl=
e=3D"color:#660">}</span><span style=3D"color:#000"><br><br></span><span st=
yle=3D"color:#800">// other stuff</span></span></span></div></code></div><b=
r><font face=3D"arial,sans-serif">I envision it otherwise working just like=
namespaces, e.g. you could add more stuff later if you really wanted. Howe=
ver, personally I'd probably just keep all definitions together. But I =
see no reason to split them though.<br><br>Thoughts? Is this something that=
's been considered and discounted for umpteen fundamental reasons long =
ago? I suspect so... as it's just too logical an extension of namespace=
s for it to have been overlooked ;-)<br><br>Either way, I'd love to hea=
r any feedback.<br><br></font></span></div></blockquote><div><br></div></di=
v></div><div>You are a bit late to the party:</div><div><br></div><div><a h=
ref=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0223r0.html=
" target=3D"_blank">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016=
/p0223r0.html</a>=C2=A0</div></div>
<p></p>
-- <br><span class=3D"">
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br></span>
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>.<span class=3D""><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/f8df777f-9785-4d7e-a75e-ae53087aac2f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f8df777f-9785-=
4d7e-a75e-ae53087aac2f%40isocpp.org</a>.<br>
</blockquote></div><br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/CACGiwhGvWcZLkN%3DAwtGcKfxrrvZ6uZ-jzA=
Yrx1BFiBhehrsG7w%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhGvWcZLkN=
%3DAwtGcKfxrrvZ6uZ-jzAYrx1BFiBhehrsG7w%40mail.gmail.com</a>.<br />
--94eb2c1309d63a6da20537248a82--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Fri, 8 Jul 2016 12:10:56 -0700 (PDT)
Raw View
------=_Part_6242_855390225.1468005056201
Content-Type: multipart/alternative;
boundary="----=_Part_6243_1141738966.1468005056201"
------=_Part_6243_1141738966.1468005056201
Content-Type: text/plain; charset=UTF-8
On Friday, July 8, 2016 at 2:57:36 PM UTC-4, T. C. wrote:
>
> You are a bit late to the party:
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0223r0.html
>
Though it's good that they independently chose nearly identical syntax.
Whatever happened with that proposal in committee anyway?
--
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/8ba3ea3c-7a51-4a6a-b300-c7923f0da264%40isocpp.org.
------=_Part_6243_1141738966.1468005056201
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Friday, July 8, 2016 at 2:57:36 PM UTC-4, T. C. wrote:<=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div></div><di=
v>You are a bit late to the party:</div><div><br></div><div><a href=3D"http=
://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0223r0.html" target=3D=
"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.google=
..com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fp=
apers%2F2016%2Fp0223r0.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHIy2eFz=
_y_FOH25Jh2mznLOLwKLA';return true;" onclick=3D"this.href=3D'http:/=
/www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21=
%2Fdocs%2Fpapers%2F2016%2Fp0223r0.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAF=
QjCNHIy2eFz_y_FOH25Jh2mznLOLwKLA';return true;">http://www.open-std.org=
/jtc1/<wbr>sc22/wg21/docs/papers/2016/<wbr>p0223r0.html</a>=C2=A0</div></di=
v></blockquote><div><br>Though it's good that they independently chose =
nearly identical syntax.<br><br>Whatever happened with that proposal in com=
mittee anyway?<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/8ba3ea3c-7a51-4a6a-b300-c7923f0da264%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/8ba3ea3c-7a51-4a6a-b300-c7923f0da264=
%40isocpp.org</a>.<br />
------=_Part_6243_1141738966.1468005056201--
------=_Part_6242_855390225.1468005056201--
.
Author: Greg Marr <gregmmarr@gmail.com>
Date: Fri, 8 Jul 2016 12:11:06 -0700 (PDT)
Raw View
------=_Part_736_651243434.1468005067050
Content-Type: multipart/alternative;
boundary="----=_Part_737_1761455359.1468005067050"
------=_Part_737_1761455359.1468005067050
Content-Type: text/plain; charset=UTF-8
On Friday, July 8, 2016 at 2:19:00 PM UTC-4, D. B. wrote:
>
> Well, it's worth a shot! This is my 1st proposal, and it's very simple. My
> proposal is to add an 'overload' for the class and namespace keywords to
> provide an (example name) "*class namespace Thingy {*" block.
> This will add enclosed definitions to the tagged class by implicitly
> scoping them with Thing:: and will otherwise reflect namespaces.
>
A proposal for this already exists, and is, I believe, in the Evolution WG.
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0223r0.html
--
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/cdb9e0ac-f02b-4c16-a561-08349c62c1ff%40isocpp.org.
------=_Part_737_1761455359.1468005067050
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Friday, July 8, 2016 at 2:19:00 PM UTC-4, D. B. wrote:<=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">Well, it's=
worth a shot! This is my 1st proposal, and it's very simple. My propos=
al is to add an 'overload' for the <span style=3D"font-family:couri=
er new,monospace">class</span> and <span style=3D"font-family:courier new,m=
onospace">namespace</span> keywords to provide an (example name) "<b><=
span style=3D"font-family:courier new,monospace">class namespace Thingy {</=
span></b>" block.<br>This will add enclosed definitions to the tagged =
class by implicitly scoping them with Thing:: and will otherwise reflect na=
mespaces.<br></div></blockquote><div><br></div><div>A proposal for this alr=
eady exists, and is, I believe, in the Evolution WG.</div><div>http://www.o=
pen-std.org/jtc1/sc22/wg21/docs/papers/2016/p0223r0.html</div><div><br></di=
v></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/cdb9e0ac-f02b-4c16-a561-08349c62c1ff%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/cdb9e0ac-f02b-4c16-a561-08349c62c1ff=
%40isocpp.org</a>.<br />
------=_Part_737_1761455359.1468005067050--
------=_Part_736_651243434.1468005067050--
.
Author: Andrey Semashev <andrey.semashev@gmail.com>
Date: Fri, 08 Jul 2016 22:15:13 +0300
Raw View
On July 8, 2016 9:19:02 PM db0451@gmail.com wrote:
> Well, it's worth a shot! This is my 1st proposal, and it's very simple. My
> proposal is to add an 'overload' for the class and namespace keywords to
> provide an (example name) "*class namespace Thingy {*" block.
> This will add enclosed definitions to the tagged class by implicitly
> scoping them with Thing:: and will otherwise reflect namespaces.
>
> With this ability, the resulting implementation file might look something
> like this:
>
> *Thingy.cpp:*
> // unrelated stuff
>
> // nice enclosed organisation of Thingy members, plus clear visual parallel
> to the class def in header
> class namespace Thingy { // means 'when defining things within these
> braces, lookup/define them as members within Thingy::'
> unsigned s_instances{0};
>
> int get_value() const { /* ... */ }
>
> void set_value(int const value) { /* ... */}
> }
>
> // other stuff
>
> I envision it otherwise working just like namespaces, e.g. you could add
> more stuff later if you really wanted. However, personally I'd probably
> just keep all definitions together. But I see no reason to split them
> though.
>
> Thoughts? Is this something that's been considered and discounted for
> umpteen fundamental reasons long ago? I suspect so... as it's just too
> logical an extension of namespaces for it to have been overlooked ;-)
>
> Either way, I'd love to hear any feedback.
Unlike classes, namespaces are open for extension - you can always open the
namespace scope and add more stuff to it. I assume you're not proposing the
same kind of openness for classes, otherwise this would break
encapsulation. In that case the syntax is kind of misleading.
Also, you should describe how it works with 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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/155cbef69e8.2731.fb49792bc380c7e55e30f872b414f11c%40gmail.com.
.
Author: "D. B." <db0451@gmail.com>
Date: Fri, 8 Jul 2016 20:20:02 +0100
Raw View
--001a114c08f4844c1f053724b048
Content-Type: text/plain; charset=UTF-8
Andrey, no of course I'm not wanting to allow reopening of classes.
Definitions will only be valid if they have been declared in the original
class declaration. But the namespace can be 'split' its definitions if
really wanted.
Anyway, see the 2016 WG doc linked by T.C., which both pre-empted me and
covers everything I'd want to say. Template classes are a very good point
that you raise, which I'd forgotten (perhaps as a psychological defence
mechanism due to how bad the current out-of-line def syntax is) - but
there's no need for me to describe how this would work with them, when
those of the WG paper already have.
--
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/CACGiwhHZFdOT3yd4ZChfWYCY-oOOsiQJYhvAoMxm38OH8Bmo0g%40mail.gmail.com.
--001a114c08f4844c1f053724b048
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Andrey, no of course I'm not wanting to allow reo=
pening of classes. Definitions will only be valid if they have been declare=
d in the original class declaration. But the namespace can be 'split=
9; its definitions if really wanted.<br><br></div>Anyway, see the 2016 WG d=
oc linked by T.C., which both pre-empted me and covers everything I'd w=
ant to say. Template classes are a very good point that you raise, which I&=
#39;d forgotten (perhaps as a psychological defence mechanism due to how ba=
d the current out-of-line def syntax is) - but there's no need for me t=
o describe how this would work with them, when those of the WG paper alread=
y have.<br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CACGiwhHZFdOT3yd4ZChfWYCY-oOOsiQJYhvA=
oMxm38OH8Bmo0g%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhHZFdOT3yd4=
ZChfWYCY-oOOsiQJYhvAoMxm38OH8Bmo0g%40mail.gmail.com</a>.<br />
--001a114c08f4844c1f053724b048--
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Mon, 18 Jul 2016 09:55:05 -0400
Raw View
On 2016-07-08 15:10, Nicol Bolas wrote:
> On Friday, July 8, 2016 at 2:57:36 PM UTC-4, T. C. wrote:
>> You are a bit late to the party:
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0223r0.html
>
> Though it's good that they independently chose nearly identical syntax.
>
> Whatever happened with that proposal in committee anyway?
It was never presented... and at the time I decided to put it on hold
for some reason, which alas I now can't remember :-).
Maybe it can be presented at Issaquah.
--
Matthew
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/nmin3q%24mnv%241%40ger.gmane.org.
.
Author: "D. B." <db0451@gmail.com>
Date: Mon, 18 Jul 2016 15:03:12 +0100
Raw View
--94eb2c0d7c60d99a0a0537e96d47
Content-Type: text/plain; charset=UTF-8
On Mon, Jul 18, 2016 at 2:55 PM, Matthew Woehlke <mwoehlke.floss@gmail.com>
wrote:
> On 2016-07-08 15:10, Nicol Bolas wrote:
> > On Friday, July 8, 2016 at 2:57:36 PM UTC-4, T. C. wrote:
> >> You are a bit late to the party:
> >> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0223r0.html
> >
> > Though it's good that they independently chose nearly identical syntax.
> >
> > Whatever happened with that proposal in committee anyway?
>
> It was never presented... and at the time I decided to put it on hold
> for some reason, which alas I now can't remember :-).
>
> Maybe it can be presented at Issaquah.
>
> --
> Matthew
>
It's a fantastic idea that would quickly become indispensible, so I hope
your effort pays off soon! Thanks for writing it up. Seems to cover
everything I could want. (when combined with the fabled
nested::namespace::scoping { ;-)
--
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/CACGiwhFqc76Tu43NPzN%3DFHrW3YryadL103nDa0YmiOZjDP_FvQ%40mail.gmail.com.
--94eb2c0d7c60d99a0a0537e96d47
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, Jul 18, 2016 at 2:55 PM, Matthew Woehlke <span dir=3D"ltr"><<a href=
=3D"mailto:mwoehlke.floss@gmail.com" target=3D"_blank">mwoehlke.floss@gmail=
..com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D=
"">On 2016-07-08 15:10, Nicol Bolas wrote:<br>
> On Friday, July 8, 2016 at 2:57:36 PM UTC-4, T. C. wrote:<br>
>> You are a bit late to the party:<br>
>> <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016=
/p0223r0.html" rel=3D"noreferrer" target=3D"_blank">http://www.open-std.org=
/jtc1/sc22/wg21/docs/papers/2016/p0223r0.html</a><br>
><br>
> Though it's good that they independently chose nearly identical sy=
ntax.<br>
><br>
> Whatever happened with that proposal in committee anyway?<br>
<br>
</span>It was never presented... and at the time I decided to put it on hol=
d<br>
for some reason, which alas I now can't remember :-).<br>
<br>
Maybe it can be presented at Issaquah.<br>
<br>
--<br>
Matthew<br></blockquote><div><br><br></div><div>It's a fantastic idea t=
hat would quickly become indispensible, so I hope your effort pays off soon=
! Thanks for writing it up. Seems to cover everything I could want. (when c=
ombined with the fabled nested::namespace::scoping { ;-)<br><br><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" 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/CACGiwhFqc76Tu43NPzN%3DFHrW3YryadL103=
nDa0YmiOZjDP_FvQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhFqc76Tu4=
3NPzN%3DFHrW3YryadL103nDa0YmiOZjDP_FvQ%40mail.gmail.com</a>.<br />
--94eb2c0d7c60d99a0a0537e96d47--
.