Does your library define just traits or try to emulate Concept Lite?

I'm not quite sure what you are asking. The library doesn't do everything that Concepts Lite does. It lets you define concept-like predicates(commonly called a type trait in C++) in a similiar manner as Concepts Lite does. It does do template constraints as well, but this is just done using `enable_if`. Also, it won't resolve ambiguity between overloads like Concepts Lite does. However, I am thinking about implementing a mechanism for this. Perhaps something like this: struct advance1 { template<class Iterator> TICK_OVERLOAD_REQUIRES(is_random_access_iterator<Iterator>); template<class Iterator> void operator()(Iterator& it, int n) const { it += n; } }; struct advance2 { template<class Iterator> TICK_OVERLOAD_REQUIRES(is_input_iterator<Iterator>); template<class Iterator> void operator()(Iterator& it, int n) const { while (n--) ++it; } }; tick::overload<advance1, advance2> advance = {}; However, this is fairly verbose even with the help of macros. It just might be easier to add some `not`s to the requires clause. Now, non-template members can be disabled, but they need to be made templated, like this: template<class Base> struct A : Base { template<class Self=A, TICK_REQUIRES(is_incrementable<Self>()) void increment() { ++(*this); } }; However, the library cannot be used with special members(such as copy constructors, move constructors, and assignment operators). This is a limitation of the language, since these special members cannont ever be templates. There might be a way to workaround the issue using universal references. I haven't really looked into it. Thanks, Paul -- View this message in context: http://boost.2283326.n4.nabble.com/Tick-Trait-instrospection-and-concepts-li... Sent from the Boost - Dev mailing list archive at Nabble.com.

Have you read the Concept-Based Overloadingin Eric's blog [1]? Eric uses a dispatching schema on which the Concept definition is the tag dispatcher.

Yes, I have, however, tag dispatching doesn't work with specialization(neither does concept-based overloading, apparently). After thinking about it more, a simpler way is to just use conditional overloading instead, which would work something like this: struct advance1 { template<class Iterator, TICK_REQUIRES(is_random_access_iterator<Iterator>())> void operator()(Iterator& it, int n) const { it += n; } }; struct advance2 { template<class Iterator, TICK_REQUIRES(is_input_iterator<Iterator>())> void operator()(Iterator& it, int n) const { while (n--) ++it; } }; tick::conditional<advance1, advance2> advance = {}; The order the functions are placed matter, think of it like this pseudo- syntax: template<class Iterator> void advance(Iterator& it, int n) if (is_random_access_iterator<Iterator>()) { it += n; } else if (is_input_iterator<Iterator>()) { while (n--) ++it; } Perhaps, some macros could help to reduce the boilerplate.

This is not a good idea. The default will be checked independently of whether increment is used or not, isn't it?

It gets checked when increment gets called(at instantiation). If `is_incrementable` is false, it will cause substitution failure. Paul -- View this message in context: http://boost.2283326.n4.nabble.com/Tick-Trait-instrospection-and-concepts-li... Sent from the Boost - Dev mailing list archive at Nabble.com.