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

Dissolve [over.oper] #3957

Open
jensmaurer opened this issue Apr 25, 2020 · 1 comment
Open

Dissolve [over.oper] #3957

jensmaurer opened this issue Apr 25, 2020 · 1 comment
Labels
decision-required A decision of the editorial group (or the Project Editor) is required.

Comments

@jensmaurer
Copy link
Member

jensmaurer commented Apr 25, 2020 •
edited

The subclause on operator overloading should be integrated into the sections where it belongs.

Restrictions on declaring operator functions (e.g. no default arguments) should be moved to [dcl.fct], where other restrictions on function declarations are located. We might want to split up [dcl.fct] into "function types", "function declarations", "operator functions" or so.

The actual expression rewrite (where e.g. @ cast_expression is turned into a call to cast-expression.operator@) should go into [expr.compound], near the description of the actual operator syntax. Some additional grouping might be advisable for a compact representation. For example, [expr.mul] through [expr.log.or] should be grouped under "Binary expressions".

[over.built] should also go under [expr].

This makes [expr] a lot more self-contained and clearly attaches the grammar presentation there to the complete semantics, in lieu of the hand-wavy note in [expr.pre] p2 pointing to [over.oper]. Currently, you match the grammar in [expr.compound], then do overload resolution as explained in [over.oper] (without pervasive cross-references), then you jump back to [expr.compound] for the built-in meaning, hitting seemingly out-of-place gems such as [expr.sub] p4 "A braced-init-list shall not be used with the built-in subscript operator."
@jensmaurer jensmaurer added the decision-required A decision of the editorial group (or the Project Editor) is required. label Apr 25, 2020
@xmh0511 xmh0511 mentioned this issue Apr 20, 2022
Closed
@xmh0511
Copy link
Contributor

xmh0511 commented Apr 20, 2022 •
edited

Moreover, the invocation of the function call operator in the function call syntax. Currently, we only have the note [expr.pre] p2 to reference to [over.oper], where the subclause [over.call] references to [over.call.object], however, we explicitly restrict what the types of the postfix-expressions are in [expr.call] p1. It is only reasonable that the transformation of the invocation of the function call operator should occur prior to we fall into [expr.call] p1, which means we should have formal rules to refer to [over.oper] for the case whose grammar is covered by [expr] but the expression's type is class or enumeration, smoothly introducing that the grammar should firstly undergo [over.oper] and the transformation takes place, then back to [expr.compound].

@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
decision-required A decision of the editorial group (or the Project Editor) is required.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@xmh0511 @jensmaurer