构造函数使用std::is_constructible引发的矛盾SFINAE问题解析

这段代码的矛盾来自SFINAE与std::is_constructible之间的循环依赖，具体逻辑如下：

1. 实际构造成功的原因：
   当执行S s1{1}或S s2{i}时，编译器推导模板构造函数的T为int（或int&），随后检查std::enable_if_t<!std::is_constructible_v<S, T>>的条件。此时std::is_constructible_v<S, T>的求值陷入循环：要判断S能否从T构造，必须先确定这个模板构造函数是否启用；而模板构造函数的启用条件又依赖is_constructible的结果。
   编译器处理这种循环时，会将std::is_constructible_v<S, T>视为false，因此!false为真，模板构造函数被启用，构造得以成功。

2. static_assert失败的原因：
   当直接查询std::is_constructible_v<S, int>时，标准规定编译器需要检查是否存在有效的构造路径。此时模板构造函数的SFINAE条件依赖is_constructible自身，导致该构造函数因SFINAE被排除在候选列表之外——因为无法在不依赖结果的前提下确定条件是否满足。没有其他可用构造函数，所以is_constructible_v<S, int>返回false，触发断言失败。

简单说：实际构造时编译器“妥协”让模板构造函数生效，但is_constructible的规范要求它必须排除这种循环依赖的候选函数，因此结果矛盾。

你的实现确实是一种不破坏std::is_constructible的SFINAE方案，核心原因是循环依赖被限制在自定义的isConstructible_v中，而标准库的std::is_constructible未被卷入：

1. 自定义isConstructible_v的循环处理：
   当模板构造函数检查!isConstructible_v<S, T>时，自定义traits会尝试判断S(std::declval<T>())是否有效。这又会触发对模板构造函数的启用检查，形成循环。编译器同样会将isConstructible_v<S, T>视为false，因此模板构造函数被启用。

2. std::is_constructible_v<S, int>正常工作的原因：
   标准库的is_constructible实现不依赖你的自定义traits，它检查S能否从int构造时，模板构造函数的SFINAE条件（!isConstructible_v<S, int>）此时已经确定为!false = true，因此该构造函数是有效的候选函数。std::is_constructible能正确识别到这一点，返回true，所以断言通过。

这种方案的本质是用一个“牺牲”的自定义traits承担循环依赖，让标准库traits保持正常工作。

你想要的效果是：当已有其他构造函数（比如默认构造、或匹配度更高的非模板构造函数）时，模板构造函数自动禁用。你的自定义traits方案可以实现这个需求：

假设给S添加一个非模板构造函数：

struct S
{
    S(const int&) {} // 非模板构造函数
    template<typename T, typename = std::enable_if_t<!isConstructible_v<S, T>>>
    S(T&&){}
};

此时isConstructible_v<S, int>会返回true（因为存在S(const int&)），因此模板构造函数的SFINAE条件不满足，会被禁用。当传入int或int&时，编译器会选择非模板构造函数；只有当传入的类型无法通过现有构造函数构造时，模板构造函数才会被启用。

这种方式完美避开了标准库traits的循环依赖问题，同时实现了你想要的优先级控制。

内容的提问来源于stack exchange，提问作者Meatboy 106