<string>: basic_string<unsigned long long> is accepted

[AlexGuteniev]

Describe the bug

Unsigned integral types are currently accepted as basic_string first template parameter with the second template parameter being default.

It should not compile, as there shouldn't be a specialization of std::char_traits for other types than standard character types.

[char.traits.specializations.general]/1:

The header <string> defines five specializations of the class template char_traits: char_traits<​char>, char_traits<char8_t>, char_traits<char16_t>, char_traits<char32_t>, and char_traits<wchar_t>.

Command-line test case

C:\Users\ALEXG~1\AppData\Local\Temp>type repro.cpp

#include <string>

int main() {
    std::basic_string<unsigned long long> s({1, 2, 3, 4});
}

C:\Users\ALEXG~1\AppData\Local\Temp>cl repro.cpp
Microsoft (R) C/C++ Optimizing Compiler Version 19.42.34226.3 for x64
Copyright (C) Microsoft Corporation.  All rights reserved.

repro.cpp
Microsoft (R) Incremental Linker Version 14.42.34226.3
Copyright (C) Microsoft Corporation.  All rights reserved.

/out:repro.exe
repro.obj

C:\Users\ALEXG~1\AppData\Local\Temp>repro.exe

C:\Users\ALEXG~1\AppData\Local\Temp>

Expected behavior

Should not compile

STL version

Version 17.12.0 Preview 1.0

Additional context

std::basic_string<unsigned long long, user_defined_traits> should still be valid.

Specializing std::char_traits for unsigned long long should not be supported (no diagnostics required I think).

A whole _String_bitmap specialization exists to support unsigned integral types; this support is mentioned as an 'extension':

STL/stl/inc/__msvc_string_view.hpp

Lines 678 to 680 in c7c5ca7

	static_assert(is_unsigned_v<_Elem>,
	"Standard char_traits is only provided for char, wchar_t, char16_t, and char32_t. See N4950 [char.traits]. "
	"Visual C++ accepts other unsigned integral types as an extension.");

[StephanTLavavej]

For context, we checked the other implementations - libstdc++ 14.2 accepts basic_string<unsigned int> silently, and so does libc++ 18.1, but libc++ trunk (19.x) finally rejects: https://godbolt.org/z/6s131qq1o

We talked about this at the weekly maintainer meeting. We agree that this extension is undesirable, and @barcharcraz noted the additional twist that basic_string<unsigned short> might be used by code with real wchar_t in order to communicate with code built with fake wchar_t (/Zc:wchar_t-, our nemesis). While in theory we could emit a Microsoft deprecation warning by default, with the intention of eventually making it an error by default, we expect that a ton of escape hatch work would be necessary in our Real World Code test suites in addition to legacy codebases. In other cases (e.g. exception::what() noexcept) the change is highly desirable and it's only the migration cost that we worry about, but in this case we believe that the value of purging this non-Standard extension, while non-zero, is quite low.

Ultimately we don't expect we'll have the capacity to deal with this in any foreseeable future, so while we acknowledge that this would be a desirable change, we're going to use our rare resolution of "won't fix forever". Thanks for bringing this up!

[AlexGuteniev]

What about other types, like basic_string<int> or basic_string<long double>?
Currently these are rejected only in find_meow_of, otherwise they are accepted.