C++20中std::rel_ops::operators被弃用的原因是什么？

嘿，这个问题问到点子上了！C20把std::rel_ops这套自动生成比较运算符的工具彻底弃用，核心原因是它已经跟不上现代C的设计理念，而且有更优的替代方案，具体来说有这几点：

• 隐式重载容易引发意外问题
  std::rel_ops的逻辑是：只要你的类型定义了operator==和operator<，它就会在全局模板里自动生成!=、>、<=、>=这四个运算符。但这种"自动生效"的特性很危险——比如当你后来给类手动添加了自己的operator!=时，编译器可能会在你写的版本和std::rel_ops生成的版本之间出现重载歧义，或者在你完全没意识到的情况下调用了自动生成的版本，导致不符合预期的行为。

• 现代C++有更强大、更安全的替代方案
  C20引入的**三路比较运算符<=>**直接把std::rel_ops拍在了沙滩上！只要你给类型定义了<=>，编译器会自动帮你生成全部六个比较运算符，而且还能通过返回不同的比较类别（比如std::strong_ordering、std::weak_ordering）来精确控制比较的语义，完全不需要依赖std::rel_ops这种简陋的自动生成逻辑。就算不用<=>，C11之后的模板元编程也能让我们写出更可控的比较运算符重载，没必要再用这个老工具。

• 全局模板带来的命名空间污染
  要让std::rel_ops生效，你通常得写using namespace std::rel_ops;，这就很容易把这些全局模板引入到当前命名空间里，导致其他不相关的类型也被意外应用这些重载，引发莫名其妙的编译错误。这完全不符合现代C++强调的显式性和最小作用域原则——我们希望每个类型的比较行为是明确、可控的，而不是靠全局模板偷偷生成。

• 灵活性和可定制性严重不足
  std::rel_ops的生成逻辑是硬编码死的：只能基于==和<来推导其他运算符。但有些类型的比较逻辑可能完全不是这样——比如有的类型更适合基于>来构建其他比较，或者需要特殊的不等判断逻辑，std::rel_ops根本没法满足这种定制需求，而三路比较运算符则能灵活应对各种场景。

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