Den lör 1 feb. 2020 kl 14:48 skrev Sona Kurazyan <sona.kuraz...@qt.io>: > > > > > -----Original Message----- > > From: Elvis Stansvik <elvst...@gmail.com> > > Sent: Friday, January 31, 2020 7:20 PM > > To: Sona Kurazyan <sona.kuraz...@qt.io> > > Cc: development@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.
Alright, thanks. That sounds reasonable to me too. Elvis > > Best regards, > Sona _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development