> On Feb 5, 2026, at 5:55 PM, Thiago Macieira via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> On Thursday, 5 February 2026 00:10:58 Pacific Standard Time Sebastian Wittmeier
> via Std-Proposals wrote:
>> -> Don't calculate the length, if not needed. Only do it at first use.
>> Should be as efficient as a char* pointer (at least regarding the
>> operations).
>
> Do note one extra benefit of only wrapping a char *: it can be used to replace
> argv[] in main() without memory allocation.
>
(This is a reply to a lot of the discussion, not just to Thiago.)

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.

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.)

I am not sure if there are any restrictions in the current proposal if the cstring_view has to be const. If not, I might be giving a non-const view (converted to char*) to a C function which might write to it and change its strlen (only making it shorter would be allowed). A size member would then be wrong anyway (unless it is supposed to be a capacity). In this sense cstring_view would be a little bit like a buffer. This would also mean that there does not have to be a terminating null character at the end of the capacity. If it is const, there has to be at least one null character within the capacity. If the cstring_view is meant as a target for a C function to write into it doesn’t even have to include any null character when the constructor is called (as the cstring might be uninitialized). (Probably, in these cases we could also use a string_view instead; but it would improve teachability if we can say: always use cstring_view when interfacing with C.)

I’m not sure if we need cstring_view to be compatible with constexpr. The only reason to use cstring_view should be to interface with C. Am I mistaken that there are no constexpr C functions? Or are some of the C standard library functions marked constexpr when included from C++? Still, we don’t need to use a C string if we don’t call any functions from other C libraries (which are very likely not constexpr).