[ 2021-06-20; Daniel comments ]

An informal editorial change suggestion has recently been made whose editorial implementation would promote the idea that the default assumption is that Postconditions: are only met if the function doesn't exit with an exception.

After analyzing all current existing Postconditions: elements the following seems to hold: Affected by this issue are only non-noexcept functions and mostly non-constructor functions (unless the Postconditions: element says something about the value of its arguments). Most existing Postconditions seem to be intended to apply only in non-exceptional cases. I found some where this is presumably not intended, namely those of the expressions os << x and is >> v in Tables [tab:rand.req.eng] and [tab:rand.req.dist], maybe also [time.zone.db.remote] p4.

Nonetheless, the editorial change seems to be applicable even without having this issue resolved, because it doesn't actually change the normative state by itself.

[ 2015-05-06 Lenexa: EirkWF to write paper addressing 2136 and 2137 ]

MC: Idea is to replace all such "If no exception" postconditions with "Exception safety" sections.

[ 2012-10 Portland: Move to Open ]

Consensus that we do not clearly say this, and that we probably should. A likely location to describe the guarantees of postconditions could well be a new sub-clause following [res.on.required] which serves the same purpose for requires clauses. However, we need such wording before we can make progress.

Also, see 2137 for a suggestion that we want to see a paper resolving both issues together.

The front matter in clause 17 should clarify that postconditions will not hold if a standard library function exits via an exception. Postconditions or guarantees that apply when an exception is thrown (beyond the basic guarantee) are described in an "Exception safety" section.