From Jason Turner

[over.match.best]

C++23 → Trunk 21.6 KB 278 lines
Current Draft | LaTeX Source
Archived: C++23
Markdown: C++23 | Trunk
Explore in Adventure Game

Diff to HTML by rtfpessoa

Files changed (1) hide show
  1. tmp/tmp44o4276u/{from.md → to.md} +150 -108
tmp/tmp44o4276u/{from.md → to.md} RENAMED
@@ -16,14 +16,14 @@ then
16
 
17
  - for some argument j, ICSʲ(`F₁`) is a better conversion sequence than
18
  ICSʲ(`F₂`), or, if not that,
19
  - the context is an initialization by user-defined conversion (see 
20
  [[dcl.init]], [[over.match.conv]], and  [[over.match.ref]]) and the
21
- standard conversion sequence from the return type of `F₁` to the
22
  destination type (i.e., the type of the entity being initialized) is a
23
  better conversion sequence than the standard conversion sequence from
24
- the return type of `F₂` to the destination type
25
  \[*Example 1*:
26
  ``` cpp
27
  struct A {
28
  A();
29
  operator int();
@@ -37,13 +37,13 @@ then
37
 
38
  — *end example*]
39
  or, if not that,
40
  - the context is an initialization by conversion function for direct
41
  reference binding [[over.match.ref]] of a reference to function type,
42
- the return type of `F1` is the same kind of reference (lvalue or
43
  rvalue) as the reference being initialized, and the return type of
44
- `F2` is not
45
  \[*Example 2*:
46
  ``` cpp
47
  template <class T> struct A {
48
  operator T&(); // #1
49
  operator T&&(); // #2
@@ -54,24 +54,38 @@ then
54
  Fn&& rf = a; // calls #2
55
  ```
56
 
57
  — *end example*]
58
  or, if not that,
59
- - `F1` is not a function template specialization and `F2` is a function
60
  template specialization, or, if not that,
61
- - `F1` and `F2` are function template specializations, and the function
62
- template for `F1` is more specialized than the template for `F2`
63
  according to the partial ordering rules described in 
64
  [[temp.func.order]], or, if not that,
65
- - `F1` and `F2` are non-template functions with the same
66
- parameter-type-lists, and `F1` is more constrained than `F2` according
67
- to the partial ordering of constraints described in
68
- [[temp.constr.order]], or if not that,
69
- - `F1` is a constructor for a class `D`, `F2` is a constructor for a
 
 
 
 
 
 
 
 
 
 
 
 
 
 
70
  base class `B` of `D`, and for all arguments the corresponding
71
- parameters of `F1` and `F2` have the same type
72
- \[*Example 3*:
73
  ``` cpp
74
  struct A {
75
  A(int = 0);
76
  };
77
 
@@ -85,48 +99,48 @@ then
85
  }
86
  ```
87
 
88
  — *end example*]
89
  or, if not that,
90
- - `F2` is a rewritten candidate [[over.match.oper]] and `F1` is not
91
- \[*Example 4*:
92
  ``` cpp
93
  struct S {
94
  friend auto operator<=>(const S&, const S&) = default; // #1
95
  friend bool operator<(const S&, const S&); // #2
96
  };
97
  bool b = S() < S(); // calls #2
98
  ```
99
 
100
  — *end example*]
101
  or, if not that,
102
- - `F1` and `F2` are rewritten candidates, and `F2` is a synthesized
103
- candidate with reversed order of parameters and `F1` is not
104
- \[*Example 5*:
105
  ``` cpp
106
  struct S {
107
  friend std::weak_ordering operator<=>(const S&, int); // #1
108
  friend std::weak_ordering operator<=>(int, const S&); // #2
109
  };
110
  bool b = 1 < S(); // calls #2
111
  ```
112
 
113
  — *end example*]
114
- or, if not that
115
- - `F1` and `F2` are generated from class template argument deduction
116
- [[over.match.class.deduct]] for a class `D`, and `F2` is generated
117
- from inheriting constructors from a base class of `D` while `F1` is
118
  not, and for each explicit function argument, the corresponding
119
- parameters of `F1` and `F2` are either both ellipses or have the same
120
  type, or, if not that,
121
- - `F1` is generated from a *deduction-guide* [[over.match.class.deduct]]
122
- and `F2` is not, or, if not that,
123
- - `F1` is the copy deduction candidate [[over.match.class.deduct]] and
124
- `F2` is not, or, if not that,
125
- - `F1` is generated from a non-template constructor and `F2` is
126
  generated from a constructor template.
127
- \[*Example 6*:
128
  ``` cpp
129
  template <class T> struct A {
130
  using value_type = T;
131
  A(value_type); // #1
132
  A(const A&); // #2
@@ -154,11 +168,11 @@ then
154
 
155
  If there is exactly one viable function that is a better function than
156
  all other viable functions, then it is the one selected by overload
157
  resolution; otherwise the call is ill-formed.[^7]
158
 
159
- [*Example 7*:
160
 
161
  ``` cpp
162
  void Fcn(const int*, short);
163
  void Fcn(int*, int);
164
 
@@ -177,35 +191,13 @@ void f() {
177
  }
178
  ```
179
 
180
  — *end example*]
181
 
182
- If the best viable function resolves to a function for which multiple
183
- declarations were found, and if any two of these declarations inhabit
184
- different scopes and specify a default argument that made the function
185
- viable, the program is ill-formed.
186
-
187
- [*Example 8*:
188
-
189
- ``` cpp
190
- namespace A {
191
- extern "C" void f(int = 5);
192
- }
193
- namespace B {
194
- extern "C" void f(int = 5);
195
- }
196
-
197
- using A::f;
198
- using B::f;
199
-
200
- void use() {
201
- f(3); // OK, default argument was not used for viability
202
- f(); // error: found default argument twice
203
- }
204
- ```
205
-
206
- — *end example*]
207
 
208
  #### Implicit conversion sequences <a id="over.best.ics">[[over.best.ics]]</a>
209
 
210
  ##### General <a id="over.best.ics.general">[[over.best.ics.general]]</a>
211
 
@@ -218,17 +210,17 @@ single expression [[dcl.init]], [[dcl.init.ref]].
218
 
219
  Implicit conversion sequences are concerned only with the type,
220
  cv-qualification, and value category of the argument and how these are
221
  converted to match the corresponding properties of the parameter.
222
 
223
- [*Note 1*: Other properties, such as the lifetime, storage class,
224
- alignment, accessibility of the argument, whether the argument is a
225
- bit-field, and whether a function is deleted [[dcl.fct.def.delete]], are
226
- ignored. So, although an implicit conversion sequence can be defined for
227
- a given argument-parameter pair, the conversion from the argument to the
228
- parameter might still be ill-formed in the final
229
- analysis. — *end note*]
230
 
231
  A well-formed implicit conversion sequence is one of the following
232
  forms:
233
 
234
  - a standard conversion sequence [[over.ics.scs]],
@@ -285,40 +277,40 @@ parameter.
285
  [*Note 3*: When the parameter has a class type, this is a conceptual
286
  conversion defined for the purposes of [[over]]; the actual
287
  initialization is defined in terms of constructors and is not a
288
  conversion. — *end note*]
289
 
290
- Any difference in top-level cv-qualification is subsumed by the
291
- initialization itself and does not constitute a conversion.
292
-
293
- [*Example 2*: A parameter of type `A` can be initialized from an
294
- argument of type `const A`. The implicit conversion sequence for that
295
- case is the identity sequence; it contains no “conversion” from
296
- `const A` to `A`. — *end example*]
297
-
298
- When the parameter has a class type and the argument expression has the
299
- same type, the implicit conversion sequence is an identity conversion.
300
- When the parameter has a class type and the argument expression has a
301
- derived class type, the implicit conversion sequence is a
302
- derived-to-base conversion from the derived class to the base class. A
303
- derived-to-base conversion has Conversion rank [[over.ics.scs]].
304
 
305
  [*Note 4*: There is no such standard conversion; this derived-to-base
306
  conversion exists only in the description of implicit conversion
307
  sequences. — *end note*]
308
 
 
 
 
 
 
 
 
309
  When the parameter is the implicit object parameter of a static member
310
  function, the implicit conversion sequence is a standard conversion
311
  sequence that is neither better nor worse than any other standard
312
  conversion sequence.
313
 
314
  In all contexts, when converting to the implicit object parameter or
315
  when converting to the left operand of an assignment operation only
316
  standard conversion sequences are allowed.
317
 
318
- [*Note 5*: When converting to the explicit object parameter, if any,
319
- user-defined conversion sequences are allowed. — *end note*]
320
 
321
  If no conversions are required to match an argument to a parameter type,
322
  the implicit conversion sequence is the standard conversion sequence
323
  consisting of the identity conversion [[over.ics.scs]].
324
 
@@ -425,11 +417,11 @@ the special rules for initialization by user-defined conversion apply
425
  when selecting the best user-defined conversion for a user-defined
426
  conversion sequence (see  [[over.match.best]] and  [[over.best.ics]]).
427
 
428
  If the user-defined conversion is specified by a specialization of a
429
  conversion function template, the second standard conversion sequence
430
- shall have exact match rank.
431
 
432
  A conversion of an expression of class type to the same class type is
433
  given Exact Match rank, and a conversion of an expression of class type
434
  to a base class of that type is given Conversion rank, in spite of the
435
  fact that a constructor (i.e., a user-defined conversion function) is
@@ -441,34 +433,47 @@ An ellipsis conversion sequence occurs when an argument in a function
441
  call is matched with the ellipsis parameter specification of the
442
  function called (see  [[expr.call]]).
443
 
444
  ##### Reference binding <a id="over.ics.ref">[[over.ics.ref]]</a>
445
 
446
- When a parameter of reference type binds directly [[dcl.init.ref]] to an
447
- argument expression, the implicit conversion sequence is the identity
448
- conversion, unless the argument expression has a type that is a derived
449
- class of the parameter type, in which case the implicit conversion
450
- sequence is a derived-to-base conversion [[over.best.ics]].
 
 
 
 
 
 
 
 
 
 
451
 
452
  [*Example 4*:
453
 
454
  ``` cpp
455
  struct A {};
456
  struct B : public A {} b;
457
  int f(A&);
458
  int f(B&);
459
  int i = f(b); // calls f(B&), an exact match, rather than f(A&), a conversion
 
 
 
 
 
460
  ```
461
 
462
  — *end example*]
463
 
464
  If the parameter binds directly to the result of applying a conversion
465
  function to the argument expression, the implicit conversion sequence is
466
  a user-defined conversion sequence [[over.ics.user]] whose second
467
- standard conversion sequence is either an identity conversion or, if the
468
- conversion function returns an entity of a type that is a derived class
469
- of the parameter type, a derived-to-base conversion.
470
 
471
  When a parameter of reference type is not bound directly to an argument
472
  expression, the conversion sequence is the one required to convert the
473
  argument expression to the referenced type according to 
474
  [[over.best.ics]]. Conceptually, this conversion sequence corresponds to
@@ -478,11 +483,11 @@ the initialization itself and does not constitute a conversion.
478
 
479
  Except for an implicit object parameter, for which see 
480
  [[over.match.funcs]], an implicit conversion sequence cannot be formed
481
  if it requires binding an lvalue reference other than a reference to a
482
  non-volatile `const` type to an rvalue or binding an rvalue reference to
483
- an lvalue other than a function lvalue.
484
 
485
  [*Note 9*: This means, for example, that a candidate function cannot be
486
  a viable function if it has a non-`const` lvalue reference parameter
487
  (other than the implicit object parameter) and the corresponding
488
  argument would require a temporary to be created to initialize the
@@ -505,16 +510,17 @@ non-`const` lvalue reference to a bit-field
505
 
506
  When an argument is an initializer list [[dcl.init.list]], it is not an
507
  expression and special rules apply for converting it to a parameter
508
  type.
509
 
510
- If the initializer list is a *designated-initializer-list*, a conversion
511
- is only possible if the parameter has an aggregate type that can be
512
- initialized from the initializer list according to the rules for
513
- aggregate initialization [[dcl.init.aggr]], in which case the implicit
514
- conversion sequence is a user-defined conversion sequence whose second
515
- standard conversion sequence is an identity conversion.
 
516
 
517
  [*Note 10*:
518
 
519
  Aggregate initialization does not require that the members are declared
520
  in designation order. If, after overload resolution, the order does not
@@ -570,11 +576,11 @@ f( {1,2,3} ); // OK, f(initializer_list<int>) identity convers
570
  f( {'a','b'} ); // OK, f(initializer_list<int>) integral promotion
571
  f( {1.0} ); // error: narrowing
572
 
573
  struct A {
574
  A(std::initializer_list<double>); // #1
575
- A(std::initializer_list<complex<double>>); // #2
576
  A(std::initializer_list<std::string>); // #3
577
  };
578
  A a{ 1.0,2.0 }; // OK, uses #1
579
 
580
  void g(A);
@@ -818,12 +824,12 @@ conversion sequences unless one of the following rules applies:
818
  ```
819
 
820
  — *end example*]
821
  or, if not that,
822
  - `S1` and `S2` include reference bindings [[dcl.init.ref]] and `S1`
823
- binds an lvalue reference to a function lvalue and `S2` binds an
824
- rvalue reference to a function lvalue
825
  \[*Example 4*:
826
  ``` cpp
827
  int f(void(&)()); // #1
828
  int f(void(&&)()); // #2
829
  void g();
@@ -831,28 +837,33 @@ conversion sequences unless one of the following rules applies:
831
  ```
832
 
833
  — *end example*]
834
  or, if not that,
835
  - `S1` and `S2` differ only in their qualification conversion
836
- [[conv.qual]] and yield similar types `T1` and `T2`, respectively,
837
- where `T1` can be converted to `T2` by a qualification conversion.
 
 
 
838
  \[*Example 5*:
839
  ``` cpp
840
  int f(const volatile int *);
841
  int f(const int *);
842
  int i;
843
  int j = f(&i); // calls f(const int*)
 
 
 
 
844
  ```
845
 
846
  — *end example*]
847
  or, if not that,
848
  - `S1`
849
- and `S2` include reference bindings [[dcl.init.ref]], and the types
850
- to which the references refer are the same type except for top-level
851
- cv-qualifiers, and the type to which the reference initialized by
852
- `S2` refers is more cv-qualified than the type to which the
853
- reference initialized by `S1` refers.
854
  \[*Example 6*:
855
  ``` cpp
856
  int f(const int &);
857
  int f(int &);
858
  int g(const int &);
@@ -868,20 +879,51 @@ conversion sequences unless one of the following rules applies:
868
  };
869
  void g(const X& a, X b) {
870
  a.f(); // calls X::f() const
871
  b.f(); // calls X::f()
872
  }
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
873
  ```
874
 
875
  — *end example*]
876
  - User-defined conversion sequence `U1` is a better conversion sequence
877
  than another user-defined conversion sequence `U2` if they contain the
878
  same user-defined conversion function or constructor or they
879
  initialize the same class in an aggregate initialization and in either
880
  case the second standard conversion sequence of `U1` is better than
881
  the second standard conversion sequence of `U2`.
882
- \[*Example 7*:
883
  ``` cpp
884
  struct A {
885
  operator short();
886
  } a;
887
  int f(int);
@@ -909,11 +951,11 @@ indistinguishable unless one of the following rules applies:
909
  to the rank of `FP2`, and
910
  - `T3` is not a floating-point type, or `T3` is a floating-point type
911
  whose rank is not equal to the rank of `FP1`, or the floating-point
912
  conversion subrank [[conv.rank]] of `FP2` is greater than the
913
  subrank of `T3`.
914
- \[*Example 8*:
915
  ``` cpp
916
  int f(std::float32_t);
917
  int f(std::float64_t);
918
  int f(long long);
919
  float x;
@@ -930,11 +972,11 @@ indistinguishable unless one of the following rules applies:
930
  of `B*` to `void*`.
931
  - If class `B` is derived directly or indirectly from class `A` and
932
  class `C` is derived directly or indirectly from `B`,
933
  - conversion of `C*` to `B*` is better than conversion of `C*` to
934
  `A*`,
935
- \[*Example 9*:
936
  ``` cpp
937
  struct A {};
938
  struct B : public A {};
939
  struct C : public B {};
940
  C* pc;
 
16
 
17
  - for some argument j, ICSʲ(`F₁`) is a better conversion sequence than
18
  ICSʲ(`F₂`), or, if not that,
19
  - the context is an initialization by user-defined conversion (see 
20
  [[dcl.init]], [[over.match.conv]], and  [[over.match.ref]]) and the
21
+ standard conversion sequence from the result of `F₁` to the
22
  destination type (i.e., the type of the entity being initialized) is a
23
  better conversion sequence than the standard conversion sequence from
24
+ the result of `F₂` to the destination type
25
  \[*Example 1*:
26
  ``` cpp
27
  struct A {
28
  A();
29
  operator int();
 
37
 
38
  — *end example*]
39
  or, if not that,
40
  - the context is an initialization by conversion function for direct
41
  reference binding [[over.match.ref]] of a reference to function type,
42
+ the return type of `F₁` is the same kind of reference (lvalue or
43
  rvalue) as the reference being initialized, and the return type of
44
+ `F₂` is not
45
  \[*Example 2*:
46
  ``` cpp
47
  template <class T> struct A {
48
  operator T&(); // #1
49
  operator T&&(); // #2
 
54
  Fn&& rf = a; // calls #2
55
  ```
56
 
57
  — *end example*]
58
  or, if not that,
59
+ - `F₁` is not a function template specialization and `F₂` is a function
60
  template specialization, or, if not that,
61
+ - `F₁` and `F₂` are function template specializations, and the function
62
+ template for `F₁` is more specialized than the template for `F₂`
63
  according to the partial ordering rules described in 
64
  [[temp.func.order]], or, if not that,
65
+ - `F₁` and `F₂` are non-template functions and `F₁` is more
66
+ partial-ordering-constrained than `F₂` [[temp.constr.order]]
67
+ \[*Example 3*:
68
+ ``` cpp
69
+ template <typename T = int>
70
+ struct S {
71
+ constexpr void f(); // #1
72
+ constexpr void f(this S&) requires true; // #2
73
+ };
74
+
75
+ void test() {
76
+ S<> s;
77
+ s.f(); // calls #2
78
+ }
79
+ ```
80
+
81
+ — *end example*]
82
+ or, if not that,
83
+ - `F₁` is a constructor for a class `D`, `F₂` is a constructor for a
84
  base class `B` of `D`, and for all arguments the corresponding
85
+ parameters of `F₁` and `F₂` have the same type
86
+ \[*Example 4*:
87
  ``` cpp
88
  struct A {
89
  A(int = 0);
90
  };
91
 
 
99
  }
100
  ```
101
 
102
  — *end example*]
103
  or, if not that,
104
+ - `F₂` is a rewritten candidate [[over.match.oper]] and `F₁` is not
105
+ \[*Example 5*:
106
  ``` cpp
107
  struct S {
108
  friend auto operator<=>(const S&, const S&) = default; // #1
109
  friend bool operator<(const S&, const S&); // #2
110
  };
111
  bool b = S() < S(); // calls #2
112
  ```
113
 
114
  — *end example*]
115
  or, if not that,
116
+ - `F₁` and `F₂` are rewritten candidates, and `F₂` is a synthesized
117
+ candidate with reversed order of parameters and `F₁` is not
118
+ \[*Example 6*:
119
  ``` cpp
120
  struct S {
121
  friend std::weak_ordering operator<=>(const S&, int); // #1
122
  friend std::weak_ordering operator<=>(int, const S&); // #2
123
  };
124
  bool b = 1 < S(); // calls #2
125
  ```
126
 
127
  — *end example*]
128
+ or, if not that,
129
+ - `F₁` and `F₂` are generated from class template argument deduction
130
+ [[over.match.class.deduct]] for a class `D`, and `F₂` is generated
131
+ from inheriting constructors from a base class of `D` while `F₁` is
132
  not, and for each explicit function argument, the corresponding
133
+ parameters of `F₁` and `F₂` are either both ellipses or have the same
134
  type, or, if not that,
135
+ - `F₁` is generated from a *deduction-guide* [[over.match.class.deduct]]
136
+ and `F₂` is not, or, if not that,
137
+ - `F₁` is the copy deduction candidate [[over.match.class.deduct]] and
138
+ `F₂` is not, or, if not that,
139
+ - `F₁` is generated from a non-template constructor and `F₂` is
140
  generated from a constructor template.
141
+ \[*Example 7*:
142
  ``` cpp
143
  template <class T> struct A {
144
  using value_type = T;
145
  A(value_type); // #1
146
  A(const A&); // #2
 
168
 
169
  If there is exactly one viable function that is a better function than
170
  all other viable functions, then it is the one selected by overload
171
  resolution; otherwise the call is ill-formed.[^7]
172
 
173
+ [*Example 8*:
174
 
175
  ``` cpp
176
  void Fcn(const int*, short);
177
  void Fcn(int*, int);
178
 
 
191
  }
192
  ```
193
 
194
  — *end example*]
195
 
196
+ [*Note 1*: If the best viable function was made viable by one or more
197
+ default arguments, additional requirements apply
198
+ [[over.match.viable]]. — *end note*]
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
199
 
200
  #### Implicit conversion sequences <a id="over.best.ics">[[over.best.ics]]</a>
201
 
202
  ##### General <a id="over.best.ics.general">[[over.best.ics.general]]</a>
203
 
 
210
 
211
  Implicit conversion sequences are concerned only with the type,
212
  cv-qualification, and value category of the argument and how these are
213
  converted to match the corresponding properties of the parameter.
214
 
215
+ [*Note 1*: Other properties, such as the lifetime, storage duration,
216
+ linkage, alignment, accessibility of the argument, whether the argument
217
+ is a bit-field, and whether a function is deleted
218
+ [[dcl.fct.def.delete]], are ignored. So, although an implicit conversion
219
+ sequence can be defined for a given argument-parameter pair, the
220
+ conversion from the argument to the parameter might still be ill-formed
221
+ in the final analysis. — *end note*]
222
 
223
  A well-formed implicit conversion sequence is one of the following
224
  forms:
225
 
226
  - a standard conversion sequence [[over.ics.scs]],
 
277
  [*Note 3*: When the parameter has a class type, this is a conceptual
278
  conversion defined for the purposes of [[over]]; the actual
279
  initialization is defined in terms of constructors and is not a
280
  conversion. — *end note*]
281
 
282
+ When the cv-unqualified version of the type of the argument expression
283
+ is the same as the parameter type, the implicit conversion sequence is
284
+ an identity conversion. When the parameter has a class type and the
285
+ argument expression has a (possibly cv-qualified) derived class type,
286
+ the implicit conversion sequence is a derived-to-base conversion from
287
+ the derived class to the base class. A derived-to-base conversion has
288
+ Conversion rank [[over.ics.scs]].
 
 
 
 
 
 
 
289
 
290
  [*Note 4*: There is no such standard conversion; this derived-to-base
291
  conversion exists only in the description of implicit conversion
292
  sequences. — *end note*]
293
 
294
+ [*Example 2*: An implicit conversion sequence from an argument of type
295
+ `const A` to a parameter of type `A` can be formed, even if overload
296
+ resolution for copy-initialization of `A` from the argument would not
297
+ find a viable function [[over.match.ctor]], [[over.match.viable]]. The
298
+ implicit conversion sequence for that case is the identity sequence; it
299
+ contains no “conversion” from `const A` to `A`. — *end example*]
300
+
301
  When the parameter is the implicit object parameter of a static member
302
  function, the implicit conversion sequence is a standard conversion
303
  sequence that is neither better nor worse than any other standard
304
  conversion sequence.
305
 
306
  In all contexts, when converting to the implicit object parameter or
307
  when converting to the left operand of an assignment operation only
308
  standard conversion sequences are allowed.
309
 
310
+ [*Note 5*: When a conversion to the explicit object parameter occurs,
311
+ it can include user-defined conversion sequences. — *end note*]
312
 
313
  If no conversions are required to match an argument to a parameter type,
314
  the implicit conversion sequence is the standard conversion sequence
315
  consisting of the identity conversion [[over.ics.scs]].
316
 
 
417
  when selecting the best user-defined conversion for a user-defined
418
  conversion sequence (see  [[over.match.best]] and  [[over.best.ics]]).
419
 
420
  If the user-defined conversion is specified by a specialization of a
421
  conversion function template, the second standard conversion sequence
422
+ shall have Exact Match rank.
423
 
424
  A conversion of an expression of class type to the same class type is
425
  given Exact Match rank, and a conversion of an expression of class type
426
  to a base class of that type is given Conversion rank, in spite of the
427
  fact that a constructor (i.e., a user-defined conversion function) is
 
433
  call is matched with the ellipsis parameter specification of the
434
  function called (see  [[expr.call]]).
435
 
436
  ##### Reference binding <a id="over.ics.ref">[[over.ics.ref]]</a>
437
 
438
+ When a parameter of type “reference to cv `T`” binds directly
439
+ [[dcl.init.ref]] to an argument expression:
440
+
441
+ - If the argument expression has a type that is a derived class of the
442
+ parameter type, the implicit conversion sequence is a derived-to-base
443
+ conversion [[over.best.ics]].
444
+ - Otherwise, if the type of the argument is possibly cv-qualified `T`,
445
+ or if `T` is an array type of unknown bound with element type `U` and
446
+ the argument has an array type of known bound whose element type is
447
+ possibly cv-qualified `U`, the implicit conversion sequence is the
448
+ identity conversion.
449
+ - Otherwise, if `T` is a function type, the implicit conversion sequence
450
+ is a function pointer conversion.
451
+ - Otherwise, the implicit conversion sequence is a qualification
452
+ conversion.
453
 
454
  [*Example 4*:
455
 
456
  ``` cpp
457
  struct A {};
458
  struct B : public A {} b;
459
  int f(A&);
460
  int f(B&);
461
  int i = f(b); // calls f(B&), an exact match, rather than f(A&), a conversion
462
+
463
+ void g() noexcept;
464
+ int h(void (&)() noexcept); // #1
465
+ int h(void (&)()); // #2
466
+ int j = h(g); // calls #1, an exact match, rather than #2, a function pointer conversion
467
  ```
468
 
469
  — *end example*]
470
 
471
  If the parameter binds directly to the result of applying a conversion
472
  function to the argument expression, the implicit conversion sequence is
473
  a user-defined conversion sequence [[over.ics.user]] whose second
474
+ standard conversion sequence is determined by the above rules.
 
 
475
 
476
  When a parameter of reference type is not bound directly to an argument
477
  expression, the conversion sequence is the one required to convert the
478
  argument expression to the referenced type according to 
479
  [[over.best.ics]]. Conceptually, this conversion sequence corresponds to
 
483
 
484
  Except for an implicit object parameter, for which see 
485
  [[over.match.funcs]], an implicit conversion sequence cannot be formed
486
  if it requires binding an lvalue reference other than a reference to a
487
  non-volatile `const` type to an rvalue or binding an rvalue reference to
488
+ an lvalue of object type.
489
 
490
  [*Note 9*: This means, for example, that a candidate function cannot be
491
  a viable function if it has a non-`const` lvalue reference parameter
492
  (other than the implicit object parameter) and the corresponding
493
  argument would require a temporary to be created to initialize the
 
510
 
511
  When an argument is an initializer list [[dcl.init.list]], it is not an
512
  expression and special rules apply for converting it to a parameter
513
  type.
514
 
515
+ If the initializer list is a *designated-initializer-list* and the
516
+ parameter is not a reference, a conversion is only possible if the
517
+ parameter has an aggregate type that can be initialized from the
518
+ initializer list according to the rules for aggregate initialization
519
+ [[dcl.init.aggr]], in which case the implicit conversion sequence is a
520
+ user-defined conversion sequence whose second standard conversion
521
+ sequence is an identity conversion.
522
 
523
  [*Note 10*:
524
 
525
  Aggregate initialization does not require that the members are declared
526
  in designation order. If, after overload resolution, the order does not
 
576
  f( {'a','b'} ); // OK, f(initializer_list<int>) integral promotion
577
  f( {1.0} ); // error: narrowing
578
 
579
  struct A {
580
  A(std::initializer_list<double>); // #1
581
+ A(std::initializer_list<std::complex<double>>); // #2
582
  A(std::initializer_list<std::string>); // #3
583
  };
584
  A a{ 1.0,2.0 }; // OK, uses #1
585
 
586
  void g(A);
 
824
  ```
825
 
826
  — *end example*]
827
  or, if not that,
828
  - `S1` and `S2` include reference bindings [[dcl.init.ref]] and `S1`
829
+ binds an lvalue reference to an lvalue of function type and `S2`
830
+ binds an rvalue reference to an lvalue of function type
831
  \[*Example 4*:
832
  ``` cpp
833
  int f(void(&)()); // #1
834
  int f(void(&&)()); // #2
835
  void g();
 
837
  ```
838
 
839
  — *end example*]
840
  or, if not that,
841
  - `S1` and `S2` differ only in their qualification conversion
842
+ [[conv.qual]] and yield similar types `T1` and `T2`, respectively
843
+ (where a standard conversion sequence that is a reference binding is
844
+ considered to yield the cv-unqualified referenced type), where `T1`
845
+ and `T2` are not the same type, and `const T2` is
846
+ reference-compatible with `T1` [[dcl.init.ref]]
847
  \[*Example 5*:
848
  ``` cpp
849
  int f(const volatile int *);
850
  int f(const int *);
851
  int i;
852
  int j = f(&i); // calls f(const int*)
853
+ int g(const int*);
854
+ int g(const volatile int* const&);
855
+ int* p;
856
+ int k = g(p); // calls g(const int*)
857
  ```
858
 
859
  — *end example*]
860
  or, if not that,
861
  - `S1`
862
+ and `S2` bind “reference to `T1`” and “reference to `T2`”,
863
+ respectively [[dcl.init.ref]], where `T1` and `T2` are not the same
864
+ type, and `T2` is reference-compatible with `T1`
 
 
865
  \[*Example 6*:
866
  ``` cpp
867
  int f(const int &);
868
  int f(int &);
869
  int g(const int &);
 
879
  };
880
  void g(const X& a, X b) {
881
  a.f(); // calls X::f() const
882
  b.f(); // calls X::f()
883
  }
884
+
885
+ int h(int (&)[]);
886
+ int h(int (&)[1]);
887
+ void g2() {
888
+ int a[1];
889
+ h(a); // calls h(int (&)[1])
890
+ }
891
+ ```
892
+
893
+ — *end example*]
894
+ or, if not that,
895
+ - `S1` and `S2` bind the same reference type “reference to `T`” and
896
+ have source types `V1` and `V2`, respectively, where the standard
897
+ conversion sequence from `V1*` to `T*` is better than the standard
898
+ conversion sequence from `V2*` to `T*`.
899
+ \[*Example 7*:
900
+ ``` cpp
901
+ struct Z {};
902
+
903
+ struct A {
904
+ operator Z&();
905
+ operator const Z&(); // #1
906
+ };
907
+
908
+ struct B {
909
+ operator Z();
910
+ operator const Z&&(); // #2
911
+ };
912
+
913
+ const Z& r1 = A(); // OK, uses #1
914
+ const Z&& r2 = B(); // OK, uses #2
915
  ```
916
 
917
  — *end example*]
918
  - User-defined conversion sequence `U1` is a better conversion sequence
919
  than another user-defined conversion sequence `U2` if they contain the
920
  same user-defined conversion function or constructor or they
921
  initialize the same class in an aggregate initialization and in either
922
  case the second standard conversion sequence of `U1` is better than
923
  the second standard conversion sequence of `U2`.
924
+ \[*Example 8*:
925
  ``` cpp
926
  struct A {
927
  operator short();
928
  } a;
929
  int f(int);
 
951
  to the rank of `FP2`, and
952
  - `T3` is not a floating-point type, or `T3` is a floating-point type
953
  whose rank is not equal to the rank of `FP1`, or the floating-point
954
  conversion subrank [[conv.rank]] of `FP2` is greater than the
955
  subrank of `T3`.
956
+ \[*Example 9*:
957
  ``` cpp
958
  int f(std::float32_t);
959
  int f(std::float64_t);
960
  int f(long long);
961
  float x;
 
972
  of `B*` to `void*`.
973
  - If class `B` is derived directly or indirectly from class `A` and
974
  class `C` is derived directly or indirectly from `B`,
975
  - conversion of `C*` to `B*` is better than conversion of `C*` to
976
  `A*`,
977
+ \[*Example 10*:
978
  ``` cpp
979
  struct A {};
980
  struct B : public A {};
981
  struct C : public B {};
982
  C* pc;