[over.match.funcs.general] p5 user-defined conversions sequence are not considered for object parameter CWG2557

[xmh0511]

[over.match.funcs.general] p5 says

The implicit object parameter, however, retains its identity since no user-defined conversions can be applied to achieve a type match with it.

It sounds like a note. The implicit conversion sequence only considered whether converting an argument to the type of the parameter can form an implicit conversion sequence. So, "retains its identity" is not matter with the reason why user-defined conversions cannot be applied. Consider this example:

struct A{
   void show(){}
   static void fun(){}
};
struct B{
    using type = A;
    operator A(){
      return A{};
    }
};
B bobj;
bobj.type::show();  // non-static member function  // #1
bobj.type::fun();  // static member function  #2

Even though [class.mfct.non.static] p2 says

If a non-static member function of a class X is called for an object that is not of type X, or of a type derived from X, the behavior is undefined.

However, it restricts nothing on the conversion sequence that converts the implicit object argument to the type of the object parameter.

It is even worse the status quo is not clear for a static member function. [over.match.funcs.general] p4 says

For static member functions, the implicit object parameter is considered to match any object (since if the function is selected, the object is discarded).

which bullet can interpret why #2 is ill-formed? neither [basic.lookup], [expr.ref], nor [over.match.funcs.general]

I think we should have a formal rule in a similar manner as [over.best.ics.general] p4, in that subclause, it is a reasonable place to talk about conversion sequence.

Such as

User-defined conversion sequences are not considered if the target is the (implicit) object parameter of a member function

[over.match.funcs.general] p5 can refer to the added rule. In addition, the original [over.match.funcs.general] p5 does not cover explicit object parameter, does it mean user-defined conversion sequence can be considered for it?

For the static member case at #2, I haven't found a corresponding rule that can interpret the ill-formed.

[jensmaurer]

I think the example has nothing to do with user-defined conversions or functions. We'd also expect an ill-formed error if bobj.type::show were a (static or non-static) data member. Note that A and B don't derive from each other.

Thus, the right place to look for a restriction is [expr.ref].

[jensmaurer]

struct A {
  static int x;
};

struct B {
  using type = A;
};

int y = B().type::x;

@opensdh, I'm not seeing anything that would make this example ill-formed. I think [expr.ref] should contain a check before the if-ladder on the kind of E2.

[xmh0511]

Thus, the right place to look for a restriction is [expr.ref].

Yes, that could be a more general way instead of concerning only member functions. If we would have that restriction, is it necessary to remain the sentence(user-defined conversion...) in [over.match.funcs.general] p5?

[jensmaurer]

Yes, I think that's still necessary for cases roughly similar to this:

struct B {
  void operator+(int) const;
};

struct D : B { };

void operator+(const D&, long);

int main()
{
  D() + 0;
}

[xmh0511]

However, [over.match.oper] p2 will reinterpret the expression to a function call, which depends on what kind of the function is.

For non-member function, it is operator+(D(),0). Instead, for member function, the expression will be reinterpretd to D().operator+(0), D().operator+(0) is till governed by [expr.ref] and only member functions can have a implicit object parameter.

[xmh0511]

There is also another concern: Are user-defined conversion sequences permitted for an explicit object parameter? This is even not mentioned by [over.match.funcs.general] p5 that only talks about implicit object parameter.

[languagelawyer]

I think the restriction for the non-static case has been mentioned a couple of times in other issues, it is https://eel.is/c++draft/expr.prim.id.general#3
Yes, it is not perfect, but replacing «can» with «shall» and «in which the object expression refers to the member's class» with «in which the object expression is of the member's class … type» feels almost editorial.

For the static members case, I'd say it is implementations' bug. It would be natural to extrapolate CWG315 decision from «we don't care about the result of the object expression» to «also, we don't care about its type» if the RHS of [expr.ref] names a static member.

[languagelawyer]

Plus there is https://eel.is/c++draft/class.access.base#6

[jensmaurer]

CWG2557

[xmh0511]

@languagelawyer [expr.prim.id.general] p3 and [class.access.base] p6 are well applied to non-static member. I wanted to use the code at #1 to expose some issues about "user-defined conversion sequence", however, it is a wrong way according to the aforemtioned rules.

[xmh0511]

@jensmaurer If "user-defined conversion sequence restriction" is necessary for implicit object parameter, could we place it in [over.best.ics] and replace it with constructive wording? BTW, how about the explicit object parameter?

[jensmaurer]

I think the explicit object parameter wants all conversions it can get; please double-check the paper that introduced it.

Regarding the move to [over.best.ics]: Yes, we probably could do that. I'm not seeing that high on the priority list, given that it works as currently specified (even though it's not pretty).

[opensdh]

@opensdh, I'm not seeing anything that would make this example ill-formed. I think [expr.ref] should contain a check before the if-ladder on the kind of E2.

Before P1787R6 it did contain

The id-expression shall name a member of the class or of one of its base classes.

but that doesn't work anymore because of using E::e;, so we need a more subtle rule.

[jensmaurer]

@opensdh, I see. I think "E2 shall denote a member of the type of E1." in [expr.ref] will fix it, and will sidestep any using E::e. See CWG2557.