[Development] std::format support for Qt string types
Thiago Macieira
thiago.macieira at intel.com
Thu Jun 6 19:08:52 CEST 2024
On Thursday 6 June 2024 08:07:31 GMT-7 Giuseppe D'Angelo via Development
wrote:
> 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.
Agreed and I noted this in the initial implementation by Ivan, which
eventually led us here.
My opinion is that we should treat formatter-to-char as UTF-8 and therefore
copy the UTF-8 string literally and transcode the Latin1 string (preferably,
on the fly without temporary memory allocation, like we do for QStringBuilder).
> > Question here is how to deal with QString(View)?
> >
> > 3a. Convert it to UTF-8, because that's the pre-existing behavior which
> >
> > should be known for the users.
> >
> > 3b. Do not implement std::formatter<QString(View), char> at all and let
> >
> > the users explicitly convert QString to something else first.
> >
> > Option 3b is inconvenient and defeats the purpose of std::format support
> > for Qt types, so I'd personally prefer 3a here.
>
> 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.
>
> 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.
>
> (Not to mention formatting _into_ char16_t, which would unlock something
> like QString::format to *create* a QString!)
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.
It might be that we're giving feedback 5 years too late, though.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Fleet Engineering and Quality
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5152 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/development/attachments/20240606/38fbd9a1/attachment-0001.bin>
More information about the Development
mailing list