cplusplus / CWG

Core Working Group
24 stars 7 forks source link

[class.mfct.non.static] The transformation to `id-expression` by adding `this` shouldn't apply to explicit parameter object non-static member function #334

Closed xmh0511 closed 1 year ago

xmh0511 commented 1 year ago

Full name of submitter (unless configured in github; will be published with the issue): Jim X

[class.mfct.non.static] says

When an id-expression ([expr.prim.id]) that is neither part of a class member access syntax ([expr.ref]) nor the unparenthesized operand of the unary & operator ([expr.unary.op]) is used where the current class is X ([expr.prim.this]), if name lookup ([basic.lookup]) resolves the name in the id-expression to a non-static non-type member of some class C, ..., the id-expression is transformed into a class member access expression ([expr.ref]) using (*this) as the postfix-expression to the left of the . operator.

The wording does not exclude the transformation for the explicit object member function of the current class.

[expr.prim.this] p3 says

It shall not appear within the declaration of either a static member function or an explicit object member function of the current class (although its type and value category are defined within such member functions as they are within an implicit object member function).

So, the transformation in the explicit object member function does not make sense.

Suggested Resolution

When an id-expression ([expr.prim.id]) that is neither part of a class member access syntax ([expr.ref]) nor the unparenthesized operand of the unary & operator ([expr.unary.op]) is used where the current class is X ([expr.prim.this]), if name lookup ([basic.lookup]) resolves the name in the id-expression to a non-static non-type member of some class C, ..., the id-expression is transformed into a class member access expression ([expr.ref]) using (*this) as the postfix-expression to the left of the . operator if the id-expression appears in a non-static member function that is an implicit object member function.

It does not clear whether we intend to give a similar transformation by using an id-expression that denotes the explicit object parameter to take the place of *this when the id-expression that denotes non-static member appears in the explicit object parameter member functions.

struct C{
   int a;
   void fun(this C& self){
        a = 0; // is this transformed to self.a = 0;?
   }
};
jensmaurer commented 1 year ago

[class.mfct.non.static] applies the transformation to both explicit object member functions and static member functions, intentionally so. Then, [expr.prim.this] p3 makes the so-transformed "this" ill-formed in the two mentioned contexts. Which is exactly what we want.

There is no intention to perform an implicit transformation for explicit object member functions. Did you find any wording to the contrary?

In short, I'm not seeing an issue here.

xmh0511 commented 1 year ago

Oh, you're right. The intent is that any id-expression that refers to a non-static member and is not qualified with object expression cannot appear in explicit object parameter member function or static member function, which would make the transformation cause ill-formed.