[over] - C++11 → C++14

Files changed (1) hide show

tmp/tmpp_vkuzje/{from.md → to.md} +219 -123

tmp/tmpp_vkuzje/{from.md → to.md} RENAMED Viewed

@@ -377,10 +377,14 @@ handled as candidate functions in the usual way.[^2] A given name can
 refer to one or more function templates and also to a set of overloaded
 non-template functions. In such a case, the candidate functions
 generated from each function template are combined with the set of
 non-template candidate functions.
 #### Function call syntax <a id="over.match.call">[[over.match.call]]</a>
 In a function call ([[expr.call]])
 ``` bnf
@@ -463,11 +467,11 @@ operators of `T` are obtained by ordinary lookup of the name
 In addition, for each non-explicit conversion function declared in `T`
 of the form
 ``` bnf
-'operator' conversion-type-id '( )' attribute-specifier-seqₒₚₜ cv-qualifier ';'
 ```
 where *cv-qualifier* is the same cv-qualification as, or a greater
 cv-qualification than, *cv*, and where *conversion-type-id* denotes the
 type “pointer to function of (`P1`,...,`Pn)` returning `R`”, or the type
@@ -537,13 +541,13 @@ struct String {
 };
 String operator + (const String&, const String&);
 void f(void) {
  const char* p= "one" + "two";  // ill-formed because neither
-                                // operand has user-defined type
  int I = 1 + 1;                 // Always evaluates to 2 even if
-                                // user-defined types exist which
                                 // would perform the operation.
 }
 ```
 If either operand has a type that is a class or an enumeration, a
@@ -574,13 +578,14 @@ version is `T1`, and for a binary operator `@` with a left operand of a
 type whose cv-unqualified version is `T1` and a right operand of a type
 whose cv-unqualified version is `T2`, three sets of candidate functions,
 designated *member candidates*, *non-member candidates* and *built-in
 candidates*, are constructed as follows:
-- If `T1` is a complete class type, the set of member candidates is the
-  result of the qualified lookup of `T1::operator@` (
-  [[over.call.func]]); otherwise, the set of member candidates is empty.
 - The set of non-member candidates is the result of the unqualified
   lookup of `operator@` in the context of the expression according to
   the usual rules for name lookup in unqualified function calls (
   [[basic.lookup.argdep]]) except that all member functions are ignored.
   However, if no operand has a class type, only those non-member
@@ -595,12 +600,12 @@ candidates*, are constructed as follows:
   defined in  [[over.built]] that, compared to the given operator,
   - have the same operator name, and
   - accept the same number of operands, and
   - accept operand types to which the given operand or operands can be
     converted according to [[over.best.ics]], and
-  - do not have the same parameter-type-list as any non-template
- non-member candidate.
 For the built-in assignment operators, conversions of the left operand
 are restricted as follows:
 - no temporaries are introduced to hold the left operand, and
@@ -626,15 +631,30 @@ void m() {
   a + b;            // operator+(a,b) chosen over int(a) + int(b)
 }
 ```
 If a built-in candidate is selected by overload resolution, the operands
-are converted to the types of the corresponding parameters of the
-selected operation function. Then the operator is treated as the
 corresponding built-in operator and interpreted according to Clause
 [[expr]].
 The second operand of operator `->` is ignored in selecting an
 `operator->` function, and is not an argument when the `operator->`
 function is called. When `operator->` returns, the operator `->` is
 applied to the value returned, with the original second operand.[^7]
@@ -679,29 +699,32 @@ the candidate functions are all the converting constructors (
 Under the conditions specified in  [[dcl.init]], as part of a
 copy-initialization of an object of class type, a user-defined
 conversion can be invoked to convert an initializer expression to the
 type of the object being initialized. Overload resolution is used to
-select the user-defined conversion to be invoked. Assuming that “*cv1*
-`T`” is the type of the object being initialized, with `T` a class type,
-the candidate functions are selected as follows:
 - The converting constructors ([[class.conv.ctor]]) of `T` are
   candidate functions.
 - When the type of the initializer expression is a class type “*cv*
   `S`”, the non-explicit conversion functions of `S` and its base
   classes are considered. When initializing a temporary to be bound to
   the first parameter of a constructor that takes a reference to
   possibly cv-qualified `T` as its first argument, called with a single
-  argument in the context of direct-initialization, explicit conversion
-  functions are also considered. Those that are not hidden within `S`
-  and yield a type whose cv-unqualified version is the same type as `T`
-  or is a derived class thereof are candidate functions. Conversion
-  functions that return “reference to `X`” return lvalues or xvalues,
-  depending on the type of reference, of type `X` and are therefore
-  considered to yield `X` for this process of selecting candidate
-  functions.
 In both cases, the argument list has one argument, which is the
 initializer expression. This argument will be compared against the first
 parameter of the constructors and against the implicit object parameter
 of the conversion functions.
@@ -744,18 +767,23 @@ applying a conversion function to an initializer expression. Overload
 resolution is used to select the conversion function to be invoked.
 Assuming that “*cv1* `T`” is the underlying type of the reference being
 initialized, and “*cv* `S`” is the type of the initializer expression,
 with `S` a class type, the candidate functions are selected as follows:
-- The conversion functions of `S` and its base classes are considered,
- except that for copy-initialization, only the non-explicit conversion
- functions are considered. Those that are not hidden within `S` and
- yield type “lvalue reference to *cv2* `T2`” (when [[dcl.init.ref]]
- requires an lvalue result) or “ `T2`” or “rvalue reference to `T2`”
- (when [[dcl.init.ref]] requires an rvalue result), where “*cv1* `T`”
- is reference-compatible ([[dcl.init.ref]]) with “*cv2* `T2`”, are
-  candidate functions.
 The argument list has one argument, which is the initializer expression.
 This argument will be compared against the implicit object parameter of
 the conversion functions.
@@ -855,12 +883,29 @@ and then
   float x = a;                    // ambiguous: both possibilities require conversions,
                                   // and neither is better than the other
   ```
   or, if not that,
-- `F1` is a non-template function and `F2` is a function template
- specialization, or, if not that,
 - `F1` and `F2` are function template specializations, and the function
   template for `F1` is more specialized than the template for `F2`
   according to the partial ordering rules described in
   [[temp.func.order]].
@@ -937,20 +982,41 @@ forms:
 - a *standard conversion sequence* ([[over.ics.scs]]),
 - a *user-defined conversion sequence* ([[over.ics.user]]), or
 - an *ellipsis conversion sequence* ([[over.ics.ellipsis]]).
-However, when considering the argument of a constructor or user-defined
-conversion function that is a candidate by  [[over.match.ctor]] when
-invoked for the copying/moving of the temporary in the second step of a
-class copy-initialization, by  [[over.match.list]] when passing the
-initializer list as a single argument or when the initializer list has
-exactly one element and a conversion to some class `X` or reference to
-(possibly cv-qualified) `X` is considered for the first parameter of a
-constructor of `X`, or by  [[over.match.copy]], [[over.match.conv]], or
-[[over.match.ref]] in all cases, only standard conversion sequences and
-ellipsis conversion sequences are considered.
 For the case where the parameter type is a reference, see
 [[over.ics.ref]].
 When the parameter type is not a reference, the implicit conversion
@@ -1068,12 +1134,12 @@ conversion function template, the second standard conversion sequence
 shall have exact match rank.
 A conversion of an expression of class type to the same class type is
 given Exact Match rank, and a conversion of an expression of class type
 to a base class of that type is given Conversion rank, in spite of the
-fact that a copy/move constructor (i.e., a user-defined conversion
-function) is called for those cases.
 ##### Ellipsis conversion sequences <a id="over.ics.ellipsis">[[over.ics.ellipsis]]</a>
 An ellipsis conversion sequence occurs when an argument in a function
 call is matched with the ellipsis parameter specification of the
@@ -1131,29 +1197,27 @@ formation of implicit conversion sequences treats the `int` bit-field as
 an `int` lvalue and finds an exact match with the parameter. If the
 function is selected by overload resolution, the call will nonetheless
 be ill-formed because of the prohibition on binding a non-`const` lvalue
 reference to a bit-field ([[dcl.init.ref]]).
-The binding of a reference to an expression that is
-*reference-compatible with added qualification* influences the rank of a
-standard conversion; see  [[over.ics.rank]] and  [[dcl.init.ref]].
 ##### List-initialization sequence <a id="over.ics.list">[[over.ics.list]]</a>
 When an argument is an initializer list ([[dcl.init.list]]), it is not
 an expression and special rules apply for converting it to a parameter
 type.
-If the parameter type is `std::initializer_list<X>` or “array of
-`X`”[^12] and all the elements of the initializer list can be implicitly
-converted to `X`, the implicit conversion sequence is the worst
-conversion necessary to convert an element of the list to `X`. This
-conversion can be a user-defined conversion even in the context of a
-call to an initializer-list constructor.
 ``` cpp
 void f(std::initializer_list<int>);
 f( {1,2,3} );               // OK: f(initializer_list<int>) identity conversion
 f( {'a','b'} );             // OK: f(initializer_list<int>) integral promotion
 f( {1.0} );                 // error: narrowing
 struct A {
@@ -1169,19 +1233,27 @@ g({ "foo", "bar" });        // OK, uses #3
 typedef int IA[3];
 void h(const IA&);
 h({ 1, 2, 3 });             // OK: identity conversion
 ```
 Otherwise, if the parameter is a non-aggregate class `X` and overload
 resolution per  [[over.match.list]] chooses a single best constructor of
 `X` to perform the initialization of an object of type `X` from the
 argument initializer list, the implicit conversion sequence is a
-user-defined conversion sequence. If multiple constructors are viable
-but none is better than the others, the implicit conversion sequence is
-the ambiguous conversion sequence. User-defined conversions are allowed
-for conversion of the initializer list elements to the constructor
-parameter types except as noted in  [[over.best.ics]].
 ``` cpp
 struct A {
   A(std::initializer_list<int>);
 };
@@ -1191,11 +1263,11 @@ f( {'a', 'b'} );            // OK: f(A(std::initializer_list<int>)) user-defined
 struct B {
   B(int, double);
 };
 void g(B);
 g( {'a', 'b'} );            // OK: g(B(int,double)) user-defined conversion
-g( {1.0, 1,0} );            // error: narrowing
 void f(B);
 f( {'a', 'b'} );            // error: ambiguous f(A) or f(B)
 struct C {
@@ -1203,20 +1275,21 @@ struct C {
 };
 void h(C);
 h({"foo"});                 // OK: h(C(std::string("foo")))
 struct D {
- C(A, C);
 };
 void i(D);
 i({ {1,2}, {"bar"} });      // OK: i(D(A(std::initializer_list<int>{1,2\),C(std::string("bar"))))}
 ```
 Otherwise, if the parameter has an aggregate type which can be
 initialized from the initializer list according to the rules for
 aggregate initialization ([[dcl.init.aggr]]), the implicit conversion
