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 terminalsI 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.dang...@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
smime.p7s
Description: S/MIME Cryptographic Signature
-- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
