3415. back_insert_iterator fails when a container is also its value type

Section: 24.5.2.2 [back.insert.iterator] Status: NAD Submitter: Billy O'Neal III Opened: 2020-03-03 Last modified: 2020-07-17

Priority: Not Prioritized

View all other issues in [back.insert.iterator].

View all issues with NAD status.

Discussion:

Consider the following:

#include <algorithm>
#include <iterator>
#include <vector>

struct example_container 
{
  using value_type = std::back_insert_iterator<example_container>;
  void push_back(const value_type&) {}
};

int main() 
{
  std::vector<std::back_insert_iterator<example_container>> v;
  example_container ex;
  std::copy(v.begin(), v.end(), std::back_inserter(ex));
}

This example is out-of-contract in the current standard because it creates back_insert_iterator<incomplete>, as per 16.4.5.8 [res.on.functions]/2. However, it might be something we are considering for future iterators and proxy reference types. In practice, the "Ill-formed, no diagnostic required" the user is likely to get is an ambiguity between what back_insert_iterator's copy assignment operator, and its "push back assigning operator". We could resolve this by changing the return type of operator* to a proxy in the same way istream_iterator does, though that might be ABI breaking for some implementations.

We should consider having a standing LWG/LEWG policy that iterators are not their own proxy operator* type if we intend to leave the door open to more incomplete type support in the standard library.

[2020-07-17; Status changed to NAD in telecon]

We reviewed the reflector discussion and were not motivated to support this. There were concerns that adding incomplete type support elsewhere in containers has caused us regrettable problems, and we're not sure we could get this right even if we wanted to support it.

Proposed resolution: