[Development] QList for Qt 6

[NIkolai Marchenko]

Ugh, apparently I answered to Lars directly instead of the whole ML >_< See
below

I do not see how this addresses the issue. You are pushing the decision to
use the compile switch or not on the same userbase who couldn't be bothered
to port away from qlist in the first place.
You are essenitally asking: "Are you sure you aren't using qlist in
specific ways?"
And the likely answer in the end will be "Eh, oooops ... hehehe"

People will use the "faster" non compatible compilation switch and *will*
break their code. It won't be Qt's fault but it *will* be perceived as such.



On Wed, May 22, 2019 at 4:50 PM Lars Knoll <lars.knoll at qt.io> wrote:

> Let’s conclude the topic of QList. I do see the concern about silent
> source breakages. Here’s what we’ll (I’ll) do then for Qt 6:
>
> 1. Rename QList to QArrayList and make QList an alias to QArrayList
> 2. Move QStringList and QByteArrayList over to inherit from QVector (that
> should be source compatible)
> 3. Rename QStringList to QStringVector (keep QStringList as a
> compatibility name), same for QBAList
> 4. Use QVector to implement QList<Foo>, if sizeof(Foo) <= sizeof(quint64)
> and Foo is movable. I’m intentionally not using sizeof(void *) here, as
> types with sizes between 4 and 8 bytes would not have stable references in
> cross platform code, so I do not believe lots of code would assume that (or
> it would have broken on 64 bit).
> 5. Add a compile time switch that allows mapping QList completely to
> QVector or to a compatibility mode where QLists of large/non movable types
> are mapped to QArrayList
> 6. For now we don’t yet want to explicitly change all our API that uses
> QList to use QVector (as that would make merging from dev a pain, let’s do
> that later this year). But to test that everything we have works with
> QVector, we’ll set the compile switch to default to mapping to QVector.
> 7. Make the implementation of QArrayList fully inline and deprecate the
> class.
>
> Let me know if there are any major concerns with this plan. It should give
> us a good compromise, where we can move all of Qt over to QVector and test
> things early, as well as providing a compatibility mode for our users
> (slower but won’t silently break).
>
> Cheers,
> Lars
>
> > On 21 May 2019, at 10:38, Giuseppe D'Angelo via Development <
> development at qt-project.org> wrote:
> >
> > Il 21/05/19 10:30, Konstantin Shegunov ha scritto:
> >> That's a hard one. Especially since very few could keep in their brain
> a list of the sizes of each and every one class from Qt. It also differs
> depending on architecture.
> >
> > I know. That's my point: we can't just break this level of source
> compatibility.
> >
> > Thanks,
> >
> > --
> > Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer
> > KDAB (France) S.A.S., a KDAB Group company
> > Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
> > KDAB - The Qt, C++ and OpenGL Experts
> >
> > _______________________________________________
> > Development mailing list
> > Development at qt-project.org
> > https://lists.qt-project.org/listinfo/development
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> https://lists.qt-project.org/listinfo/development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20190522/b1344036/attachment.html>