On Fri, 23 Sep 2011 06:45:10 lcaminiti wrote:

In this case T = val has an operator== which is private. This causes both the methods (1) using dummy::operator== and (2) the traits requirement can_call_equal<val> to fail :(

Exactly (at least for the default implementation of can_call_equal<>). This is in general the behavior you want (can't accidentally apply a generic operator== to a type with special semantics for which that wouldn't make sense), but in a contract-checking context I think most users would rather at least have the option to silently ignore the untestable constraint.

Ideally, can_call_equal<val>::value will return false instead of generating a compiler-error when val::operator== is private or protected. A part from such an (impossible?) improvement to can_call_equal, I have no solution for

Hardly impossible... If you really want the constraint to be tested, you obviously have to friend the constraint checker class (which may not always be permissible.) If you're content to ignore it, just specialize can_call_equal<perverse_type> to make the nested ::value false. Note that some user intervention is still required (adding a friend to perverse_type, or adding a specialization of can_call_equal<>), so your contracts won't be silently compiling to no-ops, but the library user has full control with minimal effort. As far as I know, there's no way to offer both options without naming the test predicate something other than operator==. Along the same lines, I recognize that test_equality() isn't the only operation required or supported by the contract mechanism (although I'll bet it's the most common.) However, I still believe that a few test_equality(), test_not_equal(), test_less_than_or_equal(), operator_add(), etc. stubs, and perhaps a HAS_MEMBER_FUNC() macro to generate other custom stubs, would enable more readable code than a postN() method for each constraint. On the other hand, there is something to be said for straightforward mechanical generation, and if you already create 4 other member functions per constraint it's probably not a big deal.

What do you think?

Honestly, I think it's a great library, and I hope I can be disciplined enough to make a habit of using it.