Am 23.10.2024 um 11:22 schrieb Ivan Solovev via Development:
Hi Thiago,
first of all, could you please clarify, how do you see the potential
implementation?
Do you think that we can reuse some of the things that std::format
provides, or do we need to write everything from scratch?
For my patches that add std::format support to QByteArray(View),
I implemented a parser that is compatible with standard format specifier for
string types, which is just a small subset of
https://eel.is/c++draft/format.string.std
And I still used std::format to do the actual formatting, because I
didn't want to mess with width and padding on my own.
a) keep the "n" and make it mandatory, as in {n}
If we use std::format, then we cannot do it, because it does the
argument index parsing on its own, and delegates to a custom formatter
specialization after that. And argument index can only be a non-negative
integer value.
std::format is complex.
std::format is a standard extension point in C++.
std::format a field of permanent improvement, for instance we've got
compile-time format-string parsing with C++20.
I'd hope for state-of-the-art integration with std::format, instead of
Qt reinventing half-baked wheel.
First of all it's a matter of relevance: With modern C++ improving more
and more it becomes easier and easier to write modern C++ applications
without Qt. At some point Qt will get perceived more like a liability
than like an advantage if Qt fails to hold pace and reinvents its own
incompatible wheels.
I'd hope Qt has learned it's lesson with custom containers. Actually
there were much better reasons to reinvent containers back the days than
there are to reinvent std::format.
So please, let's not reinvent std::format.
Let's adopt and embrace instead.
Ciao
Mathias
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
