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.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…