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.de...@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@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Reply via email to