为什么使用 `declval<U&>().~U()` 而不是 `declval().~U()` 定义 `is_destructible`？答案

【问题标题】：Why is `is_destructible` defined using `declval<U&>().~U()` and not `declval().~U()`?为什么使用 `declval<U&>().~U()` 而不是 `declval().~U()` 定义 `is_destructible`？
【发布时间】：2019-02-14 21:44:10
【问题描述】：

根据is_destructible (http://eel.is/c++draft/meta.unary.prop#lib:is_destructible) 的定义，is_destructible_v<T> 是true 当：

T 是一个引用类型，或者T 是一个完整的对象类型，表达式declval<U&>().~U() 在被视为未计算的操作数时是格式正确的，其中U 是remove_all_extents_t<T>。

为什么它使用declval<U&>().~U()而不是declval().~U()？

https://cplusplus.github.io/LWG/issue2049 中添加了declval 的措辞，以解决定义与抽象类型有关的问题。也许作者认为declval 有返回类型U 所以它不适用于抽象类型？

【问题讨论】：

在这一点上，看起来唯一的选择就是问问 Daniel Krugler :)
一个引用可以限定析构函数吗？ ~U()&& {stuff}?
@MooingDuck no.

标签： c++ language-lawyer typetraits

【解决方案1】：

所以我通过电子邮件询问了 Daniel Krügler，他允许我发表他的回答：

好问题 - 尽管答案相当琐碎且没有揭示任何语言秘密：我知道std::declval<T>() 会返回在所讨论的上下文中是一个右值引用（因此是一个右值），但是在我的心理想象中，我想表达翻译p->~T()，再次根据语言对应到(*p).~T() ([expr.ref])，所以逻辑上的结果是改变 std::declval() 调用以生成左值 T 其中析构函数被应用到。

我很确定我不相信 declval() 正在返回直接T，这个辅助功能在我脑海里烙印太深了;-)

【讨论】：