[Development] QList for Qt 6

[NIkolai Marchenko]

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 <enmarantispam at 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.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/35595db5/attachment.html>