Re: [boost] [contract] syntax redesign

Subject: Re: [boost] [contract] syntax redesign
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2011-09-05 04:04:19

> This use case is different then the above (more compelling). The
> issues here is that when programming contracts you quickly start using
> extra checks (and especially ==) which add additional requirements on
> generic types. For example, in this case T does not have to be
> EqualityComparable to program the body but you still want to program
> and check the postcondition when T happens to be EqualityComparable. I
> have been thinking to solve this issue by providing:

> namespace contract {

> temlate< typename T>
> bool equal(T const& left, T const& right) ...
> }

> equal will return true if T is not EqualityComparable and left ==
> right if T is EqualityComparable. That way you can program the
> contracts using contract::equal(x, y) without introducing additional
> requirements on T at all but still checking the contract conditions
> for EqualityComparable types. I will also expand equal to handle
> containers (compare all elements of a vector, etc) and I will provide
> similar functions for other operations. All of these contract helper
> functions will be in a separate header <contract/utility.hpp>. I have
> not started to implement this yet.

To me, this problem with equality indicates that Boost.Concept already
proves useful, as it explores practical aspects of implementing DbC in C++
and its interactions with other C++ features.

> BTW, I am also wondering if it would be useful to implement a fully
> contracted version of the STL probably in contract::std:

> #include <contract/std/vector.hpp>
> #include <contract/std/algorithm.hpp>

> contract::std::vector<int> v;
> contract::std::for_each(v.begin(), v.end(), ...);

> I think Boost.Contract can essentially implement most/all of the
> interface contracts (preconditions, postconditions, invariants, and
> concepts) documented by the SGI:
>  http://www.sgi.com/tech/stl/
>

> Would such a contract::std be any useful?

This is a fair question. And probably best answered by the authors of
contract programming proposal for C++. What ISO C++ Committee did with
nearly every new language feature (concepts, auto, noexcept, constexpr,
initializer_list) was to also use it in library in order to (i) prove that
the future is usable, (ii) give a solid example of how the feature should be
used. So, along this reasoning, there are good reasons to do it. I can see,
however, also valid reasons against it:
Boost only recently approved STL containers library rewrite:
Boost.Containers (
http://svn.boost.org/svn/boost/sandbox/move/libs/container/doc/html/index.html).
It already has Boost.PointerContainer (although it serves a different
purpose it may be distracting that they are defined and described
separately). so now, each time I use a container I will have to decide if I
am using std::vector or boost::container::vector. Now if I need to consider
a third option boost::contract::stl::vector it really gets hard. And would
they all interoperable with one another? Perhaps if the contracts were
implemented in Boost.Container, but then...
I expect that Boost.Contract syntax may discourage some Boost users, that
just want to use (and perhaps debug) Container library. Overwhelming them
with the new syntax might discourage them from using Boost.Container. If you
implement your containers separately, it is likely that they will just not
be used.
Difficult to say...

Regards,
&rzej