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