`<string>`: `char_traits` specializations for "exotic" chars
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.
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.
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.
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.
@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.
Corentin Jabot is pursuing the deprecation of any user-provided char_traits and abandoning the use of any members of std::char_traits (P3681R0).
https://github.com/cplusplus/papers/issues/2313
I've seen people using iostreams with
signed charandunsigned char, but I forget whether that extended tobasic_string.We could explore doing this with an escape hatch.
Last year, I fixed the issue for microsoft/terminal, enabling conhost to be built with libc++. The author and a commenter seemed to think that basic_string<int> could be used as small_vector<int>, but in reality, it's of little value due to the small size of the buffer.