Date: Fri, 6 Feb 2026 17:18:49 -0800
> 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?
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
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?
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
Received on 2026-02-07 01:19:05
