On Friday 28 June 2024 02:04:22 GMT-7 Ivan Solovev via SG16 wrote:
> Based on the above, we have the following questions:
> * are there any plans to provide the possibility to reserve space in the
> output?
> * are there any plans to provide the possibility to write directly to the
> output, assuming it's a contiguous buffer?
>
> Another thing which could be really beneficial for us is the possibility
> to format into a QString (which is a char16_t container).
> However, currently the standard only supports formatting into char and
> wchar_t. Is it going to change? Are there any plans to provide support
> for formatting into charN_t?

I spent some time looking into the libstdc++ implementation for the
feasibility of the above and I think the answer is the same for all of them:
Qt provides a qFormat() function, which wraps std::format_to.

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.

Likewise, we'll need to provide some char16_t encoder for some other types,
like integers, floating point, std::chrono types, etc. I would propose Qt only
have a basic set for minimum viable product. Anything else, we'll tell our
users to complain to their Standard Library implementors to provide the
char16_t formatter. And ditto for any other user-provided types: vendors must
provide char16_t formatters.

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