Why can't we declare a namespace within a class?

Solution 1:

Since you asked which parts of the standard mandate namespace location, we hit that up first:

C++11 7.3-p4: Every namespace-definition shall appear in the global scope or in a namespace scope (3.3.6).

Regarding class definitions and the proposition of declaring a namespace within, I bring you to...

C++11 9.2-p2: A class is considered a completely-defined object type (3.9) (or complete type) at the closing } of the class-specifier. Within the class member-specification, the class is regarded as complete within function bodies, default arguments, exception-specifications, and brace-or-equal-initializers for non-static data members (including such things in nested classes). Otherwise it is regarded as incomplete within its own class member-specification.

Ergo, a class definition is finite once the closing curly is reached. It cannot be opened back up and extended (derivation is something different, but it is NOT extending the class just defined).

But lurking at the very beginning of the standard definition of a namespace is the ability to extend it; to expand it for lack of a better term:

C++ 7.3-p1: A namespace is an optionally-named declarative region. The name of a namespace can be used to access entities declared in that namespace; that is, the members of the namespace. Unlike other declarative regions, the definition of a namespace can be split over several parts of one or more translation units. (emphasis added).

Therefore, a namespace within a class would violate the definition in 7.3-p4. Assuming that was not present, it would be possible to declare a namespace anywhere, including in a class, but since the definition of a class is formalized once it is closed, you would be left with only the ability to do the following if you maintained compliance with 7.3-p1:

class Foo
{
   namespace bar
   {
       ..stuff..
   }

   .. more stuff ..

   namespace bar
   {
       ..still more stuff..
   }
};

The usefulness of this feature was likely debated for about 3-full-seconds before 7.3-p4 was established to settle it.

Solution 2:

I'm going to disagree with others here. I wouldn't say there's no real advantage. Sometimes I'd just like to segregate code without extra implications. As an example, I was working in a multithreaded ringbuffer module and wanted to split the state members, some of which are atomic and/or memory-aligned, into namespaces for the producer and the consumer.

By just naming everything with producer or consumer prefixes (which is my current annoying implementation), I'm adding pollution that makes code harder to read. E.g. when everything owned by the producer starts with producer, it's easier for your brain when reading it to accidentally autocorrect producerProducerTimer (producer copy of a producer timer) as producerConsumerTimer (producer shadow of a consumer timer) or consumerProducerTimer (consumer shadow of a producer timer). Debugging that takes way longer than it needs to because the code is no longer skimmable.

By creating a nested class/struct:

• I could be giving the next developer who maintains this code the idea that more than one of these could/should be instantiated, copied, and assigned to one another within a context, so now instead of just worrying about naming I also have to = delete these things.
• I could be adding memory footprint to the context with structural alignment padding that might not otherwise be necessary.
• Making all members static isn't an option, since more than one context can be instantiated that will need its own producer/consumer state variables.
• Functions of such a struct no longer have access to other member data or functions, such as constants or functions that are shared by both sides, but instead have to take these things as arguments.

Ideally, I'd like to be able to change things like this:

rbptr producerPosition;
rbptr consumerPosition;

to this:

namespace producer
{
    rbptr position;
}
namespace consumer
{
    rbptr position;
}

Then, functions that should only touch consumer members can use the consumer namespace, functions that should only touch the producer members can use the producer namespace, and functions that need to touch both have to explicitly qualify them. There'd be no way to accidentally touch a consumer variable in a function that's only using the producer namespace.

In this case, the desire is purely for reducing naming collisions between producer and consumer copies of things, and reducing naming collisions are what namespaces exist for. For that reason, I support the proposal to be able to declare namespaces inside classes.