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. Let’s 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). That’s 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 can’t 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
