[Development] Make a decision for asynchronous APIs

[Sona Kurazyan]

> -----Original Message-----
> From: Elvis Stansvik <elvstone at gmail.com>
> Sent: Friday, January 31, 2020 7:20 PM
> To: Sona Kurazyan <sona.kurazyan at qt.io>
> Cc: development at qt-project.org
> Subject: Re: [Development] Make a decision for asynchronous APIs
> 
> >
> > 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?
> 
> I don't have too much to comment on this. Would the alternative to QFuture
> in this scenario be a future class from somewhere else (std::future, ...)? And
> the Qt goodies like cancel/pause/resume/progress API would be on QTask?

Yes, that would be my preference as well. 

Best regards,
Sona