<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml">
  <head>
    <title>Nested Namespace Definition Proposal</title>
    <meta name="generator" content="HTML Tidy, see www.w3.org" />
    <meta name="author" content="Jon Jagger" />
    <meta name="generator" content="Jon Jagger" />
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 
    <style>
    BODY
    { 
	font-family: "Arial", sans-serif;
	font-size: +16;
	background: white;
	margin: 6%;
    }

    PRE.code
    {
	font-family: "Courier New", Courier;
	font-weight: bold;
    	font-size: +14;
	background-color: B0C4DE; /* light steel blue */
	padding: 1em 1em;
	border-right: 3 solid gray;
	border-bottom: 3 solid gray;    
	border-left: 3 solid gray;
	border-top: 3 solid gray;    

	margin: 4%;
    }

    PRE.grammar
    {
        font-family: "Courier New", Courier;
	font-weight: normal;
    	font-size: +14;
	background-color: white;
	padding: 1em 1em;
	border-right: 3 solid gray;
	border-bottom: 3 solid gray;    
	border-left: 3 solid gray;
	border-top: 3 solid gray;    

	margin: 4%;
    }
    </style>
  </head>

  <body>
<h1>N1524=03-0107 (19th September 2003)</h1>
<h1>Nested Namespace Definition Proposal</h1>
Proposer: Jon Jagger <a href="mailto:jon@jaggersoft.com">jon@jaggersoft.com</a>
</br></br>
I propose that this:
<pre class="code">
namespace grammars::cplusplus
{
    ...
}</pre>
be allowed as a semantically identical alternative to this:
<pre class="code">namespace grammars
{
    namespace cplusplus
    {
        ...
    }
}</pre>

<h2>Grammar</h2>

<h3>What changes to the grammar are needed?</h3> 
The two relevant clauses (7.3.1) are:
<pre class="grammar">
original-namespace-definition:
    <b>namespace</b> identifier <b>{</b> namespace-body <b>}</b>

extension-namespace-definition:
    <b>namespace</b> original-namespace-name <b>{</b> namespace-body <b>}</b>

original-namespace-name:
    identifier</pre>

Both productions would need to be generalized to allow :: qualified identifiers. 
For example:
<pre class="grammar">
original-namespace-definition:
    <b>namespace</b> qualified-namespace-specifier <b>{</b> namespace-body <b>}</b>

extension-namespace-definition:
    <b>namespace</b> original-namespace-name <b>{</b> namespace-body <b>}</b>

original-namespace-name:
    qualified-namespace-specifier
</pre>
This uses the existing <i>qualified-namespace-specifier</i> production:
<pre class="grammar">
qualified-namespace-specifier:
    <b>::</b><sub>opt</sub> nested-name-specifier<sub>opt</sub> namespace-name

nested-name-specifier:
    class-or-namespace-name <b>::</b> nested-name-specifier<sub>opt</sub> 
    ...
</pre>

<h3>What changes to the description of the language semantics are needed?</h3>
The changes should be small, localized, and essentially lexical in nature. 
One option is to simply add a clause specifying the new more concise nested 
namespace definition as being semantically identical to its current "expanded" form 
and to leave remaining clauses intact.

<h3>Does it fit with the rest of the language?</h3>
Yes. 

<h2>Rationale</h2>

<h3>Why is the extension needed?</h3>

<ul>
<li><b>Intentional Clarity</b></br>
In many cases a nested namespace is opened solely to declare members 
in the most nested namespace:
<pre class="code">
namespace grammars
{
    // nothing here

    namespace cplusplus
    {
        class syntactic_grammar : ...
        {
            ...
        };
    }
}</pre>

This syntax is needlessly verbose and less transparent than the following 
which clearly expresses the intention to open a single namespace which happens to 
be nested:
<pre class="code">
namespace grammars::cplusplus
{
    class syntactic_grammar : ...
    {
        ...
    };
}</pre>
It is also common (especially in header files) to open a namespace solely to
write one or more forward declarations. For example:
<pre class="code">
namespace utility
{
    namespace ranges
    {
        class half_open_range;
    }
}
...
</pre>
Again, this is needlessly verbose and less transparent than:
<pre class="code">
namespace utility::ranges
{
    class half_open_range;
}
...
</pre>
</li>

<li><b>Visual Clarity</b></br>
The proposal allows the physical indentation of a class to correspond
to its logical indentation.
<pre class="code">
namespace grammars::cplusplus
{
    class syntactic_grammar : ...
    {
        ...
    };
}</pre>
</li>

