Proposed resolution:

This wording is relative to N5008.

1. Modify [range.stride.iterator] as indicated:

   namespace std::ranges {
     template<input_range V>
       requires view<V>
     template<bool Const>
     class stride_view<V>::iterator {
       using Parent = maybe-const<Const, stride_view>;                      // exposition only
       using Base = maybe-const<Const, V>;                                  // exposition only
   
       iterator_t<Base> current_ = iterator_t<Base>();                      // exposition only
       sentinel_t<Base> end_ = sentinel_t<Base>();                          // exposition only
       range_difference_t<Base> stride_ = 0;                                // exposition only
       range_difference_t<Base> missing_ = 0;                               // exposition only
   
       constexpr iterator(Parent* parent, iterator_t<Base> current,        // exposition only
                          range_difference_t<Base> missing = 0);
     public:
       […]
     
       constexpr decltype(auto) operator*() const { return *current_; }
       constexpr auto operator->() const
         requires has-arrow<iterator_t<Base>> && copyable<iterator_t<Base>>
       { return current_; }
     
       […]
     };
   }

[ 2025-10-21; Reflector poll. ]

Set priority to 3 after reflector poll.

Currently, only filter_view::iterator and join_view::InnerIter in <ranges> provide operator->, which makes sense since their `operator*` simply dereferences the underlying iterator.

It turns out this is also true for stride_view::iterator, suggesting that providing operator-> does is the intuitive thing to do, e.g. when wrapping pointers, keeping operator-> valid so that users can continue to use it->foo().

There is no reason to give up this convenience because stride_view::iterator is intended to preserve the nature of the underlying iterator.