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 _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
