Movatterモバイル変換

[Moved to DR at the February, 2014 meeting.]

Proposed resolution (January, 2014):

Change 12.2.2.3 [over.match.oper] paragraph 7 as follows:

If a built-in candidate is selected by overload resolution,the operandsof class type are converted to thetypes of the corresponding parameters of the selectedoperation function, except that the second standardconversion sequence of a user-defined conversion sequence(12.2.4.2.3 [over.ics.user]) is notapplied. Then the operator is treated as thecorresponding built-in operator and interpreted according toClause 7 [expr].[Example:

  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

—end example]

Consider an example like:

  struct Y {    operator int*();  };  extern int *p;  int *a = p + 100.0;   // #1  int *b = Y() + 100.0; // #2

#1 is ill-formed because it violates the requirement of7.6.6 [expr.add] that the non-pointer operand have integralor enumeration type. It appears that #2 is well-formed, however,because 12.2.2.3 [over.match.oper] paragraph 7 says,

If a built-in candidate is selected by overload resolution, the operandsare converted to the types of the corresponding parameters of the selectedoperation function. Then the operator is treated as the correspondingbuilt-in operator and interpreted according toClause 7 [expr].

In this case, the selected operation function is

  int *operator+(int *, std::ptrdiff_t)

100.0 is thus converted tostd::ptrdiff_t beforereaching 7.6.6 [expr.add].

This problem could be addressed by restricting the conversion tothe class or enumeration operand rather than both operands.