[Development] QList

[André Somers]

Op 25/05/2017 om 12:38 schreef Konstantin Tokarev:
>
> 25.05.2017, 02:19, "Ville Voutilainen" <ville.voutilainen at gmail.com>:
>> 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. 
> Other problem, that IMO is more serious, is that Qt *requires* user to use QList,
> by returning or taking it as and argument in various places. That's almost only
> reason why I use QList in my code[*].
>
> If Qt 6 APIs are changed from QList to QVector, lots of user code dealing with
> this APIs will break, unless QList will become an alias of QVector.
>
> [*] And, fwiw, almost only reason I use QString, but that's off-topic here
>
I think you bring up a good point there. Would not the best way out be
to fix exactly this problem? If these functions would not return a
container, but some type of view into such a container, that would leave
users free to choose the type of container they need for their job
instead of being forced into the direction Qt choose for its API. A view
might take the form of a pair of iterators, a range, or perhaps even
some specialized class that basicaly wraps a pair or iterators and that
provides convenience functions to/from the Qt containers.

André