-sequence is a user-defined conversion sequence.
 ``` cpp
 struct A {
   int m1;
   double m2;
@@ -1296,23 +1369,10 @@ conversion sequences unless one of the following rules applies:
     sequence is considered to be a subsequence of any non-identity
     conversion sequence) or, if not that,
   - the rank of `S1` is better than the rank of `S2`, or `S1` and `S2`
     have the same rank and are distinguishable by the rules in the
     paragraph below, or, if not that,
-  - `S1`
-    and `S2` differ only in their qualification conversion and yield
-    similar types `T1` and `T2` ([[conv.qual]]), respectively, and the
-    cv-qualification signature of type `T1` is a proper subset of the
-    cv-qualification signature of type `T2`.
-    ``` cpp
-    int f(const int *);
-    int f(int *);
-    int i;
-    int j = f(&i);                  // calls f(int*)
-    ```
-    or, if not that,
   - `S1` and `S2` are reference bindings ([[dcl.init.ref]]) and neither
     refers to an implicit object parameter of a non-static member
     function declared without a *ref-qualifier*, and `S1` binds an
     rvalue reference to an rvalue and `S2` binds an lvalue reference.
     ``` cpp
@@ -1343,15 +1403,30 @@ conversion sequences unless one of the following rules applies:
     or, if not that,
   - `S1` and `S2` are reference bindings ([[dcl.init.ref]]) and `S1`
     binds an lvalue reference to a function lvalue and `S2` binds an
     rvalue reference to a function lvalue.
     ``` cpp
- template<class T> int f(T&);
- template<class T> int f(T&&);
     void g();
-    int i1 = f(g);                  // calls f(T&)
     ```
   - `S1`
     and `S2` are reference bindings ([[dcl.init.ref]]), and the types
     to which the references refer are the same type except for top-level
     cv-qualifiers, and the type to which the reference initialized by
     `S2` refers is more cv-qualified than the type to which the
@@ -1375,33 +1450,40 @@ conversion sequences unless one of the following rules applies:
       b.f();                        // calls X::f()
     }
     ```
 - User-defined conversion sequence `U1` is a better conversion sequence
   than another user-defined conversion sequence `U2` if they contain the
-  same user-defined conversion function or constructor or aggregate
- initialization and the second standard conversion sequence of `U1` is
- better than the second standard conversion sequence of `U2`.
   ``` cpp
   struct A {
     operator short();
   } a;
   int f(int);
   int f(float);
   int i = f(a);                   // calls f(int), because short → int is
                                   // better than short → float.
   ```
 - List-initialization sequence `L1` is a better conversion sequence than
-  list-initialization sequence `L2` if `L1` converts to
-  `std::initializer_list<X>` for some `X` and `L2` does not.
 Standard conversion sequences are ordered by their ranks: an Exact Match
 is a better conversion than a Promotion, which is a better conversion
 than a Conversion. Two conversion sequences with the same rank are
 indistinguishable unless one of the following rules applies:
 - A conversion that does not convert a pointer, a pointer to member, or
   `std::nullptr_t` to `bool` is better than one that does.
 - If class `B` is derived directly or indirectly from class `A`,
   conversion of `B*` to `A*` is better than conversion of `B*` to
   `void*`, and conversion of `A*` to `void*` is better than conversion
   of `B*` to `void*`.
 - If class `B` is derived directly or indirectly from class `A` and
@@ -1415,21 +1497,21 @@ indistinguishable unless one of the following rules applies:
     C* pc;
     int f(A*);
     int f(B*);
     int i = f(pc);                  // calls f(B*)
     ```
-  - binding of an expression of type `C` to a reference of type `B&` is
-    better than binding an expression of type `C` to a reference of type
-    `A&`,
   - conversion of `A::*` to `B::*` is better than conversion of `A::*`
     to `C::*`,
   - conversion of `C` to `B` is better than conversion of `C` to `A`,
   - conversion of `B*` to `A*` is better than conversion of `C*` to
     `A*`,
-  - binding of an expression of type `B` to a reference of type `A&` is
-    better than binding an expression of type `C` to a reference of type
-    `A&`,
   - conversion of `B::*` to `C::*` is better than conversion of `A::*`
     to `C::*`, and
   - conversion of `B` to `A` is better than conversion of `C` to `A`.
   Compared conversion sequences will have different source types only in
@@ -1448,11 +1530,11 @@ functions in such contexts. The function selected is the one whose type
 is identical to the function type of the target type required in the
 context. That is, the class of which the function is a member is ignored
 when matching a pointer-to-member-function type. The target can be
 - an object or reference being initialized ([[dcl.init]],
-  [[dcl.init.ref]]),
 - the left side of an assignment ([[expr.ass]]),
 - a parameter of a function ([[expr.call]]),
 - a parameter of a user-defined operator ([[over.oper]]),
 - the return value of a function, operator function, or conversion (
   [[stmt.return]]),
@@ -1484,16 +1566,16 @@ non-static member function is selected, the reference to the overloaded
 function name is required to have the form of a pointer to member as
 described in  [[expr.unary.op]].
 If more than one function is selected, any function template
 specializations in the set are eliminated if the set also contains a
