C++ and adding new string types. Name a more iconic duo.

The framing most people will miss: this isn't "yet another string type." It's filling in the last cell of a 2x2 matrix that's existed since C++11:

The interesting design tension is in section 6.5. The paper chose eager size() calculation at construction. For a type whose primary purpose is C interop - where you're eventually calling c_str() and passing it to open() or sqlite3_open() or whatever - that means you're paying for a strlen you might not need. The paper argues this enables hardened preconditions and bounds-checking, which is the C++ answer, not the C answer.

The real value isn't in the API surface. c_str() and data() return the same pointer. The value is entirely in the type system: if your function takes a cstring_view, the compiler guarantees the caller provided something null-terminated. That's it. That's the whole paper. Everything else is implementation details.

The part that will generate the most heat: remove_suffix is = delete with a reason string. Which is correct - you can't chop the end off a null-terminated string without invalidating the guarantee. But I can already hear the complaints.

Edit: I should add - the csv literal suffix is going to be a problem. Every programmer on earth reads csv as "comma-separated values." They went with it to parallel sv for string_view, but the collision is real.

csv literal suffix? I got excited for a second thinking we finally got CSV parsing in the standard.

Then I remembered what committee I was dealing with.

Embedded developer here. Section 6.5 is where this paper loses me.

The whole pitch is: "your function takes a C string, use cstring_view instead of const char* to get bounds safety." Great. But the type eagerly computes size() via strlen in the const char* constructor. For us that's a non-trivial cost - we're passing paths to open() and config keys to C libraries, and we already know they're null-terminated string literals. We don't need the length. The C API doesn't need the length. Nobody needs the length.

The paper acknowledges this in 6.5 and says "users that really cannot afford that are still able to use const char*." Which is honest, but also means the type doesn't solve the problem for the people who have the problem the most.

I'll probably still use it where it matters, but the O(1)-from-literal constructor that skips the strlen would have been nice.

Rust solved this years ago with CStr and CString. One is borrowed, one is owned. Clean, simple, no embedded NUL ambiguity because CStr rejects them. Meanwhile C++ is on its third attempt at a null-terminated string view and still can't decide on the name.

Some context that might help people who weren't following in 2019:

P1402 proposed this exact type at Kona and was killed with "CONSENSUS: We will not pursue P1402R0 or this problem space." That was six years ago.

What changed:

• The Reflection paper (P2996) has APIs that return string_view but then specify that data()[size()] == '\0'. They literally needed the type and didn't have it.
• Herb's safety profiles paper (P3081) independently called out that a null-terminated view was one of the most commonly requested GSL features without a std:: equivalent.
• NVIDIA built their own (P3710), discovered the same design decisions independently, and merged into this paper.
• GitHub usage grew from ~1.9k to ~2.1k implementations. People are writing this type themselves and getting it wrong.

The committee killed it in 2019 because contracts were supposed to solve the problem. Contracts didn't ship. The problem is still there. This is the pragmatic fix.

The naming debate (cstring_view vs zstring_view) got polled in Sofia and hit no-consensus (8/6/13/4/2). The paper went with cstring_view anyway in R3, which is going to come up again.

For people who don't read papers, here's the concrete problem this solves:

// Today: bug-prone
void open_file(std::string_view path) {
    int fd = open(path.data(), O_RDONLY);
    // BUG if path came from substr()
}

// Today: works but allocates
void open_file(std::string_view path) {
    std::string owned(path);
    int fd = open(owned.c_str(), O_RDONLY);
}

// With cstring_view: safe and zero-copy
void open_file(std::cstring_view path) {
    int fd = open(path.c_str(), O_RDONLY);
    // guaranteed null-terminated
}

The first version is the bug the paper is trying to prevent. The second version works but allocates for no reason when the caller already had a null-terminated string. The third version is what you actually want.

I've found this exact bug pattern in production three times this year. The paper's GitHub examples aren't cherry-picked - this is everywhere.

Can we please get networking into the standard before we add yet another string type? I've been waiting since C++11 and at this rate my grandchildren will be the ones writing std::net::tcp::socket.

I teach intro C++ at a university. My students already struggle with when to use std::string vs const char* vs std::string_view. Now I need to add cstring_view to the decision tree.

That said - if it means I can stop explaining why string_view::data() isn't safe to pass to printf, I'll take the complexity tradeoff. The number of students who write printf("%s", sv.data()) where sv came from substr() is... non-zero.

laughs in compile times

Great, another type that will take 10 years to get through LEWG and then 5 more years before any codebase can actually use it because they're stuck on C++17.

Two things that jumped out:

1. The csv literal suffix is going to cause real confusion. Not just "haha funny acronym" confusion - I mean using namespace std::literals; will bring in csv as a suffix that has nothing to do with comma-separated values. IDE autocomplete, code search, onboarding - this will be a friction point for years.

2. The overload ambiguity (section 6.1) is more nuanced than the paper lets on. Yes, string vs string_view already has this problem with the godbolt example. But in practice most codebases don't overload on both. Adding cstring_view means any function currently taking string_view that wants null-termination now has to deal with three-way ambiguity. The requires true deprioritization trick works but it's not obvious and won't be discovered by most users.

The user should be clear about which properties of string it's expecting.

This is correct in theory and wishful thinking in practice. Most library authors will just pick one and hope for the best.

For anyone who wants to try this today rather than wait for C++29: the Beman Project reference implementation is on GitHub. Header-only, works with C++20 and up.

It's also useful for seeing the design decisions in action. The remove_suffix = delete with the reason string is a nice touch - gives you an actual error message instead of a wall of template noise.