Proposed resolution:

This wording is relative to N4950.

1. Edit [string.require] as indicated:

   -3- In every specialization basic_string<charT, traits, Allocator>, the type allocator_traits<Allocator>::value_type shall name the same type as charT. Every object of type basic_string<charT, traits, Allocator> shall use an object of type Allocator to allocate and free storage for the contained charT objects as needed. The In every specialization basic_string<charT, traits, Allocator>, the type traits shall satisfy the character traits requirements ([char.traits]).

   [Note 1: Every specialization basic_string<charT, traits, Allocator> is an allocator-aware container, but does not use the allocator’s construct and destroy member functions ([container.requirements.general]). The program is ill-formed if Allocator::value_type is not the same type as charT. — end note]

   [Note 2: The program is ill-formed if traits::char_type is not the same type as charT. — end note]

[ 2023-06-17 Approved at June 2023 meeting in Varna. Status changed: Voting → WP. ]

[ 2023-06-01; Reflector poll ]

Set status to Tentatively Ready after eight votes in favour during reflector poll.

There was a request to editorially move the added text in Note 1 into Note 2 after this is approved.

[ 2023-05-15; Jonathan Wakely provides improved wording ]

As noted above, most of this issue was resolved by P1148R0. The remainder is the change to make it ill-formed if the allocator has the wrong value_type, but since P1463R1 that is already part of the Allocator-aware container requirements, which apply to basic_string.

[ 2017-07 Toronto Tuesday PM issue prioritization ]

Priority 3; need to check general container requirements

Partially by the adoption of P1148 in San Diego.

Tim opines: "the remainder deals with allocator value type mismatch, which I think is NAD."

basic_string and basic_string_view involve undefined behavior in a few cases where it's simple for the implementation to add a static_assert and make the program ill-formed.

With regards to basic_string, [char.traits]/3 states:

Traits::char_type shall be the same as CharT.

Here, the implementation can add a static_assert using the is_same type trait. Similar issues exist in [string.require] and, for basic_string_view, in [string.view.template]/1.