> -----Original Message----- > From: Elvis Stansvik <[email protected]> > Sent: Friday, January 31, 2020 7:20 PM > To: Sona Kurazyan <[email protected]> > Cc: [email protected] > 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 _______________________________________________ Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
