`<string>`: `char_traits` specializations for "exotic" chars

[tiagomacarios]

libc++ has removed the char_traits base template.

... it must be noted that the Standard only specifies specializations of char_traits for char, char8_t, char16_t, char32_t and wchar_t. However, before this patch, we would provide a base template that accepted anything, and as a result code like std::basic_string<long long> would compile but nobody knows what it really does. It basically compiles by accident.

Should the MSVC STL adopt the same changes? This would greatly help cross-platform developers. Louis also has a great point about correctness.

Xcode 16.3 release notes.

[StephanTLavavej]

I've seen people using iostreams with signed char and unsigned char, but I forget whether that extended to basic_string.

We could explore doing this with an escape hatch.

[frederick-vs-ja]

Similar to complex<NonFloatingPoint> (see #1078), although the standard wording is obscurer for char_traits. I've filed LWG-4152 for this, but it's now unclear to me what LWG will decide to do.

[AlexGuteniev]

It might make sense to support /Zc:wchar_t--aware code even after dropping the support for the option itself, so basic_string<unsigned short> may be needed.

[StephanTLavavej]

@AlexGuteniev Note that for ordinary compilations with real wchar_t, users should not see unsigned short machinery - we've been improving the library in this area. For /Zc:wchar_t-, any mentions of wchar_t will mean unsigned short.

The only code that needs to emit both wchar_t and unsigned short is our separately compiled code that has to talk to both real and fake wchar_t clients.