[Development] QtConcurrent replacement candidate

[Elvis Stansvik]

There were some discussions last year on
https://bugreports.qt.io/browse/QTBUG-61928 about the async API future
(pun intended). I'm sure there are a few old mailing list threads too.

I too would be interested in where Qt is heading in this area going
forward. We're using the current QtConcurrent APIs, and also sometimes
using the private-ish QFutureInterface to be able to use QFuture to
its full extent, which makes us feel a little dirty :)

Elvis
Den tors 1 nov. 2018 kl 00:57 skrev Denis Kormalev <kormalev.denis at gmail.com>:
>
> Hi,
>
> As part of our work projects we have a framework (named Proof and partly open sourced). Most part of it is not really interesting outside of our industry, but one of its basic ideas is heavy usage of future/promise technology with API similar to one used in Scala. We also have tasks scheduling helpers that are based on these futures.
> I would like to ask Qt community if Qt itself needs QFuture/QtConcurrent redoing and replacing with something similar to what we do.
> If community will find it interesting I'm more than happy to implement it and do everything to make it as part of Qt someday.
> Current API is a bit specific for our projects and of course need to be reworked, but main idea can be seen from examples listed at https://github.com/opensoft/proofseed#futures-examples .
> Future/Promise API can be seen at https://github.com/opensoft/proofseed/blob/develop/include/proofseed/future.h . Main idea is that all interaction is done via QSharedPointer wrappers. I assume it is not the best way to do it and probably FutureSP should be named Future (with protected inheritance from QSharedPointer and having all methods from Future) and Future should be named something like FutureData.
> Tasks scheduling is done mostly via run() function specified at https://github.com/opensoft/proofseed/blob/develop/include/proofseed/tasks.h#L181 .
> Future also has negative class named Failure, which in case of Qt adoption probably should be just a QVariant (current implementation is, as I mentioned previously, a bit specific for our projects).
>
> Anyway, I would like to start a discussion if Qt community thinks that something like that could be useful as part of Qt itself. In this case I can work on basic API with having Future inherited from QSharedPointer and show it for early API review.
> I never did anything greater than bugfixes for Qt, so I would also need few recommendations about where to start (I assume I will need a repo in qt playground for stuff like that).
>
> Another question is about legal stuff. This library is BSD-3 licensed and I assume I will need some documents from my company if this implementation will be heavily similar to existing library. If anyone can advise (again, of course if Qt community will find it interesting) I would really appreciate it. 2
>
> --
> Regards,
> Denis Kormalev
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development