Title
back_insert_iterator fails when a container is also its value type
Status
new
Section
[back.insert.iterator]
Submitter
Billy O'Neal III

Created on 2020-03-03.00:00:00 last changed 1 month ago

Messages

Date: 2020-03-03.00:00:00

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 [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.

History
Date User Action Args
2020-03-03 00:00:00admincreate