[Development] QString and related changes for Qt 6

[Matthew Woehlke]

On 12/05/2020 13.48, Giuseppe D'Angelo via Development wrote:
> On 5/12/20 6:12 PM, Иван Комиссаров wrote:
>> So the question is - is it possible to allow to construct QString from 
>> unicode literal?
> 
> "Not yet", but adding a constructor from char16_t to QString makes sense.
> 
> This creates a problem down the line: today you have a
> 
>    f(QString)
> 
> and you call it with f(u"whatever"). Then, later on, you realize that 
> QString is not needed and QStringView suffices. (This is the case all 
> over existing Qt code.)
> 
> What do you do? Adding a QStringView overload will make calls ambiguous, 
> removing the QString one will be an ABI break. We need an established 
> solution for these cases as they'll pop up during the Qt 6 lifetime.

This can be solved with a third overload:

   template <size_t N>
   void foo(char16_t (&s)[N]) { foo(QStringView{s, N}); }

Of course, this isn't quite right; we actually want:

   QStringView{s, s[N - 1] ? N : N - 1}

...so that we correctly handle both NUL-terminated literals and also raw 
arrays (which may not be NUL-terminated!). There is the slight caveat 
that we will ignore a final NUL in a raw array, but a) I think that's 
reasonable, and b) I don't see a way around that short of a language 
change to give string literals a distinct type. Also note that 
reasonable compilers should optimize away the conditional, so there is 
no added overhead.

> Note that adding the QString(char16_t*) constructor

Pedantic, but surely you meant `char16_t const*`. (Also, please provide 
the templated overload so calling strlen is not needed!)

-- 
Matthew