From Jason Turner

[structure.specifications]

Diff to HTML by rtfpessoa

Files changed (1) hide show
  1. tmp/tmp23yv0oi1/{from.md → to.md} +48 -32
tmp/tmp23yv0oi1/{from.md → to.md} RENAMED
@@ -19,53 +19,69 @@ appropriate):[^3]
19
  - operators and other non-member functions
20
 
21
  Descriptions of function semantics contain the following elements (as
22
  appropriate):[^4]
23
 
24
- - *Requires:* the preconditions for calling the function
25
- - *Effects:* the actions performed by the function
26
- - *Synchronization:* the synchronization operations (
27
- [[intro.multithread]]) applicable to the function
28
- - *Postconditions:* the observable results established by the function
29
- - *Returns:* a description of the value(s) returned by the function
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
30
  - *Throws:* any exceptions thrown by the function, and the conditions
31
- that would cause the exception
32
- - *Complexity:* the time and/or space complexity of the function
33
- - *Remarks:* additional semantic constraints on the function
34
  - *Error conditions:* the error conditions for error codes reported by
35
- the function
36
 
37
- Whenever the *Effects:* element specifies that the semantics of some
38
  function `F` are *Equivalent to* some code sequence, then the various
39
- elements are interpreted as follows. If `F`’s semantics specifies a
40
- *Requires:* element, then that requirement is logically imposed prior to
41
- the *equivalent-to* semantics. Next, the semantics of the code sequence
42
- are determined by the *Requires:* , *Effects:* , *Synchronization:* ,
43
- *Postconditions:* , *Returns:* , *Throws:* , *Complexity:* , *Remarks:*
44
- , and *Error conditions:* specified for the function invocations
45
- contained in the code sequence. The value returned from `F` is specified
46
- by `F`’s *Returns:* element, or if `F` has no *Returns:* element, a
47
- non-`void` return from `F` is specified by the `return` statements in
48
- the code sequence. If `F`’s semantics contains a *Throws:* ,
49
- *Postconditions:* , or *Complexity:* element, then that supersedes any
 
50
  occurrences of that element in the code sequence.
51
 
52
- For non-reserved replacement and handler functions, Clause 
53
- [[language.support]] specifies two behaviors for the functions in
54
- question: their required and default behavior. The *default behavior*
55
- describes a function definition provided by the implementation. The
56
- *required behavior* describes the semantics of a function definition
57
- provided by either the implementation or a C++program. Where no
58
- distinction is explicitly made in the description, the behavior
59
- described is the required behavior.
60
 
61
  If the formulation of a complexity requirement calls for a negative
62
  number of operations, the actual requirement is zero operations.[^5]
63
 
64
  Complexity requirements specified in the library clauses are upper
65
  bounds, and implementations that provide better complexity guarantees
66
- satisfy the requirements.
67
 
68
  Error conditions specify conditions where a function may fail. The
69
  conditions are listed, together with a suitable explanation, as the
70
- `enum class errc` constants ([[syserr]]).
71
 
 
19
  - operators and other non-member functions
20
 
21
  Descriptions of function semantics contain the following elements (as
22
  appropriate):[^4]
23
 
24
+ - *Constraints:* the conditions for the function’s participation in
25
+ overload resolution [[over.match]]. \[*Note 1*: Failure to meet such a
26
+ condition results in the function’s silent
27
+ non-viability. — *end note*] \[*Example 1*: An implementation might
28
+ express such a condition via a *constraint-expression*
29
+ [[temp.constr.decl]]. *end example*]
30
+ - *Mandates:* the conditions that, if not met, render the program
31
+ ill-formed. \[*Example 2*: An implementation might express such a
32
+ condition via the *constant-expression* in a
33
+ *static_assert-declaration* [[dcl.pre]]. If the diagnostic is to be
34
+ emitted only after the function has been selected by overload
35
+ resolution, an implementation might express such a condition via a
36
+ *constraint-expression* [[temp.constr.decl]] and also define the
37
+ function as deleted. — *end example*]
38
+ - *Preconditions:* the conditions that the function assumes to hold
39
+ whenever it is called.
40
+ - *Effects:* the actions performed by the function.
41
+ - *Synchronization:* the synchronization operations
42
+ [[intro.multithread]] applicable to the function.
43
+ - *Ensures:* the conditions (sometimes termed observable results)
44
+ established by the function.
45
+ - *Returns:* a description of the value(s) returned by the function.
46
  - *Throws:* any exceptions thrown by the function, and the conditions
47
+ that would cause the exception.
48
+ - *Complexity:* the time and/or space complexity of the function.
49
+ - *Remarks:* additional semantic constraints on the function.
50
  - *Error conditions:* the error conditions for error codes reported by
51
+ the function.
52
 
53
+ Whenever the *Effects* element specifies that the semantics of some
54
  function `F` are *Equivalent to* some code sequence, then the various
55
+ elements are interpreted as follows. If `F`’s semantics specifies any
56
+ *Constraints* or *Mandates* elements, then those requirements are
57
+ logically imposed prior to the *equivalent-to* semantics. Next, the
58
+ semantics of the code sequence are determined by the *Constraints*,
59
+ *Mandates*, *Preconditions*, *Effects*, *Synchronization*,
60
+ *Postconditions*, *Returns*, *Throws*, *Complexity*, *Remarks*, and
61
+ *Error conditions* specified for the function invocations contained in
62
+ the code sequence. The value returned from `F` is specified by `F`’s
63
+ *Returns* element, or if `F` has no *Returns* element, a non-`void`
64
+ return from `F` is specified by the `return` statements [[stmt.return]]
65
+ in the code sequence. If `F`’s semantics contains a *Throws*,
66
+ *Postconditions*, or *Complexity* element, then that supersedes any
67
  occurrences of that element in the code sequence.
68
 
69
+ For non-reserved replacement and handler functions, [[support]]
70
+ specifies two behaviors for the functions in question: their required
71
+ and default behavior. The *default behavior* describes a function
72
+ definition provided by the implementation. The *required behavior*
73
+ describes the semantics of a function definition provided by either the
74
+ implementation or a C++ program. Where no distinction is explicitly made
75
+ in the description, the behavior described is the required behavior.
 
76
 
77
  If the formulation of a complexity requirement calls for a negative
78
  number of operations, the actual requirement is zero operations.[^5]
79
 
80
  Complexity requirements specified in the library clauses are upper
81
  bounds, and implementations that provide better complexity guarantees
82
+ meet the requirements.
83
 
84
  Error conditions specify conditions where a function may fail. The
85
  conditions are listed, together with a suitable explanation, as the
86
+ `enum class errc` constants [[syserr]].
87