Date: 2019-02-15.00:00:00

Proposed resolution (February, 2019):

Change 6.3 [basic.def.odr] paragraph 2 as follows:

An expression is potentially evaluated unless it is an unevaluated operand (7.2 [expr.prop]) or a subexpression thereof. The set of potential results of an expression e is defined as follows:

• ...

• If e is a class member access expression (7.6.1.5 [expr.ref]) of the form e1 . template _opt e2 naming a non-static data member, the set contains the potential results of the object expression e1 .

• if e is a class member access expression naming a static data member, the set contains the id-expression designating the data member.

• If e is a pointer-to-member expression (7.6.4 [expr.mptr.oper]) whose second operand is a constant expression of the form e1 .* e2 , the set contains the potential results of the object expression e1 .

• ...

Date: 2018-04-15.00:00:00

Notes from the April, 2018 teleconference:

CWG agreed with the suggested direction to make the member a potential result in cases like the example.

Date: 2019-02-15.00:00:00

[Accepted as a DR at the February, 2019 meeting.]

According to 6.3 [basic.def.odr] bullet 2.3, the potential results of a member access expression are simply the object expression. This rule incorrectly handles an example like:

  struct X {
    static const int n = 0;
  };
  X x = {};
  int b = x.n;

Because X::n is not one of the potential results, the expression x.n odr-uses X::n , requiring it to be defined.