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

Subject: Re: [boost] [contract] extra type requirements for contracts
From: Dave Abrahams (dave_at_[hidden])
Date: 2011-09-20 12:08:27

on Tue Sep 20 2011, lcaminiti <lorcaminiti-AT-gmail.com> wrote:

> Dave Abrahams wrote:
>> 
>
>> on Mon Sep 19 2011, lcaminiti <lorcaminiti-AT-gmail.com> wrote:
>> 
>>> This is a general issue with contracts. In general, an arbitrary complex
>>> (const) expression can be used to assert preconditions, postconditions,
>>> or
>>> invariants. Such a complex assertion might introduce an arbitray set of
>>> extra requirements on the types used, requirements that might not be
>>> necessary to implement the function body. The extra type requirements
>>> introduced by the contracts are especially problematic when programming
>>> templates because the used types are generic and it is not know a priori
>>> to
>>> the function programmer if the generic types will or not satisfy the
>>> requirements.
>> 
>> If the contract can't be expressed within the constraints, the
>> constraints are broken, period.
>
> But this means that if you add contracts to vector<T> then you cannot
> use it unless T is EqualityComparable...  I don't think that will be
> acceptable to Boost.Contract users... will it be acceptable?

No, almost certainly not.

It would probably be reasonable to say that *if* T supports ==, the
contract checking will use that, and otherwise, the parts of the
contract that depend on == won't be checked.

Another reasonable possibility (which could be used together with the
former one) would be to provide a hook for people to implement some
equivalence test for T that isn't spelled "==".  That said, I would
argue that if they can implement the equivalence test, they should call
it "==".

Overall I have more confidence in the first idea above than in the
second one.

>> Now, however, the standard contains special hand-wavey language that
>> says, essentially, "when we use a == b to describe a postcondition we
>> don't literally mean ==.  We mean that a and b are equivalent" (whatever
>> that means).  So even if T supports == it doesn't necessarily mean the
>> standard is going to use it.  I think what it really means is that b is
>> indistinguishable from any other copy of a.
>> 
>> ...which doesn't help you at all in terms of deciding what to actually
>> /do/, I know... hopefully, though, it muddies the water a bit just in
>> case it was too clear for you up till now ;-)
>> 
>
> I will study this part of the standard.

Good luck.

Incidentally, this is part of the reason Stepanov puts so much emphasis
on the importance of "regular types:" you can't check (programmatically
or by inspection) even the most basic assertions about the correctness
of code that copies data unless you have some notion of "==" for just
about everything.  However, the C++ standard was written to accomodate
"partial" types that lack essential operations, so what are you gonna
do?

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com