This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of Ready status.
forward_list modifiersSection: 23.3.7.5 [forward.list.modifiers] Status: Ready Submitter: Jonathan Wakely Opened: 2024-10-05 Last modified: 2024-10-09
Priority: 3
View all other issues in [forward.list.modifiers].
View all issues with Ready 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 ofinsert_aftershall affect the validity of iterators and references, anderase_aftershall invalidate only iterators and references to the erased elements. If an exception is thrown duringinsert_afterthere 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.
Change 23.3.7.5 [forward.list.modifiers] as indicated:
None of theoverloads ofmember functions in this subclause that insert elements affect the validity of iterators and references, andinsert_aftershallerase_aftershall invalidateinvalidates only iterators and references to the erased elements. If an exception is thrownduringby any of these member functions thereinsert_aftershall beis no effect on theforward_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]
Proposed resolution:
This wording is relative to N4988.
Change 23.3.7.5 [forward.list.modifiers] as indicated:
None of the overloads ofThe 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 throwninsert_aftershall affect the validity of iterators and references, anderase_aftershall invalidate only iterators and references to the erased elements.duringby any of these member functions thereinsert_aftershall beis no effect on the container.