为什么`is_constructible<function<int(int)>, int(*)(int,int)>::value`在VC2015RC下为真答案

【问题标题】：Why `is_constructible<function<int(int)>, int(*)(int,int)>::value` is true under VC2015RC为什么`is_constructible<function<int(int)>, int(*)(int,int)>::value`在VC2015RC下为真
【发布时间】：2015-05-28 06:31:52
【问题描述】：

#include <functional>
using namespace std;

int main()
{
   static_assert(is_constructible<function<int(int)>, int(*)(int,int)>::value, "error");
}

代码不使用 GCC 和 Clang 编译，但使用 Visual C++ 2015 RC 传递。

这是符合标准的行为还是只是一个错误？

【问题讨论】：

标签： c++ c++11 visual-c++ typetraits std-function

【解决方案1】：

std::function 的构造函数曾经接受过阳光下的一切（它是一个template<class F> function(F f)）。

然后它在标准中受到限制（LWG issue 2132），但实现该限制需要表达式 SFINAE，即Microsoft's compiler doesn't yet support。

【讨论】：

Geeee...另一个表达式 SFINAE 问题。但我仍然有一个问题，从 C++ 标准的角度来看，这种行为是否正确？还是在C++11有效，在C++14无效？
@Windoze 在已发布的 C++11 标准下，传递给定签名不可调用的内容会破坏 Requires 子句，即 UB，因此任何答案都是正确的.在 C++14 中，is_constructible 应该是 false。
是在使用类型实例化时已经 UB 还是仅在实际评估构造函数调用时才 UB？
@JohannesSchaub-litb 我认为实例化就足够了。 [res.on.functions]/2，项目符号 2.3。
@windoze 我认为std::result_of 在 2015 年（甚至 2013 年）都有效，并且对 sfinae 友好（如果不是表达式 sfinae），所以表达式 sfinae 在这里甚至不是借口。