[Development] Make a decision for asynchronous APIs

[Иван Комиссаров]

Ah, thanks. 

Now I see why I am confused - in my understanding Task is something more similar to std::function in terms that it it something that can be stored and executed (somehow) later.
E.g. instead of doing something like
auto future = QtConcurrent::run(foo, value1, value2);
We do
auto task = QtTasks::createTask(foo, value1, value2);
// do stuff
auto future = QtConcurrent::run(task);

I do not see why cancellation/progress reporting makes QFuture «not a future» - it’s simply an interface to an async execution.
Stored function call is something different, on the other hand.

Can you also elaborate what do you mean by «reusability»? Ability to do something like future.restart(); ?

> 1 февр. 2020 г., в 14:44, Sona Kurazyan <sona.kurazyan at qt.io> написал(а):
> 
> 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/fc2fcb90/attachment-0001.html>