From Jason Turner

[over.best.ics.general]

C++20 → C++23 6.6 KB 162 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/tmpzwwudnkv/{from.md → to.md} +159 -0
tmp/tmpzwwudnkv/{from.md → to.md} RENAMED
@@ -0,0 +1,159 @@
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1
+ ##### General <a id="over.best.ics.general">[[over.best.ics.general]]</a>
2
+
3
+ An *implicit conversion sequence* is a sequence of conversions used to
4
+ convert an argument in a function call to the type of the corresponding
5
+ parameter of the function being called. The sequence of conversions is
6
+ an implicit conversion as defined in [[conv]], which means it is
7
+ governed by the rules for initialization of an object or reference by a
8
+ single expression [[dcl.init]], [[dcl.init.ref]].
9
+
10
+ Implicit conversion sequences are concerned only with the type,
11
+ cv-qualification, and value category of the argument and how these are
12
+ converted to match the corresponding properties of the parameter.
13
+
14
+ [*Note 1*: Other properties, such as the lifetime, storage class,
15
+ alignment, accessibility of the argument, whether the argument is a
16
+ bit-field, and whether a function is deleted [[dcl.fct.def.delete]], are
17
+ ignored. So, although an implicit conversion sequence can be defined for
18
+ a given argument-parameter pair, the conversion from the argument to the
19
+ parameter might still be ill-formed in the final
20
+ analysis. — *end note*]
21
+
22
+ A well-formed implicit conversion sequence is one of the following
23
+ forms:
24
+
25
+ - a standard conversion sequence [[over.ics.scs]],
26
+ - a user-defined conversion sequence [[over.ics.user]], or
27
+ - an ellipsis conversion sequence [[over.ics.ellipsis]].
28
+
29
+ However, if the target is
30
+
31
+ - the first parameter of a constructor or
32
+ - the object parameter of a user-defined conversion function
33
+
34
+ and the constructor or user-defined conversion function is a candidate
35
+ by
36
+
37
+ - [[over.match.ctor]], when the argument is the temporary in the second
38
+ step of a class copy-initialization,
39
+ - [[over.match.copy]], [[over.match.conv]], or [[over.match.ref]] (in
40
+ all cases), or
41
+ - the second phase of [[over.match.list]] when the initializer list has
42
+ exactly one element that is itself an initializer list, and the target
43
+ is the first parameter of a constructor of class `X`, and the
44
+ conversion is to `X` or reference to cv `X`,
45
+
46
+ user-defined conversion sequences are not considered.
47
+
48
+ [*Note 2*: These rules prevent more than one user-defined conversion
49
+ from being applied during overload resolution, thereby avoiding infinite
50
+ recursion. — *end note*]
51
+
52
+ [*Example 1*:
53
+
54
+ ``` cpp
55
+ struct Y { Y(int); };
56
+ struct A { operator int(); };
57
+ Y y1 = A(); // error: A::operator int() is not a candidate
58
+
59
+ struct X { X(); };
60
+ struct B { operator X(); };
61
+ B b;
62
+ X x{{b}}; // error: B::operator X() is not a candidate
63
+ ```
64
+
65
+ — *end example*]
66
+
67
+ For the case where the parameter type is a reference, see 
68
+ [[over.ics.ref]].
69
+
70
+ When the parameter type is not a reference, the implicit conversion
71
+ sequence models a copy-initialization of the parameter from the argument
72
+ expression. The implicit conversion sequence is the one required to
73
+ convert the argument expression to a prvalue of the type of the
74
+ parameter.
75
+
76
+ [*Note 3*: When the parameter has a class type, this is a conceptual
77
+ conversion defined for the purposes of [[over]]; the actual
78
+ initialization is defined in terms of constructors and is not a
79
+ conversion. — *end note*]
80
+
81
+ Any difference in top-level cv-qualification is subsumed by the
82
+ initialization itself and does not constitute a conversion.
83
+
84
+ [*Example 2*: A parameter of type `A` can be initialized from an
85
+ argument of type `const A`. The implicit conversion sequence for that
86
+ case is the identity sequence; it contains no “conversion” from
87
+ `const A` to `A`. — *end example*]
88
+
89
+ When the parameter has a class type and the argument expression has the
90
+ same type, the implicit conversion sequence is an identity conversion.
91
+ When the parameter has a class type and the argument expression has a
92
+ derived class type, the implicit conversion sequence is a
93
+ derived-to-base conversion from the derived class to the base class. A
94
+ derived-to-base conversion has Conversion rank [[over.ics.scs]].
95
+
96
+ [*Note 4*: There is no such standard conversion; this derived-to-base
97
+ conversion exists only in the description of implicit conversion
98
+ sequences. — *end note*]
99
+
100
+ When the parameter is the implicit object parameter of a static member
101
+ function, the implicit conversion sequence is a standard conversion
102
+ sequence that is neither better nor worse than any other standard
103
+ conversion sequence.
104
+
105
+ In all contexts, when converting to the implicit object parameter or
106
+ when converting to the left operand of an assignment operation only
107
+ standard conversion sequences are allowed.
108
+
109
+ [*Note 5*: When converting to the explicit object parameter, if any,
110
+ user-defined conversion sequences are allowed. — *end note*]
111
+
112
+ If no conversions are required to match an argument to a parameter type,
113
+ the implicit conversion sequence is the standard conversion sequence
114
+ consisting of the identity conversion [[over.ics.scs]].
115
+
116
+ If no sequence of conversions can be found to convert an argument to a
117
+ parameter type, an implicit conversion sequence cannot be formed.
118
+
119
+ If there are multiple well-formed implicit conversion sequences
120
+ converting the argument to the parameter type, the implicit conversion
121
+ sequence associated with the parameter is defined to be the unique
122
+ conversion sequence designated the *ambiguous conversion sequence*. For
123
+ the purpose of ranking implicit conversion sequences as described in 
124
+ [[over.ics.rank]], the ambiguous conversion sequence is treated as a
125
+ user-defined conversion sequence that is indistinguishable from any
126
+ other user-defined conversion sequence.
127
+
128
+ [*Note 6*:
129
+
130
+ This rule prevents a function from becoming non-viable because of an
131
+ ambiguous conversion sequence for one of its parameters.
132
+
133
+ [*Example 3*:
134
+
135
+ ``` cpp
136
+ class B;
137
+ class A { A (B&);};
138
+ class B { operator A (); };
139
+ class C { C (B&); };
140
+ void f(A) { }
141
+ void f(C) { }
142
+ B b;
143
+ f(b); // error: ambiguous because there is a conversion b → C (via constructor)
144
+ // and an (ambiguous) conversion b → A (via constructor or conversion function)
145
+ void f(B) { }
146
+ f(b); // OK, unambiguous
147
+ ```
148
+
149
+ — *end example*]
150
+
151
+ — *end note*]
152
+
153
+ If a function that uses the ambiguous conversion sequence is selected as
154
+ the best viable function, the call will be ill-formed because the
155
+ conversion of one of the arguments in the call is ambiguous.
156
+
157
+ The three forms of implicit conversion sequences mentioned above are
158
+ defined in the following subclauses.
159
+