2016-06-24 22:10 GMT+02:00 Lorenzo Caminiti
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