> On 23 Apr 2020, at 11:30, Ville Voutilainen <ville.voutilai...@gmail.com> > wrote: > > On Thu, 23 Apr 2020 at 12:25, Philippe <philw...@gmail.com> wrote: >> >> Almost all the time I second your positions, but not this time ;) >> >> QList is historically a cause of ambiguity, and Qt6 is the chance to get rid >> of that. > > Indeed. QList causes confusion for the uninitiated that are aware of > the differences between std::vector and std::list > (as in Why Do These People Use Lists Everywhere? Why don't they use > Vectors?). Now we have papered over > the problem, but the name remains problematic, because QList is not a > list. In Qt5, QList is sometimes a list, > sometimes a vector, but in Qt6 it's never a list.
Well at this point and on todays hardware the linked list has become a very special-purpose container, so it might be reasonable to disambiguate the other way: “list” is a sequential container but no longer implies “linked”. It’s not a perfect naming, but we can get away with it :) QList is our chameleon sequential container whose implementation we can change to meet new requirements (to a certain degree), now and in the future. > > Switching the QVector implementation over to a type called QList and > aliasing QVector to that with the intent > of getting rid of the QVector name seems exactly backwards to me. I > would think the better approach would > be to keep dev as it is, and deprecate and eventually remove QList. QVector, on the other hand, guarantees contiguous storage and also has a place, like for graphics API as pointed out elsewhere in this thread. (We should then be careful about adding QList::constData() as public API, since that will tie down the QList implementation). - Morten > _______________________________________________ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
