Inject namespace experimental to std

Question

Is it bad or good parctice to inject namespace std::experimental into std like following?

namespace std
{
namespace experimental
{
}
using namespace experimental;    
}

#include <experimental/optional>

int main()
{
    std::optional< int > o;
    return 0;
}

Or even in more modern form:

#if __has_include(<optional>)
# include <optional>
#elif __has_include(<experimental/optional>)
# include <experimental/optional>
namespace std
{
using namespace experimental;    
}
#else
#error !
#endif

int main()
{
    std::optional< int > o;
    return 0;
}

The intention to introduce std::experimental "sub-namespace" is clear because std::experimental currently contains a plenty of new libraries. I think it is very likely all them will migrate into namespace std without any substantial changes and user code written currently can rely upon this (am I totally wrong?). Otherwise all this code should be refactored to change from std::experimental:: to std:: in the future. It is not big deal, but there may be reasons not to do so.

The question is about both production code and not-too-serious code.

Answer 1

Many libraries in std::experimental can and will change in ways that will break user code before they migrate to std, and they may not even migrate into std. This is why they put them in std::experimental.

std::experimental is intended for a relatively free-for-all place where you can introduce new proposed library features for C++, and compilers can implement them, without it breaking existing code. The implementations are in flux and are not standard. Some of them may make it into C++1z, but some of them may not, and those that do make it in may be changed, and those that don't make it in might make it into C++2x with substantial changes.

Simply look at the history of, say, Ranges. Or the coroutine/resumable functions stuff microsoft is proposing. Or the reflection working group. Or concepts.

The goal of this iteration of C++ is, dare I say it, to be Agile, and to fail fast. Many independent proposals work their way through the pipeline, with a goal to minimize inter-dependencies. If a given proposal isn't ready for prime time at the time a C++ standard is, it doesn't make it in. If it is ready, and worthwhile, it is added in modularly.

This was (to my understanding) done explicitly to avoid the mess where some part of the process got "too big to fail" and things that where not ready where published into the standard, or the standard release was delayed for years because something was not ready.

On top of the above, messing around with std in that way makes your program ill-formed with no diagnostic required, as other answers have pointed out.

Answer 2

Sounds like a bad idea.

First off, this is undefined behaviour. Standards draft N4140 says:

[namespace.std]/1: The behavior of a C++ program is undefined if it adds declarations or definitions to namespace std or to a namespace within namespace std unless otherwise specified. [...]

A using-directive is a kind of declaration, so UB is the order for the day.

Secondly, things in std::experimental are very much subject to change. You might find that when things are moved into std proper that your code still compiles, but doesn't act in quite the same way. This is just asking for trouble, especially in production code.