Asynchronous APIs in Qt

The module description can be found here QtConcurrent 

The general question being asked is if we want to keep/deprecate the current implementation of

• QFuture
• QFutureIterator
• QFutureWatcher
• QFutureSynchronizer

and the implementation of

• QtConcurrent High-level APIs.

Some discussion on the mailing list can be found here and in the related task (QTBUG-61928).
There are a also a code and run generator using these APIs that can be found here qtconcurrent and a related discussion happened here

Also there needs to be mentioned that Qt Creator and the Qt Installer framework use a extended/modified version of the above mentioned APIs in there own have extensions Link implemented to better use the above APIs source code.

Some further links around QFuture, QtConcurrent:

• KDE: asyncqt
• Ben Lau: AsyncFuture
• Chaining QFutures: QFutureBuilder
• Tasks that should be reevaluated: Jira
• Blog post: Multithreaded Programming with Future & Promise

Some research has already been done and what we gathered so far:

• QFutureInterface should become a QPromise and should be properly documented.
• QFuture should support continuations. Add QFuture::then, to make it similar to the upcoming C++20 std::future.
• Deprecate the job-like API of QFuture (progress, pause, cancel, etc.) and support of multiple results.
  These are specific to QtConcurrent, and don't make much sense for a QFuture for general use.
• If we keep QtConcurrent (seems like we have to, because the parallel algorithms in C++17 do not support executors), we still need to have a future with the old functionality
  (progress, pause, cancel, etc.), so we can make QtConcurrent::future out of the current QFuture and implement it based on the new QFuture.
• Add the following possibilities for creating a QFuture:
  • add something like qAsync (similar to std::async) in QtCore, which basically does the same as QtConcurrent::run
  • add something like make_ready_future and make_exceptional_future
  • Support future composition similar to when_all and when_any
  • Add unwrapping constructor that unwraps the outer future of a wrapped future (QFuture<QFuture<T>> -> QFuture<T>)
• Maybe also add QPackagedTask to keep compatibility with STL.

Since both the implementation in Qt Creator and IFW use QFuture|QtConcurrent in a slightly different manner, it might also make sense to evaluate and implement a more Task/Job like oriented abstraction, for example found in C#:

• Task
• Task<T>
• TaskCompletionSource (Promise alike)

or ThreadWeaver, KJobs

• KJob
• KCompositeJob
• KJobTrackerInterface

So probably the first question that needs to be answered is if we want to go/keep the Future-Task kinda mixed design or if we want to strip the implementation down and add/improve on missing features and stuff std::future will bring first with C++20?