On Sun, Jun 2, 2019 at 1:00 PM Zoe Carver via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> Before submitting a proposal for the following type traits, I wanted to
> get the communities opinion. What are your thoughts on adding the following
> to the standard library?
>
>
> 1. is_deletable: if the expression "delete decltype<T>()" is well-formed, provides
> the member constant value equal to true. Otherwise, value is false.
>
>
> 2. is_array_deletable: if the expression "delete[] decltype<T>()" is
> well-formed, provides the member constant value equal to true. Otherwise,
> value is false.
>
>
> This should be a small feature with little-no impact. I have a sample
> implementation if that would be helpful.
>

Those names do look like the right names for that particular facility. But
why do you want to add them to the standard library?
I mean, the standard library doesn't have is_negatable<T>, or
is_bitwise_negatable<T>, or has_sizeof<T>, or any of the other unary
operators that I can think of. So why should `delete` be special-cased?

I would also caution that your proposal would make `is_deletable_v<int*>`
invariably true, even though not all `int*` values are in fact deletable.
Deletability is a dynamic, runtime, property of a pointer value. This isn't
a killer, but it does suggest that maybe you've got an XY problem
<http://xyproblem.info> here. A new type-trait may not be the right tool
for whatever underlying job you've actually got.

Do you have examples of
(A) generic-programming contexts where an `is_deletable` facility would
have a beneficial effect?
(B) examples of real-world code where `is_deletable_v<T> && not
is_array_deletable_v<T>`, or vice versa?
(C) examples of real-world code where `is_deletable_v<T> && not
is_object_pointer_v<T>`, or vice versa?

–Arthur