为何std::basic_string_view仅支持const指针？可编辑视图需求探讨

根据说明，std::basic_string_view描述的对象可引用一段常量连续类char对象序列，序列首元素位于0位置。不过有人会想，如果这个类模板支持非const char指针会很实用，比如可借助标准算法写入空终止字节字符串。例如，假设存在一个拥有char*的std::editable_string_view，可编写如下代码：

void filler(char *str, std::size_t len, char c) {
    std::editable_string_view sv(str, len);
    std::fill(sv.begin(), sv.end(), c);
}

那么，std::basic_string_view仅支持const指针是否存在特定原因？

这个问题问到点子上了——std::basic_string_view只读的设计背后其实是标准库的一系列考量，咱们来逐一拆解：

• 核心定位：只读的非拥有式视图
  basic_string_view从诞生起的核心目标就是提供一个轻量、只读、不拥有数据的字符串引用工具。它的存在是为了避免不必要的字符串拷贝（比如在函数间传递长字符串时，用view代替拷贝），同时明确告诉使用者：你只能观察这段数据，不能修改它。如果需要可修改的视图，那是另一种不同职责的工具，应该单独设计（比如你假设的editable_string_view），这样能避免接口语义混淆。

• 从根源避免未定义行为
  如果允许basic_string_view持有非const指针，很容易出现危险的场景：比如用它去引用一个字符串字面量（const char* s = "hello";），然后通过view尝试修改内容。但字符串字面量是存储在只读内存中的，修改它属于未定义行为（可能导致程序崩溃、数据损坏等）。只读的设计直接从接口层面杜绝了这种风险，让编译器就能帮你拦截这类错误。

• 保持接口简洁与标准库一致性
  如果同时支持const和非const，basic_string_view的接口会变得臃肿：需要额外提供非const版本的迭代器、operator[]、data()等成员函数，增加了学习和使用成本。而坚持只读的单一职责，让它的接口更简洁直观。另外，这也和标准库中其他视图类（比如std::span<const T>）的设计逻辑保持一致，符合标准库“单一职责、语义清晰”的设计哲学。

• 已有现成的可修改替代方案
  其实你想要的可修改连续字符视图，标准库已经提供了完美的解决方案——std::span<char>。它既支持非const元素类型，也能像basic_string_view一样轻量地引用一段连续内存，完全可以实现你例子中的需求：

  void filler(char *str, std::size_t len, char c) {
      std::span<char> sv(str, len);
      std::fill(sv.begin(), sv.end(), c);
  }
  

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