From Jason Turner

[structure.specifications]

C++20 → C++23 3.6 KB 26 lines
Current Draft | LaTeX Source
Archived: C++20 | C++23
Markdown: C++20 | C++23
Explore in Adventure Game

Diff to HTML by rtfpessoa

Files changed (1) hide show
  1. tmp/tmp6xwstyn9/{from.md → to.md} +14 -8
tmp/tmp6xwstyn9/{from.md → to.md} RENAMED
@@ -7,43 +7,49 @@ The detailed specifications each contain the following elements:
7
  - restrictions on template arguments, if any
8
  - description of class invariants
9
  - description of function semantics
10
 
11
  Descriptions of class member functions follow the order (as
12
- appropriate):[^3]
13
 
14
  - constructor(s) and destructor
15
  - copying, moving & assignment functions
16
- - comparison functions
17
  - modifier functions
18
  - observer functions
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.
@@ -73,11 +79,11 @@ 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
 
 
7
  - restrictions on template arguments, if any
8
  - description of class invariants
9
  - description of function semantics
10
 
11
  Descriptions of class member functions follow the order (as
12
+ appropriate):[^4]
13
 
14
  - constructor(s) and destructor
15
  - copying, moving & assignment functions
16
+ - comparison operator functions
17
  - modifier functions
18
  - observer functions
19
  - operators and other non-member functions
20
 
21
  Descriptions of function semantics contain the following elements (as
22
+ appropriate):[^5]
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 can
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 can 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 can 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; violation of any preconditions results in
40
+ undefined behavior.
41
  - *Effects:* the actions performed by the function.
42
  - *Synchronization:* the synchronization operations
43
  [[intro.multithread]] applicable to the function.
44
  - *Ensures:* the conditions (sometimes termed observable results)
45
  established by the function.
46
+ - *Result:* for a *typename-specifier*, a description of the named type;
47
+ for an *expression*, a description of the type of the expression; the
48
+ expression is an lvalue if the type is an lvalue reference type, an
49
+ xvalue if the type is an rvalue reference type, and a prvalue
50
+ otherwise.
51
  - *Returns:* a description of the value(s) returned by the function.
52
  - *Throws:* any exceptions thrown by the function, and the conditions
53
  that would cause the exception.
54
  - *Complexity:* the time and/or space complexity of the function.
55
  - *Remarks:* additional semantic constraints on the function.
 
79
  describes the semantics of a function definition provided by either the
80
  implementation or a C++ program. Where no distinction is explicitly made
81
  in the description, the behavior described is the required behavior.
82
 
83
  If the formulation of a complexity requirement calls for a negative
84
+ number of operations, the actual requirement is zero operations.[^6]
85
 
86
  Complexity requirements specified in the library clauses are upper
87
  bounds, and implementations that provide better complexity guarantees
88
  meet the requirements.
89