Why does chrono have its own namespace?

Question

Everything else I have seen so far in the C++ standard library is in the std namespace. If I use things from std::chrono I usually exceed my 80 cha

Answer 1

I was lead author on the chrono proposal. A sub-namespace was not my first choice, just because of the verbosity. I find myself writing using namespace std::chrono almost every time I use the facility.

However this was a very controversial proposal. And many people, including some of my co-authors strongly felt that a sub-namespace was appropriate. I did not strongly object to the sub-namespace because we were in a space of needing to compromise, or become just as dead-locked as the US congress. :⁠-⁠) The result of such a dead-lock would have probably been C11's timespec.

boost has experimented with sub-namespaces much more aggressively than the std has and one of the key authors on this paper is also the author of the boost date-time library upon which chrono evolved from. So that would obviously have a strong pull in the direction of using a sub-namespace.

Looking forward it is quite possible that the sub-namespace will become absolutely required. Imagine if we add calendrical services that include an abbreviation for December: dec. This would directly conflict with:

ios_base& dec(ios_base& str);

in <ios>. So all in all, I was probably wrong in not insisting on a sub-namespace from the beginning. :⁠-⁠) Going forward it will be interesting to watch where the committee does and does not create sub-namespaces.

Update (6 years later...)

The truth is always stranger than fiction...

So I did propose std::chrono::dec as an abbreviation for December, thinking that would be safe because of the nested chrono namespace. But no, the committee decided to rename std::chrono::dec to std::chrono::December during the standardization process because of potential conflicts.

So are nested namespaces worth it?

I don't know. This update is a datapoint, not an opinion.

Answer 2

There are other namespaces too, like std::placeholders. Ultimately, in C++03 the Committee did not go for subnamespaces, but it is now painfully obvious that the std namespace is becoming massively overloaded. As such, I expect that many library proposals for C++14 will use a subnamespace for larger organizations of components.