> Well, then the rest of my email applies: what's the path toward making it
modifiable?

The point is to not do this. Global mutable state is, in general,
massively problematic. On top of being bug-prone and introducing
potential for spooky action at a distance it opens the question of
thread safety. All this has been discussed during previous meetings on
P1275.

Instead of trying to make old anti-patterns work I think applications
should find better designs. I can think of a few, I'm sure others can
think of more clever solutions.

For an updated draft of the paper please see
https://isocpp.org/files/papers/P3474R0.html which has addressed a
number of points of feedback received in this thread.

Jeremy

On Tue, Oct 15, 2024 at 11:55 PM Thiago Macieira via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> On Tuesday 15 October 2024 21:41:56 GMT-7 Tiago Freire wrote:
> > > Well, then the rest of my email applies: what's the path toward making it
> > > modifiable?
> > Is there anything stopping you from making a copy?
>
> A copy of what? You didn't provide a way to create a std::arguments or
> arguments_view from existing a string array in your paper. That would still be
> sub-optimal, because we'd have to document:
>
> "Do not EVER use std:arguments(). Instead, use
> QCoreApplication::arguments_view(), which has the same interface but is
> correct."
> (becausw QCoreApplication::arguments() is already taken)
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Principal Engineer - Intel DCAI Platform & System Engineering
>
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals