Should the implementation guard itself against comma overloading?

Question

For example uninitialized_copy is defined in the standard as:

Effects:

for (; first != last; ++result, ++first)   ::new (static_cast<void*>(&*result))     typename iterator_traits<ForwardIterator>::value_type(*first); 

If understood literally, this is a requirement to call operator ,(ForwardIterator, InputIterator). And in fact this code prints Hello world! ten times:

#include <memory> #include <iterator> #include <iostream>   using namespace std;  namespace N {          struct X : iterator<forward_iterator_tag, int> {         pointer _p;         X(pointer p) : _p(p) {}         X& operator++() { ++_p; return *this; }         X operator++(int) { X r(*this); ++_p; return r; }         reference operator*() const { return *_p; }         pointer operator->() const { return _p; }     };           bool operator==(X a, X b) { return a._p == b._p; }     bool operator!=(X a, X b) { return !(a == b); }           void operator,(X a, X b) { cout << "Hello world!\n"; } }  int a[10], b[10];   int main() {     using N::X;     uninitialized_copy(X(a), X(a+10), X(b)); } 

However, for most other algorithms the standard gives the description in prose. E.g. for copy there's no requirement for operator , to be called. But if I change

    uninitialized_copy(X(a), X(a+10), X(b)); 

in the above code to

    copy(X(a), X(a+10), X(b)); 

then Hello world! is still printed ten times. The said results are observable in both, VS2005 and GCC 4.3.4. However, if I write

    mismatch(X(a), X(a+10), X(b)); 

instead, then VS2005 prints Hello world! ten times but GCC does not.

Unfortunately I couldn't find where the standard prohibits operator, overloading for iterator types. On the contrary, it prohibits the implementations to do calls as above [global.functions]:

Unless otherwise specified, global and non-member functions in the standard library shall not use functions from another namespace which are found through argument-dependent name lookup (3.4.2).

So who of the four parties is wrong: MSVC, GCC, ISO or me? (Choose one)

Answer 1

Nice catch. I think in my humble opinion that the ISO committee's intention was that §3.4.2 should be followed. The suggested semantics of uninitialized_copy is wrongly interpreted as if requiring the comma to be called. And implementations should not be using it (I'd report a bug to gcc btw).