Re: [boost] [contract] extra type requirements for contracts

Subject: Re: [boost] [contract] extra type requirements for contracts
From: Brent Spillner (spillner_at_[hidden])
Date: 2011-09-23 18:00:53

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.