[Development] How qAsConst and qExchange lead to qNN

[Ulf Hermann]

> 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 ...

best regards,
Ulf