`<ranges>`: iterator and sentinel of `iota_view` should be ADL-proof

[frederick-vs-ja]

Describe the bug
[range.iota] describes the iterator and sentinel types of iota_view as nested classes, but MSVC STL doesn't follow the wording. Difference from the standard wording is observable via ADL (Godbolt link).

#include <ranges>

constexpr int foo(auto) noexcept { return 42; } // selected by libc++ & libstdc++

namespace fvs {
    constexpr int foo(std::input_iterator auto) noexcept { return 0; } // selected by MSVC STL
    struct bar {};
}

using ioit = std::ranges::iterator_t<std::ranges::iota_view<fvs::bar*, fvs::bar*>>;
static_assert(foo(ioit{}) == 42);

I think we should make them non-template classes nested in class templates. IIUC the enclosing class is not nessarily iota_view, which allows SCARY implementation strategies.

See also

• WG21-P2538, and
• How hana::type<T> “disables ADL”.

[StephanTLavavej]

We talked about this at the weekly maintainer meeting. Although this wouldn't be the most breaking change in the world, changing the types of iota_view's iterators and sentinels would be observable to users, and the benefit doesn't seem to outweigh the risk here, so we have a weak preference for deferring such changes to vNext.

It does seem that this is a bug according to the Standard as written. Personally, it seems to me that the Standard is a little too strict here about whether these are nested vs. independent classes (as it is silent on the nature of container iterators), but @strega-nil-ms thinks that the Standard is fine, so opinions vary.

[StephanTLavavej]

It appears that you filed LWG-3907 "Can iterator types of range adaptors and range factories be SCARY?" for this - thanks!