[Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

[André Pönitz]

On Wed, Oct 14, 2015 at 06:37:19AM +0000, Knoll Lars wrote:
> Agree here as well. We can’t make QString utf-8 backed without breaking
> way too much code. I also don’t see the need for it. The native encoding
> on Windows and Mac (Cocoa) is utf-16 as well, on Linux it’s utf-8. So no
> matter which platform we’re on, we won’t avoid some conversions.

I am afraid that "the native encoding on Windows and Mac (Cocoa)
is UTF-16" argument does not carry much weight in my daily work.

I read/write files a lot, talk to processes/services/whatever.
Almost all of that uses some 8-bit encoding, often enough something
compatible with UTF-8, also on Windows and Mac. Even small fry like
settings keys is usually plain English 7-bit clean.

QString's UTF-16 is pretty much the antithesis of a good compromise in
that area. It generates line noise in the sources and wastes cycles at
runtime.

> And I will strongly oppose any attempts to make QString some sort of
> hybrid supporting both. The added complexity in maintaining the code base
> is simply not worth it.

I don't think a hybrid would be better, either. But that is not
part of this RFC.

I think Marc's proposal of using *View classes in interfaces has some merits.
How much exactly I am unsure about. I only know that the (non-)performance
of QString based interfaces has bitten me often enough to justify at least
some experiments.


That's why I'd like to propose the following: 

Since experiments within Qt proper are difficult due to the BC
and SC guarantees we give and the practical impossibility to un-do
additions we should simply not do it there.

Instead, we could (and should) use part of Qt Creator's code base,
specifically some of 'leaf' plugins (i.e. plugins with no known
downstream users), to play with the idea, and develop a solid
understanding of the pros and cons of the idea of using *View
classes in interfaces until Qt 6 comes.

The way forward could be to add e.g. 'Utils::[Q]StringView'
and 'Utils::[Q]ByteArrayView' in implementation src/libs/utils
and start using these in a few 'harmless' plugins.

The advantages here are less restrictions due to lower compatibility
guarantees, less restrictions imposed by older compilers, less harm
done if the experiment fails (i.e. if the *Views turn out to not be
beneficial) and generally more flexibility when e.g. comparing competing
implementations.

Opinions?

Andre'