From Jason Turner

[structure]

Diff to HTML by rtfpessoa

Files changed (1) hide show
  1. tmp/tmp9ugyp3ft/{from.md → to.md} +48 -17
tmp/tmp9ugyp3ft/{from.md → to.md} RENAMED
@@ -115,54 +115,85 @@ appropriate):[^5]
115
  overload resolution [[over.match]]. \[*Note 1*: Failure to meet such a
116
  condition results in the function’s silent
117
  non-viability. — *end note*] \[*Example 1*: An implementation can
118
  express such a condition via a *constraint-expression*
119
  [[temp.constr.decl]]. — *end example*]
 
120
  - *Mandates:* the conditions that, if not met, render the program
121
  ill-formed. \[*Example 2*: An implementation can express such a
122
  condition via the *constant-expression* in a
123
  *static_assert-declaration* [[dcl.pre]]. If the diagnostic is to be
124
  emitted only after the function has been selected by overload
125
  resolution, an implementation can express such a condition via a
126
  *constraint-expression* [[temp.constr.decl]] and also define the
127
  function as deleted. — *end example*]
128
- - *Preconditions:* the conditions that the function assumes to hold
129
- whenever it is called; violation of any preconditions results in
130
- undefined behavior.
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
131
  - *Effects:* the actions performed by the function.
 
132
  - *Synchronization:* the synchronization operations
133
  [[intro.multithread]] applicable to the function.
 
134
  - *Ensures:* the conditions (sometimes termed observable results)
135
- established by the function.
 
 
 
136
  - *Result:* for a *typename-specifier*, a description of the named type;
137
- for an *expression*, a description of the type of the expression; the
138
- expression is an lvalue if the type is an lvalue reference type, an
139
- xvalue if the type is an rvalue reference type, and a prvalue
140
- otherwise.
 
141
  - *Returns:* a description of the value(s) returned by the function.
 
142
  - *Throws:* any exceptions thrown by the function, and the conditions
143
  that would cause the exception.
 
144
  - *Complexity:* the time and/or space complexity of the function.
 
145
  - *Remarks:* additional semantic constraints on the function.
 
146
  - *Error conditions:* the error conditions for error codes reported by
147
  the function.
148
 
149
  Whenever the *Effects* element specifies that the semantics of some
150
  function `F` are *Equivalent to* some code sequence, then the various
151
  elements are interpreted as follows. If `F`’s semantics specifies any
152
  *Constraints* or *Mandates* elements, then those requirements are
153
  logically imposed prior to the *equivalent-to* semantics. Next, the
154
  semantics of the code sequence are determined by the *Constraints*,
155
- *Mandates*, *Preconditions*, *Effects*, *Synchronization*,
156
- *Postconditions*, *Returns*, *Throws*, *Complexity*, *Remarks*, and
157
- *Error conditions* specified for the function invocations contained in
158
- the code sequence. The value returned from `F` is specified by `F`’s
159
- *Returns* element, or if `F` has no *Returns* element, a non-`void`
160
- return from `F` is specified by the `return` statements [[stmt.return]]
161
- in the code sequence. If `F`’s semantics contains a *Throws*,
162
- *Postconditions*, or *Complexity* element, then that supersedes any
163
- occurrences of that element in the code sequence.
 
164
 
165
  For non-reserved replacement and handler functions, [[support]]
166
  specifies two behaviors for the functions in question: their required
167
  and default behavior. The *default behavior* describes a function
168
  definition provided by the implementation. The *required behavior*
 
115
  overload resolution [[over.match]]. \[*Note 1*: Failure to meet such a
116
  condition results in the function’s silent
117
  non-viability. — *end note*] \[*Example 1*: An implementation can
118
  express such a condition via a *constraint-expression*
119
  [[temp.constr.decl]]. — *end example*]
120
+
121
  - *Mandates:* the conditions that, if not met, render the program
