On Friday 28 June 2024 15:53:21 GMT-7 Thiago Macieira via SG16 wrote:
> The trick is that we provide our own output iterator. When std::formatter
> for our own types detects this output iterator type from the context, we
> can implement the space reservation and writing into the buffer properly.
> That can also therefore implement the conversion from UTF-8 for std::string
> and std::string_view, and a direct memcpy for std::u16string. We don't need
> to implement std::u32string and I quite frankly don't care about wchar_t --
> I think it was a mistake for std::format to have that instead of char16_t
> and char32_t.

Actually, the for the majority of those types (if not all of them), we'll
probably just have an entire hand-rolled implementation anyway, compiled out-
of-line and built into QtCore. With that, we can probably take extra liberties
with buffers that wouldn't be allowed in inline code being emitted into user
code, with generic formatters.

After all, the vast majority of strings being formatted are not known at
compile time. They come from translation files installed by the application.

That means we won't simply wrap std::format_to like std::format does. We'll
need to provide a function that extracts arguments and separates the ones for
which we have a built-in formatter, and thus only need a reference capture,
and those for which we don't and thus must capture a type-erased formatter.

I'm hoping we can keep the format parser.

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