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-specifieropt namespace-name

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

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?

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