consider reordering Postconditions: library element after Throws: #3612
Description
We currently list library descriptive elements in this order (ignoring Requires: on the basis that we're working to remove it):
- Constraints:
- Mandates:
- Preconditions:
- Effects:
- Synchronization:
- Postconditions:
- Returns:
- Throws:
- Complexity:
- Remarks:
- Error conditions:
These mostly, but not entirely, have a nice temporal flow to them. First we do overload resolution (Constraints:) to pick a function, then picking that function might give an error (Mandates:). At runtime, we need the Preconditions: to be met, and then the Effects: happen (perhaps with a specified Complexity:), along with perhaps some Synchronization:.
Then the function either Returns: or Throws: (and in so doing, reports any Error conditions:).
Only then (after a return or the absence of a throw) are the Postconditions: fully established.
To make this flow more naturally, we could:
- Reorder Postconditions: after Throws:
- Reorder Error conditions: alongside Returns: and Throws:
- Reorder Complexity: alongside Effects:
We'll need to look at some affected library wording and see if this is actually an improvement in practice, and check with LWG to see if they're happy with this reordering.