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

[Marc Mutz]

Hi Andre,

On Wednesday 14 October 2015 22:37:01 André Pönitz wrote:
> 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?

I disagree that QtC is a better place to try out QStringView.

The user base of Qt APIs is orders of magnitude larger than that of QtC APIs, 
and we should encourage outside experiments, not prevent them.

Just like QStringBuilder, we can make QStringView opt-in for now (which means 
providing a QString overload :( - but we can start with existing API).

Thanks,
Marc

-- 
Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts