How do they avoid conceptual overload problems without explicit models (aka concept maps)

Question

As stated in a number of conversations and reports by Andrew Sutton, the Concepts Lite proposal has a concept-based overload concept and at the same time does not have a concept map concept, that is, the template arguments are checked against the concept completely by the compiler. Given this, it is unclear how they will solve the problem described in the 2005 document by Sick and Gregor: " Explicit model definitions are needed ." In short, the problem could be formulated with the following quote from the article.

Thus, there are certain types of input iterators (such as istream_iterator) that will be erroneously classified as advanced iterators. What is the danger in this? Some algorithms are sent based on Input_iterator vs. Forward_iterator

(However, there are other examples besides iterators.)

Yes, I know that the above article discusses C ++ 0x concepts, but the problem seems to be “general” compared to the concept proposals.

Answer 1

Proposal in n3351 The design concept for STL is to continue using iterator category tags:

concept InputIterator<WeakInputIterator I> = EqualityComparable<I> && Derived<IteratorCategory<I>, input_iterator_tag>; 

In the syntax expected to be included in the standard for n4377, the C ++ Extensions for Concepts :

 template<typename I> concept bool InputIterator = WeakInputIterator<I>() && EqualityComparable<I>() && Derived<IteratorCategory<I>, input_iterator_tag>(); 

From the previous document:

While C ++ 11 does this, it is possible to evaluate all static requirements [...], we still need to differentiate some concepts based on their semantic requirements. The iterator category solves this problem for us.

In general, semantic requirements can be expressed by checking a type predicate (for example, a nested type or a constant or type function) that exists solely for the purpose of runtime semantics.