Title
Partially initialized variables during constant initialization
Status
open
Section
7.7 [expr.const]
Submitter
Barry Revzin

Created on 2022-02-21.00:00:00 last changed 4 months ago

Messages

Date: 2022-03-15.00:00:00

Alternative suggested resolution (March, 2022):

Change in 7.7 [expr.const] paragraph 11 as follows:

A constant expression is either a glvalue core constant expression that refers to an entity that is a permitted result of a constant expression (as defined below), or a prvalue core constant expression whose value satisfies the following constraints:
  • if the value is an object of class type, each non-static data member of reference type refers to an entity that is a permitted result of a constant expression,
  • if the value is of pointer type, it contains the address of an object with static storage duration, the address past the end of such an object (7.6.6 [expr.add]), the address of a non-immediate function, or a null pointer value,
  • if the value is of pointer-to-member-function type, it does not designate an immediate function, and
  • if the value is an object of class or array type, each subobject is initialized (11.9.3 [class.base.init]) and satisfies these constraints for the value.
Date: 2022-02-18.07:47:23

Suggested resolution:

Change in 7.7 [expr.const] paragraph 2:
A variable or temporary object o is constant-initialized if
  • either it has an initializer or its default-initialization results in some initialization being performed, and
  • every non-variant non-static data member and base class subobject is initialized (11.9.3 [class.base.init]), and
  • the full-expression of its initialization is a constant expression when interpreted as a constant-expression, except that if o is an object, that full-expression may also invoke constexpr constructors for o and its subobjects even if those objects are of non-literal class types.
Date: 2022-03-29.18:46:44

Consider:

  struct A { int x = 1; int y; };
  constinit A a;                   // static storage duration; #1

The treatment of this example changed with P1331R2 (Permitting trivial default initialization in constexpr contexts), adopted 2019-07. Prior to this paper, the default constructor of A was not constexpr because it left a data member uninitialized. With paper P1331, the restriction was shifted to reading uninitialized objects during constant evaluation, and the variable a now satisfies the requirements for "constant-initialized" in 7.7 [expr.const] paragraph 2:

A variable or temporary object o is constant-initialized if
  • either it has an initializer or its default-initialization results in some initialization being performed, and
  • the full-expression of its initialization is a constant expression when interpreted as a constant-expression, except that if o is an object, that full-expression may also invoke constexpr constructors for o and its subobjects even if those objects are of non-literal class types.

Zero-initialization is not performed prior to constant-initialization per 6.9.3.2 [basic.start.static] paragraph 2:

Constant initialization is performed if a variable or temporary object with static or thread storage duration is constant-initialized (7.7 [expr.const]). If constant initialization is not performed, a variable with static storage duration (6.7.5.2 [basic.stc.static]) or thread storage duration (6.7.5.3 [basic.stc.thread]) is zero-initialized (9.4 [dcl.init]). Together, zero-initialization and constant initialization are called static initialization; all other initialization is dynamic initialization.

Thus, #1 is valid and a is statically initialized, but a.y would remain uninitialized, which is surprising for an object with static storage duration.

Current implementations diagnose an error at #1, because the variable a is actually not considered to be constant-initialized.

This issue is closely related to issue 2558.

History
Date User Action Args
2022-02-21 00:00:00admincreate
2022-02-18 07:47:23adminsetmessages: + msg6740
2022-02-18 07:47:23adminsetmessages: + msg6739