[Development] QString and related changes for Qt 6

[Matthew Woehlke]

On 12/05/2020 03.49, Lars Knoll wrote:
> * QStringLiteral should turn into a small wrapper around u”…”, and
> probably also get deprecated. Maybe we could add a user defined
> literal for it instead that returns a read-only QString (QString s =
> “…”_q;). So u”…” would lead to a QStringView, u”…”_q to a read-only
> QString.
How will this work? As I understand, the main advantage to 
QStringLiteral is that it statically encodes the *length* as well as the 
data. This isn't possible with raw literals, which are merely 
NUL-terminated.

Even std::string wants literals for this reason. A UDL would obviously 
be superior, but I don't see us ever getting rid of some form of QString 
literal short of templatizing *everything* that takes a T* (for T in 
char, char16_t, etc.) to take a T(&)[N] instead.

> In most other places we should by default only use QString, unless
> there are very significant performance benefits to be had from using
> QStringView. This helps us keep an API that’s both easy to use and
> maintain. With the ideas above, you can still create a read-only
> string, so data copies can in many cases be avoided if required.
Really? How?

The "nice" thing about QStringView is that it does not have ownership; 
you have to be careful about how long you hold onto it lest it turn into 
a dangling pointer. You can't construct a QString from any old bag of 
byt^Wcharacters because a QString is implicitly valid until it is destroyed.

That said, I think I understand the reasoning here; make it up front 
that the input is going to wind up in *a* QString. If the user's input 
is *already* a QString, the function can make a shared copy rather than 
constructing a brand new one. However, it would be nice for such 
functions to offer r-value reference overloads for cases where a QString 
needs to be created, or if the user is done with their copy. (Actually, 
a possibly-owning reference wrapper could be useful here...)

-- 
Matthew