Qt Contributor Summit 2019 - QtCore

Session notes.

Recap:

• https://bugreports.qt.io/browse/QTBUG-71036

Calendaring & time

• We have calendars!
• QDateTime internal state keeping requires cleanup (doable in Qt 6, e.g. remove the dpointer for good)
• Some API fixups also needed (but possibly after the internals have been cleaned up), no other deprecating expected
• Compatibility with C++20's calendaring: looking into it. Unfortunately we can't depend on it in time for 6.0, but Eddy is looking at it closely, to ensure maximum compatibility
• We need to get rid of locale-specific behavior from QDateTime (it should be C)

Containers

• QList = QVector by default in Qt 6
• s/QList/QVector/g just before Qt 6 release to avoid merging nightmare
• Not sure if to keep Qt5List. We need more evaluation about how much code breaks (e.g. when Creator, KDE port it). Not so many fixes were required in Qt but this was after many fixes have already landed after Clazy passes in Qt itself.
• QPair=std::pair => no brainer
• QHash in terms of std::unordered_map: Lars, Peppe experimented on it, it "works", esp. after
• Concerns regards std::unordered_map itself -- it's not great in terms of performance (or: it's "as bad" as QHash, so the only save is the maintenance). Should we look at other unorderd_map implementations under BSD? What about qHash and the seeding?
• QMap => std::map, yes
• QLinkedList => Qt5LinkedList
• (Need to clarify what ends up in a Qt5Support library)
• Do we need to provide generic accessors for arbitrary containers, esp. in the light of ranges added to C++20? (And what about things like toSet, toList, etc.?) Concerns raised by starting including std headers all over the place.

QString, QStringView, QByteArray

• QByteArray
  • should be ASCII only, not Latin1 (e.g. toUpper() toLower() printf() etc.)
  • should this be a stopgap measure towards a Qt7 QByteArray for std::byte
    • we can "take" std::bytes without problems; returning not really
    • Also related: QTBUG-64746
  • what would be the advantage of QByteArray in terms of std::byte vs. a QVector<std::byte>? If it's substring search, does it make sense to look for a std::byte needle?
  • Short Bytearray Optimization? Possible
    • QTBUG-64747
    • We need to decide whether to have it "globally". We need good testcases
    • In Qt 6 design QString/QByteArray can reference to literals/constants without memory allocations so SOO won't help there
  • QByteArrayView? TO BE DISCUSSED
• QStringView
  • We need to define "what it means" when passing QString vs QStringView
  • We need to have a discussion, unfortunately we're running out of time. E.g. hasParameter(QStringView) requires hasParameter(u"foo") but not hasParameter("foo")
  • All the overloads are kind of a nightmare (for maintenance and teachability), can we streamline?
  • We need Marc in this discussion.
• QCharRef, QByteRef, QStringRef => gone in 6.0
• QStringLiteral => u""
• Naked const char * APIs should be gone
• QLatin1String future?
• Remove APIs that take (pointer, len) in favour of views

Split-up of QtCore

• QtSCXML can be moved out (note that declarative depends on it)
• PROBABLY MORE STUFF

Codecs

• Legacy text codecs implementations in Qt are going to be dropped from Qt itself; anything but UTF- codecs will require 3rd party (ICU).
• Can we require the system to be properly set up? (locale not set => is it our problem?)
• QTextCodec as an API has a few defects
  • Can we fix it? (What are the problems in the first place? Is there a bug report? Is QTextCodec a dead end / we need a new class? How much breakage?)
  • Should it be moved out of QtCore?
  • Concern is on low-end: do we want QtCore to unconditionally link to ICU, just for codecs?
    • Well it's not just codecs: QLocale, QCollation, calendars all require ICU anyhow
    • We don't strictly need this ICU linking anyhow: QTextCodec is extensible; we can move the ICU dependency to another library or plugin. Out of the box QTextCodec in Core will only provide UTF-.
