[Development] Make a decision for asynchronous APIs

[Sona Kurazyan]

In my understanding a future represents a single result of a computation which will be available sometime in future, it doesn’t assume reusability, progress reporting, etc. If you take a look to other implementations of a future (like boost::future, folly::future or std::experimental::future), none of them has this “extra” functionality similar to QFuture, none of them represents a set of results as QFuture does. This may be confusing for people who are expecting QFuture to be a typical future they are used to, and I actually saw some complains about that.

Best regards,
Sona


From: Иван Комиссаров <abbapoh at gmail.com>
Sent: Saturday, February 1, 2020 1:56 PM
To: Sona Kurazyan <sona.kurazyan at qt.io>
Cc: development at qt-project.org
Subject: Re: [Development] Make a decision for asynchronous APIs

Can you please elaborate the difference?


31 янв. 2020 г., в 17:24, Sona Kurazyan <sona.kurazyan at qt.io<mailto:sona.kurazyan at qt.io>> написал(а):

Additionally, there are some discussions about QFuture being a mix between a “Task” and a “Future”. One of the options of improving this situation is to make a QTask (or QJob) out of the current QFuture. But then the question is: should we also support a “classic” QFuture? Is there a value in having it, when there are already some very advanced implementations of a future?


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20200201/936e43bb/attachment.html>