[Development] HEADS-UP: QStringLiteral

[Edward Welbourne]

>> Returning to your original post:
>>>>> All the major frameworks out there (i.e. Java, C#) they have a
>>>>> single String which does all the magic.
>>
>> Yes, and those systems are all built with the assumption that client
>> code doesn't care if every single time anything happens to a string a
>> fresh copy of it is made.  They probably aren't actually that
>> inefficient, but the basic premise of the design of those easy-to-use
>> string classes is that if they were it wouldn't matter much.

Bogdan Vatra (21 August 2019 13:28) replied:
> When I say framework, I actually mean the framework code not the
> client code.  Let's take the java classes from Android, can you please
> show me a single place where Android folk are using some strange:
> String myString = StringLiteral("string") instead of a simple String
> myString = "string"; ?

Indeed, because Java (and others) have opted to care more about ease of
use than efficiency, their strings are easier to use.

>> We don't have that luxury, sad to say,

> But we have the luxury to loose potential Qt contributors because we
> are going to force them to use so many string wrappers?

We'd rather not - and hence the present discussion thread - how do we do
better than the present tangled mess ? - which I entirely agree is a mess:
the fact that we need to add [0]'s account of when to use which to our
docs is a testament to how confusing the present situation is.

* [0] https://codereview.qt-project.org/c/qt/qtdoc/+/268079

It remains that solving the problem is hard.  One of the things folk
want is a data() method on a string that lets them get at the raw data
and do as they please to it; this forces the string type to store its
data in the encoding that the data() method returns - UTF-16.  Having
done that, all other types of data must be converted to that encoding,
when constructing a string.  That means literals in source code either
are in UTF-16 (in which case, if their content can be expressed in pure
ASCII, the literal takes up twice as much memory in the binary as it
really needs) or have to be converted at run-time; either of these is a
cost one may reasonably prefer to avoid.

	Eddy.