Alright, I'm updating the way concept maps are defined and I'd like some feedback here before I go through the task of creating yet another named-parameter macro. In designing Generic, I've gone in a slightly different direction from what would have been C++0x concepts and concept maps. In particular, instead of having "auto concepts", all concepts are by default explicit, however, a programmer can create one or more "auto concept maps" for a given concept. These "auto concept maps" act as concept maps with optional conditions (SFINAE and metafunction conditions). For instance, there has been concern in the C++ community about making iterator concepts, not to mention many other concepts, auto. I side with the explicit crowd and agree that most concepts should be be explicit, including iterator concepts, however, given certain conditions, I believe that it is acceptable for types that pass some kind of basic compile-time check to be automatically mapped if the superficial requirements of the concept are met. If it's not clear what I mean, here is an example: ////////// BOOST_GENERIC_CONCEPT_MAP ( ( template ( (class) T ) ) , (ForwardIterator)( T ) , ( if ( check_if_T_uses_the_boost_forward_iterator_helper_base< T > ) ) ) ( // Empty implementation ) ////////// In the above code we have an auto concept map for ForwardIterator that only applies to types which inherit from forward_iterator_helper of Boost.Operators. In addition to the explicitly specified "if" check, it will also implicitly check via SFINAE all of the syntactic concept requirements. The idea is that if a class uses the iterator helper base then it is likely trying to be a forward iterator. While this is not entirely true 100% of the time (a quick example is another intermediate base that uses this helper base), it should be safe and useful in practice and is IMO a better alternative to fully auto concepts, and it should alleviate the need for programmers creating iterators to have to manually make empty concept maps in many situations. First, I'd like to get some feedback on this approach before I take the time to fully implement it. Does the idea of "auto concept maps" as opposed to "auto concepts" make sense? What problems may arise from this? One thing that may initially appear to be a problem is that you can have two auto concept maps with overlapping conditions, in which case the auto concept map to use would be ambiguous. This problem can be alleviated by explicitly specifying a non-auto concept map which would be preferred over the auto maps. The rules for which concept maps get picked are the same as they are for matching template specializations that have (optional) Enable_If style conditions, as that's how everything is implemented underneath the hood, so the method of disambiguation should be fairly familiar to C++ programmers. If anyone sees any problems with this approach, please let me know, as it will save me a lot of effort if there are any as-of-yet unforeseen show-stopping problems. -- -Matt Calabrese