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

[Kevin Kofler]

Mutz, Marc via Development wrote:
> == QSharedDataPointer / QExplicitlySharedDataPointer ==
> 
> These are basically Qt-internals, and should never have been public in
> the first place.

Why? They are essential to be able to implement one's own CoW types and thus 
write idiomatic Qt code.

I use QSharedDataPointer a lot, and my code will likely be stuck on Qt 5 or 
6 forever if they get removed resp. deprecated in Qt 6.

> == Q_FOREACH -> ranged for loops
> (https://codereview.qt-project.org/c/qt/qtbase/+/147363) ==

As I already wrote when Q_FOREACH was deprecated to begin with, the problem 
is that this replacement is dangerous because ranged for does not copy (so 
legacy code that accidentally changed the container, which was harmless with 
Q_FOREACH, will crash and burn with ranged for) and can be inefficient with 
CoW types if done carelessly because ranged for does not automatically 
constify the container (whereas Q_FOREACH made a const copy).

> === related: Q_FOREVER -> for(;;) ===

This just reduces readability for no maintainability gain whatsoever.

> == Java-style iteration
> (https://codereview.qt-project.org/c/qt/qtbase/+/262344) ==

The Java-style iterators are much more convenient to use than the STL-style 
ones, and quadratic loops can be accidentally written with both.

> == QScopedPointer -> std::unique_ptr ==
> == QLinkedList -> std::list
> == qHash() -> std::hash ==
> == MT plumbing ==
> === QAtomic -> std::atomic ===
> === QMutex / QReadWriteLock -> std::*mutex* ===
> === QMutexLocker -> std::unique_lock ===
> === QWaitCondition -> std::condition_variable(_any) ===
> == QQueue / QStack -> std::queue, std::stack ==
> == QSharedPointer / QWeakPointer -> std::shared_ptr/weak_ptr ==
> == QSet / QHash -> std::unordered_set/map ==
> == QMap -> std::map ==

All these have the same issue: You are proposing to deprecate Qt types in 
favor of STL types, which have a different naming convention (_ vs. camel 
case) and often terse, harder to understand names (e.g., ptr vs. Pointer, 
push/pop for a queue vs. enqueue/dequeue, etc.), and which do not support 
CoW (all the container types in your list), nor Java-style iterators, for 
that matter.

I think Qt should keep striving for completeness and not require its users 
to mix&match Qt and STL usage with all the STL's ugliness.

        Kevin Kofler
        (who thinks C++ is a great language except for its standard library)