2069. Inconsistent exception spec for basic_string move constructor

Section: 27.4.3.3 [string.cons] Status: C++14 Submitter: Bo Persson Opened: 2011-07-01 Last modified: 2016-01-28

Priority: Not Prioritized

View all other issues in [string.cons].

View all issues with C++14 status.

Discussion:

Sub-clause 27.4.3.3 [string.cons] contains these constructors in paragraphs 2 and 3:

basic_string(const basic_string<charT,traits,Allocator>& str);
basic_string(basic_string<charT,traits,Allocator>&& str) noexcept;

[…]

-3- Throws: The second form throws nothing if the allocator's move constructor throws nothing.

How can it ever throw anything if it is marked noexcept?

[2011-07-11: Daniel comments and suggests wording changes]

Further, according to paragraph 18 of the same sub-clause:

basic_string(const basic_string& str, const Allocator& alloc);
basic_string(basic_string&& str, const Allocator& alloc);

[…]

-18- Throws: The second form throws nothing if alloc == str.get_allocator() unless the copy constructor for Allocator throws.

The constraint "unless the copy constructor for Allocator throws" is redundant, because according to Table 28 — Allocator requirements, the expressions

X a1(a);
X a(b);

impose the requirement: "Shall not exit via an exception".

[ 2011 Bloomington. ]

Move to Ready.

Proposed resolution:

This wording is relative to the FDIS.

1. Change 27.4.3.3 [string.cons] p3 as indicated (This move constructor has a wide contract and is therefore safely marked as noexcept):

   basic_string(const basic_string<charT,traits,Allocator>& str);
   basic_string(basic_string<charT,traits,Allocator>&& str) noexcept;
   

   -2- Effects: Constructs an object of class basic_string as indicated in Table 64. In the second form, str is left in a valid state with an unspecified value.

   -3- Throws: The second form throws nothing if the allocator's move constructor throws nothing.

2. Change 27.4.3.3 [string.cons] p18 as indicated (This move-like constructor may throw, if the allocators don't compare equal, but not because of a potentially throwing allocator copy constructor, only because the allocation attempt may fail and throw an exception):

   basic_string(const basic_string& str, const Allocator& alloc);
   basic_string(basic_string&& str, const Allocator& alloc);
   

   […]

   -18- Throws: The second form throws nothing if alloc == str.get_allocator() unless the copy constructor for Allocator throws.