>
>
> 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.
>
> Thanks again,
>
> Best,
> FPE(foxofice)