[Development] The future of smart pointers in Qt API

[Matthew Woehlke]

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