This includes an experimental workaround for LWG3664 "LWG3392 broke std::ranges::distance(a, a+3)", but the workaround may be incomplete, I'm not sure. This should be re-audited when LWG3664 is actually adopted, to see if we need to change anything about our implementation. See also https://github.com/microsoft/STL/pull/2500
The current draft standard says
template<input_or_output_iterator I, sentinel_for<I> S> requires (!sized_sentinel_for<S, I>) constexpr iter_difference_t<I> distance(I first, S last); template<input_or_output_iterator I, sized_sentinel_for<I> S> constexpr iter_difference_t<I> distance(const I& first, const S& last);
My P/R is
template<class I, sentinel_for<I> S> requires (!sized_sentinel_for<S, I>) constexpr iter_difference_t<I> distance(I first, S last); template<class I, sized_sentinel_for<decay_t<I>> S> constexpr iter_difference_t<I> distance(const I& first, S last);
Microsoft STL is also planning to adopt the P/R: https://github.com/microsoft/STL/pull/2500
However, @tcanens pointed out a problem with the P/R: you can have an evil sentinel that is a sized_sentinel_for<int*> but doesn't support last - first when first is not literally an int*.
Can you add an entry for not-yet-voted LWG3664 and mark it as implemented?
So do I understand correctly that the resolution of LWG3664 might change? I just want to be careful to avoid implementing stale resolutions.