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.
Philippe On Thu, 23 Apr 2020 07:53:04 +0000 Lars Knoll <lars.kn...@qt.io> wrote: Ive had similar thoughts lately as well. I can see a few more reasons to keep QList as the name of the class: > > > (3) Less ambiguity with QVector(2/3/4)D > (4) QList is the known type and the one promoted in our API so far, so no > need for people to re-learn Qt > (5) a lot less code churn for us and our users > > > So Im in favour of doing this and keeping QList as the name for the class. > > > Cheers, > Lars > >> On 23 Apr 2020, at 09:43, Simon Hausmann <simon.hausm...@qt.io> wrote: >> >> Hi, >> >> >> In dev we've had QVector being an alias for QList for a while now. For the >> 6.0 release this particular topic (QList/QVector) suggests two goals (among >> others): >> >> >> (1) Use the same type throughout the public API of Qt. >> >> >> (2) Make it easy for our users to maintain a code base that works with >> Qt 5 and 6. >> >> >> >> >> In the light of those two goals, I think we should keep using QList as the >> type in the public API. I don't think we should do a search and replace >> activity and switch to QVector. In the light of that, I would like to >> propose simply deprecating QVector and stick to QList everywhere. >> >> >> >> >> What do you think? >> >> >> >> >> Simon >> _______________________________________________ >> 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
