The purpose of this project is to experiment with the design of the iterator
concepts hierarchy. Specifically, the difference between Input and Forward
iterators with regard to the MultiPass axiom. The new approach is predicated on
the notion of an "explicit" concept - this kind of concept is basically rejected
outright, unless it is explicitly modeled.


== Reasons for Concepts Maps ==
There seem to be two reasons to construct concept maps: to provide associated
types and to explicitly model concepts. Consider the concept maps for pointers
that declare the required associated types. In the first case, associated types
can be provided by specializing metafunctions although that can, unfortunately
distribute the adaptation of types, increasing the complexity of adaptation.

Is there a way to simplify the adaptation process?

Is it acceptable to require specializations of *each* concept where associated
types cannot be deduced?

== Checking Requirements ==
There seems to be a motivating requirement that decouples the checking of a
concept from its definition, especially in the presence of concept maps. Simply
claiming that a type models a concept doesn't necessarily make it so. For
example, in the current system, I can claim that a list iterator is a model of
the RandomAccessIterator concept, and there is nothing that verifies that that
is the case.

This is made more difficult since the checks are deductive. I can't really
make the claim and then cause the deductive check because creating a concept
map does not affect the metaprogramming of the deduction. In short this is
really an unimplementable feature - I think.