On Tue, Feb 3, 2026 at 2:39 AM FPE via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> Thank you all for the ongoing discussion – it's great to see so many thoughtful perspectives!
>
> I wanted to express strong agreement with Arthur O'Dwyer's point in his recent message (16959.php). Since std::string and std::string_view both allow embedded nulls (e.g., constructing a string_view from a std::string containing "\0" includes the full length beyond the null), std::cstring_view should behave consistently for the same reasons. Inconsistency here would be seriously misleading to users who expect the "string" family to align.
>
> If cstring_view were to disallow embedded nulls or stop at the first one, it would break seamless interoperability with the rest of the string view ecosystem – member functions wouldn't match, conversions would be error-prone, and switching between types would require extra care or copies. In that case, it might be better to avoid the "string" naming entirely (perhaps something like txt_view or similar) or even just use raw char* for strict C semantics.
>
> While I understand the concerns raised by Thiago Macieira and Jason McKesson about prioritizing pure C semantics (stopping at the first null for safety/reliability with C APIs), I believe the risks of breaking consistency with string_view outweigh that in most cases – especially since string_view already trusts user input in similar ways. Keeping alignment makes the type much more usable in modern C++ code without surprising developers.

Here's a question: should `cstring_view` be used in "modern C++ code"?
That is, why do we need the type to begin with?

NUL-terminated strings are, ideally, a thing that should not exist. C
(and C++) is built on that concept, and there are a lot of C APIs that
expect NUL-terminated strings. In an ideal world, they wouldn't exist.
But they do exist.

So we have a problem: `string_view` cannot interact with such APIs
because it doesn't ensure that the string it contains is
NUL-terminated. So if we want C++ to interact with such APIs, we need
another type, one that ensures NUL-termination and thus can be used
with those APIs.

Being usable with NUL-terminated string APIs is the entire reason why
we need the type.

Your argument only makes sense if the idea behind `cstring_view` was
to essentially *replace* `string_view`. That it isn't merely a tool
you use when you have to engage with NUL-termination-based string
APIs, but is instead the standard for how you deal with all string
views.

And that's just not a good idea. `cstring_view` is an exception
handler, a thing you should use when you need it. It shouldn't be
littered everywhere in your "modern C++ code".