Title
Allocation in core constant expressions
Status
c++23
Section
7.7 [expr.const]
Submitter
Davis Herring

Created on 2019-08-28.00:00:00 last changed 16 months ago

Messages

Date: 2022-11-10.20:32:58

Proposed resolution (approved by CWG 2022-11-10):

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

For the purposes of determining whether an expression E is a core constant expression, the evaluation of a call to the body of a member function of std::allocator<T> as defined in 20.2.10.2 [allocator.members], where T is a literal type, does not disqualify E from being a core constant expression, even if the actual evaluation of such a call would otherwise fail the requirements for a core constant expression is ignored. Similarly, the evaluation of a call to the body of std::construct_at or std::ranges::construct_at (27.11.8 [specialized.construct]) does not disqualify E from being a core constant expression unless the first argument, of type T*, does not point to storage allocated with std::allocator<T> or to an object whose lifetime began within the evaluation of E, or the evaluation of is considered to include only the underlying constructor call disqualifies E from being a core constant expression call if the first argument (of type T*) points to storage allocated with std::allocator<T> or to an object whose lifetime began within the evaluation of E.
Date: 2022-11-10.20:32:58

CWG telecon 2022-10-21:

The references to destroy_at were removed in an unrelated update to the Working Draft. Also, restore the reference to local objects whose lifetime began within E.

Date: 2022-10-30.06:43:13

Suggested resolution [SUPERSEDED]:

Replace the entirety of 7.7 [expr.const] paragraph 6 with the following:

For the purposes of determining whether an expression E is a core constant expression, the evaluation of a call to the body of a member function of std::allocator<T> as defined in 20.2.10.2 [allocator.members], where T is a literal type, does not disqualify E from being a core constant expression, even if the actual evaluation of such a call would otherwise fail the requirements for a core constant expression is ignored. Similarly, the evaluation of a call to the body of std::destroy_at, std::ranges::destroy_at, std::construct_at, or std::ranges::construct_at (27.11.8 [specialized.construct]) does not disqualify E from being a core constant expression unless the first argument, of type T*, does not point to storage allocated with std::allocator<T> or to an object whose lifetime began within the evaluation of E, or the evaluation of is considered to include only the underlying constructor call disqualifies E from being a core constant expression (for the functions construct_at) or destructor (for the functions destroy_at) call if the first argument (of type T*) points to storage allocated with std::allocator<T>.
Date: 2022-11-15.00:00:00

[Accepted as a DR at the November, 2022 meeting.]

7.7 [expr.const] paragraph 5 attempts to describe allowable allocation/deallocation calls in terms of what could be called “core constant subexpressions,” but the actual definition of a core constant expression in paragraph 4 is in terms of evaluation.

History
Date User Action Args
2023-07-16 13:00:43adminsetstatus: open -> c++23
2023-07-16 13:00:43adminsetstatus: drwp -> open
2023-02-18 18:43:04adminsetstatus: dr -> drwp
2022-11-25 05:14:04adminsetstatus: ready -> dr
2022-11-10 22:06:59adminsetstatus: review -> ready
2022-11-10 22:06:59adminsetstatus: review -> review
2022-11-10 22:06:59adminsetstatus: review -> review
2022-11-10 22:06:59adminsetstatus: review -> review
2022-11-10 20:32:58adminsetmessages: + msg7017
2022-11-10 20:32:58adminsetmessages: + msg6998
2022-10-30 06:43:13adminsetstatus: ready -> review
2022-10-30 06:43:13adminsetstatus: ready -> ready
2022-10-30 06:43:13adminsetstatus: ready -> ready
2022-10-30 06:43:13adminsetstatus: open -> ready
2022-02-18 07:47:23adminsetmessages: + msg6718
2019-08-28 00:00:00admincreate