Proposed resolution:

This wording is relative to N5032.

1. Modify [iterator.concept.sentinel] as indicated:

   template<class S, class I>
     concept sentinel_for =
       semiregular<S> &&
       !is-integer-like<S> &&
       input_or_output_iterator<I> &&
       weakly-equality-comparable-with<S, I>; // see [concept.equalitycomparable]
   

[ 2026-02-27; LWG telecon: move to Ready ]

[ 2026-02-20; Jonathan provides new wording ]

[ 2026-02-20; Reflector poll. ]

Set priority to 3 after reflector poll.

The type in the example is basically a `std::any` that additionally type-erases equality. That causes a problem for templated iterators that have their value type's namespace as an associated namespace for ADL.

Instead of allowing integers to be sentinels in general but just restricting them from being used with these overloads, we could just change the concept so that integers do not model `sentinel_for`. That's similar to what we did for `span`'s constructor which has a similar problem (though that one's more aggressive due to compatibility constraints).

Currently, `ranges::advance` and `ranges::next` have `operator()` overloads that accept `(iterator, sentinel)` and `(iterator, difference)`. However, when the difference type of the iterator is also a sentinel type, there may be ambiguity in both overloads.

E.g. the following example is rejected when compiling with libc++ or libstdc++ (demo):

#include <cstddef>
#include <iterator>
#include <type_traits>

template<class T>
struct FwdIter { // triggers ADL for T
  FwdIter();

  using value_type      = std::remove_cv_t<T>;
  using difference_type = int;

  T& operator*() const;

  FwdIter& operator++();
  FwdIter operator++(int);

  friend bool operator==(const FwdIter&, const FwdIter&);
};

static_assert(std::forward_iterator<FwdIter<int>>);

struct OmniConv {
  OmniConv(const auto&);
  friend bool operator==(OmniConv, OmniConv); // found by ADL via things related to OmniConv
};

int main() {
  FwdIter<OmniConv> it{};
  std::ranges::advance(it, 0); // ambiguous
  std::ranges::next(it, 0); // ambiguous
}

Perhaps it would be better to ensure that calling `ranges::advance` or `ranges::next` with an iterator value and a value of the difference type is unambiguous. Note that wrapping iterators that trigger ADL for the value type like the `FwdIter` in this example are common in standard library implementations, so ambiguity can be easily raised from containers with such `OmniConv` being their element type.