Skip to content

Dissolve [over.oper] #3957

Open
Open

Description

@jensmaurer

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."

Activity

  1. added
    decision-requiredA decision of the editorial group (or the Project Editor) is required.
    on Apr 25, 2020
  2. xmh0511 commented on Apr 20, 2022

    @xmh0511
    Contributor

    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].

  3. tkoeppe commented on Jun 16, 2025

    @tkoeppe
    Contributor

    Editorial meeting decision: We are interested in this change, but it needs a few things to line up:

    • We need Core oversight, so CWG needs to have enough breathing room for this.
    • This needs some form of reviewable write-up; ideally a paper, at least with a relatively specific plan and outline. So we also need a volunteer to draft this.
    • Since the text is generally in flux, the actual finalization and application would probably have to happen rather quickly.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    decision-requiredA decision of the editorial group (or the Project Editor) is required.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions