[Development] QList for Qt 6

[NIkolai Marchenko]

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.welbourne at qt.io>
wrote:

> On Thu, May 16, 2019 at 9:35 PM Vitaly Fanaskov <vitaly.fanaskov at 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20190520/0f04d373/attachment.html>