-non-template function, and any given function template specialization
-`F1` is eliminated if the set contains a second function template
-specialization whose function template is more specialized than the
-function template of `F1` according to the partial ordering rules of
-[[temp.func.order]]. After such eliminations, if any, there shall remain
-exactly one selected function.
 ``` cpp
 int f(double);
 int f(int);
 int (*pfd)(double) = &f;        // selects f(double)
@@ -1592,11 +1674,11 @@ The allocation and deallocation functions, `operator` `new`, `operator`
 completely in  [[basic.stc.dynamic]]. The attributes and restrictions
 found in the rest of this subclause do not apply to them unless
 explicitly stated in  [[basic.stc.dynamic]].
 An operator function shall either be a non-static member function or be
-a non-member function and have at least one parameter whose type is a
 class, a reference to a class, an enumeration, or a reference to an
 enumeration. It is not possible to change the precedence, grouping, or
 number of operands of operators. The meaning of the operators `=`,
 (unary) `&`, and `,` (comma), predefined for each type, can be changed
 for specific class and enumeration types by defining operator functions
@@ -1750,19 +1832,19 @@ is selected as the best match function by the overload resolution
 mechanism ([[over.match]]).
 ### Increment and decrement <a id="over.inc">[[over.inc]]</a>
 The user-defined function called `operator++` implements the prefix and
-postfix `++` operator. If this function is a member function with no
-parameters, or a non-member function with one parameter of class or
-enumeration type, it defines the prefix increment operator `++` for
-objects of that type. If the function is a member function with one
-parameter (which shall be of type `int`) or a non-member function with
-two parameters (the second of which shall be of type `int`), it defines
-the postfix increment operator `++` for objects of that type. When the
-postfix increment is called as a result of using the `++` operator, the
-`int` argument will have value zero.[^13]
 ``` cpp
 struct X {
   X&   operator++();            // prefix ++a
   X    operator++(int);         // postfix a++
@@ -1790,16 +1872,21 @@ analogously.
 ### User-defined literals <a id="over.literal">[[over.literal]]</a>
 ``` bnf
 literal-operator-id:
-    'operator' '""' identifier
 ```
-The *identifier* in a *literal-operator-id* is called a *literal suffix
-identifier*. some literal suffix identifiers are reserved for future
-standardization; see  [[usrlit.suffix]].
 A declaration whose *declarator-id* is a *literal-operator-id* shall be
 a declaration of a namespace-scope function or function template (it
 could be a friend function ([[class.friend]])), an explicit
 instantiation or specialization of a function template, or a
@@ -1822,10 +1909,13 @@ const char*, std::size_t
 const wchar_t*, std::size_t
 const char16_t*, std::size_t
 const char32_t*, std::size_t
 ```
 A *raw literal operator* is a literal operator with a single parameter
 whose type is `const char*`.
 The declaration of a literal operator template shall have an empty
 *parameter-declaration-clause* and its *template-parameter-list* shall
@@ -1845,17 +1935,20 @@ overload resolution rules. Also, they can be declared `inline` or
 called explicitly, their addresses can be taken, etc.
 ``` cpp
 void operator "" _km(long double);                  // OK
 string operator "" _i18n(const char*, std::size_t); // OK
-template <char...> int operator "" \u03C0(); // OK: UCN for lowercase pi
-float operator ""E(const char*); // error: ""E (with no intervening space)
- // is a single token
-float operator " " B(const char*);                  // error: non-adjacent quotes
 string operator "" 5X(const char*, std::size_t);    // error: invalid literal suffix identifier
 double operator "" _miles(double);                  // error: invalid parameter-declaration-clause
-template <char...> int operator "" j(const char*); // error: invalid parameter-declaration-clause
 ```
 ## Built-in operators <a id="over.built">[[over.built]]</a>
 The candidate operator functions that represent the built-in operators
@@ -1946,11 +2039,11 @@ T operator-(T);
 For every promoted integral type *T*, there exist candidate operator
 functions of the form
 ``` cpp
-T operator\sim(T);
 ```
 For every quintuple (*C1*, *C2*, *T*, *CV1*, *CV2*), where *C2* is a
 class type, *C1* is the same type as C2 or is a derived class of C2, *T*
 is an object type or a function type, and *CV1* and *CV2* are
@@ -1959,11 +2052,13 @@ form
 ``` cpp
 CV12 T& operator->*(CV1 C1*, CV2 T C2::*);
 ```
-where *CV12* is the union of *CV1* and *CV2*.
 For every pair of promoted arithmetic types *L* and *R*, there exist
 candidate operator functions of the form
 ``` cpp
@@ -1998,24 +2093,24 @@ candidate operator functions of the form
 ``` cpp
 std::ptrdiff_t   operator-(T, T);
 ```
-For every *T*, where *T* is an enumeration type, a pointer type, or
-`std::nullptr_t`, there exist candidate operator functions of the form
 ``` cpp
 bool    operator<(T, T);
 bool    operator>(T, T);
 bool    operator<=(T, T);
 bool    operator>=(T, T);
 bool    operator==(T, T);
 bool    operator!=(T, T);
 ```
-For every pointer to member type *T* there exist candidate operator
-functions of the form
 ``` cpp
 bool    operator==(T, T);
 bool    operator!=(T, T);
 ```
@@ -2152,10 +2247,11 @@ T       operator?:(bool, T, T);
 [expr]: expr.md#expr
 [expr.ass]: expr.md#expr.ass
 [expr.call]: expr.md#expr.call
 [expr.cast]: expr.md#expr.cast
 [expr.cond]: expr.md#expr.cond
 [expr.prim]: expr.md#expr.prim
 [expr.static.cast]: expr.md#expr.static.cast
 [expr.sub]: expr.md#expr.sub
 [expr.type.conv]: expr.md#expr.type.conv
 [expr.unary.op]: expr.md#expr.unary.op
@@ -2214,13 +2310,13 @@ T       operator?:(bool, T, T);
     ignored.
 [^2]: The process of argument deduction fully determines the parameter
     types of the function template specializations, i.e., the parameters
     of function template specializations contain no template parameter
-    types. Therefore the function template specializations can be
- treated as normal (non-template) functions for the remainder of
-    overload resolution.
 [^3]: Note that cv-qualifiers on the type of objects are significant in
     overload resolution for both glvalue and class prvalue objects.
 [^4]: An implied object argument must be contrived to correspond to the

 refer to one or more function templates and also to a set of overloaded
 non-template functions. In such a case, the candidate functions
 generated from each function template are combined with the set of
 non-template candidate functions.
+A defaulted move constructor or assignment operator ([[class.copy]])
+that is defined as deleted is excluded from the set of candidate
+functions in all contexts.
 #### Function call syntax <a id="over.match.call">[[over.match.call]]</a>
 In a function call ([[expr.call]])
 ``` bnf
 In addition, for each non-explicit conversion function declared in `T`
 of the form
 ``` bnf
+'operator' conversion-type-id '( )' cv-qualifier ref-qualifierₒₚₜ exception-specificationₒₚₜ attribute-specifier-seqₒₚₜ ';'
 ```
 where *cv-qualifier* is the same cv-qualification as, or a greater
 cv-qualification than, *cv*, and where *conversion-type-id* denotes the
 type “pointer to function of (`P1`,...,`Pn)` returning `R`”, or the type
 };
 String operator + (const String&, const String&);
 void f(void) {
  const char* p= "one" + "two";  // ill-formed because neither
+                                // operand has class or enumeration type
  int I = 1 + 1;                 // Always evaluates to 2 even if
+                                // class or enumeration types exist that
                                 // would perform the operation.
 }
 ```
 If either operand has a type that is a class or an enumeration, a
 type whose cv-unqualified version is `T1` and a right operand of a type
 whose cv-unqualified version is `T2`, three sets of candidate functions,
 designated *member candidates*, *non-member candidates* and *built-in
 candidates*, are constructed as follows:
