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