[Development] HEADS-UP: QStringLiteral

[Lars Knoll]

> On 21 Aug 2019, at 13:01, Tor Arne Vestbø <Tor.arne.Vestbo at qt.io> wrote:
> 
> 
> 
>> On 21 Aug 2019, at 11:50, Bogdan Vatra via Development <development at qt-project.org> wrote:
>> 
>> Am I the only one which finds situations silly ? Of course there are more 
>> examples with the other String wrappers/functions in Qt, but I think is enough 
>> to show how crazy is the situation.
> 
> You are not! 
> 
> I completely agree, and I think it’s a detriment to Qt’s promise of easy to use APIs that these optimised versions are not automagic and hidden behind the scenes, or don’t have a clear cut story for when to explicitly use.

+1. Things are getting overly complex. And in the end most people will write less optimal code simply because they do now know which class is the best to use in which use case. If people on this list are confused, you can be certain that 98% of our users will not get the subtle differences.
> 
>> // Even more
>> QHash<QString, QString> test;
>> test[QLatin1String("key1")] = QLatin1String("some text %1").arg(1); // wrong
>> test[QStringLiteral("key1")] = QStringLiteral("some text %1").arg(1); // wrong 
>> again
>> test[QLatin1String("key1")] = QStringLiteral("some text %1").arg(1); // still 
>> wrong
>> test[QLatin1String("key1")] = QStringLiteral("some text %1").arg(1); // 
>> victory !!!
> 
> This should just be test[“key”] = “value”. How do we get there?

One way would be by enforcing utf8 as source encoding for Qt based projects. It’s a huge shame that C++ doesn’t specify the encoding of source code as opposed to pretty much any other programming language (hell even JS got that one right…). 

So I think it might be worthwhile enforcing that for Qt 6. But it leaves the question of what to do with QL1String.

Cheers,
Lars