+- If `T1` is a complete class type or a class currently being defined,
+ the set of member candidates is the result of the qualified lookup of
+ `T1::operator@` ([[over.call.func]]); otherwise, the set of member
+  candidates is empty.
 - The set of non-member candidates is the result of the unqualified
   lookup of `operator@` in the context of the expression according to
   the usual rules for name lookup in unqualified function calls (
   [[basic.lookup.argdep]]) except that all member functions are ignored.
   However, if no operand has a class type, only those non-member
   defined in  [[over.built]] that, compared to the given operator,
   - have the same operator name, and
   - accept the same number of operands, and
   - accept operand types to which the given operand or operands can be
     converted according to [[over.best.ics]], and
+  - do not have the same parameter-type-list as any non-member candidate
+ that is not a function template specialization.
 For the built-in assignment operators, conversions of the left operand
 are restricted as follows:
 - no temporaries are introduced to hold the left operand, and
   a + b;            // operator+(a,b) chosen over int(a) + int(b)
 }
 ```
 If a built-in candidate is selected by overload resolution, the operands
+of class type are converted to the types of the corresponding parameters
+of the selected operation function, except that the second standard
+conversion sequence of a user-defined conversion sequence (
+[[over.ics.user]]) is not applied. Then the operator is treated as the
 corresponding built-in operator and interpreted according to Clause
 [[expr]].
+``` cpp
+struct X {
+  operator double();
+};
+struct Y {
+  operator int*();
+};
+int *a = Y() + 100.0;      // error: pointer arithmetic requires integral operand
+int *b = Y() + X();        // error: pointer arithmetic requires integral operand
+```
 The second operand of operator `->` is ignored in selecting an
 `operator->` function, and is not an argument when the `operator->`
 function is called. When `operator->` returns, the operator `->` is
 applied to the value returned, with the original second operand.[^7]
 Under the conditions specified in  [[dcl.init]], as part of a
 copy-initialization of an object of class type, a user-defined
 conversion can be invoked to convert an initializer expression to the
 type of the object being initialized. Overload resolution is used to
+select the user-defined conversion to be invoked. The conversion
+performed for indirect binding to a reference to a possibly cv-qualified
+class type is determined in terms of a corresponding non-reference
+copy-initialization. Assuming that “*cv1* `T`” is the type of the object
+being initialized, with `T` a class type, the candidate functions are
+selected as follows:
 - The converting constructors ([[class.conv.ctor]]) of `T` are
   candidate functions.
 - When the type of the initializer expression is a class type “*cv*
   `S`”, the non-explicit conversion functions of `S` and its base
   classes are considered. When initializing a temporary to be bound to
   the first parameter of a constructor that takes a reference to
   possibly cv-qualified `T` as its first argument, called with a single
+  argument in the context of direct-initialization of an object of type
+ “*cv2* `T`”, explicit conversion functions are also considered. Those
+ that are not hidden within `S` and yield a type whose cv-unqualified
+ version is the same type as `T` or is a derived class thereof are
+ candidate functions. Conversion functions that return “reference to
+ `X`” return lvalues or xvalues, depending on the type of reference, of
+ type `X` and are therefore considered to yield `X` for this process of
+ selecting candidate functions.
 In both cases, the argument list has one argument, which is the
 initializer expression. This argument will be compared against the first
 parameter of the constructors and against the implicit object parameter
 of the conversion functions.
 resolution is used to select the conversion function to be invoked.
 Assuming that “*cv1* `T`” is the underlying type of the reference being
 initialized, and “*cv* `S`” is the type of the initializer expression,
 with `S` a class type, the candidate functions are selected as follows:
+- The conversion functions of `S` and its base classes are considered.
+ Those non-explicit conversion functions that are not hidden within `S`
+ and yield type “lvalue reference to *cv2* `T2`” (when initializing an
+ lvalue reference or an rvalue reference to function) or “ `T2`” or
+ “rvalue reference to `T2`” (when initializing an rvalue reference or
+ an lvalue reference to function), where “*cv1* `T`” is
+  reference-compatible ([[dcl.init.ref]]) with “*cv2* `T2`”, are
+  candidate functions. For direct-initialization, those explicit
+  conversion functions that are not hidden within `S` and yield type
+  “lvalue reference to *cv2* `T2`” or “*cv2* `T2`” or “rvalue reference
+  to *cv2* `T2`,” respectively, where `T2` is the same type as `T` or
+  can be converted to type `T` with a qualification conversion (
+  [[conv.qual]]), are also candidate functions.
 The argument list has one argument, which is the initializer expression.
 This argument will be compared against the implicit object parameter of
 the conversion functions.
   float x = a;                    // ambiguous: both possibilities require conversions,
                                   // and neither is better than the other
   ```
   or, if not that,
+- the context is an initialization by conversion function for direct
+ reference binding ([[over.match.ref]]) of a reference to function
+  type, the return type of `F1` is the same kind of reference (i.e.
+  lvalue or rvalue) as the reference being initialized, and the return
+  type of `F2` is not
+  ``` cpp
+  template <class T> struct A {
+    operator T&();        // #1
+    operator T&&();       // #2
+  };
+  typedef int Fn();
+  A<Fn> a;
+  Fn& lf = a;             // calls #1
+  Fn&& rf = a;            // calls #2
+  ```
+  or, if not that,
+- `F1` is not a function template specialization and `F2` is a function
+  template specialization, or, if not that,
 - `F1` and `F2` are function template specializations, and the function
   template for `F1` is more specialized than the template for `F2`
   according to the partial ordering rules described in
   [[temp.func.order]].
 - a *standard conversion sequence* ([[over.ics.scs]]),
 - a *user-defined conversion sequence* ([[over.ics.user]]), or
 - an *ellipsis conversion sequence* ([[over.ics.ellipsis]]).
+However, if the target is
+- the first parameter of a constructor or
+- the implicit object parameter of a user-defined conversion function
+and the constructor or user-defined conversion function is a candidate
+by
+-  [[over.match.ctor]], when the argument is the temporary in the second
+  step of a class copy-initialization,
+-  [[over.match.copy]], [[over.match.conv]], or [[over.match.ref]] (in
+  all cases), or
+- the second phase of [[over.match.list]] when the initializer list has
+  exactly one element, and the target is the first parameter of a
+  constructor of class `X`, and the conversion is to `X` or reference to
+  (possibly cv-qualified) `X`,
+user-defined conversion sequences are not considered. These rules
+prevent more than one user-defined conversion from being applied during
+overload resolution, thereby avoiding infinite recursion.
+``` cpp
+struct Y { Y(int); };
+  struct A { operator int(); };
+  Y y1 = A();  // error: A::operator int() is not a candidate
+  struct X { };
+  struct B { operator X(); };
+  B b;
+  X x({b});    // error: B::operator X() is not a candidate
+```
 For the case where the parameter type is a reference, see
 [[over.ics.ref]].
 When the parameter type is not a reference, the implicit conversion
 shall have exact match rank.
 A conversion of an expression of class type to the same class type is
 given Exact Match rank, and a conversion of an expression of class type
 to a base class of that type is given Conversion rank, in spite of the
+fact that a constructor (i.e., a user-defined conversion function) is
+called for those cases.
 ##### Ellipsis conversion sequences <a id="over.ics.ellipsis">[[over.ics.ellipsis]]</a>
 An ellipsis conversion sequence occurs when an argument in a function
 call is matched with the ellipsis parameter specification of the
 an `int` lvalue and finds an exact match with the parameter. If the
 function is selected by overload resolution, the call will nonetheless
 be ill-formed because of the prohibition on binding a non-`const` lvalue
 reference to a bit-field ([[dcl.init.ref]]).
 ##### List-initialization sequence <a id="over.ics.list">[[over.ics.list]]</a>
 When an argument is an initializer list ([[dcl.init.list]]), it is not
 an expression and special rules apply for converting it to a parameter
 type.
+If the parameter type is `std::initializer_list<X>` and all the elements
+of the initializer list can be implicitly converted to `X`, the implicit
+conversion sequence is the worst conversion necessary to convert an
+element of the list to `X`, or if the initializer list has no elements,
+the identity conversion. This conversion can be a user-defined
+conversion even in the context of a call to an initializer-list
+constructor.
 ``` cpp
 void f(std::initializer_list<int>);
+f( {} );                    // OK: f(initializer_list<int>) identity conversion
 f( {1,2,3} );               // OK: f(initializer_list<int>) identity conversion
 f( {'a','b'} );             // OK: f(initializer_list<int>) integral promotion
 f( {1.0} );                 // error: narrowing
 struct A {
 typedef int IA[3];
 void h(const IA&);
 h({ 1, 2, 3 });             // OK: identity conversion
 ```
+Otherwise, if the parameter type is “array of `N` `X`”[^12], if the
+initializer list has exactly `N` elements or if it has fewer than `N`
+elements and `X` is default-constructible, and if all the elements of
+the initializer list can be implicitly converted to `X`, the implicit
+conversion sequence is the worst conversion necessary to convert an
+element of the list to `X`.
 Otherwise, if the parameter is a non-aggregate class `X` and overload
 resolution per  [[over.match.list]] chooses a single best constructor of
 `X` to perform the initialization of an object of type `X` from the
 argument initializer list, the implicit conversion sequence is a
+user-defined conversion sequence with the second standard conversion
+sequence an identity conversion. If multiple constructors are viable but
+none is better than the others, the implicit conversion sequence is the
+ambiguous conversion sequence. User-defined conversions are allowed for
+conversion of the initializer list elements to the constructor parameter
+types except as noted in  [[over.best.ics]].
 ``` cpp
 struct A {
   A(std::initializer_list<int>);
 };
 struct B {
   B(int, double);
 };
 void g(B);
 g( {'a', 'b'} );            // OK: g(B(int,double)) user-defined conversion
+g( {1.0, 1.0} );            // error: narrowing
 void f(B);
 f( {'a', 'b'} );            // error: ambiguous f(A) or f(B)
 struct C {
 };
 void h(C);
 h({"foo"});                 // OK: h(C(std::string("foo")))
 struct D {
+ D(A, C);
 };
 void i(D);
 i({ {1,2}, {"bar"} });      // OK: i(D(A(std::initializer_list<int>{1,2\),C(std::string("bar"))))}
 ```
 Otherwise, if the parameter has an aggregate type which can be
 initialized from the initializer list according to the rules for
 aggregate initialization ([[dcl.init.aggr]]), the implicit conversion
+sequence is a user-defined conversion sequence with the second standard
+conversion sequence an identity conversion.
 ``` cpp
 struct A {
   int m1;
   double m2;
     sequence is considered to be a subsequence of any non-identity
     conversion sequence) or, if not that,
   - the rank of `S1` is better than the rank of `S2`, or `S1` and `S2`
     have the same rank and are distinguishable by the rules in the
     paragraph below, or, if not that,
   - `S1` and `S2` are reference bindings ([[dcl.init.ref]]) and neither
     refers to an implicit object parameter of a non-static member
     function declared without a *ref-qualifier*, and `S1` binds an
     rvalue reference to an rvalue and `S2` binds an lvalue reference.
     ``` cpp
     or, if not that,
   - `S1` and `S2` are reference bindings ([[dcl.init.ref]]) and `S1`
     binds an lvalue reference to a function lvalue and `S2` binds an
     rvalue reference to a function lvalue.
     ``` cpp
+    int f(void(&)());               // #1
+    int f(void(&&)());              // #2
     void g();
+    int i1 = f(g);                  // calls #1
     ```
+    or, if not that,
+  - `S1`
+    and `S2` differ only in their qualification conversion and yield
+    similar types `T1` and `T2` ([[conv.qual]]), respectively, and the
+    cv-qualification signature of type `T1` is a proper subset of the
+    cv-qualification signature of type `T2`.
+    ``` cpp
+    int f(const volatile int *);
+    int f(const int *);
+    int i;
+    int j = f(&i);                  // calls f(const int*)
+    ```
+    or, if not that,
   - `S1`
     and `S2` are reference bindings ([[dcl.init.ref]]), and the types
     to which the references refer are the same type except for top-level
     cv-qualifiers, and the type to which the reference initialized by
     `S2` refers is more cv-qualified than the type to which the
       b.f();                        // calls X::f()
     }
     ```
 - User-defined conversion sequence `U1` is a better conversion sequence
   than another user-defined conversion sequence `U2` if they contain the
+  same user-defined conversion function or constructor or they
+ initialize the same class in an aggregate initialization and in either
+ case the second standard conversion sequence of `U1` is better than
+  the second standard conversion sequence of `U2`.
   ``` cpp
   struct A {
     operator short();
   } a;
   int f(int);
   int f(float);
   int i = f(a);                   // calls f(int), because short → int is
                                   // better than short → float.
   ```
 - List-initialization sequence `L1` is a better conversion sequence than
+  list-initialization sequence `L2` if
+ - `L1` converts to `std::initializer_list<X>` for some `X` and `L2`
+    does not, or, if not that,
+  - `L1` converts to type “array of `N1` `T`”, `L2` converts to type
+    “array of `N2` `T`”, and `N1` is smaller than `N2`.
 Standard conversion sequences are ordered by their ranks: an Exact Match
 is a better conversion than a Promotion, which is a better conversion
 than a Conversion. Two conversion sequences with the same rank are
 indistinguishable unless one of the following rules applies:
 - A conversion that does not convert a pointer, a pointer to member, or
   `std::nullptr_t` to `bool` is better than one that does.
+- A conversion that promotes an enumeration whose underlying type is
+  fixed to its underlying type is better than one that promotes to the
+  promoted underlying type, if the two are different.
 - If class `B` is derived directly or indirectly from class `A`,
   conversion of `B*` to `A*` is better than conversion of `B*` to
   `void*`, and conversion of `A*` to `void*` is better than conversion
   of `B*` to `void*`.
 - If class `B` is derived directly or indirectly from class `A` and
     C* pc;
     int f(A*);
     int f(B*);
     int i = f(pc);                  // calls f(B*)
     ```
+  - binding of an expression of type `C` to a reference to type `B` is
+    better than binding an expression of type `C` to a reference to type
+    `A`,
   - conversion of `A::*` to `B::*` is better than conversion of `A::*`
     to `C::*`,
   - conversion of `C` to `B` is better than conversion of `C` to `A`,
   - conversion of `B*` to `A*` is better than conversion of `C*` to
     `A*`,
+  - binding of an expression of type `B` to a reference to type `A` is
+    better than binding an expression of type `C` to a reference to type
+    `A`,
   - conversion of `B::*` to `C::*` is better than conversion of `A::*`
     to `C::*`, and
   - conversion of `B` to `A` is better than conversion of `C` to `A`.
   Compared conversion sequences will have different source types only in
 is identical to the function type of the target type required in the
 context. That is, the class of which the function is a member is ignored
 when matching a pointer-to-member-function type. The target can be
 - an object or reference being initialized ([[dcl.init]],
+  [[dcl.init.ref]], [[dcl.init.list]]),
 - the left side of an assignment ([[expr.ass]]),
 - a parameter of a function ([[expr.call]]),
 - a parameter of a user-defined operator ([[over.oper]]),
 - the return value of a function, operator function, or conversion (
   [[stmt.return]]),
 function name is required to have the form of a pointer to member as
 described in  [[expr.unary.op]].
 If more than one function is selected, any function template
 specializations in the set are eliminated if the set also contains a
