We want to prevent
QStringView(QChar|QLatin1String|QByteArray|const char*)
from compiling as QStringView(QString(...)), so I added = delete'ed
ctors for these types to QStringView. However, that makes QStringView
participate in overload resolution for these types. Even if the
QStringView ctor will always fail to compile, the presence of these
ctors alone makes calls to functions overloaded on QString and
QStringView ambiguous:
f(QStringView);
f(QString);
f(foo); // ambiguous
f(QChar('f')) // ambiguous
f(QLatin1String(foo)); // ambiguous
f(QByteArray(foo)); // ambiguous
Fix by making the QString and QStringRef constructors templates
constrained to accept only these two types. This should also help to
move the QStringView definition to before the QString one (as soon as
we get rid of or start to ignore QString::Null), simplifying a lot of
code in qstring.h down the line.
This should also fix MSVC's accepting of two user-defined conversions
which caused static non-compile-tests to fail in the initial
QStringView patch, and which were therefore removed. This patch brings
them back.
Change-Id: I95ac38c0d31cd8c726f7e952017569d32e484413
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
7180236063