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

### 2238. Problematic iterator-pair constructor of containers

Section: 21.5 [c.strings] Status: Open Submitter: Johannes Schaub Opened: 2013-02-02 Last modified: 2016-08-09

Priority: 3

View other active issues in [c.strings].

View all other issues in [c.strings].

View all issues with Open status.

Discussion:

The non-explicit nature of the iterator-pair constructor of containers, such a

>     template <class InputIterator>
>     vector(InputIterator first, InputIterator last, const Allocator& = Allocator());

can be selected in unexpected situations, leading to a hard runtime error, as demonstrated by the following example:

>     #include <vector>

>     void f(std::vector<char> v){ /* ... */}

>     int main() {
>       f({"A", "B"});
>     }

The actually intended initializer-list constructor isn't feasible here, so the best match is the constructor template

>     template <class InputIterator>
>     vector(InputIterator first, InputIterator last, const Allocator& = Allocator());

This compiles, but will result in code running amok. The potential trap (that cannot be easily detected by the library implementation) could be reduced by making this constructor explicit. It would still have the effect to be selected here, but the code would be ill-formed, so the programmer gets a clear message here.

[2014-06 Rapperswil]

JW: can't fix this, don't want to touch this, Do The Right Thing clause has been a source of tricky issues. only really happens with string literals, that's the only way to create an array that isn't obviously an array

GR: want to see paper

AM: is it only string literals, or also UDLs?

STL: maybe, but we don't need to deal with that. This is only a problem in a very specific case

Leave as Open.

Proposed resolution: