From Jason Turner

[over.match.best]

C++11 → C++14 14.9 KB 185 lines
Current Draft | LaTeX Source
Archived: C++11 | C++14
Markdown: C++11 | C++14
Explore in Adventure Game

Diff to HTML by rtfpessoa

Files changed (1) hide show
  1. tmp/tmp8awz7kf3/{from.md → to.md} +113 -59
tmp/tmp8awz7kf3/{from.md → to.md} RENAMED
@@ -38,12 +38,29 @@ and then
38
  float x = a; // ambiguous: both possibilities require conversions,
39
  // and neither is better than the other
40
  ```
41
 
42
  or, if not that,
43
- - `F1` is a non-template function and `F2` is a function template
44
- specialization, or, if not that,
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
45
  - `F1` and `F2` are function template specializations, and the function
46
  template for `F1` is more specialized than the template for `F2`
47
  according to the partial ordering rules described in 
48
  [[temp.func.order]].
49
 
@@ -120,20 +137,41 @@ forms:
120
 
121
  - a *standard conversion sequence* ([[over.ics.scs]]),
122
  - a *user-defined conversion sequence* ([[over.ics.user]]), or
123
  - an *ellipsis conversion sequence* ([[over.ics.ellipsis]]).
124
 
125
- However, when considering the argument of a constructor or user-defined
126
- conversion function that is a candidate by  [[over.match.ctor]] when
127
- invoked for the copying/moving of the temporary in the second step of a
128
- class copy-initialization, by  [[over.match.list]] when passing the
129
- initializer list as a single argument or when the initializer list has
130
- exactly one element and a conversion to some class `X` or reference to
131
- (possibly cv-qualified) `X` is considered for the first parameter of a
132
- constructor of `X`, or by  [[over.match.copy]], [[over.match.conv]], or
133
- [[over.match.ref]] in all cases, only standard conversion sequences and
134
- ellipsis conversion sequences are considered.
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
135
 
136
  For the case where the parameter type is a reference, see 
137
  [[over.ics.ref]].
138
 
139
  When the parameter type is not a reference, the implicit conversion
@@ -251,12 +289,12 @@ conversion function template, the second standard conversion sequence
251
  shall have exact match rank.
252
 
253
  A conversion of an expression of class type to the same class type is
254
  given Exact Match rank, and a conversion of an expression of class type
255
  to a base class of that type is given Conversion rank, in spite of the
256
- fact that a copy/move constructor (i.e., a user-defined conversion
257
- function) is called for those cases.
258
 
259
  ##### Ellipsis conversion sequences <a id="over.ics.ellipsis">[[over.ics.ellipsis]]</a>
260
 
261
  An ellipsis conversion sequence occurs when an argument in a function
262
  call is matched with the ellipsis parameter specification of the
@@ -314,29 +352,27 @@ formation of implicit conversion sequences treats the `int` bit-field as
314
  an `int` lvalue and finds an exact match with the parameter. If the
315
  function is selected by overload resolution, the call will nonetheless
316
  be ill-formed because of the prohibition on binding a non-`const` lvalue
317
  reference to a bit-field ([[dcl.init.ref]]).
318
 
319
- The binding of a reference to an expression that is
320
- *reference-compatible with added qualification* influences the rank of a
321
- standard conversion; see  [[over.ics.rank]] and  [[dcl.init.ref]].
322
-
323
  ##### List-initialization sequence <a id="over.ics.list">[[over.ics.list]]</a>
324
 
325
  When an argument is an initializer list ([[dcl.init.list]]), it is not
326
  an expression and special rules apply for converting it to a parameter
327
  type.
328
 
329
- If the parameter type is `std::initializer_list<X>` or “array of
330
- `X`”[^12] and all the elements of the initializer list can be implicitly
331
- converted to `X`, the implicit conversion sequence is the worst
332
- conversion necessary to convert an element of the list to `X`. This
333
- conversion can be a user-defined conversion even in the context of a
334
- call to an initializer-list constructor.
 
335
 
336
  ``` cpp
337
  void f(std::initializer_list<int>);
 
338
  f( {1,2,3} ); // OK: f(initializer_list<int>) identity conversion
339
  f( {'a','b'} ); // OK: f(initializer_list<int>) integral promotion
340
  f( {1.0} ); // error: narrowing
341
 
342
  struct A {
@@ -352,19 +388,27 @@ g({ "foo", "bar" }); // OK, uses #3
352
  typedef int IA[3];
353
  void h(const IA&);
354
  h({ 1, 2, 3 }); // OK: identity conversion
355
  ```
356
 
 
 
 
 
 
 
 
357
  Otherwise, if the parameter is a non-aggregate class `X` and overload
358
  resolution per  [[over.match.list]] chooses a single best constructor of
359
  `X` to perform the initialization of an object of type `X` from the
360
  argument initializer list, the implicit conversion sequence is a
361
- user-defined conversion sequence. If multiple constructors are viable
362
- but none is better than the others, the implicit conversion sequence is
363
- the ambiguous conversion sequence. User-defined conversions are allowed
364
- for conversion of the initializer list elements to the constructor
365
- parameter types except as noted in  [[over.best.ics]].
 
366
 
367
  ``` cpp
368
  struct A {
369
  A(std::initializer_list<int>);
370
  };
@@ -374,11 +418,11 @@ f( {'a', 'b'} ); // OK: f(A(std::initializer_list<int>)) user-defined
374
  struct B {
375
  B(int, double);
376
  };
377
  void g(B);
378
  g( {'a', 'b'} ); // OK: g(B(int,double)) user-defined conversion
379
- g( {1.0, 1,0} ); // error: narrowing
380
 
381
  void f(B);
382
  f( {'a', 'b'} ); // error: ambiguous f(A) or f(B)
383
 
384
  struct C {
@@ -386,20 +430,21 @@ struct C {
386
  };
387
  void h(C);
388
  h({"foo"}); // OK: h(C(std::string("foo")))
389
 
390
  struct D {
391
- C(A, C);
392
  };
393
  void i(D);
394
  i({ {1,2}, {"bar"} }); // OK: i(D(A(std::initializer_list<int>{1,2\),C(std::string("bar"))))}
395
  ```
396
 
397
  Otherwise, if the parameter has an aggregate type which can be
398
  initialized from the initializer list according to the rules for
399
  aggregate initialization ([[dcl.init.aggr]]), the implicit conversion
400
- sequence is a user-defined conversion sequence.
 
401
 
402
  ``` cpp
403
  struct A {
404
  int m1;
405
  double m2;
@@ -479,23 +524,10 @@ conversion sequences unless one of the following rules applies:
479
  sequence is considered to be a subsequence of any non-identity
480
  conversion sequence) or, if not that,
481
  - the rank of `S1` is better than the rank of `S2`, or `S1` and `S2`
482
  have the same rank and are distinguishable by the rules in the
483
  paragraph below, or, if not that,
484
- - `S1`
485
- and `S2` differ only in their qualification conversion and yield
486
- similar types `T1` and `T2` ([[conv.qual]]), respectively, and the
487
- cv-qualification signature of type `T1` is a proper subset of the
488
- cv-qualification signature of type `T2`.
489
- ``` cpp
490
- int f(const int *);
491
- int f(int *);
492
- int i;
493
- int j = f(&i); // calls f(int*)
494
- ```
495
-
496
- or, if not that,
497
  - `S1` and `S2` are reference bindings ([[dcl.init.ref]]) and neither
498
  refers to an implicit object parameter of a non-static member
499
  function declared without a *ref-qualifier*, and `S1` binds an
500
  rvalue reference to an rvalue and `S2` binds an lvalue reference.
501
  ``` cpp
@@ -526,15 +558,30 @@ conversion sequences unless one of the following rules applies:
526
  or, if not that,
527
  - `S1` and `S2` are reference bindings ([[dcl.init.ref]]) and `S1`
528
  binds an lvalue reference to a function lvalue and `S2` binds an
529
  rvalue reference to a function lvalue.
530
  ``` cpp
531
- template<class T> int f(T&);
532
- template<class T> int f(T&&);
533
  void g();
534
- int i1 = f(g); // calls f(T&)
535
  ```
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
536
  - `S1`
537
  and `S2` are reference bindings ([[dcl.init.ref]]), and the types
538
  to which the references refer are the same type except for top-level
539
  cv-qualifiers, and the type to which the reference initialized by
540
  `S2` refers is more cv-qualified than the type to which the
@@ -558,33 +605,40 @@ conversion sequences unless one of the following rules applies:
558
  b.f(); // calls X::f()
559
  }
560
  ```
561
  - User-defined conversion sequence `U1` is a better conversion sequence
562
  than another user-defined conversion sequence `U2` if they contain the
563
- same user-defined conversion function or constructor or aggregate
564
- initialization and the second standard conversion sequence of `U1` is
565
- better than the second standard conversion sequence of `U2`.
 
566
  ``` cpp
567
  struct A {
568
  operator short();
569
  } a;
570
  int f(int);
571
  int f(float);
572
  int i = f(a); // calls f(int), because short → int is
573
  // better than short → float.
574
  ```
575
  - List-initialization sequence `L1` is a better conversion sequence than
576
- list-initialization sequence `L2` if `L1` converts to
577
- `std::initializer_list<X>` for some `X` and `L2` does not.
 
 
 
578
 
579
  Standard conversion sequences are ordered by their ranks: an Exact Match
580
  is a better conversion than a Promotion, which is a better conversion
581
  than a Conversion. Two conversion sequences with the same rank are
582
  indistinguishable unless one of the following rules applies:
583
 
584
  - A conversion that does not convert a pointer, a pointer to member, or
585
  `std::nullptr_t` to `bool` is better than one that does.
 
 
 
586
  - If class `B` is derived directly or indirectly from class `A`,
587
  conversion of `B*` to `A*` is better than conversion of `B*` to
588
  `void*`, and conversion of `A*` to `void*` is better than conversion
589
  of `B*` to `void*`.
590
  - If class `B` is derived directly or indirectly from class `A` and
@@ -598,21 +652,21 @@ indistinguishable unless one of the following rules applies:
598
  C* pc;
599
  int f(A*);
600
  int f(B*);
601
  int i = f(pc); // calls f(B*)
602
  ```
603
- - binding of an expression of type `C` to a reference of type `B&` is
604
- better than binding an expression of type `C` to a reference of type
605
- `A&`,
606
  - conversion of `A::*` to `B::*` is better than conversion of `A::*`
607
  to `C::*`,
608
  - conversion of `C` to `B` is better than conversion of `C` to `A`,
609
  - conversion of `B*` to `A*` is better than conversion of `C*` to
610
  `A*`,
611
- - binding of an expression of type `B` to a reference of type `A&` is
612
- better than binding an expression of type `C` to a reference of type
613
- `A&`,
614
  - conversion of `B::*` to `C::*` is better than conversion of `A::*`
615
  to `C::*`, and
616
  - conversion of `B` to `A` is better than conversion of `C` to `A`.
617
 
618
  Compared conversion sequences will have different source types only in
 
38
  float x = a; // ambiguous: both possibilities require conversions,
39
  // and neither is better than the other
40
  ```
41
 
42
  or, if not that,
43
+ - the context is an initialization by conversion function for direct
44
+ reference binding ([[over.match.ref]]) of a reference to function
45
+ type, the return type of `F1` is the same kind of reference (i.e.
46
+ lvalue or rvalue) as the reference being initialized, and the return
47
+ type of `F2` is not
48
+ ``` cpp
49
+ template <class T> struct A {
50
+ operator T&(); // #1
51
+ operator T&&(); // #2
52
+ };
53
+ typedef int Fn();
54
+ A<Fn> a;
55
+ Fn& lf = a; // calls #1
56
+ Fn&& rf = a; // calls #2
57
+ ```
58
+
59
+ or, if not that,
60
+ - `F1` is not a function template specialization and `F2` is a function
61
+ template specialization, or, if not that,
62
  - `F1` and `F2` are function template specializations, and the function
63
  template for `F1` is more specialized than the template for `F2`
64
  according to the partial ordering rules described in 
65
  [[temp.func.order]].
66
 
 
137
 
138
  - a *standard conversion sequence* ([[over.ics.scs]]),
139
  - a *user-defined conversion sequence* ([[over.ics.user]]), or
140
  - an *ellipsis conversion sequence* ([[over.ics.ellipsis]]).
141
 
142
+ However, if the target is
143
+
144
+ - the first parameter of a constructor or
145
+ - the implicit object parameter of a user-defined conversion function
146
+
147
+ and the constructor or user-defined conversion function is a candidate
148
+ by
149
+
150
+ - [[over.match.ctor]], when the argument is the temporary in the second
151
+ step of a class copy-initialization,
152
+ - [[over.match.copy]], [[over.match.conv]], or [[over.match.ref]] (in
153
+ all cases), or
154
+ - the second phase of [[over.match.list]] when the initializer list has
155
+ exactly one element, and the target is the first parameter of a
156
+ constructor of class `X`, and the conversion is to `X` or reference to
157
+ (possibly cv-qualified) `X`,
158
+
159
+ user-defined conversion sequences are not considered. These rules
160
+ prevent more than one user-defined conversion from being applied during
161
+ overload resolution, thereby avoiding infinite recursion.
162
+
163
+ ``` cpp
164
+ struct Y { Y(int); };
165
+ struct A { operator int(); };
166
+ Y y1 = A(); // error: A::operator int() is not a candidate
167
+
168
+ struct X { };
169
+ struct B { operator X(); };
170
+ B b;
171
+ X x({b}); // error: B::operator X() is not a candidate
172
+ ```
173
 
174
  For the case where the parameter type is a reference, see 
175
  [[over.ics.ref]].
176
 
177
  When the parameter type is not a reference, the implicit conversion
 
289
  shall have exact match rank.
290
 
291
  A conversion of an expression of class type to the same class type is
292
  given Exact Match rank, and a conversion of an expression of class type
293
  to a base class of that type is given Conversion rank, in spite of the
294
+ fact that a constructor (i.e., a user-defined conversion function) is
295
+ called for those cases.
296
 
297
  ##### Ellipsis conversion sequences <a id="over.ics.ellipsis">[[over.ics.ellipsis]]</a>
298
 
299
  An ellipsis conversion sequence occurs when an argument in a function
300
  call is matched with the ellipsis parameter specification of the
 
352
  an `int` lvalue and finds an exact match with the parameter. If the
353
  function is selected by overload resolution, the call will nonetheless
354
  be ill-formed because of the prohibition on binding a non-`const` lvalue
355
  reference to a bit-field ([[dcl.init.ref]]).
356
 
 
 
 
 
357
  ##### List-initialization sequence <a id="over.ics.list">[[over.ics.list]]</a>
358
 
359
  When an argument is an initializer list ([[dcl.init.list]]), it is not
360
  an expression and special rules apply for converting it to a parameter
361
  type.
362
 
363
+ If the parameter type is `std::initializer_list<X>` and all the elements
364
+ of the initializer list can be implicitly converted to `X`, the implicit
365
+ conversion sequence is the worst conversion necessary to convert an
366
+ element of the list to `X`, or if the initializer list has no elements,
367
+ the identity conversion. This conversion can be a user-defined
368
+ conversion even in the context of a call to an initializer-list
369
+ constructor.
370
 
371
  ``` cpp
372
  void f(std::initializer_list<int>);
373
+ f( {} ); // OK: f(initializer_list<int>) identity conversion
374
  f( {1,2,3} ); // OK: f(initializer_list<int>) identity conversion
375
  f( {'a','b'} ); // OK: f(initializer_list<int>) integral promotion
376
  f( {1.0} ); // error: narrowing
377
 
378
  struct A {
 
388
  typedef int IA[3];
389
  void h(const IA&);
390
  h({ 1, 2, 3 }); // OK: identity conversion
391
  ```
392
 
393
+ Otherwise, if the parameter type is “array of `N` `X`”[^12], if the
394
+ initializer list has exactly `N` elements or if it has fewer than `N`
395
+ elements and `X` is default-constructible, and if all the elements of
396
+ the initializer list can be implicitly converted to `X`, the implicit
397
+ conversion sequence is the worst conversion necessary to convert an
398
+ element of the list to `X`.
399
+
400
  Otherwise, if the parameter is a non-aggregate class `X` and overload
401
  resolution per  [[over.match.list]] chooses a single best constructor of
402
  `X` to perform the initialization of an object of type `X` from the
403
  argument initializer list, the implicit conversion sequence is a
404
+ user-defined conversion sequence with the second standard conversion
405
+ sequence an identity conversion. If multiple constructors are viable but
406
+ none is better than the others, the implicit conversion sequence is the
407
+ ambiguous conversion sequence. User-defined conversions are allowed for
408
+ conversion of the initializer list elements to the constructor parameter
409
+ types except as noted in  [[over.best.ics]].
410
 
411
  ``` cpp
412
  struct A {
413
  A(std::initializer_list<int>);
414
  };
 
418
  struct B {
419
  B(int, double);
420
  };
421
  void g(B);
422
  g( {'a', 'b'} ); // OK: g(B(int,double)) user-defined conversion
423
+ g( {1.0, 1.0} ); // error: narrowing
424
 
425
  void f(B);
426
  f( {'a', 'b'} ); // error: ambiguous f(A) or f(B)
427
 
428
  struct C {
 
430
  };
431
  void h(C);
432
  h({"foo"}); // OK: h(C(std::string("foo")))
433
 
434
  struct D {
435
+ D(A, C);
436
  };
437
  void i(D);
438
  i({ {1,2}, {"bar"} }); // OK: i(D(A(std::initializer_list<int>{1,2\),C(std::string("bar"))))}
439
  ```
440
 
441
  Otherwise, if the parameter has an aggregate type which can be
442
  initialized from the initializer list according to the rules for
443
  aggregate initialization ([[dcl.init.aggr]]), the implicit conversion
444
+ sequence is a user-defined conversion sequence with the second standard
445
+ conversion sequence an identity conversion.
446
 
447
  ``` cpp
448
  struct A {
449
  int m1;
450
  double m2;
 
524
  sequence is considered to be a subsequence of any non-identity
525
  conversion sequence) or, if not that,
526
  - the rank of `S1` is better than the rank of `S2`, or `S1` and `S2`
527
  have the same rank and are distinguishable by the rules in the
528
  paragraph below, or, if not that,
 
 
 
 
 
 
 
 
 
 
 
 
 
529
  - `S1` and `S2` are reference bindings ([[dcl.init.ref]]) and neither
530
  refers to an implicit object parameter of a non-static member
531
  function declared without a *ref-qualifier*, and `S1` binds an
532
  rvalue reference to an rvalue and `S2` binds an lvalue reference.
533
  ``` cpp
 
558
  or, if not that,
559
  - `S1` and `S2` are reference bindings ([[dcl.init.ref]]) and `S1`
560
  binds an lvalue reference to a function lvalue and `S2` binds an
561
  rvalue reference to a function lvalue.
562
  ``` cpp
563
+ int f(void(&)()); // #1
564
+ int f(void(&&)()); // #2
565
  void g();
566
+ int i1 = f(g); // calls #1
567
  ```
568
+
569
+ or, if not that,
570
+ - `S1`
571
+ and `S2` differ only in their qualification conversion and yield
572
+ similar types `T1` and `T2` ([[conv.qual]]), respectively, and the
573
+ cv-qualification signature of type `T1` is a proper subset of the
574
+ cv-qualification signature of type `T2`.
575
+ ``` cpp
576
+ int f(const volatile int *);
577
+ int f(const int *);
578
+ int i;
579
+ int j = f(&i); // calls f(const int*)
580
+ ```
581
+
582
+ or, if not that,
583
  - `S1`
584
  and `S2` are reference bindings ([[dcl.init.ref]]), and the types
585
  to which the references refer are the same type except for top-level
586
  cv-qualifiers, and the type to which the reference initialized by
587
  `S2` refers is more cv-qualified than the type to which the
 
605
  b.f(); // calls X::f()
606
  }
607
  ```
608
  - User-defined conversion sequence `U1` is a better conversion sequence
609
  than another user-defined conversion sequence `U2` if they contain the
610
+ same user-defined conversion function or constructor or they
611
+ initialize the same class in an aggregate initialization and in either
612
+ case the second standard conversion sequence of `U1` is better than
613
+ the second standard conversion sequence of `U2`.
614
  ``` cpp
615
  struct A {
616
  operator short();
617
  } a;
618
  int f(int);
619
  int f(float);
620
  int i = f(a); // calls f(int), because short → int is
621
  // better than short → float.
622
  ```
623
  - List-initialization sequence `L1` is a better conversion sequence than
624
+ list-initialization sequence `L2` if
625
+ - `L1` converts to `std::initializer_list<X>` for some `X` and `L2`
626
+ does not, or, if not that,
627
+ - `L1` converts to type “array of `N1` `T`”, `L2` converts to type
628
+ “array of `N2` `T`”, and `N1` is smaller than `N2`.
629
 
630
  Standard conversion sequences are ordered by their ranks: an Exact Match
631
  is a better conversion than a Promotion, which is a better conversion
632
  than a Conversion. Two conversion sequences with the same rank are
633
  indistinguishable unless one of the following rules applies:
634
 
635
  - A conversion that does not convert a pointer, a pointer to member, or
636
  `std::nullptr_t` to `bool` is better than one that does.
637
+ - A conversion that promotes an enumeration whose underlying type is
638
+ fixed to its underlying type is better than one that promotes to the
639
+ promoted underlying type, if the two are different.
640
  - If class `B` is derived directly or indirectly from class `A`,
641
  conversion of `B*` to `A*` is better than conversion of `B*` to
642
  `void*`, and conversion of `A*` to `void*` is better than conversion
643
  of `B*` to `void*`.
644
  - If class `B` is derived directly or indirectly from class `A` and
 
652
  C* pc;
653
  int f(A*);
654
  int f(B*);
655
  int i = f(pc); // calls f(B*)
656
  ```
657
+ - binding of an expression of type `C` to a reference to type `B` is
658
+ better than binding an expression of type `C` to a reference to type
659
+ `A`,
660
  - conversion of `A::*` to `B::*` is better than conversion of `A::*`
661
  to `C::*`,
662
  - conversion of `C` to `B` is better than conversion of `C` to `A`,
663
  - conversion of `B*` to `A*` is better than conversion of `C*` to
664
  `A*`,
665
+ - binding of an expression of type `B` to a reference to type `A` is
666
+ better than binding an expression of type `C` to a reference to type
667
+ `A`,
668
  - conversion of `B::*` to `C::*` is better than conversion of `A::*`
669
  to `C::*`, and
670
  - conversion of `B` to `A` is better than conversion of `C` to `A`.
671
 
672
  Compared conversion sequences will have different source types only in