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

[Vitaly Fanaskov]

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.

This is also very good point. STL is definitely ugly, Qt provides much prettier API.
We actually can use std::* in implementation, but should provide Qtish interface. It also would be nice, because:
1) Avoid using std::* in interfaces
2) Keep API convention users get used to
3) Keep all Qt guarantees about compatibility
4) Give developers freedom in improvements API

After all, STL updates approximately once in three years. So, we can easily follow all changes and update Qt API accordingly. It’s probably worth reusing something (e.g. time suffixes from chrono), but carefully.

--
Best Regards,

Fanaskov Vitaly
Senior Software Engineer

The Qt Company / Qt Quick and Widgets Team

On 29 May 2019, at 19:42, Kevin Kofler <kevin.kofler at chello.at<mailto:kevin.kofler at chello.at>> wrote:

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)

_______________________________________________
Development mailing list
Development at qt-project.org<mailto:Development at qt-project.org>
https://lists.qt-project.org/listinfo/development

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20190529/8dda8dfd/attachment.html>