[libcxx-commits] [PATCH] D68364: Implement C++20's P0784 (More constexpr containers)

Richard Smith - zygoloid via Phabricator via libcxx-commits libcxx-commits at lists.llvm.org
Mon Sep 28 17:35:04 PDT 2020


rsmith added a comment.

In D68364#2299336 <https://reviews.llvm.org/D68364#2299336>, @ldionne wrote:

> In D68364#2294569 <https://reviews.llvm.org/D68364#2294569>, @jwakely wrote:
>
>> I don't think your implementation is valid. I think P0784 only allows new-expressions and calls to `std::allocator::allocate` in constexpr functions, not calls to `operator new`.
>
> Hmm, right. It's actually impossible to implement `__libcpp_allocate` in a constexpr-friendly manner, since it's just allocating bytes.

Right, we need to rely on implementation magic. I wrote up a document proposing how to do this <https://docs.google.com/document/d/1vTtCyAhSlu4ui5-wgMNLO-JzJCMIw86tNj882RDRUnI/edit> a year or so ago, and shared it with some GCC folks (I don't remember whether it was mailed to the GCC mailing list or just to Jason or what) suggesting that we follow option 3 of that doc -- in particular, this permits calls to `operator new` "//transitively// within a member of `std::allocator<T>`" (emphasis mine), precisely so that stdlib implementations can pull out helper functions as libc++ does, and don't need to branch on `is_constant_evaluated()` for this at all. That said, this is all vendor extension territory, and GCC is of course under no obligation to follow my proposal, and indeed seems not to have followed this detail of it. So be it.

But... there's no question of "valid" here :)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D68364/new/

https://reviews.llvm.org/D68364



More information about the libcxx-commits mailing list