Qt Contributor Summit 2019 - QtCore

Session notes.

Recap:

Calendaring & time

QList = QVector by default in Qt 6
s/QList/QVector/g before Qt 6 releaase 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)
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.

Legacy text codecs implementations in Qt are going to be dropped from Qt itself; anything but UTF- codecs will require 3rd party (ICU).

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

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.