> Volker Hilsheimer via Development <development@qt-project.org> wrote:
nice pragmatic overview :) Philippe On Wed, 9 Nov 2022 09:15:16 +0000 Volker Hilsheimer via Development <development@qt-project.org> wrote: > Hi, > > > On 8 Nov 2022, at 22:20, Marc Mutz via Development > > <development@qt-project.org> wrote: > > To summarize: > > - I will not accept responsibility for any container rewrites in any of > > the Qt major version changes. I was not involved in any of these > > decisions, and where I was involved in the discussion, my suggestions > > were not followed. > > > Indeed. And those who were involved, and made those decisions, did so with > best intentions. > > Lets please keep a respectful tone in this conversation. Finger-pointing is > not going to get us anywhere, and I hope we can learn and come up with good > steps forward without making this personal. > > > > - I do not want to take Qt containers away from Qt users. Instead, I > > want our APIs to stop forcing our users (and us) to use (owning) Qt > > containers. > > > It would be great if we can add mechanisms in Qt that allows allows people to > iterate e.g. over the selected rows in a QItemSelectionModel, without Qt > having to create a temporary list with a ton of memory allocation, just so > that the calling code can throw the list away after iterating over it once. > There are many APIs in Qt where the returned value is going to be temporary. > QObject::findChildren is another example - we iterate over objects to create > the list, then we return the list, then client code iterates over the list to > do something with the objects (perhaps only the first). > > Thats clearly inefficient, and it impacts Qt in many places and modules. > Making a e.g. std::span available with appropriately implemented iterators > would help with that, with the possible foot-gun that people that keep that > std::span around will end up with invalidated iterators. > > But I do believe that we can add APIs that are iterator and ranges friendly > to Qt without tossing out the baby with the bathwater and without breaking > tons of code and patterns. For APIs where we simply return a stored QList we > want to be able to return that QList as a shared copy. If we would only > return a std::span as a view on the stored list, then client code will need > to construct their copy from that std::span. That is equally silly. > > I really think that we can add many of those new capabilities without causing > unnecessary churn, and without introducing incompatibilities or deprecations. > And in the few cases where we cant without seriously compromising the > end-goal or quality of the overall API, a public discussion here on the > mailing list is necessary. > > > Volker > > _______________________________________________ > 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