122
  ill-formed. \[*Example 2*: An implementation can express such a
123
  condition via the *constant-expression* in a
124
  *static_assert-declaration* [[dcl.pre]]. If the diagnostic is to be
125
  emitted only after the function has been selected by overload
126
  resolution, an implementation can express such a condition via a
127
  *constraint-expression* [[temp.constr.decl]] and also define the
128
  function as deleted. — *end example*]
129
+
130
+ - the conditions that are required for a call to the function to be a
131
+ constant subexpression [[defns.const.subexpr]].
132
+
133
+ - *Preconditions:* conditions that the function assumes to hold whenever
134
+ it is called; violation of any preconditions results in undefined
135
+ behavior. \[*Example 3*: An implementation can express some such
136
+ conditions via the use of a contract assertion, such as a precondition
137
+ assertion [[dcl.contract.func]]. — *end example*]
138
+
139
+ - conditions that the function assumes to hold whenever it is called.
140
+ - When invoking the function in a hardened implementation, prior to
141
+ any other observable side effects of the function, one or more
142
+ contract assertions whose predicates are as described in the
143
+ hardened precondition are evaluated with a checking semantic
144
+ [[basic.contract.eval]]. If any of these assertions is evaluated
145
+ with a non-terminating semantic and the contract-violation handler
146
+ returns, the program has undefined behavior.
147
+ - When invoking the function in a non-hardened implementation, if any
148
+ hardened precondition is violated, the program has undefined
149
+ behavior.
150
+
151
  - *Effects:* the actions performed by the function.
152
+
153
  - *Synchronization:* the synchronization operations
154
  [[intro.multithread]] applicable to the function.
155
+
156
  - *Ensures:* the conditions (sometimes termed observable results)
157
+ established by the function. \[*Example 4*: An implementation can
158
+ express some such conditions via the use of a contract assertion, such
159
+ as a postcondition assertion [[dcl.contract.func]]. — *end example*]
160
+
161
  - *Result:* for a *typename-specifier*, a description of the named type;
162
+ for an *expression*, a description of the type and value category of
163
+ the expression; the expression is an lvalue if the type is an lvalue
164
+ reference type, an xvalue if the type is an rvalue reference type, and
165
+ a prvalue otherwise.
166
+
167
  - *Returns:* a description of the value(s) returned by the function.
168
+
169
  - *Throws:* any exceptions thrown by the function, and the conditions
170
  that would cause the exception.
171
+
172
  - *Complexity:* the time and/or space complexity of the function.
173
+
174
  - *Remarks:* additional semantic constraints on the function.
175
+
176
  - *Error conditions:* the error conditions for error codes reported by
177
  the function.
178
 
179
  Whenever the *Effects* element specifies that the semantics of some
180
  function `F` are *Equivalent to* some code sequence, then the various
181
  elements are interpreted as follows. If `F`’s semantics specifies any
182
  *Constraints* or *Mandates* elements, then those requirements are
183
  logically imposed prior to the *equivalent-to* semantics. Next, the
184
  semantics of the code sequence are determined by the *Constraints*,
185
+ *Mandates*, *Constant When*, *Preconditions*, *Hardened preconditions*,
186
+ *Effects*, *Synchronization*, *Postconditions*, *Returns*, *Throws*,
187
+ *Complexity*, *Remarks*, and *Error conditions* specified for the
188
+ function invocations contained in the code sequence. The value returned
189
+ from `F` is specified by `F`’s *Returns* element, or if `F` has no
190
+ *Returns* element, a non-`void` return from `F` is specified by the
191
+ `return` statements [[stmt.return]] in the code sequence. If `F`’s
192
+ semantics contains a *Throws*, *Postconditions*, or *Complexity*
193
+ element, then that supersedes any occurrences of that element in the
194
+ code sequence.
195
 
196
  For non-reserved replacement and handler functions, [[support]]
197
  specifies two behaviors for the functions in question: their required
198
  and default behavior. The *default behavior* describes a function
199
  definition provided by the implementation. The *required behavior*