CWG3110 [expr.const] Should literal-ness of the element type invalidate constexpr allocation?

[frederick-vs-ja]

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:

14. 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.
    [...]

[jensmaurer]

CWG3110