Curious issue with char_traits

[Paolo Carlini]

Gabriel Dos Reis wrote:

>| Opinions?
>
>That is the tip of the iceberg.  Following the wisdom of someone who
>is opposed to cover up, I'm opposed to __char_traits as a fix to the
>real problem.
>  
>
Indeed, I agree it's the tip of the iceberg. Therefore, what shall we
do, more generally? In the meanwhile, I figured out some scenarios:
1- We move the current __gnu_cxx::char_traits inside namespace
__gnu_internal instead. That would certainly fix the additional examples
pointed out by Howard. In fact, it can be argued that we are talking
about an implementation detail of std::char_traits, which, as such, may
rightly belong to __gnu_internal. What I don't like is that the original
idea was having __gnu_cxx::char_traits something visible to the user of
the library, ready for specializations, not really only a pure
implementation detail, also an extension. Usually stuff inside
__gnu_internal is not meant for this kind of use, is meant to be
completely hidden.
2- The iceberg, as I see the issue, excluding for now core language
(ADL, etc...) and limiting our attention to the library, is the presence
of non-uglifyied stuff inside __gnu_cxx, to wit, all the legacy SGI/HP
stuff, that I moved there from std with your help as one of my first
projects. That stuff is special, because usually we uglify everything,
everything inside __gnu_cxx, and for a reason (I'm not 100% sure this is
obvious to everyone). Therefore the idea would be working on that, instead:
    2.1- Move all the legacy stuff inside a separate namespace,
__gnu_legacy, for instance, keeping __gnu_cxx for properly uglifyied
extensions.
    2.2- Uglify the legacy stuff (I don't like this idea much, because
code really using, e.g., copy_n, would have to be fixed in many places)
    2.3- Remove completely the legacy facilities (also not so good, in
my opinion, at least we want to keep things like slist, rope).

What do you think? I'm sure I'm missing other solutions, I have more in
mind, but cannot get it into focus...

Paolo.