Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[over.match.oper] p2 It seems that p2 omits the function call operator #5401

Closed
xmh0511 opened this issue Apr 20, 2022 · 4 comments
Closed

[over.match.oper] p2 It seems that p2 omits the function call operator #5401

xmh0511 opened this issue Apr 20, 2022 · 4 comments

Comments

@xmh0511
Copy link
Contributor

xmh0511 commented Apr 20, 2022 •
edited

[over.oper.general] p11 says

Operators not mentioned explicitly in subclauses [over.ass] through [over.inc] act as ordinary unary and binary operators obeying the rules of [over.unary] or [over.binary].

() has its own subclause [over.call], thus it is not intended to be covered by [over.binary]. In Table 17, it lists all operators mentioned in [over.unary] through [over.inc] except that () in [over.call]. It is reasonable that Table 17 should also cover [over.call] , since it says

If either operand has a type that is a class or an enumeration, a user-defined operator function can be declared that implements this operator or a user-defined conversion can be necessary to convert the operand to a type that is appropriate for a built-in operator. In this case, overload resolution is used to determine which operator function or built-in operator is to be invoked to implement the operator.

struct C{ void operator()(...);};
C c;
c(1,2,3);

The above example is exactly the case where the operand has a class type. Furthermore, [expr.pre] p3 says

If a built-in operator is selected, such conversions will be applied to the operands before the operation is considered further according to the rules in subclause [expr.compound]; see [over.match.oper], [over.built].

void fun(int){}
struct A{
   using T = void(*)(int);
   operator T(){
         return fun;
   };
};
A a;
a(0);  // #1

The conversion should be applied before we fall into [expr.call] p1:

The postfix expression shall have function type or function pointer type.

So, when we check [over.match.oper], we would seek the () function call operator in the subclause.
@jensmaurer
Copy link
Member

The function call syntax is not handled by [over.match.oper]; it is not considered an "operator" in that sense. Instead, it is covered by [over.call.object]. The lack of () in table 17 clearly makes that subsection inapplicable for operator().

@xmh0511
Copy link
Contributor Author

xmh0511 commented Apr 20, 2022 •
edited

@jensmaurer If [over.match.oper] does not intend to cover (), how to interpret [expr.pre] p3? Moreover, we agree () is an operator that can be overloaded in [over.oper]. How to introduce [over.call.object] when we check [expression]?

What I want to say is we just have a note [expr.pre] p2 to reference to [over.oper] that covers subclause [over.call].

For example:

{
    S{}(1,2,3);
}

when this expression-statement is used, it interpret S{}(1,2,3) as the expression that reference to [expr.comma], which will ultimately lead to [expr.call], what we expect is that S{}(1,2,3) can be transformed to S{}.operator()(1,2,3) or S{}.operator convertion-type-id()(1,2,3), which is the final syntax that obeys the rules defined in [expr.call]. In other words, we should smoothly lead to [over.oper] prior to any analysing defined in [expr].

@xmh0511
Copy link
Contributor Author

xmh0511 commented Apr 20, 2022

Incidentally, [over.match.call.general] says

In a function call

  • postfix-expression ( expression-listopt)

if the postfix-expression names at least one function or function template, overload resolution is applied as specified in [over.call.func]. If the postfix-expression denotes an object of class type, overload resolution is applied as specified in [over.call.object].

However, we have restricted that the postfix-expression in a function call shall

The postfix expression shall have function type or function pointer type.

So, whether the transformation(transform the postfix-expression to a function call) or [expr.call] go first?

@xmh0511
Copy link
Contributor Author

xmh0511 commented Apr 20, 2022

@jensmaurer This #3957 precisely exposes what I am concerned about here.

@xmh0511 xmh0511 mentioned this issue May 19, 2022
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@xmh0511 @jensmaurer