We currently list library descriptive elements in this order (ignoring Requires: on the basis that we're working to remove it):
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:
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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4