[Development] QList

[Lars Knoll]

> On 18 Mar 2017, at 19:15, Thiago Macieira <thiago.macieira at intel.com> wrote:
> 
> Em sábado, 18 de março de 2017, às 10:37:15 PDT, Marc Mutz escreveu:
>> Ville,
>> 
>> A word of warning: when it comes to QList, there's a very vocal minority
>> that claims that either QList works perfectly well or else ain't so bad.
>> But afaict, there's consensus between the people who actually count (sorry
>> to be blunt, but Qt is not a democracy, but a meritocracy) that QList as-is
>> currently was a mistake and needs to go in Qt 6. The only difference in
>> opinion is how to cushion the fall.
>> 
>> Lars, Thiago: it would be nice if you could confirm (or deny, in case I
>> misinterpreted) the above as soon as you can. Otherwise this thread will
>> derail massively again.
> 
> I think we're in agreement.

Yes, we agree that QList as it is today is nothing we want in Qt 6. But we can’t simply remove it neither, as it would break way too much user code out there.
> 
> During Qt 5 development, I began the process of rewriting QList so it suffered 
> less from the problems it suffers, but I ran out of time and it was also an 
> impossible task given the requirement to support C++98 at the time (no 
> <type_traits>). The objective was to make QList a hybrid: a real vector with 
> no overhead for types smaller than 32 bytes, a pointer list otherwise.
> 
> But as time went by, I don't think that hybrid approach is valid. A vector is 
> simply much better. For Qt 6, I'd like QVector and QList to be the same type 
> -- possibly even interchangeable, so that code that began using QVector in 
> Qt 5 will be able to "return" QList.

+1 on this. They are pretty much API compatible, so this should be rather straightforward. 

This does cause a change in runtime behaviour for people storing very large objects in the container that we will need to document carefully. But it will IMO work very nicely for 95% of it’s uses, and even give some performance benefits in those cases.
> 
>>> In other words, introduce generic code where there wasn't generic code
>>> before - users writing
>>> non-generic code calling non-templates that return QLists will need to
>>> use deduction or a metaprogramming tool.
>> 
>> No, that is false. You can keep using QList for now everywhere you used it
>> so far, in non-generic code. Nothing changes for existing types. And for
>> new types, the compiler will make sure that you don't get away with QList.
>> We do recommened to use auto to receive QLists to avoid having to port
>> these code lines manually come Qt 6. I do not consider auto variables
>> "generic code".
> 
> I don't agree with the poisoning. See my comment in the QStringView review. I 
> agree we should teach users to port away from QList, but not hat it's such a 
> terrible class that they have to port right now, before using new 
> functionality. 

Agree with Thiago. If we do turn QList into QVector, there is IMO no need to poison things right now. Simply replacing all our uses for Qt 6 and maybe deprecating QList then should be enough.
> 
>>>> 4. Provide QArrayList for code that needs stability of references
>>>> (stability
>>>> 
>>>>   statically checked in Qt 5, enforced in Qt 6).
>>> 
>>> It seems that (4) is perfectly safe, whereas (2) and (3) are breaking
>>> changes; to what extent, I would like to know.
> 
> Actually, we can get started in (4) right now. This will allow porting now.

That’s probably a good idea. It would help to have that class in 5.10 or latest 5.11.
> 
>> (2) is possibly breaking, yes. We should intercept by deprecating
>> QList::toSet() and re-adding it as a free function.
> 
> Isn't that simply std::copy?
> 
>> (3) is breaking nothing for existing code, since it only applies to new
>> types. New types don't magically show up in your source code. You have to
>> introduce them yourself. As for existing generic code, it's a
>> source-incompatibility that is accepted, because it can be fixed by using
>> auto variables. Or you don't use the new type at all. I mean, we're not
>> talking about QString here. With very few exceptions, any type we're adding
>> now will not get widespread use before Qt 6, anyway. One exception
>> hopefully being QStringView.
> 
> It's abou the message it brings. Doing that is telling people to port right 
> away, not when they have the time to do it properly.
> 
>> Indeed, if it was easy, it would have been done long ago. But it's
>> nonetheless absolutely necessary. Q6String will not fit into a QList
>> anymore. QVariant and QModelIndex already don't. And given the extensive
>> use of QVariant in QML/Qt's property system, I don't think anyone can be
>> happy about the per-element memory allocation in QVariantList.
> 
> Aye.

Yep, we all agree on this :)

Cheers,
Lars