为何std::string与std::string_view未重载operator+？

当我们想要拼接std::string与std::string_view时，标准库并没有提供如下形式的全局operator+重载：

// 省略模板参数
std::basic_string operator+(const std::basic_string& lhs, const StringViewLike& rhs);
std::basic_string operator+(const StringViewLike& lhs, const std::basic_string& rhs);

这直接导致现有写法必须额外构造临时std::string，带来不必要的性能损耗，比如：

std::string make_phrase(std::string_view say, std::string_view to) {
  return std::string(say) + std::string(to);
}

这段代码会先为to构造临时std::string并拷贝视图指向的数据，再将临时对象的内容追加到std::string(say)的结果中，最后销毁临时对象，整个过程存在完全多余的拷贝操作。

虽然std::basic_string的成员函数operator+=提供了对应的string_view重载：

basic_string& operator+=(const StringViewLike& t);

可以通过return std::string(say) += to;避免拷贝，但这种写法的可读性远不如直观的operator+拼接。

标准库不提供这些重载，核心原因有三点：

1. 避免重载歧义
   如果添加std::basic_string与StringViewLike的operator+，会和现有重载产生潜在冲突。比如传递字符串字面量时，const char*和std::string_view版本的重载都能匹配，编译器无法确定调用哪个版本，直接导致编译错误。

2. ADL（依赖参数查找）的冲突风险
   std::string_view可以指向任意字符序列，包括用户自定义的字符类型或字符串类型。全局operator+接受StringViewLike参数时，可能触发意外的ADL查找，引入用户自定义的重载，破坏标准库行为的一致性。

3. 历史兼容与优先级权衡
   std::string_view是C++17才引入的特性，而std::string的operator+重载体系早已成型。添加新重载需要严格保证对现有代码的兼容性，同时标准委员会需要权衡特性收益与潜在风险——毕竟通过operator+=或手动构造的方式已经能实现需求，只是写法不够优雅，优先级远低于其他关键特性。

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