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.kof...@chello.at<mailto:kevin.kof...@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@qt-project.org<mailto:Development@qt-project.org> https://lists.qt-project.org/listinfo/development
_______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
