On 12/05/2020 13.48, Giuseppe D'Angelo via Development wrote:
On 5/12/20 6:12 PM, Иван Комиссаров wrote:
So the question is - is it possible to allow to construct QString from
unicode literal?
"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.
This can be solved with a third overload:
template <size_t N>
void foo(char16_t (&s)[N]) { foo(QStringView{s, N}); }
Of course, this isn't quite right; we actually want:
QStringView{s, s[N - 1] ? N : N - 1}
...so that we correctly handle both NUL-terminated literals and also raw
arrays (which may not be NUL-terminated!). There is the slight caveat
that we will ignore a final NUL in a raw array, but a) I think that's
reasonable, and b) I don't see a way around that short of a language
change to give string literals a distinct type. Also note that
reasonable compilers should optimize away the conditional, so there is
no added overhead.
Note that adding the QString(char16_t*) constructor
Pedantic, but surely you meant `char16_t const*`. (Also, please provide
the templated overload so calling strlen is not needed!)
--
Matthew
_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
