On Tuesday 2 July 2024 20:08:05 CEST Tiago Freire wrote:
> Yeah,
> If you want to pass Qt Strings trough std::formatter, then per parameter
> allocation is going to be necessary, that will not improve.
> But if
> std::string is what gets used, then why not skip the QByteArray altogether?

It's doable; it just requires adding a new function equivalent to
QtPrivate::convertToUtf8() that returns std::string. We haven't needed that so
far. But that only solves half the problem.

> I've heard rumors about charN_t support for formatters, not sure it is
> going anywhere any time soon because the feeling I got is that there's no
> real idea on the direction on how that should look like. UTF-8 seems to be
> on more solid grounds than the rest, if I had to bet, I would say that will
> come out before anything else, but even that looks unsure at this point.
> I don't think you would want to wait until 2030 to implement the feature.

We need both UTF-8 and UTF-16. UTF-8 is the permanent storage and interchange
mechanism, but in-memory storage is very often done in UTF-16, used by APIs
like JNI, Cocoa, ICU and, of course, Qt. So here are Qt's voice of support for
those two. If it's a matter of people's time, ditch UTF-32 and wchar_t.

I'd also advise implementations to assume that the execution charset on Unix
systems is UTF-8.

> If you are implementing a custom qFormat as an alternative solution to
> std::format, I would advise not basing it on std::format, you can do
> everything with 0 copies and without touching the heap.
 
Thanks, that's what my investigation turned up too. I'm hoping we can keep the
format_args and pattern parser though. We'd prefer the parser in UTF-16
because Qt translation files (.qm) store that in UTF-16[*].

[*] big endian, because the format was designed in the late 1990s and early
2000s.

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