This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of Open status.
Section: 16.3.2 [structure] Status: Open Submitter: Jens Maurer Opened: 2012-03-08 Last modified: 2024-10-05
Priority: 3
View all issues with Open status.
Discussion:
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.
[ 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 99 [res.on.required] which serves the same purpose for requires clauses. However, we need such wording before we can make progress.
Also, see 2137(i) for a suggestion that we want to see a paper resolving both issues together.
[2015-05-06 Lenexa: EricWF to write paper addressing 2136 and 2137]
MC: Idea is to replace all such "If no exception" postconditions with "Exception safety" sections.
[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
30.11.2.4 [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.
[2024-10-03; Jonathan adds wording]
Proposed resolution:
This wording is relative to N4988.
Change 16.3.2.4 [structure.specifications] as indicated:
(3.6) — Postconditions: the conditions (sometimes termed observable results) established by the function when a call to it returns normally.