[Development] QString and related changes for Qt 6

[Thiago Macieira]

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