Proposed resolution:

Changes are based off of N4618

1. Modify [basic.string] as indicated (in the synopsis):

   class basic_string {
   public:
   // types:
     using traits_type      = traits;
     using value_type       = charTtypename traits::char_type;
     using allocator_type   = Allocator
   

2. Change [string.require]/3 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 Allocator object used shall be obtained as described in 23.2.1. [ Note: In every specialization basic_string<charT, traits, Allocator>, the type traits shall satisfy the character traits requirements (21.2), and the type traits::char_type shall namebe the same type as charT; see 21.2. — end note ]

[ Kona 2017-02-28 ]

Accepted as Immediate to resolve NB comment.

[ 2017-02-02 Marshall adds ]

In [string.require]/3, there's already a note that the types shall be the same. In [string.view.template]/1, it says "In every specialization basic_string_view<charT, traits, Allocator>, the type traits shall satisfy the character traits requirements (21.2), and the type traits::char_type shall name the same type as charT".

Addresses US 145

There is no requirement that traits::char_type is charT, although there is a requirement that allocator::value_type is charT. This means that it might be difficult to honour both methods returning reference (such as operator[]) and charT& (like front/back) when traits has a surprising char_type. It seems that the allocator should not rebind in such cases, making the reference-returning signatures the problematic ones.

Suggested resolution: Add a requirement that is_same_v<typename traits::char_type, charT> is true, and simplify so that value_type is just an alias for charT.