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