[Development] How qAsConst and qExchange lead to qNN
ulf.hermann at qt.io
Wed Nov 9 08:18:58 CET 2022
> I don't want to take the Qt containers away from Qt users. I want to get
> rid of their use in our APIs, so that both the Qt implementation as well
> as our users are free to choose the best container for their needs
> instead of having to pick from one of the public Qt containers.
I would like to know how that is supposed to work in practice. We have a
lot of public API dealing with Qt containers all over. What are you
going to do to, for example, to
void addActions(const QList<QAction*> &actions);
in qwidget.h? What should it look like when we're done and our users are
free to choose the best container for their needs?
Mind that I'm specially interested in this because I'm currently facing
a similar problem, making different container types available in QML.
QML has its own poor man's "range" type in the form of QQmlListProperty
and it's terrible.
> >> Q_FOREACH
> > [I can make 100% correct predictions about changes I intent to push,
> > too. What's the point?]
> I have no desire to touch the implementation of Q_FOREACH, ever. I did,
> unwillingly, when its users suffered unnecessary pessimisations in the
> past, but the port to C++20 ranged-for-with-init is not of that kind.
Waiting for someone to push a patch with code you've already outlined
and then approving it is pretty much the same as changing it yourself.
You just don't need any approval for that ...
More information about the Development