On Sunday, February 1st, 2026 at 7:22 AM, Thiago Macieira via Std-Proposals <std-proposals_at_[hidden]> wrote:

>
> > Advantages over P3655R2 “std::zstring_view”
> > -------------------------------------------
> > 1. Simpler, more minimal implementation – only two data members plus a
> > static empty buffer.
>
>
> Why two? What's the point in keeping the size, if it can be calculated?
> Compilers are good at remembering strlen() calls. Please argue for and against
> it, remembering it can get out of sync if the string is changed.
>

I think part of the problem is that cstring_view is being pitched as a
solution for both producers and consumers of null-terminated strings. I
agree that consumers probably don't need or want the size. They don't
need it if they're just going to pass the string directly to a C API, so
why require the callers to know/compute the size. They don't want it if
embedded nulls mean it might not reflect the size the C side sees anyway.

OTOH producers of null-terminated strings don't know how the string is
going to be used, so it makes sense to return a string_view with the
added information that it's null terminated (as in
https://eel.is/c++draft/meta.reflection#meta.syn-3). This information is
useful even in the presence of embedded nulls (at the very least, it
allows you to safely strlen() the string). The name "cstring_view" might
be misleading though, if the actual C-string might be different.