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: 23.3.7.5 [forward.list.modifiers] Status: C++17 Submitter: Tim Song Opened: 2016-01-14 Last modified: 2023-02-07

Priority: 0

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

View all issues with C++17 status.

Discussion:

[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(i), 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 [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()) elementscopies 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).