[boost] [explore] Extending namespace std

Subject: [boost] [explore] Extending namespace std
From: Jeffrey Faust (jeff_at_[hidden])
Date: 2009-12-03 20:38:24

The various threads of discussion have died down.  These include the
name of the library, whether it's useful or not, if it is useful can it
be satisfied by an existing library, whether it should it be part of
another library or be a library on its own, and gcc compiler switches.
All of these are important and we'll have to address them at some point
(except perhaps the compiler switches).
 
One item that was brought up and dismissed is that the implementation
relies on extending namespace std.  I'd like to visit this item more
thoroughly.  In my opinion the ideal interface is the most natural,
simplest, and the most familiar to C++ developers: 'cout << c;' where c
is a container of type C.  Going beyond this nominal usage employs
stream manipulators, again something that is known.  Other forms such as
'print(c);' or 'wrapper(cout) << c;' are inferior interfaces.  The
former is clumsy and the latter does not extend in a natural way.
 
Whether or not you agree, for the sake of argument, let's start with the
statement that 'cout << c;' is the ideal interface for this library.
Let's discuss how we can make this work.
 
The only way I know how to make 'cout << c;' work for all cases is to
put operator<<(C) in the same namespace as C.  For example, variant<C,
...> will not stream if C is in std and operator<<(C) is not.  The only
way operator<<(variant) can see operator<<(C) is through ADL.  If
anybody can think of a mechanism where this will work without extending
namespace std, please speak up.
 
In regards to extending namespace std, I understand what the standard
says and I think I understand the reasons behind it.  I could add
something to namespace std that conflicts with an existing item,
changing the behavior.  This is certainly undefined behavior, and the
standard is right in restricting it.
 
I don't believe this problem exist for the explore library.
 
If we know that on all supported compilers that extending namespace std
in this way behaves correctly, what is the concrete problem of doing so?
 
Thanks for reading,
 
-- Jeff Faust