[Development] QList for Qt 6

[Mutz, Marc]

On 2019-05-20 15:52, Lars Knoll wrote:
> Hi Marc,
> 
>> On 20 May 2019, at 14:39, Mutz, Marc via Development
>> <development at qt-project.org> wrote:
>> 
>> Hi Lars,
>> 
>> I'm on record for claiming QList needs to die, and I work for a
>> company that still makes part of its living by porting Qt 3 apps to
>> Qt 4 (and 5). So I should be celebrating if you create more
>> potential work for KDAB, but I'm actually ok with keeping QList.
>> 
>> Provided it vanishes from each and every Qt API.
>> 
>> Whether to call it Q5List or QArrayList or continue with QList
>> doesn't matter. Actually, I'd err on keeping QList, to minimize
>> porting. What I want to avoid is to break user code silently. Asan
>> is a runtime-checker, the code must actually be exercised, which is
>> trivial for QToolBox but might be problematic if it's in, say, error
>> handling code. And you rightfully pointed out that it's very hard
>> for a static checker to find cases where reference stability is
>> used. Not impossible, but hard.
>> 
>> I want to understand what problems you see with keeping QList as-is
>> with deprecated implicit conversions to and from QVector, assuming
>> all Qt API that uses QList is ported to QVector.
>> 
>> The way I see it:
>> 
>> Given:
>> * QList stays as-is
>> * No Qt API takes or returns QList anymore, but QVector
>> * QList implicitly converts to QVector, and vice versa
>> * These implicit conversions are marked as deprecated
>> 
>> Pros:
>> * Old (user) code doesn't silently change the meaning
>> * Old (user) code continues to work, lets users port at their own
>> leisure
>> * Receiving objects can be done with auto variables for optimal
>> performance
>> or with QList for old code.
>> * Users passing QLists into Qt APIs enjoy the implicit conversion to
>> QVector
>> + This might be slow, but you say yourself that speed doesn't
>> matter
>> for 95% of the code and it's easier to find and fix slow code in
>> the 5% than it is to find a silent reference stability breakage
>> in
>> the 95%.
>> 
>> Cons:
>> * Unported code will get penalized by the implicit conversions from
>> and to QList
>> + But using the 95/5-argument here, again: it's easier to find
>> where the app
>> got slower in the 5% than to find a bug in the 95%.
>> 
>> The pros far, far outweigh the cons. I'd very much like to know in
>> which aspects inheriting QList from QVector fares better than this
>> proposal.
> 
>  I’m not proposing to make QList inherit QVector. Actually, I’m
> making it an alias to QVector. See
> https://codereview.qt-project.org/c/qt/qtbase/+/242692 .
> 
> With that, one option could be to make the alias dependent on a
> compile time setting for the application code (ie. have a simple
> define whether we do
> 
> using QList = QVector
> 
> Or
> 
> using QList = Qt5Support::QList

Ok, QList as an alias for QVector takes care of the technical issues I 
have with using inheritance. It doesn't address my concerns regarding 
breaking QList behaviour. What purpose is served to call something QList 
that is in fact a QVector? Please spell it out for me, as I don't see 
it.

>> My fear is that QList : QVector will lead to some of Qt's APIs
>> continuing to use QList, which would lock Qt into QList for another
>> major release cycle and only postpone the inevitable QList removal.
> 
> No, of course we need to get rid of all references to QList in our
> APIs.

I appreciate that commitment very much.

Thanks,
Marc