namespace pollution

[Steven King <sxking at uswest dot net>]

Generally, as a compiler/library user, I've always operated under the
assumption that if I dont directly #include anything other than the standard
headers, I shouldnt have to worry about name clashes with any name not reserved
by the standard.  Now consider a (somewhat contrived) example.

#include <locale>

struct iconv
{
   iconv (char const *) throw ();
   ~iconv ();
};

int
main ()
{
   iconv *i = new iconv ("?");
}

This wont compile with the current library because one of the headers
indirectly #included from locale is iconv.h which defines a function iconv. 
This is not, to the best of my knowledge, a reserved symbol.  That the
compilers error message, "`i' undeclared (first use this function)", doesnt
actually tell me whats really wrong doesnt help either.

My thought is that any non-standard symbols used by the library be placed in an
implementation reserved namespace and if they are imported into namespace std,
be given an implementation reserved name.  ie for bits/codecvt.h (the header
that #includes iconv.h) we might have something like

namespace _C_legacy {
   extern "C" {
# include <iconv.h>
   }
}

namespace std
{
   typedef _C_legacy::iconv_t __iconv_t;
   inline __iconv_t __iconv_open (...) { return _C_legacy::iconv_open (...); }
   inline __iconv_t __iconv (...) { return _C_legacy::iconv (...); }
   inline int __iconv_close (...) { return _C_legacy::iconv_close (...) }
}

namespace std
{
   class __enc_traits
   {
   public:
        typedef __iconv_t __desc_type;
   // etc, etc
   };
}

The reason I'm bring this up, is at the very least it impacts the shadow header
layout.

Any thoughts?  Objections?  Alternatives?

-- 
Steven King
sxking@uswest.net