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.