[Development] HEADS-UP: QStringLiteral

[André Pönitz]

On Wed, Aug 21, 2019 at 10:01:29AM +0000, Tor Arne Vestbø 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! 

Indeed.

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

Same here.

Traditionally, "ease of use" and "consistent API" have been a core values of Qt,
even consciously bought at the cost of some bytes and some cycles.

Of course, this has meant that in certain parts of certain types of applications
Qt could not sensibly be used. Still, in most cases all, or almost all of the code
could be "plain Qt", benefiting for creation and maintenance from those values.
I do believe this was a sensible setup for Qt, and I do think there's room for
a general purpose framework living that compromise also in today's world.

During the last years (ok, let's say, starting around \epsilon A.J. - "After
Jasmin") this promise has been more or less silently broken, once by "leaf" modules
deviating, partially intentionally, from previous naming conventions, then for real
accidents that couldn't be corrected due to too-late discovery and compatibility
promises, and finally by attempts to provide "high performance" alternatives in
some places.

In the end we lost uniform, easy-to-use interfaces, and the performance gains are
only present in very isolated areas of the offering with long stretches in-between,
hidden by obscure and continuously changing do's and don'ts so that they are
effectively not visible in real-world GUI-centric applications.


With Qt 6 approaching, we could, at least in theory, revert steps on the "un-Qt-ish"
path, or opt for any of the alternatives ("modern C++ trumps all", "performance
trumps all", "random hogwash of whatever gets a +2 on Gerrit").

I surely have a preference here, but I'll be probably ok with anything that follows
*some* rules set, but I'd like to have a conscious decision on that.

If that does not happen, we will continue on the hogwash path.  For me that'd be the
least preferable option of all.

Andre'


PS:

> > test[QLatin1String("key1")] = QLatin1String("some text %1").arg(1);
> > 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 option is to use QT_RESTRICTED_CAST_FROM_ASCII instead of QT_NO_CAST_FROM_ASCII
for your application.

Yes, that costs cycles. But one is still free to use The Right Decorations in the
handful places where one doesn't want to in an application.