+function that is not a function template specialization, and any given
+function template specialization `F1` is eliminated if the set contains
+a second function template specialization whose function template is
+more specialized than the function template of `F1` according to the
+partial ordering rules of  [[temp.func.order]]. After such eliminations,
+if any, there shall remain exactly one selected function.
 ``` cpp
 int f(double);
 int f(int);
 int (*pfd)(double) = &f;        // selects f(double)
 completely in  [[basic.stc.dynamic]]. The attributes and restrictions
 found in the rest of this subclause do not apply to them unless
 explicitly stated in  [[basic.stc.dynamic]].
 An operator function shall either be a non-static member function or be
+a non-member function that has at least one parameter whose type is a
 class, a reference to a class, an enumeration, or a reference to an
 enumeration. It is not possible to change the precedence, grouping, or
 number of operands of operators. The meaning of the operators `=`,
 (unary) `&`, and `,` (comma), predefined for each type, can be changed
 for specific class and enumeration types by defining operator functions
 mechanism ([[over.match]]).
 ### Increment and decrement <a id="over.inc">[[over.inc]]</a>
 The user-defined function called `operator++` implements the prefix and
+postfix `++` operator. If this function is a non-static member function
+with no parameters, or a non-member function with one parameter, it
+defines the prefix increment operator `++` for objects of that type. If
+the function is a non-static member function with one parameter (which
+shall be of type `int`) or a non-member function with two parameters
+(the second of which shall be of type `int`), it defines the postfix
+increment operator `++` for objects of that type. When the postfix
+increment is called as a result of using the `++` operator, the `int`
+argument will have value zero.[^13]
 ``` cpp
 struct X {
   X&   operator++();            // prefix ++a
   X    operator++(int);         // postfix a++
 ### User-defined literals <a id="over.literal">[[over.literal]]</a>
 ``` bnf
 literal-operator-id:
+    'operator' string-literal identifier
+    'operator' user-defined-string-literal
 ```
+The *string-literal* or *user-defined-string-literal* in a
+*literal-operator-id* shall have no *encoding-prefix* and shall contain
+no characters other than the implicit terminating `'\0'`. The
+*ud-suffix* of the *user-defined-string-literal* or the *identifier* in
+a *literal-operator-id* is called a *literal suffix identifier*. some
+literal suffix identifiers are reserved for future standardization; see
+[[usrlit.suffix]].
 A declaration whose *declarator-id* is a *literal-operator-id* shall be
 a declaration of a namespace-scope function or function template (it
 could be a friend function ([[class.friend]])), an explicit
 instantiation or specialization of a function template, or a
 const wchar_t*, std::size_t
 const char16_t*, std::size_t
 const char32_t*, std::size_t
 ```
+If a parameter has a default argument ([[dcl.fct.default]]), the
+program is ill-formed.
 A *raw literal operator* is a literal operator with a single parameter
 whose type is `const char*`.
 The declaration of a literal operator template shall have an empty
 *parameter-declaration-clause* and its *template-parameter-list* shall
 called explicitly, their addresses can be taken, etc.
 ``` cpp
 void operator "" _km(long double);                  // OK
 string operator "" _i18n(const char*, std::size_t); // OK
+template <char...> double operator "" _\u03C0(); // OK: UCN for lowercase pi
+float operator ""_e(const char*); // OK
+float operator ""E(const char*);                    // error: reserved literal suffix~([usrlit.suffix], [lex.ext])
+double operator""_Bq(long double);                  // OK: does not use the reserved name _Bq~([global.names])
+double operator"" _Bq(long double);                 // uses the reserved name _Bq~([global.names])
+float operator " " B(const char*);                  // error: non-empty string-literal
 string operator "" 5X(const char*, std::size_t);    // error: invalid literal suffix identifier
 double operator "" _miles(double);                  // error: invalid parameter-declaration-clause
+template <char...> int operator "" _j(const char*); // error: invalid parameter-declaration-clause
+extern "C" void operator "" _m(long double);        // error: C language linkage
 ```
 ## Built-in operators <a id="over.built">[[over.built]]</a>
 The candidate operator functions that represent the built-in operators
 For every promoted integral type *T*, there exist candidate operator
 functions of the form
 ``` cpp
+T operator~(T);
 ```
 For every quintuple (*C1*, *C2*, *T*, *CV1*, *CV2*), where *C2* is a
 class type, *C1* is the same type as C2 or is a derived class of C2, *T*
 is an object type or a function type, and *CV1* and *CV2* are
 ``` cpp
 CV12 T& operator->*(CV1 C1*, CV2 T C2::*);
 ```
+where *CV12* is the union of *CV1* and *CV2*. The return type is shown
+for exposition only; see  [[expr.mptr.oper]] for the determination of
+the operator’s result type.
 For every pair of promoted arithmetic types *L* and *R*, there exist
 candidate operator functions of the form
 ``` cpp
 ``` cpp
 std::ptrdiff_t   operator-(T, T);
 ```
+For every *T*, where *T* is an enumeration type or a pointer type, there
+exist candidate operator functions of the form
 ``` cpp
 bool    operator<(T, T);
 bool    operator>(T, T);
 bool    operator<=(T, T);
 bool    operator>=(T, T);
 bool    operator==(T, T);
 bool    operator!=(T, T);
 ```
+For every pointer to member type *T* or type `std::nullptr_t` there
+exist candidate operator functions of the form
 ``` cpp
 bool    operator==(T, T);
 bool    operator!=(T, T);
 ```
 [expr]: expr.md#expr
 [expr.ass]: expr.md#expr.ass
 [expr.call]: expr.md#expr.call
 [expr.cast]: expr.md#expr.cast
 [expr.cond]: expr.md#expr.cond
+[expr.mptr.oper]: expr.md#expr.mptr.oper
 [expr.prim]: expr.md#expr.prim
 [expr.static.cast]: expr.md#expr.static.cast
 [expr.sub]: expr.md#expr.sub
 [expr.type.conv]: expr.md#expr.type.conv
 [expr.unary.op]: expr.md#expr.unary.op
     ignored.
 [^2]: The process of argument deduction fully determines the parameter
     types of the function template specializations, i.e., the parameters
     of function template specializations contain no template parameter
+    types. Therefore, except where specified otherwise, function
+ template specializations and non-template functions ([[dcl.fct]])
+ are treated equivalently for the remainder of overload resolution.
 [^3]: Note that cv-qualifiers on the type of objects are significant in
     overload resolution for both glvalue and class prvalue objects.
 [^4]: An implied object argument must be contrived to correspond to the

Diff to HTML by rtfpessoa