When enable_if disables a particular overload resolution candidate,
rummage through the enable_if condition to find the specific condition
that caused the failure. For example, if we have something like:
template< typename Iter, typename = std::enable_if_t<Random_access_iterator<Iter> && Comparable<Iterator_value_type<Iter>>>> void mysort(Iter first, Iter last) {}
and we call "mysort" with "std::list<int>" iterators, we'll get a
diagnostic saying that the "Random_access_iterator<Iter>" requirement
failed. If we call "mysort" with
"std::vector<something_not_comparable>", we'll get a diagnostic saying
that the "Comparable<...>" requirement failed.
I can imagine this being a bit surprising in other cases where it also fires (eg enable_if<N == 3 || N == 4> would only diagnose the N == 4 part). If we're only targeting the precise pattern used by ranges v3 here, we could check that the expression comes from a macro named CONCEPT_REQUIRES or CONCEPT_REQUIRES_.