[Development] HEADS-UP: QStringLiteral

[Mutz, Marc]

Hi,

In light of a recent attempt to re-introduce QStringLiteral, relacing 
QLatin1String, I'd like to remind everyone that QStringLiteral has a lot 
of drawbacks and should not be used unless it saves a memory allocation.

Drawbacks include:

- doubled storage requirements (2 bytes/char) over a L1/US-ASCII string
- unsharability with C strings (each QStringLiteral contains a new 
lambda, lambdas have unique types, static data in token-for-token 
identical lambdas is duplicated, merging these violates the standard)
- introduction of QString dtor calls (cannot be optimized away)

Anti-patterns include: Using QStringLiteral in

- comparisons (includes relational operators, indexOf, contains)
- composition (QStringBuilder, append, prepend, arg() (now partly 
available on QStringView and QLatin1String, too)
- lookup and, I believe, even insertion, in JSON and soon CBOR classes
- debug statements (we prefer debug code to be compact, not fast)
- arguments to any other function overloaded QStringView or 
QLatin1String

Alternatives to QStringLiteral:

- u"..." (→ QStringView)
- QLatin1String

Please take note of the following recent developments:

- arg(string, ...., string) ("multiArg") is available now on QL1S and 
QStringView
   - number formatting isn't, yet
- You can use u"..." in Qt sources unconditionally
   - converts implicitly to QStringView
- To convert QString → QStringView, prefer qToStringViewIgnoringNull() 
when you don't need to distinguish between the null and the empty state. 
It saves a branch.

Please help spreading this knowledge in review and your own work.

Thanks,
Marc