P3541 R1 Violation handlers vs `noexcept`

[wg21bot]

P3541R0 Violation handlers vs noexcept (Andrzej Krzemieński)

[timuraudio]

Discussed and polled in SG21 on 2025-10-09. There is nothing further for SG21 to do on this paper, so I am removing the SG21 label from this paper.

Poll results:

If P3081 Profiles add implicit contract checks to core language expressions such as pointer dereference or array indexing...

Poll 1
...we prefer the noexcept operator to return false for such expressions, since their evaluation can call the contract-violation handler which may throw (P3541R1 Option 1).

SF F N A SA
0 2 0 7 9

Result: Consensus against

Poll 2
...we want to require that contract-violation handlers must be noexcept
(P3541R1 Option 2).

SF F N A SA
0 1 2 9 7

Result: Consensus against

Poll 3
...we want to explore a solution where whether the contract-violation handler can throw out of the evaluation of such expressions, and what the noexcept operator returns for them, is configurable (P3541R1 Option 3).

SF F N A SA
0 2 3 8 6

Result: Consensus against

Poll 4
...we prefer the noexcept operator to return true for such expressions, despite the fact that their evaluation can call the contract-violation handler which may throw (P3541R1 Option 4).

SF F N A SA
5 10 1 2 1

Result: Consensus

Poll 5
...we prefer to restrict the evaluation of such implicit contract checks to evaluation semantics that cannot result in the contract-violation handler being called (P3541R1 Option 5).

SF F N A SA
2 3 4 6 3

Result: No consensus

Poll 6
...we prefer to unconditionally disallow the contract-violation handler from throwing out of the evaluation of such expressions; an attempt to do so would call std::terminate.

SF F N A SA
1 1 5 7 3

Result: Consensus against

Poll 7
...we prefer to optionally disallow the contract-violation handler from throwing out of the evaluation of such expressions; an attempt to do so would call std::terminate.

SF F N A SA
3 9 4 0 0

Result: Consensus

[wg21bot]

P3541R1 Violation handlers vs noexcept (Andrzej Krzemieński)

[rogerorr]

SG23 discussed P3541R1 in Hagenberg on 2025-02-11 - notes here and took one poll:

SG23 recommends to EWG that the issues described in P3541 are addressed before P3081 and P3100 are discussed further.

*Favor	Neutral	Against
7	0	0

Unanimously in favor

[jfbastien]

Profiles were discussed in EWG in Hagenberg on Wednesday:

• P3589 C++ Profiles: The Framework
• P3611 Dealing with pointer errors: Separating static and dynamic checking
• P3081: Core safety profiles for C++26
• P3586R0 — The Plethora of Problems With Profiles

See #2058