> 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.
> 
> 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


_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Reply via email to