Topic: Nested namespace definition proposal
Author: Robert Kawulak <robert.kawulak@gmail.com>
Date: Sat, 29 Mar 2014 19:55:30 +0100
Raw View
This is a multi-part message in MIME format.
------=_NextPart_000_0027_01CF4B88.D753E9F0
Content-Type: text/plain; charset=ISO-8859-1
Dear all,
I've written a draft proposal for nested namespace definitions (attached to this
message). I'd like to hear your comments and suggestions.
In short, the paper proposes allowing to use a qualified name in a namespace
definition to define several nested namespaces at once, for example:
namespace A::B::C {
//...
}
The code above would be equivalent to:
namespace A {
namespace B {
namespace C {
//...
}
}
}
Best regards,
Robert Kawulak
--
---
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/.
------=_NextPart_000_0027_01CF4B88.D753E9F0
Content-Type: text/html;
name="ns.html"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
filename="ns.html"
<!DOCTYPE html>
<html lang=3D"en">
<head>
<meta charset=3D"utf-8">
<title>Nested namespace definition</title>
</head>
<body>
<table><tbody>
<tr><td>Document number:</td><td><i>TBD</i></td></tr>
<tr><td>Date:</td><td><i>TBD</i></td></tr>
<tr><td>Project:</td><td>Programming Language C++, Evolution =
Working Group</td></tr>
<tr><td>Reply-to:</td><td>Robert Kawulak <Robert Kawulak at =
gmail dot com></td></tr>
</tbody></table>
<h1>Nested namespace definition</h1>
<section><h2 id=3D"contents">I. Table of Contents</h2>
<ul>
<li><a href=3D"#introduction">II. Introduction</a></li>
<li><a href=3D"#motivation">III. Motivation</a></li>
<li><a href=3D"#impact">IV. Impact On the Standard</a></li>
<li><a href=3D"#issues">V. Open Issues</a></li>
<li><a href=3D"#specifications">VI. Technical =
Specifications</a></li>
<li><a href=3D"#acknowledgements">VII. Acknowledgements</a></li>
</ul>
</section>
<section><h2 id=3D"introduction">II. Introduction</h2>
<p>The paper proposes allowing to use a qualified name in a =
namespace definition to define several nested namespaces at once, for =
example:
<pre><code>
namespace A::B::C {
//...
}
</code></pre>
The code above would be equivalent to:
<pre><code>
namespace A {
namespace B {
namespace C {
//...
}
}
}
</code></pre></p>
<p>The feature has already been proposed by Jon Jagger in the <a =
href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1524.htm=
">N1524 <cite>Nested Namespace Definition Proposal</cite></a> paper in =
2003, but it's listed in <a =
href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2869.htm=
l">N2869 <cite>State of C++ Evolution (Post San Francisco =
2008)</cite></a> under <q>Not ready for C++0x, but open to resubmit in =
future</q>.</p>
</section>
<section><h2 id=3D"motivation">III. Motivation</h2>
<section><h3 id=3D"demand">Programmers' demand</h3>
<p>There is clearly a need for a more concise way of defining nested =
namespaces than what the language offers today. The feature is asked for =
over and over by C++ users; see for example a few of the top web search =
results for a related query:
<ul>
<li><a =
href=3D"https://groups.google.com/a/isocpp.org/d/topic/std-proposals/o7U0=
8Z_7EgI/discussion">ISO C++ Standard =E2=80=93 Future Proposals forum: =
<cite>nested namespace declaration</cite></a></li>
<li><a =
href=3D"https://groups.google.com/a/isocpp.org/d/topic/std-proposals/HMUt=
_-cb4Wg/discussion">ISO C++ Standard =E2=80=93 Future Proposals forum: =
<cite>Namespaces-related open questions</cite></a></li>
<li><a href=3D"http://stackoverflow.com/q/11358425">Stack =
Overflow: <cite>Is there a better way to express nested namespaces in =
C++ within the header</cite></a></li>
<li><a href=3D"http://stackoverflow.com/q/3603461">Stack =
Overflow: <cite>Is there a specific reason nested namespace declarations =
are not allowed in C++?</cite></a></li>
<li><a href=3D"http://stackoverflow.com/q/3589204">Stack =
Overflow: <cite>Multiple namespace declaration in C++</cite></a></li>
<li><a =
href=3D"http://visualstudio.uservoice.com/forums/121579/suggestions/22866=
01">Visual Studio UserVoice: <cite>Nested namespace =
declarations</cite></a> (Note that it is currently the 19<sup>th</sup> =
top voted idea out of 233 for C++.)</li>
</ul>
Quite possibly some of the users asking for this feature are =
novices/newcomers from other languages who used this syntax intuitively =
and found that their compiler doesn't accept it. This might indicate =
that the new syntax would not only mean saving some typing to =
experienced programmers, but it would also mean one confusion less to =
C++ learners.</p>
</section>
<section><h3 id=3D"prevalence">Prevalence</h3>
<p>It is not uncommon to find many deeply nested namespaces in large =
projects. For example, a search using the regular expression pattern =
<code>(namespace\s+\w+\s*\{\s*){3,}</code> to find nested namespace =
definitions at least 3 levels deep in the include directory of <a =
href=3D"http://www.boost.org/">Boost libraries</a> yielded 3758 matches =
and the greatest nesting level found this way was 7 (4 matches).</p>
</section>
<section><h3 id=3D"existing-other">Existing practice in other =
languages</h3>
<p>An <a =
href=3D"http://msdn.microsoft.com/en-us/library/dfb3cx8s.aspx#code-snippe=
t-7">analogous syntax</a> is found and heavily used in the C# =
programming language. Some other languages do not even allow for nesting =
of namespace definitions but only for providing a hierarchical namespace =
specification in a single declaration (e.g. <a =
href=3D"http://docs.oracle.com/javase/specs/jls/se7/html/jls-7.html#jls-7=
..4.1">Java</a> or <a =
href=3D"http://www.php.net/manual/en/language.namespaces.nested.php">PHP<=
/a>).</p>
</section>
<section><h3 id=3D"existing-cpp">Existing practice in C++</h3>
<p>The author is not aware of any C++ compiler supporting this =
feature; however <a href=3D"http://www.lazycplusplus.com/">Lzz</a>, <q>a =
tool that automates many onerous C++ programming tasks</q>, supports it =
=E2=80=93 from the tool's <a =
href=3D"http://www.lazycplusplus.com/doc.html#support">documentation</a>:=
<blockquote>
The name of a named namespace may be qualified.=20
<pre><code>
namespace A::B { typedef int I; }
</code></pre>
is equivalent to:=20
<pre><code>
namespace A { namespace B { typedef int I; } }
</code></pre>
</blockquote></p>
</section>
</section>
<section><h2 id=3D"impact">IV. Impact On the Standard</h2>
<p>The proposal describes a pure language extension which is a =
non-breaking change =E2=80=93 code that was previously ill-formed now =
would have well-defined semantics.</p>
</section>
<section><h2 id=3D"issues">V. Open Issues</h2>
<section><h3 id=3D"attributes">Attributes</h3>
<p>Currently, the C++ Standard doesn't allow for specification of =
attributes for namespaces, but a resolution to the <a =
href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3957.htm=
l#113">EWG issue #113</a> may lift this limitation. In such case the =
proposal will have to take attributes into account, for example by =
stating that attributes, if any, apply only to the innermost namespace =
name and thus
<pre><code>
namespace A::B::C [[attr]] {
//...
}
</code></pre>
is equivalent to
<pre><code>
namespace A {
namespace B {
namespace C [[attr]] {
//...
}
}
}
</code></pre></p>
</section>
<section><h3 id=3D"inline">Inline namespaces</h3>
<p>It is not yet clear to the author what is the best way to deal =
with inline namespaces. One possibility is that only the innermost =
namespace is defined inline, another one is that all the specified =
namespaces are inline. In either case the semantics seem to be =
potentially confusing. Another possibility is to make inline qualified =
namespace definitions ill-formed.</p>
</section>
<section><h3 id=3D"aliases">Namespace aliases</h3>
<p>By analogy, qualified names could also be allowed in namespace =
alias definitions, in which case
<pre><code>
using namespace A::B::C =3D X;
</code></pre>
would be equivalent to
<pre><code>
namespace A {
namespace B {
using namespace C =3D X;
}
}
</code></pre>
However, use cases for qualified namespace aliases seem to be =
infrequent (the author didn't find any in Boost for example) so they =
wouldn't be further considered if found useless or problematic for any =
reason.</p>
</section>
</section>
<section><h2 id=3D"specifications">VI. Technical Specifications</h2>
<p>Proposed wording will be provided at a later time.</p>
</section>
<section><h2 id=3D"acknowledgements">VII. Acknowledgements</h2>
<p><i>TBD</i></p>
</section>
</body>
</html>
------=_NextPart_000_0027_01CF4B88.D753E9F0--
.
Author: Troy Heron <troy.heron@hixxy.org>
Date: Sun, 30 Mar 2014 07:17:39 +1000
Raw View
--e89a8ff1c08c225f0104f5c559fb
Content-Type: text/plain; charset=ISO-8859-1
I really hope this proposal gets taken seriously / approved. The current
way of doing things really is horrible. This proposal is such an obvious
improvement, it's surprising it wasn't accepted the first time it was
proposed.
On Sun, Mar 30, 2014 at 4:52 AM, Robert Kawulak <tigrisek@interia.pl> wrote:
> Dear all,
>
> I've written a draft proposal for nested namespace definitions (attached
> to this
> message). I'd like to hear your comments and suggestions.
>
> In short, the paper proposes allowing to use a qualified name in a
> namespace
> definition to define several nested namespaces at once, for example:
>
> namespace A::B::C {
> //...
> }
>
> The code above would be equivalent to:
>
> namespace A {
> namespace B {
> namespace C {
> //...
> }
> }
> }
>
> Best regards,
> Robert Kawulak
>
> --
>
> ---
> 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/.
--e89a8ff1c08c225f0104f5c559fb
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I really hope this proposal gets taken seriously / approve=
d. The current way of doing things really is horrible. This proposal is suc=
h an obvious improvement, it's surprising it wasn't accepted the fi=
rst time it was proposed.</div>
<div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Sun, Mar 3=
0, 2014 at 4:52 AM, Robert Kawulak <span dir=3D"ltr"><<a href=3D"mailto:=
tigrisek@interia.pl" target=3D"_blank">tigrisek@interia.pl</a>></span> w=
rote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Dear all,<br>
<br>
I've written a draft proposal for nested namespace definitions (attache=
d to this<br>
message). I'd like to hear your comments and suggestions.<br>
<br>
In short, the paper proposes allowing to use a qualified name in a namespac=
e<br>
definition to define several nested namespaces at once, for example:<br>
<br>
=A0 =A0 namespace A::B::C {<br>
=A0 =A0 =A0 =A0 //...<br>
=A0 =A0 }<br>
<br>
The code above would be equivalent to:<br>
<br>
=A0 =A0 namespace A {<br>
=A0 =A0 =A0 =A0 namespace B {<br>
=A0 =A0 =A0 =A0 =A0 =A0 namespace C {<br>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 //...<br>
=A0 =A0 =A0 =A0 =A0 =A0 }<br>
=A0 =A0 =A0 =A0 }<br>
=A0 =A0 }<br>
<br>
Best regards,<br>
Robert Kawulak<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<br>
<br>
---<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%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/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/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" 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 />
--e89a8ff1c08c225f0104f5c559fb--
.
Author: David Krauss <potswa@gmail.com>
Date: Sun, 30 Mar 2014 11:47:05 +0800
Raw View
--Apple-Mail=_A0CC8C03-0960-4CCB-9A0E-CF831739129C
Content-Type: text/plain; charset=ISO-8859-1
On 2014-03-30, at 5:17 AM, Troy Heron <troy.heron@hixxy.org> wrote:
> I really hope this proposal gets taken seriously / approved. The current way of doing things really is horrible. This proposal is such an obvious improvement, it's surprising it wasn't accepted the first time it was proposed.
Gratuitous nesting levels are horrible. Is there a motivating case that isn't ported from Java? Why not use a naming convention such as
namespace A_B_C {
....
}
This avoids defining extraneous, meaningless constructs.
If you really must provide a namespace hierarchy interface, you can do so with aliases:
namespace A { namespace B {
namespace C = A_B_C;
} }
Coding styles which abuse punctuation to obtain visual appearance rather than semantics may be popular, but it's still not a strong motivation.
That said, there are genuine issues around namespace scoping such as allowing specialization of a template outside its native namespace. I hope that's resolved.
--
---
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/.
--Apple-Mail=_A0CC8C03-0960-4CCB-9A0E-CF831739129C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;03–30, at 5:17 AM, Troy Heron <<a href=3D"mailto:troy.heron@=
hixxy.org">troy.heron@hixxy.org</a>> wrote:</div><br class=3D"Apple-inte=
rchange-newline"><blockquote type=3D"cite"><div dir=3D"ltr">I really hope t=
his proposal gets taken seriously / approved. The current way of doing thin=
gs really is horrible. This proposal is such an obvious improvement, it's s=
urprising it wasn't accepted the first time it was proposed.</div></blockqu=
ote><div><br></div><div>Gratuitous nesting levels are horrible. Is there a =
motivating case that isn’t ported from Java? Why not use a naming con=
vention such as</div><div><br></div><div><font face=3D"Courier">namespace A=
_B_C {</font></div><div><font face=3D"Courier">...</font></div><div><font f=
ace=3D"Courier">}</font></div><div><br></div><div>This avoids defining extr=
aneous, meaningless constructs.</div><div><br></div><div>If you really must=
provide a namespace hierarchy interface, you can do so with aliases:</div>=
<div><br></div><div><font face=3D"Courier">namespace A { namespace B {</fon=
t></div><div><font face=3D"Courier">namespace C =3D A_B_C;</font></div><div=
><font face=3D"Courier">} }</font></div><div><br></div><div>Coding styles w=
hich abuse punctuation to obtain visual appearance rather than semantics ma=
y be popular, but it’s still not a strong motivation.</div></div><br>=
<div>That said, there are genuine issues around namespace scoping such as a=
llowing specialization of a template outside its native namespace. I hope t=
hat’s resolved.</div><div><br></div></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_A0CC8C03-0960-4CCB-9A0E-CF831739129C--
.
Author: Robert Kawulak <robert.kawulak@gmail.com>
Date: Sun, 30 Mar 2014 13:25:28 +0200
Raw View
> From: David Krauss
> Gratuitous nesting levels are horrible.
Gratuitous possibly are. That doesn't change the fact that there are legitimate
reasons for nesting.
> Is there a motivating case that isn't ported from Java?
Boost is the motivating case mentioned in the paper - are you suggesting it is
ported from Java?
> Why not use a naming convention such as
>
> namespace A_B_C {
>...
> }
Yeah, a similar convention is very common in C, due to lack of namespaces. Not
exactly a step forward.
> That said, there are genuine issues around namespace scoping such as
> allowing specialization of a template outside its native namespace.
> I hope that's resolved.
If you mean "resolved by this paper" then no - it's way out of its scope.
There's another paper (N3867) dealing with this.
Best regards,
Robert
--
---
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/.
.
Author: David Krauss <potswa@gmail.com>
Date: Sun, 30 Mar 2014 23:37:57 +0800
Raw View
On 2014-03-30, at 8:37 PM, David Krauss <potswa@gmail.com> wrote:
> The proposed shortcut simplifies the task of going directly to a nested namespace, but the regex you used doesn't analyze how often the enclosing namespaces are skipped. It's pretty much a non sequitur.
Whoa. I did not hit send. I'm very sorry.
--
---
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/.
.
Author: Robert Kawulak <robert.kawulak@gmail.com>
Date: Mon, 31 Mar 2014 05:15:30 +0200
Raw View
> From: David Krauss
> > The proposed shortcut simplifies the task of going directly to a nested
> namespace, but the regex you used doesn't analyze how often the enclosing
> namespaces are skipped. It's pretty much a non sequitur.
Sorry, but I don't understand - what do you mean by skipping the enclosing
namespaces and why is this number relevant?
Best regards,
Robert
--
---
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/.
.