[Development] HEADS-UP: QStringLiteral
Jaroslaw.Kobus at qt.io
Wed Aug 21 12:17:26 CEST 2019
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.
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
> test[QLatin1String("key1")] = QStringLiteral("some text %1").arg(1); // still
> test[QLatin1String("key1")] = QStringLiteral("some text %1").arg(1); //
> victory !!!
This should just be test[“key”] = “value”. How do we get there?
Development mailing list
Development at qt-project.org
More information about the Development