[Development] QList

[Ville Voutilainen]

On 24 May 2017 at 22:25, Marc Mutz <marc.mutz at kdab.com> wrote:
> On 2017-05-24 15:12, Konstantin Tokarev wrote:
>>
>> 24.05.2017, 15:49, "NIkolai Marchenko" <enmarantispam at gmail.com>:
>>>
>>> A semi-sane idea that I think no one has suggested yet:
>>>
>>> What if, starting from Qt6, QList becomes a wrapper for QArrayList with a
>>> contructor from this type?
>>> After all making existing code slightly _slower_ because of the wrapping
>>> overhead is way less problematic than breaking it outright.
>>> It will nudge the users of QLists that need to be fast to switch but will
>>> leave users of "default no brainer container" happy as they likely wouldn't
>>> even notice.
>>
>>
>> If existing Qt APIs switch from QList to QVector in Qt 6, such change
>> will make it hard to support both Qt 5 and Qt 6 in the same code base.
>
>
> Which is why I suggested to make QList a type alias for QVector or
> QArrayList, depending on some yet-to-be-determined criteria. Obvious
> candidates algorithms are:


I think we need to take a serious step backwards here. I, for various reasons,
got the impression that a major problem at hand is that when a user (NOT in any
template code, necessarily) uses QList<Foo>, that user doesn't know the
consequences. Mostly because depending on the characteristics of Foo,
the user doesn't know what the performance characteristics and semantics
of QList<Foo> are, because QList might or might not use (in)direct storage.

Perhaps I completely fail to understand the problem space. I (think I)
have read Marc's writings
on the subject matter, but chances are that the crux of the matter is
still escaping me.
How does it help anyone to create a new alias that still results in a
concrete type
the semantics of which still depend on the element type?