On Wednesday 16 October 2024 07:54:20 GMT-7 Jeremy Rifkin via Std-Proposals
wrote:
> The current draft of the paper has changed to involve individual
> std::arguments objects that users manage as opposed to a global singleton.
> These will unfortunately require backing storage, but, this does make some
> sort of modification more possible; QT could theoretically pass a modified
> std::arguments object. How to facilitate modification here is something I
> would have to think about more, as it may preclude some cheaper designs.

QCoreApplication can keep a list of its parsed arguments and allow access back
to it. Global storage is not a problem.

> FWIW I would be surprised if std::arguments were ever used in QT. QT is
> basically its own ecosystem and I would expect some API with QStings to be
> preferred.

Indeed, but if std::arguments serves a sufficient purpose, then we can at least
say "it's usable". That's the difference between "Qt provides a better API than
std:: but both work" and "the std:: API is broken, do not ever use it in a Qt
application"

Specifically, the reason why we tell people to use
QCoreApplication::arguments() today is the handling of non-ANSI file names on
Windows. We have some workarounds to get the original W content of the
command-line despite going through the 8-bit main() function, which can have
mangled the names. If std::arguments() supports this same use-case, then this
reduces the delta to "Qt API is better".

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Principal Engineer - Intel DCAI Platform & System Engineering