is_constructible 和 is_destructible 不受友元声明的影响

Clang 和 GCC 似乎不尊重friend评估时的声明std::is_constructible and std::is_destructible.

关于“is_constructible”，cppreference.com 说： http://en.cppreference.com/w/cpp/types/is_constructible

访问检查就像从与 T 和 Args 中的任何类型无关的上下文中执行一样。仅考虑变量定义的直接上下文的有效性。

（该网站没有解释如何is_destructible处理访问检查，但处理访问修饰符do影响行为is_destructible一般来说，所以我希望它的工作方式与is_constructible.)

因此，在我看来这段代码应该not编译，因为在直接上下文检查构造函数和析构函数are可用，如局部变量实例化所示：

class Private
{
    Private() {}
    ~Private() {}

    friend class Friend;
};

class Friend
{
    public:
        Friend()
        {
            // Both of these should fire, but they do not.
            static_assert(
                !std::is_constructible<Private>::value,
                "the constructor is public");
            static_assert(
                !std::is_destructible<Private>::value,
                "the destructor is public");
            // There is no error here.
            Private p;
        }
};

...but Coliru 编译没有错误 http://coliru.stacked-crooked.com/a/54c1a1d0b19d2d86（使用 GCC 或 Clang）。

这是一个错误（或者至少是一个不符合项）吗？both编译器，还是 cppreference.com 歪曲了标准，或者我误解了 cppreference.com 的声明？

这正是

访问检查的执行就像是从与以下内容无关的上下文中执行的：T和 中的任何类型Args.

说。 “的朋友T” 根据定义，并非“与T".

“直接上下文” https://stackoverflow.com/q/15260685/1858225是一个艺术术语，但无论如何，该句子谈论的是假设变量定义的直接上下文，而不是使用is_constructible.

这将是疯狂的is_constructible检查上下文相关；这意味着相同的类型，is_constructible<T, Args...>，在不同的上下文中有不同的基类。