This is an unofficial snapshot of the ISO/IEC JTC1 SC22 WG21 Core Issues List revision 115d. See http://www.open-std.org/jtc1/sc22/wg21/ for the official list.
2024-10-26
[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.
Suggested resolution [SUPERSEDED]:
Replace the entirety of 7.7 [expr.const] paragraph 6 with the following:
For the purposes of determining whether an expressionEis a core constant expression, the evaluation ofa call tothe 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 expressionis ignored. Similarly, the evaluation ofa call tothe 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 ofis considered to include only the underlying constructorcall 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>.
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.
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 ofa call tothe 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 expressionis ignored. Similarly, the evaluation ofa call tothe 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 ofis considered to include only the underlying constructorcall disqualifies E from being a core constant expressioncall 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.