• to/fromLocal8Bit and/or setCodecForLocale => deprecate and remove; conversions should be explicit...
• QXmlStream: those may require non UTF- codecs; there may be XML files in non UTF-8. How to handle those?
  • Register text codecs when linking to QtTextCodecs? Circular dependency?
  • Can QXmlStreamWriter write any other codec? Yes. Can we deprecate it right now?
• What does Qt assume on locale on UNIX systems?
  • What happens if you haven't set anything?
    • Thiago: assume it is C.UTF-8
    • Peppe: crash/warning
  • What happens if you have set an encoding we would support (via QtTextCodecs or whatever), but not UTF-8?
    • Warning and override with UTF-8
  • Special case: C (that we would support anyhow), but not C.UTF-8?
    • Thiago: assume it is C.UTF-8
    • Warning? 7 bit is perfectly compatible
  • What happens if you have set an encoding we do NOT support?
    • Andre: override the user; assume it is UTF-8
      • Peppe: at a minimum: every time we override, print a warning!
  • What happens to child processes?
    • No -- there was a warning for the user

Threading

• QRecursiveMutex split from QMutex
  • Deprecate our lockers after 6.0
  • Do we need QBasicMutex any longer? Likely no after the split
• QWaitCondition & QReadWriteLocker improvements?
  • Those can be improved, e.g. making them big enough to avoid memory allocations
• Future of QFuture
  • QFuture is still in QtCore
  • QFutureInterface was still around, but never cleaned up
    • If noone cleans it up for 6.0, move QFuture/QFutureInterface to QtConcurrent and keep it there
  • std::future / std::promise are there, but no continuations!

Paths/Filesystem

• If you know about Windows path handling: please help Eddy! (E.g. filesystem paths that are neither absolute or relative)
• Discuss if we want a dedicated filesystem path class -- we need to evaluate the impact on our API.
  • We want overloads taking std::fs::path, but not sure about a dedicated class to store paths

Other

• Regexp
  • P0169R0 - regex with Unicode character types
  • P1844R0 - Enhancement of regex
• Ville: performance concerns, std::regex implementations are still bad
• We can stick with QRegularExpression, but that poses a buildsystem question (getting rid of bootstrap). CMake may fix it. So far only a couple of bootsrapped tools will actually require it.

MetaType / QVariant

• QAny
  • like QVariant but without implicit conversions
    • e.g. in comparisons
    • all over GUI delegates (put in a date, get out a string or put in a color, get out an image)
    • will cause lots of breakages if we'd remove QVariant's behavior from .value or .toInt
  • explicit conversions are still needed
  • research required to decide whether a new class or something else is feasible
    • could we deprecate more in the existing QVariant API
  • could we use external templates to solve the template bloat and deprecate more of the .toXYZ functions
    • or is this a non-issue and needs to be removed from clazy?
  • where would this be used?
    • e.g. SQL or QML
    • remove distinction between special-cased types and user-registered types
  • path forward
    • potentially warn when a conversion occurr at runtime and offer more explicit API to use instead when this is actually desired
    • more research needed

unique_ptr <-> QObject interop

• opt-in: either QObject parent or unique_ptr keeps ownership
• there's a POC patch on gerrit but needs quite some changes throughout the code base
  • std::make_unique + std::move
  • make_child to remove "raw news"
• could help with C++ Core Guidelines and similar
• new API should be explicit about ownership
• splitting up constructors to make ownership more explicit
  • either owned via parent or not-owned
  • macros could then deprecate the non-owned one
• how should proper C++ APIs look like that are friendly to C++ programmers that transfer ownership?
  • make ownership transfer explicit via type system
• observer_ptr vs. raw ptr vs. unique_ptr
  • raw ptr is like an observer_ptr but not obvious esp. in legacy code bases
  • observer_ptr is much better in that regard, but it's in a TR and not clear if it ever gets really upstream
  • should we build a Qt specific alternative?
    • like QPointer but less overhead
  • gsl observer type alias potentially another alternative
• outcome
  • it would be good to have this concept further evaluated and offered as an opt-in way of writing Qt code
  • should be source compatible (just more overloads)