为无operator>的类添加该运算符的代码合法性及编译器差异问询

代码合法性分析 #

这段代码的核心逻辑是通过std::experimental::is_detected检测类是否已定义operator>，若未定义则生成一个基于operator<的默认实现。但它存在递归检测的逻辑悖论：当检测gt_t<T>（即T是否有operator>）时，编译器会将我们定义的模板operator>纳入重载候选，而该模板的启用条件又依赖于!is_detected<gt_t, T>::value——这就形成了循环依赖：判断是否启用模板需要先知道is_detected的结果，而is_detected的计算又需要判断模板是否可行。

从C++标准层面看，这种递归的模板参数替换行为没有明确规定，属于编译器对SFINAE（替换失败不是错误）规则的细节实现差异。标准仅要求替换过程中出现无效类型/表达式时排除模板，但未明确如何处理循环依赖的替换场景。因此，这段代码的行为是编译器相关的，无法保证在所有符合标准的编译器中正常工作。

不过GCC 8.1+、Clang 5.0+等编译器通过优化模板替换逻辑，能够识别这种递归检测的循环，终止无效的递归替换，判定模板在当前检测场景下不可行，从而让is_detected<gt_t, T>返回false，最终启用我们的模板生成operator>。这种处理符合SFINAE的核心精神，因此在这些编译器中代码可正常运行，但并非严格意义上的“标准合法”，而是依赖编译器实现细节。

GCC版本差异的原因 #

GCC 7.5及更早版本的模板元编程模块未处理这种递归替换的循环场景：计算is_detected<gt_t, A>时，编译器会无限递归地尝试实例化模板operator>的启用条件，无法识别循环依赖，最终触发“递归实例化过深”的编译错误。

GCC 8.1对模板替换逻辑做了关键改进：新增递归模板依赖检测机制，当发现替换过程中出现循环引用时，终止当前替换流程，将该模板标记为“不可行”，避免无限递归。这一优化让编译器能正确处理检测逻辑，最终成功编译代码。

补充说明 #

虽然新编译器能正常处理，但这种实现依赖编译器特定优化，可移植性较差。更稳健的实现是直接检测类是否存在operator<，再生成对应的operator>，从根源上避免递归检测问题。

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