On Fri, Feb 6, 2026 at 1:54 AM Jan Schultke via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>>
>> I don’t think that we need a wrapper for char*. The only thing you would gain is member functions instead of free standing functions. This only comes down to taste and does not warrant an additional type.
>>
>> The primary reason I see for a cstring_view is to improve safety (as long as we are in C++ and not C). This only works if cstring_view does not only store a pointer, but also a size (or rather a capacity). Someone has allocated some memory for this string and this gives us some capacity (which might be less than what was allocated depending on how the view is constructed). If we access a character inside this view the compiler/runtime can do bounds checks (through contracts). This would already be much safer even if strlen is less than the capacity saved inside the view.
>
>
> Agreed, this feature is pointless if it just wraps a pointer.
>
>>
>> Since we assume a C-style null terminated string, iteration should definitely still be until the null character is hit (or maybe until strlen). Checking for capacity could be done in addition to this. (Or runtime checks through contracts could trigger with out-of-bounds access.)
>
>
> That sounds questionable to me. std::string iteration also doesn't stop at nulls, and constantly dealing with nested nulls inhibits optimizations like copying strings with std::memcpy. When looking at the string from a "range perspective", its size should match the advertised size(). The null-terminated size is only relevant to C APIs.

But the only reason to even have `cstring_view` at all is to engage
with APIs that expect NUL-terminated strings. If you have an API that
takes a sized string, we already have that: `string_view`.

`cstring_view` should not be thought of as some kind of generalized
replacement for `string_view`. You use it when you care about the size
of the string being determined by a NUL-terminator.