Details
-
Suggestion
-
Resolution: Unresolved
-
Not Evaluated
-
None
-
None
-
None
Description
QString::compare()/QString::localAwareCompare() have overloads for working with different combinations of QString/QStringView/QLatin1String arguments. For example QString::localeAwareCompare() can be called for two QLatin1String arguments (after implicitly converting them to QString). This raises the question, if such functions should be part of QString's API, since QString serves as a namespace for these functions.
Consider making them free functions, e.g. qCompareStrings()/qCompareStringsLocaleAware() (or similar) that will work with all combinations of different string types. For example, at the moment one can call QString::compare(QString, QLatin1String)/QString::compare(QLatin1String, QString), but can't call QString::compare(QLatin1String, QLatin1String) (unlike localeAwareCompare()).
From the discussion related to https://codereview.qt-project.org/c/qt/qtbase/+/398419:
We need to take a step back and assess whether a given static function forms part of the class' API or not. In the case of QString::fromUtf8(), it is, obviously, I shall hope. But QString::compare(lhs, rhs) really isn't. In there, QString is but a namespace. The QString prefix doesn't give you anything except a way to shorten the function's name to 'compare'.
The original submission of QStringView had qCompareStrings() instead of QtPrivate::compareStrings(). Now you see why.
Suggestion: Make a qCompareStringsLocaleAware() overload set (or qLocaleAwareCompare(), if we can think of other things that can be compared locale-aware).