[libc++] `__wrap_iter<T>` can hijack `operator+`/`operator<` via ADL

[MitalAshok]

With two T* pointers, </- always has the built-in meaning. But __wrap_iter has a T* template argument so that adds T's namespace as an associated namespace.

In particular, with nasty_char (from https://github.com/llvm/llvm-project/blob/main/libcxx/test/support/nasty_string.h),

https://godbolt.org/z/YT3MvPGd9:

static_assert(std::random_access_iterator<nasty_char*>);
static_assert(!std::random_access_iterator<std::__wrap_iter<nasty_char*>>);
static_assert(!std::random_access_iterator<nasty_string::iterator>);

Shouldn't use user-overloads for non-pointer types, like template<typename T> friend bool operator<(T, T) with T = __wrap_iter<my_random_access_iterator>, either.

[frederick-vs-ja]

Related: the following program doesn't compile when adding -D_LIBCPP_ABI_USE_WRAP_ITER_IN_STD_ARRAY (Godbolt link) due to a similar cause.

#include <array>

struct incomplete;
template<class T>
struct holder {
    T t;
};

int main()
{
    for (auto&& _ : std::array<holder<incomplete>*, 1>{}) {}
}

[philnik777]

True, but this is a fundamental issue. There is no way to write overloaded operators that are ADL proof.

[frederick-vs-ja]

True, but this is a fundamental issue. There is no way to write overloaded operators that are ADL proof.

Can we turn __wrap_iter<T> into something like __wrap_iter_provider<T>::__iterator to make it ADL-proof?

[MitalAshok]

It does seem possible to do (see linked PR), but seems very costly.

Also, unlike with something like P2538R1, the standard seems silent on if ADL should be done. Consider:

#include <list>
#include <iterator>

struct nefarious {
  friend void operator!=(std::list<nefarious>::iterator, std::list<nefarious>::iterator) = delete;
};

int main() {
    for (const auto& n : std::list<nefarious>()) {

    }
}

This would fail on every reasonable implementation, even though the standard says "A list meets all of the requirements of a container". It would be possible to ADL-proof it in a similar way, but I think the user is wrong for defining that operator!=.

The better fix for this problem is to just make nasty_char's operator<=> not beat __wrap_iter's operator<=> (either by adding a second overload with that takes the same type of __wrap_iter or changing nasty_char's operator<=> to take two different template parameters)

[philnik777]

Yes, it is theoretically possible to change, but not without an ABI break. And IMO that ABI break is way too costly to implement it in the unstable ABI for what we gain. It's just not worth the effort for something that won't make much of a difference in the end.