And on the matter of "you should have read all the discussions so you had years to port away from QList"
I am sorry, what? QList was never indicated as deprecated or somehow undesirable in Qt docs far as I know and not every developer actively reads these topics. Moreover with all the discussions that were going on about "somehow saving the user the pain for Qt6" I am sure a lot of ppl who *knew* still didn't bother. This *really* is not something I expected being thrown around as a serious argument here. On Mon, May 20, 2019 at 2:18 PM NIkolai Marchenko <enmarantis...@gmail.com> wrote: > I was speaking strictly of the cases where users already have auto used in > their code _expecting it to signify owning container_. > Imagine if they expect ownership in these cases. If the actual owning > container that exists somewhere else somehow goes out of scope > when the user expected to own it for a while (but declared it as auto) you > are introducing nasty bugs while maintaining SC. > > On Mon, May 20, 2019 at 12:35 PM Edward Welbourne <edward.welbou...@qt.io> > wrote: > >> On Thu, May 16, 2019 at 9:35 PM Vitaly Fanaskov <vitaly.fanas...@qt.io> >> wrote: >> >> If a user needs a regular container, range might be simply assigned >> to it. >> >> NIkolai Marchenko (16 May 2019 20:38) replied >> > It depends on what you expect the average usecase to be. >> > If we assume that a regular container is generally more used then you >> are preventing ppl from "almost always auto" >> >> First: I don't believe we've committed to "almost always auto" as a Qt >> coding style (it leaves the reader to work out what everything is, which >> I - as a reviewer - really don't like). Being explicit about what type >> of container you want to use has its virtues (albeit, as Marc points >> out, auto's ambiguity is good when the API is in flux). >> >> Second: if we return a container, the API designer has to decide which >> type of container to return, which forces the caller to do a conversion >> if that wasn't the type they wanted. Returning a range lets the caller >> chose how to store the values. >> >> However, that's only a win if the supplier wasn't already holding the >> values in a container, which CoW lets us return cheaply. >> >> The win (assuming C++ ranges work enough like python generators) comes >> when you're traversing some population of things and selecting some to >> return, while skipping the rest; classically that might be implemented >> as a traversal with a call-back object to act on each item; but a range >> lets the caller just iterate over the results found, turning the >> call-back's code into a loop's body, which is far easier to follow; or >> collecting the results into a container of the caller's choosing. >> >> Eddy. >> >
_______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development