I’m confused about how it would even be possible to contemplate abandoning the implicit sharing paradigm given how deeply embedded it is within *all* of Qt, going well beyond the container classes: http://doc.qt.io/qt-5/implicit-sharing.html
Seems like Qt has adopted a core design principle here (which has proven it’s value and is simple enough to understand) and it is simply not up for discussion changing such a thing? A Qt using a completely different design principle for the containers vs. everything else would be thoroughly confusing to say the least. - Randy > On Jan 19, 2016, at 8:11 AM, Marc Mutz <marc.m...@kdab.com> wrote: > > On Tuesday 19 January 2016 15:00:33 Marc Mutz wrote: >> Now: >> 1. Tell people to use auto when receiving Qt containers returned from a >> function. >> 2. Tell people to stick to the std-compatible API subset. >> 3. Deprecate Q_FOREACH and recommend range-for (+ qAsConst(), where >> needed). > > 4. Port as many internal containers (those that are not exposed in API) to > std > ones. > >> In Qt 6: >> 1. Implement the containers on top of std ones, dropping CoW, providing >> simple, fast (when moving), conversion between std and Qt containers. >> 2. Deprecate the std-incompatible API subset >> 3. Remove Q_FOREACH >> 4. Deprecate qAsConst() > > 5. Use Qt containers only in the interface, not the implementation. > >> In Qt 7: >> 1. Drop all Qt container API use from the library, use only std ones. >> 2. Keep the Qt ones around as deprecated, in a separate compat library. >> 3. Drop qAsConst() >> >> In Qt 8: >> Remove the Qt ones. >> >> That easily spans 10-15 years, but at least we'd have an exit strategy. >> >> If, otoh, by Qt 6, we'd still continue doing nothing, as before, we'll >> lose another four years. > > -- > 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 Experts > _______________________________________________ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
