InputIterator
template parameter for priority_queue
constructorsSection: 23.6.4 [priority.queue] Status: C++23 Submitter: Tim Song Opened: 2021-02-17 Last modified: 2023-11-22
Priority: Not Prioritized
View all other issues in [priority.queue].
View all issues with C++23 status.
Discussion:
There is nothing in 23.6.4 [priority.queue] or more generally 23.6 [container.adaptors]
saying that InputIterator
in the following constructor templates has to be an input iterator.
template<class InputIterator> priority_queue(InputIterator first, InputIterator last, const Compare& x, const Container&); template<class InputIterator> priority_queue(InputIterator first, InputIterator last, const Compare& x = Compare(), Container&& = Container());
The second constructor template above therefore accepts
std::priority_queue<int> x = {1, 2};
to produce a priority_queue
that contains a single element 2
. This behavior seems extremely questionable.
[2021-02-26; LWG telecon]
Set status to Tentatively Ready after discussion and poll.
F | A | N |
---|---|---|
11 | 0 | 0 |
[2021-06-07 Approved at June 2021 virtual plenary. Status changed: Voting → WP.]
Proposed resolution:
[Drafting note: Because an upcoming paper provides iterator-pair constructors for other container adaptors, the wording below adds the restriction to 23.6.1 [container.adaptors.general] so that it also covers the constructors that will be added by that paper. — end drafting note]
This wording is relative to N4878.
Add the following paragraph to 23.6.1 [container.adaptors.general] after p3:
-?- A constructor template of a container adaptor shall not participate in overload resolution if it has an
InputIterator
template parameter and a type that does not qualify as an input iterator is deduced for that parameter.-4- A deduction guide for a container adaptor shall not participate in overload resolution if any of the following are true:
(4.1) — It has an
InputIterator
template parameter and a type that does not qualify as an input iterator is deduced for that parameter.[…]