Document number:N4026
Date:2014-05-23
Project:Programming Language C++, Evolution Working Group
Reply-to:Robert Kawulak <Robert Kawulak at gmail dot com>

Nested namespace definition

I. Table of Contents

II. Introduction

The paper proposes allowing the use of 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 {
                //...
            }
        }
    }
    

The feature was already proposed by Jon Jagger in 2003 in the paper N1524 Nested Namespace Definition Proposal, but it has been listed in N2869 State of C++ Evolution (Post San Francisco 2008) under Not ready for C++0x, but open to resubmit in future.

III. Motivation

Programmers' demand

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:

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.

Prevalence

It is not uncommon to find many deeply nested namespaces in large projects. For example, a search using the regular expression pattern (namespace\s+\w+\s*\{\s*){3,} to find nested namespace definitions at least 3 levels deep in the include directory of Boost libraries yielded 3758 matches and the greatest nesting level found this way was 7 (4 matches).

Existing practice in other languages

An analogous syntax 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. Java or PHP).

Existing practice in C++

The author is not aware of any C++ compiler supporting this feature; however Lzz, a tool that automates many onerous C++ programming tasks, supports it – from the tool's documentation:

The name of a named namespace may be qualified.

    namespace A::B { typedef int I; }
    
is equivalent to:

    namespace A { namespace B { typedef int I; } }
    

IV. Impact On the Standard

The proposal describes a pure language extension which is a non-breaking change – code that was previously ill-formed now would have well-defined semantics.

V. Open Issues

Attributes

Currently, the C++ Standard doesn't allow for specification of attributes for namespaces, but a resolution to the EWG issue #113 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


    namespace A::B::C [[attr]] {
        //...
    }
    
is equivalent to

    namespace A {
        namespace B {
            namespace C [[attr]] {
                //...
            }
        }
    }
    

Inline namespaces

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.

Namespace aliases

By analogy, qualified names could also be allowed in namespace alias definitions, in which case


    using namespace A::B::C = X;
    
would be equivalent to

    namespace A {
        namespace B {
            using namespace C = X;
        }
    }
    
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.

VI. Technical Specifications

Proposed wording will be provided at a later time.