为何无法拼接两个std::string_view？是否属同类提案范畴？

问题背景 #

在代码中使用std::string_view存储配置类字符串，利用其只读视图、无拷贝的特性提升效率，但遇到无法直接拼接两个std::string_view的问题——标准库未定义operator+运算符。已知std::string与std::string_view的拼接被认为是标准疏漏且已有提案，结果应为std::string，那两个std::string_view的拼接是否也属于这类情况？若不属于，原因是什么？

示例代码 #

std::string_view s1{"concate"};
std::string_view s2{"nate"};
std::string_view s3{s1 + s2};

报错信息 #

error: no match for 'operator+' (operand types are 'std::string_view' {aka 'std::basic_string_view<char>'} and 'std::string_view' {aka 'std::basic_string_view<char>'})

核心解答 #

两个std::string_view的拼接并不属于标准疏漏，标准库不支持直接拼接的原因主要有两点：

• 设计定位的本质差异
  std::string_view的核心是只读视图，本身不持有内存，仅指向已有字符序列的指针和长度。而拼接操作必然需要创建新的字符序列并存储结果，这和string_view“无拷贝、仅视图”的设计初衷冲突——拼接结果不可能是另一个string_view（没有现成内存块容纳拼接后的内容），只能是std::string。
  如果为string_view定义operator+，返回值只能是std::string，但这会误导使用者：以为拼接是轻量的视图操作，实际却触发了内存分配和拷贝，违背string_view高效无拷贝的设计预期。

• 避免语义歧义与隐性开销
  标准库刻意避免这种“看似轻量实则有开销”的操作。若允许s1 + s2（两个string_view）返回std::string，容易让开发者忽略背后的内存分配，误用在性能敏感场景中。相比之下，显式调用std::string(s1) + s2或std::string(s1).append(s2)，能更清晰地表达“需要分配内存存储拼接结果”的意图。

  而std::string与std::string_view的拼接被视为疏漏，是因为std::string本身是持有内存的字符串类型，拼接string_view到string上符合其语义，且这类操作需求普遍，标准库早期未支持属于设计遗漏，因此才有补全提案。

可行的拼接方式 #

若需拼接两个std::string_view，可显式创建std::string完成：

std::string_view s1{"concate"};
std::string_view s2{"nate"};
// 方式1：分步拼接
std::string s3{s1};
s3 += s2;
// 方式2：一行完成
std::string s4 = std::string(s1) + s2;

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