[Development] QList

[Matthew Woehlke]

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...)

-- 
Matthew