[Development] QString and related changes for Qt 6

[Edward Welbourne]

On 5/12/20 6:12 PM, Иван Комиссаров wrote:
>> So the question is - is it possible to allow to construct QString from unicode literal?

Giuseppe D'Angelo (12 May 2020 19:48) replied:
> "Not yet", but adding a constructor from char16_t to QString makes sense.
>
> This creates a problem down the line: today you have a
>
>   f(QString)
>
> and you call it with f(u"whatever"). Then, later on, you realize that
> QString is not needed and QStringView suffices. (This is the case all
> over existing Qt code.)
>
> What do you do? Adding a QStringView overload will make calls ambiguous,
> removing the QString one will be an ABI break. We need an established
> solution for these cases as they'll pop up during the Qt 6 lifetime.
>
> Note that adding the QString(char16_t*) constructor introduces this
> ambiguity for the functions that are already overloaded on
> QString+QStringView (and thus today are using QStringView).

Would it suffice to skip the QString(char16_t *) constructor and,
instead, have a QString(QStringView) constructor ?

I guess calls to functions taking QString would have to make one of the
steps explicit, when passing a u"...", i.e. either call
f(QString(u"...")) or f(QStringView(u"...")), preferring the latter (as
it's future-proof against f changing signature from QString to
QStingView later; note that this concern applies to Qt-using code, which
may allow itself such ABI-breaks, not just Qt itself, which wouldn't, at
least not once the old API has appeared in a public release).  I suppose
both forms are capable of exploiting constexpr and happening at
compile-time, when the compiler deigns to make it so.

	Eddy.