Reason

Nothing external can depend on an entity in a nested unnamed namespace. Consider putting every definition in an implementation source file in an unnamed namespace unless that is defining an "external/exported" entity.

Example; bad

static int f();
int g();
static bool h();
int k();

Example; good

namespace {
    int f();
    bool h();
}
int g();
int k();

Example

An API class and its members can't live in an unnamed namespace; but any "helper" class or function that is defined in an implementation source file should be at an unnamed namespace scope.

???

Enforcement

• ???

SL: The Standard Library

Using only the bare language, every task is tedious (in any language). Using a suitable library any task can be reasonably simple.

The standard library has steadily grown over the years. Its description in the standard is now larger than that of the language features. So, it is likely that this library section of the guidelines will eventually grow in size to equal or exceed all the rest.

<< ??? We need another level of rule numbering ??? >>

C++ Standard Library component summary:

• SL.con: Containers
• SL.str: String
• SL.io: Iostream
• SL.regex: Regex
• SL.chrono: Time
• SL.C: The C Standard Library

Standard-library rule summary:

• SL.1: Use libraries wherever possible
• SL.2: Prefer the standard library to other libraries
• SL.3: Do not add non-standard entities to namespace std
• SL.4: Use the standard library in a type-safe manner
• ???