Qt Contributors Summit 2019 Qt 6 Changes / Migration

Qt 6 Changes / Migration Session at Qt Contributors Summit 2019

• How can we migration to Qt 6 as easy as possible and start already in Qt 5?
• For example, a unified string theory would be a relevant topic

Prominent Changes

• List/Vector ok in majority of cases (plain replacement)
• QString remains in API since QStringView reveals too much about API; will be possible to construct a readonly QString
• MetaObject indexes change, but should not cause problems except maybe iterating over all
• QVariant: Cannot remove all conversions and magic, extract base class QAny, move QVariant to a new Qt5Support library, ditto QRegExp
• OpenGL extra classes (except context and functions) will be moved to old/new QtOpenGL library -> header only, trivial
• Remove Multiple inheritance of QImage/Pixmap/QPaintDeviceWindow from QPaintDevice and others. , add a templated constructor to QPainter instead, should have minimal impact
• Add new versions of toInt(bool &ok) returning std::optional (C++17), implement old on functions top?

Migration

• u"" string should already be possible in Qt 5 at the cost of one allocation (QStringLiteral?)
• Use clazy as maintained by KDE (Sergio) to port source code
• Modernizing code helps, for example use range-based for
• Almost always auto helps

Some Proposed clazy fixes

• QLatin1String(). etc -> u""
• remove QStringRef::toString(), fix QString::midRef() -> QString::mid() etc

QStringBuilder caveat when using auto

• auto name = xmlStreamReader.name() Ok
• auto name = xmlStreamReader.name() +"B" Wrong, result is a QStringBuilder helper type with references to source strings

Other Topics

• Turn deprecations warnings off/on : Cannot reach a conclusion, ported code will cause warnings in Qt 6 initially
• ABI implications of new property stuff, mixing old and new properties, BC challenges when extending properties? Requires some black magic in C++ 17