[Development] Qt 5 types under consideration for deprecation / removal in Qt 6

[Alberto Mardegan]

On 29/05/19 13:53, Mutz, Marc via Development wrote:
> == QSharedDataPointer / QExplicitlySharedDataPointer ==
> 
> These are basically Qt-internals, and should never have been public in
> the first place. It's _because_ they are public that we have two of
> them, and soon a third one (properly non-public):
> https://codereview.qt-project.org/c/qt/qtbase/+/115213 That commit's
> message also explains what's wrong with the QSDP and QESDP.

No way :-)
I've never used QExplicitlySharedDataPointer myself, but
QSharedDataPointer is very useful; it should not be removed in Qt6.

And if it gets deprecated, an equally easy to use alternative should be
provided.

> == QScopedPointer -> std::unique_ptr ==
> 
> Suggested by Thiago on
> https://codereview.qt-project.org/c/qt/qtbase/+/261553
> 
> I agree. We now have std::unique_ptr, and it's movable. QScopedPointer
> had the problem that it didn't know what it wanted to be:
> boost::scoped_ptr or std::unique_ptr. A real scoped pointer would not
> offer release(), a unique_ptr would need to provide move semantics.
> QScopedPointer has release(), but no moves (were proposed, but not
> accepted).

I never used release(), and I'm fine if std::unique_ptr is used as the
implementation. But the name QScopedPointer is so much better than
unique_ptr, that I wouldn't like to see it deprecated.

> == QLinkedList -> std::list
> (https://codereview.qt-project.org/c/qt/qtbase/+/261421) ==
> 
> Of the Qt containers, this one is the most-unused (in Qt code), as well
> as the one that's furthest behind it's STL counter-part. Whenever I use
> std::list, I use it for splice(), a function that just cannot be added
> to a CoW container. Qt is already almost completely QLinkedList-free.
> Let's bury QLinkedList.

I bet it's unused because everyone is using QList. But once we deprecate
QList, people will start asking for a CoW version of std::list.

It's not clear to me why splice() cannot be implemented: it would just
mean that the list data would detach as in all other non-const methods.
Or am I missing something?


In general, I agree with the plan to make our classes more interoperable
with the STL, but I vote for keeping our own CoW classes and naming
conventions.


Ciao,
  Alberto

-- 
http://www.mardy.it - Geek in un lingua international