Re: [boost] [contract] Without the macros

Subject: Re: [boost] [contract] Without the macros
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2016-06-24 17:25:22

2016-06-24 22:10 GMT+02:00 Lorenzo Caminiti <lorcaminiti_at_[hidden]>:

>
> > Here is the last version of the proposal:
> > http://open-std.org/JTC1/SC22/WG21/docs/papers/2016/p0380r0.pdf
>
> I always thought it'd be great to have contracts added to the core
> language... if not for anything else, for a more concise syntax and
> compiler optimizations. Unfortunately I found this P0380 proposal
> largely inadequate. In my opinion/experience, the following are major
> issues with P0380:
>
> 1. Complete lack of class invariants. In my experience, class
> invariants are essentially as important as preconditions when
> programming contracts for objects.
> 2. No old values for postconditions. In my experience, most
> postcondition assertions cannot be programmed without old values.
> 3. If I understand it correctly, the rule that "the contracts of every
> declaration of a function must be (ODR) identical" (P0380 section 4)
> essentially prevent subcontracting.
>
> Class invariants, postcondition old values, and subcontracting are key
> aspects of contract programming. A framework that does not support
> those is not really a contract programming framework, it's essentially
> just a bit more than `assert()`. Maybe that was the intent of P0380 to
> be just a bit more than `assert()`... but is that useful or it's best
> to just use `assert()` at that point (maybe within #ifdef to emulate
> the default/axiom/audit levels)?
>

I think you need to look at P0380 as a step towards full contract support.
The authors are well aware that more support is needed in the future; they
simply decided to add some uncontroversial parts as soon s possible. I
think it is a wise choice to add features cautiously, given that there
exist no implementation experience in C++. I think contracts in C++ are
somewhat different than these in Eiffel. The focus is more on being able to
perform static analysis. And it is not clear what exactly is needed to help
static analysers. This has been described in n4160
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4160.html> (
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4160.html).

This limited proposal is already useful on its own, and gives some values
to programmers, while buying some time for the Committee to decide how they
want to handle invariants in C++. For instance, should class invariant also
be required to hold before and and after free functions that are declared
friends by our class? Again, it is described in n4160
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4160.html>.

> N1962 (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1962.html)
> was a solid proposal for adding Contract Programming to C++. Why not
> accepting that proposal (maybe with the attributes syntax introduced
> by P0380)?
>

This proposal is more feature complete, but it does not go into details of
how contracts interact with other c++-specific features like friends,
noexcept, constexpr. It does not give evidence that it is sufficient to
support static analysers.

Regards,
&rzej