On 03/02/2020 16.25, Giuseppe D'Angelo via Development wrote: > Other people are free disagree with this. (For instance, in Qt 6 the > decision (which I disagree with) was to introduce similar gratuitous and > very hidden source-incompatible changes, e.g. with QList and QHash both > breaking iterator stability.
Wait, *what*?! I literally *just* wrote code that relies on that. Since when do *associative* containers not have iterator stability? (For that matter, why is *QList* breaking iterator stability? We can't be talking about "for 'small' types", because that was never a thing. QList is silently replaced with QVector?! I thought we decided *not* to do that!) >> Indirectly, standard containers have no direct equivalent of .contains() https://en.cppreference.com/w/cpp/container/map/contains Getting a sane API into STL isn't *completely* hopeless. Unfortunately, we probably won't be seeing `is_empty` any time soon :'(, and we're still missing `value_or` (for `[unordered_]map`; `optional` has it...). (I'm still hoping we will eventually get an STL2, with a completely redesigned API, making sane choices and heavily inspired by the Qt container API.) That said, I find https://github.com/Kitware/qtextensions/blob/master/core/qtGet.h *extremely* useful. -- Matthew _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development