Before porting multi-arg() to QAnyStringView, first port the unary
arg() overloads for symmetry reasons (unlike the views, multi-arg() on
QString is only considered for more than one argument().
This causes tension with the other arg() overloads, so finally make
the overload set a sane one by using constrained templates instead of
overloaded regular functions. This also solves the following problems:
- that char16_t and char8_t didn't match the char-ish overloads, but
the integer-ish ones,
- that arg('a') matched the char overload (and therefore printed a
character 'a') while arg('a', 2, 16) was ambiguous and arg('a', 2,
16, QChar('0')) called the integral overload, printing the numeric
value instead,
- that arg(qfloat16) was ambiguous when QFLOAT16_IS_NATIVE
- that using u' ' as `fillChar` sometimes caused ambiguities (and you
had to use ' '_L1 instead).
Needed to explicitly exclude wchar_t from the is_string_like arg()
overload, to at least keep existing behavior and not make matters
worse by treating wchar_t as a string-like on Windows and as
integer-like on Unix :( We'll hopefully still fix QTBUG-126054 before
this is relased.
[ChangeLog][QtCore][Potentially Source-Incompatible Changes] The
QString::arg() overloads have been redesigned. Character-like types
(char, char16_t, char8_t, wchar_t (still subject to QTBUG-126054 at
the time of writing), char32_t) now always output the character, not
its numeric value. In particular, char16_t and char arguments now
match the string-ish arg() overload (and therefore don't provide a
`base` argument anymore. A backwards-compatible fix is to cast char,
char16_t, and wchar_t arguments to uint. This also fixes the ambiguity
errors you may have seen when using a char16_t as `fillChar`.
[ChangeLog][QtCore][QString] Unary arg() now accepts QAnyStringView
(incl. QUtf8StringView).
Fixes: QTBUG-125588
Fixes: QTBUG-126053
Fixes: QTBUG-126055
Task-number: QTBUG-126054
Change-Id: If0bfd92e15952738f3870a540f52a7cc470b047f
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
563ed822f8