关于std::is_assignable处理抽象类时的编译器行为差异及正确实现方式的技术问询

一、抽象类场景下std::is_assignable的正确行为 #

先给出核心结论：Clang的行为完全符合C++标准，GCC的实现存在偏差。

我们结合标准定义拆解原因：std::is_assignable<T, U>的判定逻辑是，表达式std::declval<T>() = std::declval<U>()作为未求值操作数时是否良构（即能通过编译语法/语义检查）。

针对你的抽象类Abstr：

1. 编译器会为它隐式声明拷贝赋值操作符，签名为Abstr& operator=(const Abstr&)——注意这个隐式声明的操作符没有引用限定符（ref-qualifier），这意味着它既可以被左值调用，也可以被右值调用。
2. std::declval<Abstr>()返回的是Abstr&&（右值），而C++允许右值绑定到const Abstr&类型的参数，因此赋值操作符的参数可以正常匹配。
3. 综上，std::declval<Abstr>() = std::declval<Abstr>()这个表达式是完全良构的，std::is_assignable<Abstr, Abstr>::value理应返回true。

GCC判定为false的原因，大概率是错误地将“抽象类无法实例化”纳入了判定逻辑——但标准明确要求is_assignable只关注表达式的合法性，不关注是否能实际执行（毕竟是未求值操作数）。

而你用C++20 Concept自定义的is_assignable_concept，直接用requires表达式检查了核心表达式的良构性，完全贴合标准定义，因此两款编译器都能正确返回true。

二、为什么标准库不用Concept实现类型特性？ #

这个问题主要有几个关键原因：

• 历史兼容性：绝大多数标准类型特性（比如std::is_assignable）是C11引入的，而Concept是C20才新增的特性。标准库需要保持对C11/C14/C17的向后兼容，不可能用C20特性去实现更早版本就存在的组件。
• 语义精确性：标准对每个类型特性的语义都有极其细致的规定，传统SFINAE实现可以精准匹配这些细节。虽然Concept的requires表达式看起来更简洁，但在部分边缘场景下，它的行为可能和标准规定的类型特性语义存在细微差异——标准库需要严格遵循既定语义，不能轻易替换实现方式。
• 职责划分：Concept的设计初衷是作为模板参数的约束，而类型特性的职责是编译时布尔查询。两者在标准库中各司其职，混用会模糊设计边界，不利于代码的可读性和维护性。
• 实现稳定性：基于SFINAE的类型特性实现已经经过多年验证和优化，在各编译器上表现稳定。换成Concept实现需要重新适配所有编译器，还要确保和旧版本行为完全一致，成本高且收益有限。

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