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-boun...@qt-project.org> on behalf of Tor Arne
Vestbø <tor.arne.ves...@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@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@qt-project.org
https://lists.qt-project.org/listinfo/development
_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
