On Tuesday, 12 May 2020 02:01:45 PDT Edward Welbourne wrote: > I largely agree, with the exception of: supporting an 8-bit string view > type for comparisons (including startsWith(), find()/indexOf() and > similar) can save client code a factor of two on the size of many string > literals. I'm fine with limiting its use to the QString(View) API, > though. So QUtf8View would replace QLatin1String as that 8-bit view > type, with a much more limited scope. > > While we can simply ask folk to stick a u on the front of their strings, > doubling the size of each, it would be a kindness to those with lots of > string literals to allow them to use u8 instead and avoid that doubling. > Meanwhile, the many situations where data from an outside source arrives > in UTF-8 make a case for providing a view type that can wrap such data > and make it "presentable" for interaction with QString(View), tagged > with the right semantics (i.e. the knowledge that it's UTF-8) in the > type system.
I think we need some more data before we do that. First of all, char8_t doesn't exist before C++20. u8"" has existed since C++11, but it didn't produce char8_t literals until C++20. So we have to be careful with recommending people use it. The APIs we add using char8_t, if any, will exist with C++20 only. But for Qt, everything char is already UTF-8, so we don't need char8_t. The problem with QUtf8View is how it may be used. Unlike QLatin1String, direct UTF-16-to-UTF-8 comparisons as easy, so the QString methods that would take QUtf8View are necessarily slower. If space is a constraint but not runtime, it might be best to just use QString constructor. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development