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.
Note that adding the QString(char16_t*) constructor introduces this ambiguity for the functions that are already overloaded on QString+QStringView (and thus today are using QStringView).
Thanks, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
