[Development] Dropping the option to disable QStringBuilder in 5.10?

[Thiago Macieira]

On Tuesday, 16 May 2017 06:14:39 PDT Marc Mutz wrote:
> Hi,
> 
> I'd like to suggest to drop the option to disable QStringBuilder-backed op+
> in Qt 5.10. We have been compiling Qt itself with QStringBuilder-backed op+
> and have seen very little breakages (mainly in qmake, with its own string
> type).
> 
> The reason to drop it is that QStringBuilder is a lot more maintainable than
> op+, since adding a new supported type is O(1) instead of O(N), N = #of
> existing supported types: You just specialise QConcatenable, instead of
> adding
> 
>  { op+(new, old), op+(old, new) | old \in already-supported-types }
> 
> And we have been adding a lot of such types for 5.10: char16_t, char16_t*,
> char16_t[N], QStringView, and there are obvious next candidates: std::
> (u16)string, wchar_t{,*,[N]}, std::(u16)string_view, CFString, NSString, ...

It's a source-incompatible change:

template <typename T> void f(T);

	QString s = "Hello";
	f((s + " %1").arg("World"));

The above has problems with QStringBuilder and QStringArgBuilder: when the op+ 
is enabled, s + " %1" is not a QString, it's a QStringBuilder<QString,char[5]> 
and that's a type that does not have .arg(). When QStringArgBuilder is 
enabled, the result from .arg() is not a QString, but a QStringArgBuilder 
(which derives from QString, so it has .left()), but then the template 
function is called with the wrong type.

If you dropped the .arg, it would be calling the wrong template function. And 
in the presence of C++11 auto, the problem exists elsewhere too.

So I think this needs to be left as a Qt 6.0 change.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center