N1524=03-0107 (19th September 2003)

Nested Namespace Definition Proposal

Proposer: Jon Jagger jon@jaggersoft.com

I propose that this:

namespace grammars::cplusplus
{
    ...
}

be allowed as a semantically identical alternative to this:

namespace grammars
{
    namespace cplusplus
    {
        ...
    }
}

Grammar

What changes to the grammar are needed?

The two relevant clauses (7.3.1) are:

original-namespace-definition:
    namespace identifier { namespace-body }

extension-namespace-definition:
    namespace original-namespace-name { namespace-body }

original-namespace-name:
    identifier

Both productions would need to be generalized to allow :: qualified identifiers. For example:

original-namespace-definition:
    namespace qualified-namespace-specifier { namespace-body }

extension-namespace-definition:
    namespace original-namespace-name { namespace-body }

original-namespace-name:
    qualified-namespace-specifier

This uses the existing qualified-namespace-specifier production:

qualified-namespace-specifier:
    ::_opt nested-name-specifier_opt namespace-name

nested-name-specifier:
    class-or-namespace-name :: nested-name-specifier_opt 
    ...

What changes to the description of the language semantics are needed?

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.

Does it fit with the rest of the language?

Yes.

Rationale

Why is the extension needed?

Intentional Clarity
In many cases a nested namespace is opened solely to declare members in the most nested namespace:
```
namespace grammars
{
    // nothing here

    namespace cplusplus
    {
        class syntactic_grammar : ...
        {
            ...
        };
    }
}
```
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:
```
namespace grammars::cplusplus
{
    class syntactic_grammar : ...
    {
        ...
    };
}
```
It is also common (especially in header files) to open a namespace solely to write one or more forward declarations. For example:
```
namespace utility
{
    namespace ranges
    {
        class half_open_range;
    }
}
...
```
Again, this is needlessly verbose and less transparent than:
```
namespace utility::ranges
{
    class half_open_range;
}
...
```
Visual Clarity
The proposal allows the physical indentation of a class to correspond to its logical indentation.
```
namespace grammars::cplusplus
{
    class syntactic_grammar : ...
    {
        ...
    };
}
```
Syntactic Consistency
An out of line a nested class definition looks like this:
```
    class syntactic_grammar::literal_match
    {
       ...
    };
```
A using directive looks like this:
```
using grammars::cplusplus;
```
A using declaration looks like this:
```
using grammars::cplusplus::syntactic_grammar;
```
And an explicit qualification looks like this:
```
    ...
    grammars::cplusplus::syntactic_grammar syntactic;
    ...
```
It seems odd and arbitrary to allow the qualified :: syntax in all constructs except in the proposed case.

Who is the audience for the change?

Is this a general purpose change?

Does it affect one group of C++ language users more than others?

Is it implementable on all reasonable hardware and systems?

Is it useful on all reasonable hardware and systems?

What kinds of programming and design styles does it support?

What kinds of programming and design styles does it prevent?

What other languages (if any) provide such features?

namespace-declaration:
    namespace qualified-identifier namespace-body ;_opt

qualified-identifier:
    identifier
    qualified-identifier . identifier

Does it ease the design, implementation, or use of libraries?

Implementation

What effect does it have on a C++ implementation?

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

What difference does the feature have on code?

What does the code look like without/with this change?

See example above.

What is the effect of not doing this change?

A needless inconsistency remains.

Does use of the new feature lead to demands for new support tools?

No.

What impact does the change have on efficiency and compatibility with C and existing C++?

How does the change affect runtime efficiency?

No affect.

How does the change affect compile and link times?

Compile times may reduce minimally since the proposed syntax is more concise. Link times would be unaffected.

Does the change affect existing programs?

No.

Does the change affect the degree of static or dynamic checking possible for C++ programs?

No.

How easy is the change to document and teach?

To novices?

Very easy. Many programmers are now learning C++ after Java and you have to explicitly explain that the proposed syntax is illegal.

To experts?

Ditto.

What reasons could there be for not making the extension?

Does it affect old code that does not use the extension?

No.

Is it hard to learn?

No.

Does it lead to demands for further extensions?

No.

Does it lead to larger compilers?

No.

Does it require extensive runtime support?

No.

Could it encourage deeply nested namespaces?

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.

Alternatives

Are there alternative ways of providing a feature to serve the need?

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

Are there alternative ways of using the syntax suggested?

No.

Are there attractive generalizations of the suggested scheme?

No. (Except possibly the ability to forward declare a nested class - but that would be a much more substantial change).