Rationale:

[ 2020-11-09 Resolved for C++20. Status changed: Tentatively Resolved → Resolved. ]

[ 2020-05-03 Reflector discussion ]

Tentatively Resolved by P0408R7 adopted in Cologne 2019.

The change we approved is not what the issue recommended (and not what some implementations do), so we decided with leaving it as Tentatively Resolved to give people a chance to review it.

[ 2020-05-02 Daniel comments ]

It seems that this issue is now resolved by the proposal P0408R7, accepted in Cologne 2019.

The paper clarified that the allocator is provided based on the effect of initializing the exposition-only basic_string buf with the provided basic_string argument s (Which again is specified in terms of the allocator-related specification([string.require] p3).

[ 2017-11 Albuquerque Wednesday night issues processing ]

Priority set to 3

[ 2017-11-01, Marshall comments ]

There exist two related proposals, namely P0407R1 and P0408R2.

Consider the following constructor from [stringbuf.cons] before p3:

explicit basic_stringbuf(
  const basic_string<charT, traits, Allocator>& s,
  ios_base::openmode which = ios_base::in | ios_base::out);

In [stringbuf.cons]/3, it says:

Effects: Constructs an object of class basic_stringbuf, initializing the base class with basic_streambuf() (30.6.3.1), and initializing mode with which. Then calls str(s).

But that doesn't mention where the allocator for the basic_stringbuf comes from. Until recently, most implementations just default constructed the allocator. But that requires that the allocator be default constructible.

This bug was filed against libc++ for this case.

I think that the basic_stringbuf should be constructed with a copy of the allocator from the string.