Howard Hinnant wrote:
Fwiw, I used something closely related in libc++ for SFINAE on the “member
template members” of the containers (the ones taking iterators) to
disambiguate them from the members/constructors not taking iterators, but
having the same number of parameters. But instead of is_iterator, I
needed is_input_iterator, is_forward_iterator, etc.
That was exactly what I had in mind. Instead of enable_if on is_iterator<T>,
it's almost always better to use enable_if on is_convertible, where tag is the kind of
iterator the function actually needs. (This requires the new and improved
iterator_traits though - were those C++14?)
About the only use case I can envisage for the plain is_iterator is
template<class It> typename enable_if::type
function( It first, It last )
{
static_assert( is_forward_iterator<T>::value, "'function' requires
forward iterators" );
// ...
}
where you deliberately don't SFINAE out the function in order to produce a
better error message in the presence of other overloads.
But even then... is_input_iterator would be good enough, I suppose.
(-pedantic on: an iterator is not required to have nested types, so the
implementation is not quite correct. Of course, again, without the new and
improved iterator_traits, it's the best that we can do.)
