> On Feb 6, 2026, at 9:26 PM, Thiago Macieira via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> On Friday, 6 February 2026 08:19:37 Pacific Standard Time Sebastian Wittmeier
> via Std-Proposals wrote:
>> A) would be good for quick estimates, e.g. buffer space
>>
>> B) would be a safety-feature/limit for mutable C strings, if the NUL byte
>> gets overwritten
>
> I don't think a type with "view" in the name should allow mutating, at all.

I believe I understand where you are coming from, but I don’t fully agree.
>
> If you want to change the string, go back to the original buffer, which is
> probably a std::string, std::vector, or std::span. That one will provide you
> with the capacity.

Don’t get fooled by the name: std::span is a view (that allows mutation) as it doesn’t own the memory it points to. In general, there is no need for std::string_view in addition to std::span, but we have it anyway because it has additional member functions specific to string handling. In the same way cstring_view can be quite useful when interfacing with C. If we make cstring_view non-mutating I would wish for yet another class that can be used everywhere where a C function expects a ‘char*’ instead of a ‘const char *’. I’m not sure if another class is the best solution. Maybe mutability has to be part of the template arguments of the class. Because constructing a cstring_view from a ‘const char*’ certainly should not allow mutation. (I hope this differentiation already works quite well with std::span.)
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Principal Engineer - Intel Data Center - Platform & Sys. Eng.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
> <signature.asc>