On Fri, Feb 6, 2026, at 08:18, Jason McKesson via Std-Proposals wrote:
> 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.

More importantly, we cannot cache the length of the string because some uses of cstring_view will mutate the string and change the length. One of the motivations for zstring_view in the paper is to ensure the result of strlen is cached avoiding the need to call that function (though the compiler can maybe optimize some out). However since the length can change in normal use we need to note when that length is invalidated, and then figure out how to handle those cases.