为何std::expected的operator==不具备SFINAE友好性？

这确实是个值得深究的标准库设计细节，我来帮你理清楚背后的逻辑~

你观察到的现象完全符合C++标准的规定：std::expected::operator==并没有采用SFINAE的方式在类型不可比较时退出重载决议，而是直接规定这种情况下**程序是格式错误（ill-formed）**的。你用std::equality_comparable做的断言在不同编译器/标准库上表现不一，也正是源于这个设计差异带来的实现细节区别。

至于为什么不做SFINAE友好，主要有这几个核心原因：

• 语义明确性优先：std::expected的相等比较本质上依赖内部T和U类型的相等可比性——两个expected对象相等，要么都包含值且值相等，要么都包含错误且错误相等。如果T或U本身不能做相等比较，那这个操作从逻辑上就是不合理的。直接触发硬错误，能更早、更明确地提醒开发者修正类型设计，而不是通过SFINAE悄悄跳过重载，留下难以排查的隐式问题。
• 简化实现与维护：如果要让operator==支持SFINAE，需要在函数签名中添加复杂的约束，同时检查T和U的equality_comparable概念。这种复杂的约束会增加标准库实现的负担，也会让函数签名变得晦涩。相比之下，直接规定硬错误的实现成本更低，语义也更直白。
• 避免重载歧义风险：SFINAE虽然灵活，但有时会导致重载解析出现意外匹配。比如如果某个不可比较的类型恰好有其他全局或类内的operator==重载，SFINAE排除std::expected的版本后，可能会匹配到这些不期望的重载，反而增加调试难度。硬错误则能直接阻断这种情况，让开发者明确知道“这个比较操作本身就是非法的”。

再回到你给出的代码示例：

#include <concepts>
#include <expected>

struct A {};

static_assert(!std::equality_comparable<std::expected<A, A>>);

这个断言在不同标准库上的表现差异，本质是各实现对std::equality_comparable的检查逻辑不同：比如libc++可能会提前检查内部的A是否满足equality_comparable，从而判定std::expected<A,A>不满足概念；而MSVC STL可能直接尝试实例化operator==，触发了标准规定的硬错误。

备注：内容来源于stack exchange，提问作者HolyBlackCat