Full name of submitter (unless configured in github; will be published with the issue): Jiang An
Reference (section label): [expr.const]
Link to reflector thread (if any):
Issue description:
Currently, [expr.const] p14 says:
For the purposes of determining whether an expression E is a core constant expression, the evaluation of the body of a member function of std::allocator<T> as defined in [allocator.members], where T is a literal type, is ignored.
It seems that when T is not a literal type, there is (or can be?) constant evaluation failure, as the function bodies that generally call non-constexpr ::operator new/::operator delete are not ignored.
However, implementations consistently accept the following example (Godbolt link) despite that std::locale is not a literal type.
#include <locale>
#include <memory>
static_assert([]{
auto a = std::allocator<std::locale>{};
a.deallocate(a.allocate(42), 42);
return true;
}());
It's possibly more reasonable not to require literal-ness here as no non-constexpr function call is made.
Suggested resolution:
Modify [expr.const] as indicated:
- For the purposes of determining whether an expression E is a core constant expression, the evaluation of the body of a member function of
std::allocator<T> as defined in [allocator.members], where T is a literal type, is ignored.
[...]
Full name of submitter (unless configured in github; will be published with the issue): Jiang An
Reference (section label): [expr.const]
Link to reflector thread (if any):
Issue description:
Currently, [expr.const] p14 says:
It seems that when
Tis not a literal type, there is (or can be?) constant evaluation failure, as the function bodies that generally call non-constexpr::operator new/::operator deleteare not ignored.However, implementations consistently accept the following example (Godbolt link) despite that
std::localeis not a literal type.It's possibly more reasonable not to require literal-ness here as no non-constexpr function call is made.
Suggested resolution:
Modify [expr.const] as indicated: