Confusing documentation. Not incorrect.

How embarrising.


On Fri, Feb 6, 2026, at 19:51, Henry Miller wrote:
> On Fri, Feb 6, 2026, at 19:18, Andre Kostur wrote:
>>> Too late, std::strintg_view already has operator[] which allows mutating the string. You can't change the length of the
>> string (except by getting a different string_view), but you can change
>> the individual characters.
>>
>> Isn't op[] on a std::string_view a const member function returning a
>> const reference?
>
> https://en.cppreference.com/w/cpp/string/basic_string_view/operator_at.html
> in the example code clearly shows modifying the data via operator[].
> However now that you point it out, it is a const reference, and gcc15
> rejects the example code.
>
> At this point I'm going to stand corrected. I was mislead by incorrect
> documentation.
>
> Though that doesn't mean cstring_view needs to follow the same
> semantics (particularly when the data is ultimately passed to a C
> function). How does the confusion of another _view that works
> different weight against the usefulness of a type that is designed to
> pass into C functions in an area where C is known bug-prone? Or
> perhaps we should open the bike-shed: do we want a _view here, or do we
> want something only somewhat similar but that allows other operations.
>
>> On Fri, Feb 6, 2026 at 5:09 PM Henry Miller via Std-Proposals
>> <std-proposals_at_[hidden]> wrote:
>>>
>>>
>>> On Fri, Feb 6, 2026, at 14:26, Thiago Macieira via Std-Proposals 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.
>>>
>>> Too late, std::strintg_view already has operator[] which allows mutating the string. You can't change the length of the
>>> string (except by getting a different string_view), but you can change the individual characters.
>>>
>>> > 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.
>>>
>>> The point here is people need to deal with c-style strings in C++, the buffers you get from existing C++ containers often fall short (are not null terminated). Sure we can agree to ban (or at least make hard) particularly problematic things, but the goal is to make c strings easier to use - in particular when calling C functions, not satisfy some notion of purity. One of the things commonly done by the C functions is mutate strings, so we need to allow for it somehow. Maybe that is go back the original buffer, but what is the point of having something to make calling C easier if we can't use it to call C functions?
>>>
>>> I think for this to advance someone needs to do the tedious work of finding all the different custom implementations. We need to know what people are already doing with their custom cstring_view/zsring_views - there are several of them on github, and they seem to be in use in various large projects. We don't have to support everything already being done, but know what users are doing is a good step. Why is someone using cstring_view in the real world, what do they like/dislike about their implementation. What do they think about the proposal?
>>> --
>>> Std-Proposals mailing list
>>> Std-Proposals_at_[hidden]
>>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals