[Development] QList

[Marc Mutz]

On 2017-04-25 20:45, Matthew Woehlke wrote:
> On 2017-04-25 09:48, Thiago Macieira wrote:
>> Basically the discussion is: what should happen to QArrayList<int> or
>> QArrayList<void *>?
>> 
>>  a) fail to compile
>>  b) become an array list
>>  c) become a vector
>> 
>> I point out that (c) is what QList does, and we don't need the same 
>> behaviour
>> as QList already has.
>> 
>> Marc proposed (a), which is the simplest solution to the problem. I 
>> wanted
>> (b), which would require duplication of code and Marc was unwilling to 
>> do
>> that.
> 
> Why would a container type fail to compile for such basic types? For
> what types *would* it compile? It would help for context if people
> didn't have to read the review request.
> 
> (Okay, having gone and read the review request...)
> 
> FWIW, I think (b) makes more long-term sense... if we provide a
> container type whose purpose is to makes explicit guarantees about
> indirect storage and guaranteed reference stability, I'd hope that
> container would work for *all* types.
> 
> Maybe an alternate approach makes sense?
> 
> 1. Rename QList -> QArrayList.
> 2. Remove special case of inline storage.
> 3. Add QList<T> as an alias to either QArrayList<T> or QVector<T>
> depending on T.
> 
> No code duplication, no change in *observed* behavior of QList, but
> QList itself can be deprecated and eventually removed. (Maybe even in
> 6.x, since the removal is BC, and there is a work-around - declare and
> specialize it yourself - for anyone that for some reason can't just
> switch to QVector/QArrayList.)
> 
> And, no, I don't think std::vector<std::unique_ptr<T>> can replace
> QArrayList; the item semantics are too different from std::vector<T>.
> (I'd like to see a std::indirect_vector or such...)

This is precisely what I suggested previously in this thread. For Qt 6.

The discussion here is what to do in Qt 5. My opinion on this is covered 
in my latest QList exit strategy that you will find in this thread, too.

Thanks,
Marc