cplusplus / cplusplus/draft

[expr.type], [expr.call] Draw connection between type adjustment paragraphs

Open
#7,063 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

P3-Other
Dominant language
TeX
Stars
221
Forks
813
Avg merge
16h 4m
Merged PRs (30d)
36

Description

We have the general rule [expr.type] p1:

If an expression initially has the type “reference to T” ([dcl.ref], [dcl.init.ref]), the type is adjusted to T prior to any further analysis.
The expression designates the object or function denoted by the reference, and the expression is an lvalue or an xvalue, depending on the expression.

For function calls, there is the more concrete rule [expr.call] p13:

A function call is an lvalue if the result type is an lvalue reference type or an rvalue reference to function type, an xvalue if the result type is an rvalue reference to object type, and a prvalue otherwise.

I feel like we should connect these paragraphs in some way. The main reason why we need [expr.type] p1 is for function calls anyway. I'm not sure if it even serves any purpose or is completely covered by more concrete rules.

In any case, we could leave some note such as

+ For the type adjustment rules from the return type of a function
+ to the result type of function call expressions, see [expr.call].

If it turns out that [expr.type] p1 is covered by other rules, we could consider turning it into a note or deleting it. The current wording strategy is to always state what type and value category an expression has, so I cannot think of any non-defective wording where [expr.type] p1 would apply.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by comparing [expr.type] p1 with [expr.call] p13 and tracing how the draft describes function-call result types and value categories. Determine whether [expr.type] p1 is redundant or should point readers to [expr.call]. Done means the relationship is resolved in the wording, with an appropriate note, revision, or deletion.

Written by the indexing model from the issue text.

Assessment

Tech stack
cpp
Domain
documentation
Issue type
Documentation
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
30/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.