P2900 R10 Contracts for C++

[wg21bot]

P2900R0 Contracts for C++ (Joshua Berne)

[wg21bot]

P2900R1 Contracts Working Paper (Joshua Berne)

[wg21bot]

P2900R2 Contracts for C++ (Joshua Berne, Timur Doumler, Andrzej Krzemieński)

[wg21bot]

P2900R3 Contracts for C++ (Joshua Berne, Timur Doumler, Andrzej Krzemieński)

[wg21bot]

P2900R4 Contracts for C++ (Joshua Berne, Timur Doumler, Andrzej Krzemieński)

[wg21bot]

P2900R5 Contracts for C++ (Joshua Berne, Timur Doumler, Andrzej Krzemieński)

[erichkeane]

EWG discussed this all-day Wednesday in Tokyo. The following polls were taken:

The following contracts polls are not meant to be binding, but rather to offer a first set of feedback to the authors.

Poll: P2900r6: contracts should have enforce semantics only, and should not have ignore nor observe.

SF	F	N	A	SA
6	1	3	15	24

Poll: P2900r6: contracts in constant expressions should have enforce semantics only, and should not have ignore nor observe.

SF	F	N	A	SA
7	10	16	7	8

Poll: P2900r6: contracts should specify contracts on virtual functions in its Minimal Viable Proposal.

SF	F	N	A	SA
8	15	10	13	5

Poll: P2900r6: contracts should specify contracts on function pointers in its Minimal Viable Proposal.

SF	F	N	A	SA
6	6	14	15	8

Poll: P2900r6: contracts should specify contracts on coroutines in its Minimal Viable Proposal.

SF	F	N	A	SA
6	3	11	19	7

Poll: P2900r6: contracts should not allow throwing exceptions out of a violation handler.

SF	F	N	A	SA
8	16	12	7	14

Poll: P2900r6: contracts should not be able to evaluate preconditions/postconditions/assertions more than once per invocation.

SF	F	N	A	SA
13	8	15	10	8

Result:

Poll: P2900r6: contracts should expose less undefined behavior than regular C++ code does.

SF	F	N	A	SA
17	12	12	12	5

Result:

Poll: P2900r6: contracts - there should be some usage experience of contracts in an implementation of the STL (without necessarily having a paper to adopt these changes) before contracts can move to plenary.

SF	F	N	A	SA
16	30	12	3	0

Poll: P2900r6: contracts - there should be some usage specification of contracts in the STL before contracts can move to plenary.

SF	F	N	A	SA
6	10	11	14	15

[inbal2l]

2024-03-18 Library Evolution Tokyo

P2900R6: Contracts for C++

2024-03-18 Library Evolution Telecon Minutes

Champion: Timur Doumler
Chair: Inbal Levi / Fabio Fracassi
Minute Taker: Robert Leahy

Summary

Please add motivation for at least one (in the paper):

Add “contracts_ prefix” to “detection_mode”and pull contract_violation and “void invoke_default_contract_violation_handler(const contract_violation&);” out of std::contracts namespace into std:: namespace

Leave the namespace std::contracts but remove the contract from the functions and types in that namespace:

namespace std::contracts {
class violation;
void invoke_default_violation_handler(const violation&);
}

ACTION: Come back with implementation experience

ACTION: Renaming requests - attendees asking to modify:

“Invoke_default_contract_violation_handler” (by Pablo - “default_contract_violation_handler”?)

“Contract_violation (by David)

Attendees will suggest names in the reflector, and authors will rename/ leave according to the feedback whatever gets most support.

Next Steps

P2900 authors will work with Library Implementors to verify the library interface doesn't have extensive overhead. Once finalized, we will see the newly proposed library interface.
The result of the discussion is the paper: "P3191R0: Feedback on the scalability of contract violation handlers in P2900".
We see a lot of value in implementation and deployment experience.

[wg21bot]

P2900R6 Contracts for C++ (Joshua Berne, Timur Doumler, Andrzej Krzemieński)

[wg21bot]

P2900R7 Contracts for C++ (Joshua Berne, Timur Doumler, Andrzej Krzemieński)

[timuraudio]

Amendments considered by SG21 in Tokyo (after EWG and LEWG sessions):

2024-03-21, Tokyo

For the enums in P2900R6, make the underlying type unspecified; mention in the front matter of P2900 that the design intent is that the underlying type needs to be large enough to hold all possible values, including any vendor-provided ones.
SF F N A SA
2 14 5 2 0
Result: Consensus

We want to rename the terms "contract violation" and "contract violation handler" and their associated library names in P2900 to some other terms that reflect that the situations described by them do not necessarily represent a violation of the plain-language contract of a function.
SF F N A SA
0 7 9 9 3
Result: Not consensus

Use two different handlers for a contract predicate that evaluates to false and a contract predicate whose evaluation exits via an exception, respectively.
SF F N A SA
0 3 3 8 11
Result: Consensus against

The library facilities proposed in P2900R6 should be in namespace std rather than in a nested namespace std::contracts.
SF F N A SA
1 6 4 9 2
Result: Not consensus

In P2900R6, rename enum contract_kind to assertion_kind.
SF F N A SA
1 14 8 1 1
Result: Consensus

In P2900R6, rename enum contract_semantic to evaluation_semantic.
SF F N A SA
2 16 7 0 0
Result: Consensus

Add a contract semantic to P2900R6 where the predicate is evaluated, on contract violation no contract-violation handler is invoked, and the program is stopped in an implementation-defined way.
SF F N A SA
23 10 0 0 0
Result: Consensus

In P2900R6, when the contract-violation handler returns normally and the semantic is enforce, rather than calling abort(), the program should be stopped in an implementation-defined way.
SF F N A SA
17 13 1 1 0
Result: Consensus

In P2900R6, add a recommended practice, that the enforce semantic should call std::abort().
SF F N A SA
2 9 15 4 0
Result: No consensus

[timuraudio]

Further post-Tokyo amendments considered by SG21:

2024-04-04, Telecon

Poll 1:
For the Contracts MVP, rename invoke_default_contract_violation_handler to
default_contract_violation_handler.

SF F N A SA
0 2 3 7 4
Result: Consensus Against

Poll 2:
For the Contracts MVP, rename invoke_default_contract_violation_handler to
default_handle_contract_violation.

SF F N A SA
0 0 4 9 4
Result: Consensus Against

Poll 3:
For the Contracts MVP, rename invoke_default_contract_violation_handler to
invoke_default_violation_handler.

SF F N A SA
2 8 4 1 3
Result: N/A (Exploratory poll)

Poll 4:
For the Contracts MVP, do not change the name
invoke_default_contract_violation_handler.

SF F N A SA
6 4 5 2 2
Result: N/A (Exploratory poll)

Poll 5:
For the Contracts MVP, rename invoke_default_contract_violation_handler to
invoke_default_violation_handler (poll re-run considering the results of the
exploratory polls 3 and 4).

SF F N A SA
3 4 2 6 3
Result: Not Consensus

Poll 6:
For the Contracts MVP, rename contract_violation to violation.

SF F N A SA
1 1 4 4 4
Result: Consensus Against

[jfbastien]

Seen in St Louis Monday/Tuesday:

Not polled today:
• having only one evaluation semantic
• contract behavior in constant expression context
• contract support for virtual functions
• contract support for function pointers
• contract support for coroutines
• contracts exposing less undefined behavior than regular C++ does
• STL usage experience
• STL usage specification

Poll: P2900r7: The method for evaluation semantics’ termination should not be implementation defined for enforce/quick_enforce. A solution to remove implementation-defined might be to specify the behavior of existing semantics, and could also include specifying more evaluation semantics.

| SF | F | N | A | SA |
| 2 | 4 | 7 | 19 | 4 |

Result: consensus against.

Poll: P2900r7: contracts should not be able to evaluate preconditions/postconditions/assertions more than once per invocation.

| SF | F | N | A | SA |
| 3 | 2 | 2 | 17 | 11 |

Consensus against.

Poll: P2900r7: contracts should not be able to evaluate preconditions/postconditions/assertions more than twice per invocation.

| SF | F | N | A | SA |
| 1 | 8 | 4 | 17 | 5 |

Consensus against.

Poll: P2900r7: Contracts should not allow throwing exceptions out of a violation handler.

| SF | F | N | A | SA |
| 0 | 5 | 4 | 9 | 16 |

Consensus against.

Poll: P2900r7: local variables, *this, and the return value in contract predicates should not be implicitly const.

| SF | F | N | A | SA |
| 9 | 5 | 4 | 10 | 5 |

No consensus for change, but strong divide.

Poll: P2900r7: (We want to leave the door open for contracts, post-MVP, to support assume semantics.) && (This desire has implications on the MVP design).
Decision helper:
| | MVP blocks| MVP doesn’t block|
|Want | F | A |
|Don’t | A | A |

| SF | F | N | A | SA |
| 0 | 0 | 3 | 18 | 11 |

Consensus against.

[wg21bot]

P2900R8 Contracts for C++ (Joshua Berne, Timur Doumler, Andrzej Krzemieński)

[wg21bot]

P2900R9 Contracts for C++ (Joshua Berne, Timur Doumler, Andrzej Krzemieński)

[wg21bot]

P2900R10 Contracts for C++ (Joshua Berne, Timur Doumler, Andrzej Krzemieński)