On Saturday 18 March 2017 20:05:59 Ville Voutilainen wrote: > On 18 March 2017 at 19:37, Marc Mutz <marc.m...@kdab.com> wrote: > > > No, that is false. You can keep using QList for now everywhere you used > > it so far, in non-generic code. Nothing changes for existing types. And > > for new types, the compiler will make sure that you don't get away with > > QList. We do recommened to use auto to receive QLists to avoid having to > > port these code lines manually come Qt 6. I do not consider auto > > variables "generic code". > > Right. I, however, do consider them generic code. :)
You're free to call a chicken a pig for your own entertainment, but in the interest of understanding what everyone says, please stick to established definitions. Generic code is generally understood to be code that uses generic programming, which in turn is defined as [...] an approach to software decomposition whereby fundamental requirements on types are abstracted from across concrete examples of algorithms and data structures and formalised as concepts, analogously to the abstraction of algebraic theories in abstract algebra. (Wikipedia, citing Stepanov/Musser). So neither auto i = int{0}; nor QHash<int, QStringView> hash = ...; auto values = hash.values(); are examples of generic code. > Ok. I think the first thing we need is the QList replacement, whatever > it is. I think the poisoning > ideas can follow that, if at all. That, at least, is simple: QVector is currectly the only viable choice. What to do with QVector in Qt 6 is in open debate. Thanks, Marc -- Marc Mutz <marc.m...@kdab.com> | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development