[Development] HEADS-UP: QStringLiteral

[Jaroslaw Kobus]

I propose the following policy regarding any further new string classes / wrappers in Qt:

Whenever anyone propose new string class / wrapper in public API of Qt, he is obligated to deprecate in parallel at least 2 other string classes / wrappers in public API of Qt.

Regards

Jarek

________________________________________
From: Development <development-bounces at qt-project.org> on behalf of Tor Arne Vestbø <Tor.arne.Vestbo at qt.io>
Sent: Wednesday, August 21, 2019 12:01 PM
To: Bogdan Vatra
Cc: Thiago Macieira; Qt development mailing list
Subject: Re: [Development] HEADS-UP: QStringLiteral



> 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.

> // 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?

Tor Arne
_______________________________________________
Development mailing list
Development at qt-project.org
https://lists.qt-project.org/listinfo/development