[Development] std::format support for Qt string types

[Giuseppe D'Angelo]

On 07/06/2024 10:53, Ivan Solovev via Development wrote:
> Hi
> 
>  > I think we should conceptually separate formatting from printing on a
>  > terminal. std::format isn't /_just_/ for printing on terminals
> 
> I agree. But the same question about encoding to be used is still valid 
> here.
> 
>  > What do you mean by "readable" here?
> 
> I was mostly thinking about "readable in the terminal", because that's how
> I did most of my tests. And from that point of view "readable" is very
> close to what QString::toLocal8Bit() tries to do. So that's what I called
> option 2 in my initial email.
> 

I'd just set this problem aside. Correct printing in a terminal may 
require re-encoding of the output of a formatter, in a way which is 
complicated, and that's why we have `std::print`.

> https://eel.is/c++draft/print.fun#10

> https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2093r14.html#unicode



>  > I'm not following this. If I do
>  >
>  >  std::format("{} {}", utf8string, latin1string)
>  >
>  > what am I supposed to get out? A string which is a mix of two different
>  > encodings? I don't think that's ever possibly wanted.
> 
> Yes, that's exactly what I mean. And, by the way, that's exactly how
> std::format is working now.

What Eddy said already. (A corollary: I'm 100% OK at adding a formatter 
for QByteArray(View), basically reusing the one for std::string_view).


>  > The concern I was quoting before is this: suppose that tomorrow we have
>  > a formatter for `const char16_t *` into char. This formatter does some
>  > kind of transcoding. Then QString(View) ought to do precisely the same!
>  > If we take a different decision now, we risk having compatibility
>  > problems down the line.
> 
> Standard in its current state does not care about transcoding (see the
> utf8 + latin1 example above). So, if we do not go for option 3 at least
> for QLatin1StringView and QUtf8StringView, we would already have
> compatibility problems.

I disagree: the standard cares about transcoding, in the sense that it 
deliberately doesn't allow it to happen: you can't format a charN_t 
sequence out. Today, you have to convert them (and you're on your own). 
Tomorrow, who knows -- thus my concern that we need to be aligned with 
upstream, or we risk divergence. Cf. for example this approach:

> https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2728r6.html#add-utf_view-specialization-of-formatter




>  >> Now, I don't really know if formatting char16_t is anywhere on SG16's
>  >> radar in the short term, but that sounds definitely something to
>  >> investigate and report about, in order to make a more informed decision.
>  >
>  > Yup, I think we need to engage SG16 before continuing with this. We need
>  > char16_t to be enabled on the generic formatters, for one thing.
> 
> I must admit that I have no idea how this process works. How to reach out
> to them and ask if they have any plans about char16_t support?
> Maybe even asking if they have any plans for wchar_t -> char formatters
> would be helpful.
> Is there anyone familiar with the process?

SG16 is one of the most open and welcoming C++ study groups. You can 
find plenty of resources here https://github.com/sg16-unicode/sg16 . 
Their mailing list (reflector) is here 
https://lists.isocpp.org/mailman/listinfo.cgi/sg16 .


Thank you,

-- 
Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - Trusted Software Excellence

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4244 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.qt-project.org/pipermail/development/attachments/20240607/84f51187/attachment.bin>