pino added a comment.
TBH I had the idea of making `splitLocale()` public, since it was a public
API in `KLocale`. I still see a couple of users of it, and in the past I
remember people working around the lack of `splitLocale()` by doing the same
job on their own, when porting away from kdelibs4support.
With that in mind, IMHO using `QStringRef` for a public API still seems odd
to me, especially that if you really care about any part split, then most
probably you will pass to other APIs that use `QString` (sort of nullifying the
gain from using `QStringRef`).
I saw too many cases in kdelibs 4.x applications using patterns like:
QString language, dummy;
KLocale::splitLocale(locale, language, dummy, dumy, dummy);
Because of that, a better API would be to pass `QString*` for the split
parts, so you can decide what actually you want as results -- e.g.:
QString language;
KLocalizedString::splitLocale(locale, &language, nullptr, nullptr, nullptr);
REPOSITORY
R249 KI18n
REVISION DETAIL
https://phabricator.kde.org/D14504
To: apol, #frameworks, ilic
Cc: pino, kde-frameworks-devel, michaelh, ngraham, bruns
