Namespaces, headers, and modifications to standard classes

Since the extensions described in this document are experimental and not part of the C++ standard library, they should not be declared directly within namespace std. Unless otherwise specified, all components described in this document either:

• modify an existing interface in the C++ Standard Library in-place,
• are declared in a namespace whose name appends ::experimental::fundamentals_v3 to a namespace defined in the C++ Standard Library, such as std or std::chrono, or
• are declared in a subnamespace of a namespace described in the previous bullet, whose name is not the same as an existing subnamespace of namespace std.

Each header described in this document shall import the contents of std::experimental::fundamentals_v3 into std::experimental as if by

namespace std::experimental::inline fundamentals_v3 {}

This document also describes some experimental modifications to existing interfaces in the C++ Standard Library.

Unless otherwise specified, references to other entities described in this document are assumed to be qualified with std::experimental::fundamentals_v3::, and references to entities described in the standard are assumed to be qualified with std::.

Extensions that are expected to eventually be added to an existing header <meow> are provided inside the <experimental/meow> header, which shall include the standard contents of <meow> as if by

#include <meow>

New headers are also provided in the <experimental/> directory, but without such an #include.

This is the last in a series of revisions of this document planned by the C++ committee; while there are no plans to resume the series, any future versions will define their contents in std::experimental::fundamentals_v4, std::experimental::fundamentals_v5, etc., with the most recent implemented version inlined into std::experimental.

Feature-testing recommendations

For the sake of improved portability between partial implementations of various C++ standards, implementers and programmers are recommended to follow the guidelines in this section concerning feature-test macros. Standing document SD-6 makes similar recommendations for ISO/IEC 14882:2020.

Implementers who provide a new standard feature should define a macro with the recommended name, in the same circumstances under which the feature is available (for example, taking into account relevant command-line options), to indicate the presence of support for that feature. Implementers should define that macro with the value specified in the most recent version of this document that they have implemented. The recommended macro name is "__cpp_lib_experimental_" followed by the string in the "Macro Name Suffix" column.

Programmers who wish to determine whether a feature is available in an implementation should base that determination on the presence of the header (determined with __has_include(<header/name>)) and the state of the macro with the recommended name. (The absence of a tested feature may result in a program with decreased functionality, or the relevant functionality may be provided in a different way. A program that strictly depends on support for a feature can just try to use the feature unconditionally; presumably, on an implementation lacking necessary support, translation will fail.)