On 29 March 2017 at 15:31, Marc Mutz <[email protected]> wrote: >> All this makes me wonder why we should have QArrayList at all. If it's >> slated for immediate deprecation, > > I said _I_ would immediately deprecate it. Wether we do depends on a lot of > other things, too. E.g. what will happen to our other containers. > >> we perhaps should never let it out, and just tell people to use >> QVector or QLinkedList instead of QList. > > It's part of the QList exit strategy. Q6ArrayList will be one and Q6Vector the > other implementation underlying Q6List, which then will be the template alias > that contains the std::conditional that we currently have inside QList.
That sounds like we will continue to have a QArrayList. Sure, we can try to not expose it, but having a guaranteed-indirect-storate CoW list seems plenty attractive. > We can't make QLinkedList the other implementation beside QVector, since > QLinkedList does not provide an efficient index-based API (even though Qt > tried that, too: http://doc.qt.io/qt-4.8/q3valuelist.html). Like the > Q3ValueList in that link, it's a vehicle to keep old source working. Indeed, which suggests that there may be sufficient motivation for QArrayList as a separate container. _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
