[Development] QList

[Christoph Feck]

On 25.05.2017 19:03, André Somers wrote:
>> On 25 May 2017, at 18:40, Christoph Feck <cfeck at kde.org> wrote:
>>
>>> On 25.05.2017 13:53, André Somers wrote:
>>> Op 25/05/2017 om 12:38 schreef Konstantin Tokarev:
>>>> 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.
>>
>> If you only return a view to the container, then if the container is modified, the return value is no longer valid. Returning a full container (referenced, with copy-on-write semantics) will not have this problem.
>
> Sure, but do you always or even most of the time need that feature? If not, why always pay for it? And it would be easy to turn it into a container when needed, but then you can choose the most appropriate for your task instead of always getting a QList (now) or a QVector (Qt6?)

Indeed in most cases you really do not need this feature, but unless 
there will be a compile-time error, we will see subtle bugs/crashes 
introduced where that feature was relied upon.

I have seen many crashes in the big KDE code base from Qt3->Qt4 porting 
just because the code compiled fine (e.g. after mass-renaming class or 
method names), but semantics changed in subtle or unexpected ways.