cplusplus / cplusplus/draft

[intro.execution] p3 Is an operand applied with (built-in)conversions not a subexpression of an operation E?

Open
#5,425 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

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

Description

[intro.execution] p3 says

The immediate subexpressions of an expression E are

  • the constituent expressions of E's operands ([expr.prop]),
  • any function call that E implicitly invokes,
  • if E is a lambda-expression ([expr.prim.lambda]), the initialization of the entities captured by copy and the constituent expressions of the initializer of the init-captures,
  • if E is a function call or implicitly invokes a function, the constituent expressions of each default argument ([dcl.fct.default]) used in the call, or
  • if E creates an aggregate object ([dcl.init.aggr]), the constituent expressions of each default member initializer ([class.mem]) used in the initialization.

A subexpression of an expression E is an immediate subexpression of E or a subexpression of an immediate subexpression of E.

Consider this example:

int a = 0, b = 1;
a+b;  // #1

[basic.lval] p6 says

Whenever a glvalue appears as an operand of an operator that expects a prvalue for that operand, the lvalue-to-rvalue, array-to-pointer, or function-to-pointer standard conversions are applied to convert the expression to a prvalue.

So, any of the operands at #1 is the prvalue rather than a or b. According to the first bullet, such two prvalues are the operands. The constituent expression of the prvalue is itself. That means a and b are not subexpressions of the expression at #1. However, if the conversion is a user-defined conversion, the associated function call is a subexpression, as per the second bullet.

Moreover, this can introduce a doubt, when we say

the full-expression of its initialization is a constant expression when interpreted as a constant-expression

What can be subexpressions of the constant-expression when built-in conversion applies?

const int v = 0;
constexpr int i = v;

The initialization should be the prvalue that results from applying lvalue-to-rvalue conversion to v, In analogy to above, v is not a subexpression in that constant-expression.

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 reading [intro.execution] p3 and [basic.lval] p6, then trace the issue's a+b and constexpr int i = v examples. Determine how built-in conversions affect operand and subexpression terminology, and clarify the standard wording so the treatment of constant expressions is unambiguous.

Written by the indexing model from the issue text.

Assessment

Tech stack
cpp
Domain
compilers
Issue type
Bug
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.