generic locale

[Loren James Rittle <rittle at latour dot rsch dot comm dot mot dot com>]

I have a request for the users of non-glibc ports and all library
developers.  The current generic locale code ignores all locale()
objects created by users.  I see why Benjamin did this based on the
C89/C99 API in this area.  However, I think I see how to improve the
generic situation with various degrees of effort/risk/reward.

Here are the choices I would like user input on:

(a) keep the status quo; do not throw exceptions for e.g.:
      locale loc_de("de_DE"); istringstream iss; iss.imbue(loc_de);
    even though they have no effect on input handling, etc.

(b) At least throw an exception in generic for all user instantiations
    of locale() objects unless they map to the "C" (or ""?) locale.
    This, at least, better matches reality.  (Optionally, modify all
    22_locale test case per Martin's idea and/or catch the
    generic-doesn't-handle-non-C-locale exception and accept that as
    an OK run-time termination.)

(c) make generic work for single-threaded programs no matter how slow
    it is; use my system's libc dammit (note: the status quo is already
    broken w.r.t. threading since any unguarded call to setlocale()
    are unsafe and we would have no idea what users might do outside
    the library code)

(d) make generic work for multi-threaded programs (as long as all IO
    is C++-style, see note in c) no matter how slow it is; use my
    system's libc dammit

(e) make generic work for multi-threaded programs (a small race would
    remain against user programs with threads of control that called
    setlocale() directly but protect internal library use); use C89
    locale calls only to fetch "struct lconv" from OS but otherwise
    assume that IO conversions are now disconnected from libc

(f) do whatever you want Loren but put it in 'enhanced-generic' which
    is cloned off generic to start

(z) lobby libc maintainers everywhere to add MT-safe API points that
    match up with glibc

They are listed in the order of hardness with the exception of (f)
which I assume will operate under relaxed checkin requirements since
it can't possible break anyone else unless they manually request it.
That said, (f) probably wouldn't be checked in until it passed
all/many 22_locale tests on at least one port.  I personally favor
doing (b) ASAP and then (f) [where f probably looks like c or e in
practice without the risk of breaking rarely tested ports].

Comments?  Are people starting to care about C++ locale support?  I
admit that I am one of those "one-language speaking" Americans that
knows little beyond the fact that the English actually speak a
different language than us. ;-)

Regards,
Loren