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

### 2585. `forward_list::resize(size_type, const value_type&)` effects incorrect

Section: 99 [forwardlist.modifiers] Status: C++17 Submitter: Tim Song Opened: 2016-01-14 Last modified: 2017-07-30

Priority: 0

View all other issues in [forwardlist.modifiers].

View all issues with C++17 status.

Discussion:

99 [forwardlist.modifiers]/29 says that the effects of `forward_list::resize(size_type sz, const value_type& c)` are:

> Effects: If `sz < distance(begin(), end())`, erases the last `distance(begin(), end()) - sz` elements from the list. Otherwise, inserts `sz - distance(begin(), end())` elements at the end of the list such that each new element, `e`, is initialized by a method equivalent to calling `allocator_traits<allocator_type>::construct(get_allocator(), std::addressof(e), c)`.

In light of LWG 2218, the use of `allocator_traits<allocator_type>::construct` is incorrect, as a rebound allocator may be used. There's no need to repeat this information, in any event — no other specification of `resize()` does it.

[2016-02, Issues Telecon]

P0; move to Tentatively Ready.

[2016-02-11, Alisdair requests reopening]

I believe the standard is correct as written, and that by removing the clear direction to make the copy with uses-allocator-construction, we open ourselves to disputing this very point again at some point in the future.

The issue seems to be complaining that a rebound allocator may be used instead of the allocator returned by `get_allocator()` call, and nailing us down to exactly which instantiation of `allocator_traits` is used. Given the requirements on allocators being constructible from within the same template "family" though, and specifically that copies compare equal and can allocate/deallocate on each other's behalf, this should clearly fall under existing as-if freedom. The construct call is even more clear, as there is no requirement that the allocator to construct be of a kind that can allocate the specific type being constructed — a freedom granted precisely so this kind of code can be written, and be correct, regardless of internal node type of any container and the actual rebound allocator used internally.

I think the new wording is less clear than the current wording, and would prefer to resolve as NAD.

Proposed resolution:

This wording is relative to N4567.

1. Edit 99 [forwardlist.modifiers]/29 as indicated:

   > [Drafting note: "copies of `c`" is the phrase used by `vector::resize` and `deque::resize`.]

   >     void resize(size_type sz, const value_type& c);

   > > -29- Effects: If `sz < distance(begin(), end())`, erases the last `distance(begin(), end()) - sz` elements from the list. Otherwise, inserts `sz - distance(begin(), end())` elements copies of `c` at the end of the list such that each new element, `e`, is initialized by a method equivalent to calling `allocator_traits<allocator_type>::construct(get_allocator(), std::addressof(e), c)`.