This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of WP status.

4164. Missing guarantees for forward_list modifiers

Section: 23.3.7.5 [forward.list.modifiers] Status: WP Submitter: Jonathan Wakely Opened: 2024-10-05 Last modified: 2024-11-28

Priority: 3

View all other issues in [forward.list.modifiers].

View all issues with WP status.

Discussion:

The new std::list members added by P1206R7, insert_range(const_iterator, R&&), prepend_range(R&&), and append_range(R&&), have the same exception safety guarantee as std::list::insert(const_iterator, InputIterator, InputIterator), which is:

Remarks: Does not affect the validity of iterators and references. If an exception is thrown, there are no effects.

This guarantee was achieved for the new list functions simply by placing them in the same set of declarations as the existing insert overloads, at the start of 23.3.9.4 [list.modifiers].

However, the new std::forward_list members, insert_range_after(const_iterator, R&&) and prepend_range(R&&), do not have the same guarantee as forward_list::insert_after. This looks like an omission caused by the fact that insert_after's exception safety guarantee is given in a separate paragraph at the start of 23.3.7.5 [forward.list.modifiers]:

None of the overloads of insert_after shall affect the validity of iterators and references, and erase_after shall invalidate only iterators and references to the erased elements. If an exception is thrown during insert_after there shall be no effect.

I think we should give similar guarantees for insert_range_after and prepend_range. The change might also be appropriate for emplace_after as well. A "no effects" guarantee is already given for push_front and emplace_front in 23.2.2.2 [container.reqmts] p66, although that doesn't say anything about iterator invalidation so we might want to add that to 23.3.7.5 [forward.list.modifiers] too. For the functions that insert a single element, it's trivial to not modify the list if allocating a new node of constructing the element throws. The strong exception safety guarantee for the multi-element insertion functions is easily achieved by inserting into a temporary forward_list first, then using splice_after which is non-throwing.

[2024-10-09; Reflector poll]

Set priority to 3 after reflector poll.

It was suggested to change "If an exception is thrown by any of these member functions that insert elements there is no effect on the forward_list" to simply "If an exception is thrown by any of these member functions there is no effect on the forward_list"

Previous resolution [SUPERSEDED]:

This wording is relative to N4988.

1. Change 23.3.7.5 [forward.list.modifiers] as indicated:

   None of the overloads of insert_after shall member functions in this subclause that insert elements affect the validity of iterators and references, and erase_after shall invalidate invalidates only iterators and references to the erased elements. If an exception is thrown during insert_after by any of these member functions there shall be is no effect on the forward_list.

[2024-10-09; LWG suggested improved wording]

The proposed resolution potentially mandates a change to resize when increasing the size, requiring implementations to "roll back" earlier insertions if a later one throws, so that the size is left unchanged. It appears that libstdc++ and MSVC already do this, libc++ does not.

[2024-10-09; LWG telecon: Move to Ready]

[Wrocław 2024-11-23; Status changed: Voting → WP.]

Proposed resolution:

This wording is relative to N4988.

1. Change 23.3.7.5 [forward.list.modifiers] as indicated:

   None of the overloads of insert_after shall affect the validity of iterators and references, and erase_after shall invalidate only iterators and references to the erased elements. The member functions in this subclause do not affect the validity of iterators and references when inserting elements, and when erasing elements invalidate iterators and references to the erased elements only. If an exception is thrown during insert_after by any of these member functions there shall be is no effect on the container.