On 5/12/20 6:12 PM, Иван Комиссаров wrote: >> So the question is - is it possible to allow to construct QString from >> unicode literal?
Giuseppe D'Angelo (12 May 2020 19:48) replied: > "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). Would it suffice to skip the QString(char16_t *) constructor and, instead, have a QString(QStringView) constructor ? I guess calls to functions taking QString would have to make one of the steps explicit, when passing a u"...", i.e. either call f(QString(u"...")) or f(QStringView(u"...")), preferring the latter (as it's future-proof against f changing signature from QString to QStingView later; note that this concern applies to Qt-using code, which may allow itself such ABI-breaks, not just Qt itself, which wouldn't, at least not once the old API has appeared in a public release). I suppose both forms are capable of exploiting constexpr and happening at compile-time, when the compiler deigns to make it so. Eddy. _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development