Proposed resolution:

Change 24.2:

24.2 Header <iterator> synopsis

...
template <class Container, class Iterator>
   insert_iterator<Container> inserter(Container& x, Iterator typename Container::iterator i);
...

Change 24.4.2.5:

24.4.2.5 Class template insert_iterator

...
template <class Container, class Iterator>
   insert_iterator<Container> inserter(Container& x, Iterator typename Container::iterator i);
...

Change 24.4.2.6.5:

24.4.2.6.5 inserter

template <class Container, class Inserter>
   insert_iterator<Container> inserter(Container& x, Inserter typename Container::iterator i);

-1- Returns: insert_iterator<Container>(x,typename Container::iterator(i)).

The declaration of std::inserter is:

template <class Container, class Iterator>
insert_iterator<Container>
inserter(Container& x, Iterator i);

The template parameter Iterator in this function is completely unrelated to the template parameter Container when it doesn't need to be. This causes the code to be overly generic. That is, any type at all can be deduced as Iterator, whether or not it makes sense. Now the same is true of Container. However, for every free (unconstrained) template parameter one has in a signature, the opportunity for a mistaken binding grows geometrically.

It would be much better if inserter had the following signature instead:

template <class Container>
insert_iterator<Container>
inserter(Container& x, typename Container::iterator i);

Now there is only one free template parameter. And the second argument to inserter must be implicitly convertible to the container's iterator, else the call will not be a viable overload (allowing other functions in the overload set to take precedence). Furthermore, the first parameter must have a nested type named iterator, or again the binding to std::inserter is not viable. Contrast this with the current situation where any type can bind to Container or Iterator and those types need not be anything closely related to containers or iterators.

This can adversely impact well written code. Consider:

#include <iterator>
#include <string>

namespace my
{

template <class String>
struct my_type {};

struct my_container
{
template <class String>
void push_back(const my_type<String>&);
};

template <class String>
void inserter(const my_type<String>& m, my_container& c) {c.push_back(m);}

}  // my

int main()
{
    my::my_container c;
    my::my_type<std::string> m;
    inserter(m, c);
}

Today this code fails because the call to inserter binds to std::inserter instead of to my::inserter. However with the proposed change std::inserter will no longer be a viable function which leaves only my::inserter in the overload resolution set. Everything works as the client intends.

To make matters a little more insidious, the above example works today if you simply change the first argument to an rvalue:

    inserter(my::my_type(), c);

It will also work if instantiated with some string type other than std::string (or any other std type). It will also work if <iterator> happens to not get included.

And it will fail again for such inocuous reaons as my_type or my_container privately deriving from any std type.

It seems unfortunate that such simple changes in the client's code can result in such radically differing behavior.