<!--
<li><b>Physical Correspondence</b></br>
If your folder hierarchy mirrors your namespace nesting then, in 
the previous example, syntactic_grammar.hpp will live in the cplusplus 
folder which in turn will live in the grammars folder. This allows a 
high degree of #include/qualified-name correspondence:
<pre class="code">
#include "grammars/cplusplus/syntactic_grammar.hpp"
...
using grammars::cplusplus::syntactic_grammar;
...
</pre>
</li>
-->

<li><b>Syntactic Consistency</b></br>
An out of line a nested class definition looks like this:
<pre class="code">
    class syntactic_grammar::literal_match
    {
       ...
    };
</pre>
A using directive looks like this:
<pre class="code">
using grammars::cplusplus;
</pre>
A using declaration looks like this:
<pre class="code">
using grammars::cplusplus::syntactic_grammar;
</pre>
And an explicit qualification looks like this:
<pre class="code">
    ...
    grammars::cplusplus::syntactic_grammar syntactic;
    ...</pre>
It seems odd and arbitrary to allow the qualified :: syntax in all constructs 
except in the proposed case.
</li>

<h3>Who is the audience for the change?</h3>
Any C++ programmer defining namespaces.

<h3>Is this a general purpose change? </h3>
Yes.

<h3>Does it affect one group of C++ language users more than others?</h3>
Yes. It affects library implementers more than library users.

<h3>Is it implementable on all reasonable hardware and systems? </h3>
Yes.

<h3>Is it useful on all reasonable hardware and systems? </h3>
Yes.

<h3>What kinds of programming and design styles does it support? </h3>
It does not add extra support for any new style. 

<h3>What kinds of programming and design styles does it prevent? </h3>
None. The proposal is not to replace the existing syntax for nested namespaces 
- it is to provide a concise and logically intuitive alternative.

<h3>What other languages (if any) provide such features? </h3>
A Java package declaration and a C# namespace declaration have a corresponding syntax. 
For example, the C# namespace declaration is as follows:
<pre class="grammar">
namespace-declaration:
    <b>namespace</b> qualified-identifier namespace-body <b>;</b><sub>opt</sub>

qualified-identifier:
    identifier
    qualified-identifier <b>.</b> identifier
</pre>

<h3>Does it ease the design, implementation, or use of libraries? </h3>
Yes. In a small way it eases the implementation of libraries.

</ul>

<h2>Implementation</h2>

<h3>What effect does it have on a C++ implementation?</h3>

Minimal effect is anticipated on compiler organization. No effect is anticipated on runtime support.

<h2>What difference does the feature have on code?</h2>

<h3>What does the code look like without/with this change? </h3>
See example above.

<h2>What is the effect of not doing this change? </h2>

A needless inconsistency remains.

<h3>Does use of the new feature lead to demands for new support tools? </h3>
No.

<h2>What impact does the change have on efficiency and compatibility with C and existing C++?</h2>

<h3>How does the change affect runtime efficiency?</h3>
No affect.

<h3>How does the change affect compile and link times? </h3>
Compile times may reduce minimally since the proposed syntax is more concise. Link times would be unaffected.

<h3>Does the change affect existing programs?</h3>
No.

<h3>Does the change affect the degree of static or dynamic checking possible for C++ programs? </h3>
No.

<h2>How easy is the change to document and teach?</h2>

<h3>To novices? </h3>
Very easy. 
Many programmers are now learning C++ <i>after</i> Java
and you have to explicitly explain that the proposed
syntax is illegal.

<h3>To experts? </h3>
Ditto.

<h2>What reasons could there be for not making the extension?</h2>

<h3>Does it affect old code that does not use the extension? </h3>
No.

<h3>Is it hard to learn? </h3>
No.

<h3>Does it lead to demands for further extensions? </h3>
No.

<h3>Does it lead to larger compilers? </h3>
No.

<h3>Does it require extensive runtime support? </h3>
No.

<h3>Could it encourage deeply nested namespaces? </h3>
Deeply nested namespaces are already possible but it is not inconceivable that 
the proposed concise syntax could, ever so slightly, encourage deeper nesting and, 
as a consequence, possibly discourage explicit qualification and encourage 
using directives. (On the other hand, the more concise syntax might encourage 
forward declarations in header files.) All that can be said for sure is that
the proposed syntax makes nested namespaces easier to declare, format, read, and 
understand. 

<h2>Alternatives</h2>

<h3>Are there alternative ways of providing a feature to serve the need? </h3>

Perhaps. But the suggested syntax is arguably the most logical choice.

<h3>Are there alternative ways of using the syntax suggested? </h3>
No.

<h3>Are there attractive generalizations of the suggested scheme? </h3>
No. (Except possibly the ability to forward declare a nested class - but 
that would be a much more substantial change).

  </body>
</html>
