A separate namespace for implementation functions?

[Gabriel Dos Reis]

"Stephen M. Webb" <stephen@bregmasoft.com> writes:

| I've been grooming some of the header files to remove unneeded functions
| (usually leftover workarounds for compilers that don't support partial
| specialization).  This still leaves a whole slew of auxiliary support functions,
| especially for the implementation of Algorithms.  Most of the time, these
| auxiliary support functions have uglified names so there are no name
| conflicts with userspace names, but the language itself provides a
| mechanism to do this.

The uglification question has nothing to do with namespace -- there
already have been some discussions on that topic.  Macros for example
don't respect scopes.

| My question-of-the-day is this.  Should these auxiliary functions be put
| in a separate namespace (say, std::impl)?

There is no need to.

|  The advantages are that their
| use is a little clearer and someone is less likely to assume they can use
| such a function

Oh, anyone using an identifier of the form _[A-Z_].* knows that he/she
makes non-portabitlity assumptions.


| (they might use std::__copy_aux since it's obviously a
| standard function,

That is unlikely.

| but maybe hesitate at std::impl::__copy_aux).

We're not allowed to use std::impl. The identifier 'impl' is in the
user-namespace. 

|  The only
| real disadvantage is that code must be touched.

For no gain.

| The isues to be addressed include:
| 
| Should this even be done?

I think no.

For extentions, we have __gnu_cxx.

-- Gaby