[Development] QList

[Thiago Macieira]

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.

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.

> > 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. 

> > > 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.

> (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.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center