[libcxx-commits] [PATCH] D55840: P0722R3: Implement library support for destroying delete

Sat Feb 2 14:26:41 PST 2019

EricWF added inline comments.

================
Comment at: include/new:167
+#if defined(__cpp_impl_destroying_delete) && __cpp_impl_destroying_delete >= 201806L
+#define __cpp_lib_destroying_delete 201806L
+
----------------
Please use the `generate_feature_test_macro_components.py` script to handle defining and testing the feature test macros.

================
Comment at: include/new:169
+
+struct destroying_delete_t {
+  explicit destroying_delete_t() = default;
----------------
mclow.lists wrote:
> ckennelly wrote:
> > ldionne wrote:
> > > Please guard with > C++17. We should not enable features in older standards unless we have a compelling reason to.
> > If there's compiler support (we're checking _impl), would it be reasonable to provide it with C++17 as well?
> Not reasonable, no.
> I did this one, for something that I thought was a slam-dunk (`string_view` in pre-c++17) and it has been nothing but a series of small annoyances.
> 
This is a separate question from `std::string_view`. This is a core-language feature that needs library support. The compiler decides whether this feature is on or off.

Like aligned allocation and sized delete, the library should provide `destroying_delete_t` whenever the compiler defines its language feature test macro. Otherwise, Clang can't do its job. This approach allows users to opt-into important new language features as an extension, or to opt-out of them when availability is a concern (this is particularly important for allocation/deallocation functions).

We should enable the typedef when either `_LIBCPP_STD_VER > 17` or `defined(__cpp_impl_destroying_delete)`. The latter macro signify that Clang needs us to provide the type because *clang* has chosen to provide this language feature as an extension.

Repository:
  rCXX libc++

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

https://reviews.llvm.org/D55840