Title
§[map.modifiers]/2 imposes nonsensical requirement on insert(InputIterator, InputIterator)
Status
c++17
Section
[map.modifiers]
Submitter
Tim Song

Created on 2015-12-12.00:00:00 last changed 89 months ago

Messages

Date: 2016-02-07.20:24:45

Proposed resolution:

This wording is relative to N4567.

  1. Edit [map.modifiers] as indicated:

    template <class P> pair<iterator, bool> insert(P&& x);
    template <class P> iterator insert(const_iterator position, P&& x);
    template <class InputIterator>
    void insert(InputIterator first, InputIterator last);
    

    -1- Effects: The first form is equivalent to return emplace(std::forward<P>(x)). The second form is equivalent to return emplace_hint(position, std::forward<P>(x)).

    -2- Remarks: These signatures shall not participate in overload resolution unless std::is_constructible<value_type, P&&>::value is true.

Date: 2016-02-07.20:24:45

[ 2016-02, Issues Telecon ]

P0; move to Tentatively Ready.

Date: 2015-12-22.10:15:35

The initial paragraphs of [map.modifiers] currently read:

template <class P> pair<iterator, bool> insert(P&& x);
template <class P> iterator insert(const_iterator position, P&& x);
template <class InputIterator>
void insert(InputIterator first, InputIterator last);

-1- Effects: The first form is equivalent to return emplace(std::forward<P>(x)). The second form is equivalent to return emplace_hint(position, std::forward<P>(x)).

-2- Remarks: These signatures shall not participate in overload resolution unless std::is_constructible<value_type, P&&>::value is true.

Clearly, p2's requirement makes no sense for insert(InputIterator, InputIterator) - it doesn't even have a template parameter called P.

This paragraph used to have text saying "The signature taking InputIterator parameters does not require CopyConstructible of either key_type or mapped_type if the dereferenced InputIterator returns a non-const rvalue pair<key_type,mapped_type>. Otherwise CopyConstructible is required for both key_type and mapped_type", but that was removed by LWG 2005, whose PR was written as if that overload didn't exist in the text.

It looks like the text addressing this overload is redundant to the requirements on a.insert(i, j) in Table 102 that value_type be EmplaceConstructible from *i. If so, then the signature should just be deleted from this section.

History
Date User Action Args
2017-07-30 20:15:43adminsetstatus: wp -> c++17
2016-03-07 04:11:48adminsetstatus: ready -> wp
2016-02-07 20:24:45adminsetmessages: + msg7962
2016-02-07 20:24:45adminsetstatus: new -> ready
2015-12-17 19:08:12adminsetmessages: + msg7660
2015-12-12 00:00:00admincreate