Lots of reasons, but mostly it clearly delineates what is required from what is returned.
I agree with you that requires is important, particularly for concept-based overloads where one overload has more refined concepts than another
Can you guys give me an example of this?
std::advance, even in the C++98 standard library, is overloaded differently for input iterators than it is from bidirectional and random access iterators. With random access iterators, advance operates in constant time. With input iterators, advance operates linearly.
Sure, I understand:
template< class I, class Distance > requries InputIterator<I> void advance( I& it, Distance n ) { /* linear complexity... */ }
template< class I, class Distance > requries BidirectionalIterator<I> void advance( I& it, Distance n ) { /* ... */ }
template< class I, class Distance > requries RandomAccessIterator<I> void advance( I& it, Distance n ) { /* constant complexity... */ }
I agree, this type of overloading is a reason for having requires, enable_if will not suffice. Is there any other reason?
One (perhaps minor) reason is that enable_if is an ugly workaround rather than a decent solution for the problem. enable_if is a class template. WHen using it in declaring your function template you have to choose how you want to "uglify" your declaration: (1) Uglify the return type? (2) Add a useless function argument? (3) Add a useless template parameter? "requires" on the other hand gives you another section in the declaration that does not interfere with function arguments or return value. This is only a problem of enable_if. If we have "mini-concepts" in form of static-if, the argument above would not hold anymore. Regards, &rzej