Dave Abrahams wrote
on Fri Dec 16 2011, "Jeffrey Lee Hellrung, Jr." <jeffrey.hellrung-AT-gmail.com> wrote:
On Thu, Dec 15, 2011 at 8:26 AM, Lorenzo Caminiti <lorcaminiti@>wrote: [...]
I'm asking because Boost.Contract will support both type predicates and concepts so I need to tell the users why they can use both, when to use concepts, and when to use type predicates. Actually, Boost.Parameter also supports both because it can be used together with Boost.Concept so IMO it'd be nice to add the same explanation to Boost.Parameter as well.
I don't think Boost.Contract nor Boost.Parameter is special in this regard. The guideline I follow is: use type predicates only to differentiate between overloads via SFINAE; otherwise, use concept assertions, as they typically provide more informative error messages and don't complicate the function signature.
I mostly agree, but there are a few exceptions to that rule. One is when you're writing conversion operators, constructors, or other operations with broadly-understood semantics: if you don't use SFINAE to take them out of contention when they don't apply, then other people using traits (usually relying on SFINAE tricks themselves) will get the wrong answer for, e.g., is_convertible<T,U>, has_addition<T>, etc.
I think a (bad) example of that is the implementation of operator== for std::vector<T> which is not taken out of overload resolution using SFINAE when T does not have an operator==. Then has_equal_to< std::vector<T> > is true even when has_equal_to<T> is false, making necessary to explicitly specialize has_equal_to for vectors (and other containers) to work around this :( Another example of when you want SFINAE to fail the overload instead of a concept error is to distinguis deduced parameters for which you will always use type predicates (as far as I can tell). (I will add the result of this discussion to Boost.Contract docs.) --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/parameter-type-predicates-vs-concepts-tp4... Sent from the Boost - Dev mailing list archive at Nabble.com.