On 18 March 2017 at 19:37, Marc Mutz <[email protected]> wrote: >> In other words, introduce generic code where there wasn't generic code >> before - users writing >> non-generic code calling non-templates that return QLists will need to >> use deduction or a metaprogramming tool. > > 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. :) I don't use them when they introduce a possibility that the type I *want* changes to another type. That might well *not* be a case for a QList->somethingelse transition. >> > 3. Disable QList for all new QFoo value types (by specializing >> > QList<QFoo> as >> > >> > an empty class). >> > >> > 4. Provide QArrayList for code that needs stability of references >> > (stability >> > >> > statically checked in Qt 5, enforced in Qt 6). >> >> It seems that (4) is perfectly safe, whereas (2) and (3) are breaking >> changes; to what extent, I would like to know. > > (2) is possibly breaking, yes. We should intercept by deprecating > QList::toSet() and re-adding it as a free function. > > (3) is breaking nothing for existing code, since it only applies to new types. > New types don't magically show up in your source code. You have to introduce > them yourself. As for existing generic code, it's a source-incompatibility > that is accepted, because it can be fixed by using auto variables. Or you Fair enough, but since it's a source-incompatibility, it *is* a breaking change. What, if anything, it really breaks is the important question. >> > In Qt 6: >> > >> > 5. Replace all QList uses left with ... what ? QVector? std::vector? >> > >> > -> separate discussion >> > >> > 6. Kill QList or keep it as a deprecated class. >> >> This certainly seems feasible, but the migration and the extent of it >> its interesting. There's a fair bunch >> of QList-using code out there, afaik. > > Indeed, if it was easy, it would have been done long ago. But it's nonetheless > absolutely necessary. Q6String will not fit into a QList anymore. QVariant and > QModelIndex already don't. And given the extensive use of QVariant in QML/Qt's > property system, I don't think anyone can be happy about the per-element > memory allocation in QVariantList. 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. _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
