So what you are suggesting, is basically the current QFuture (combined with QFutureWtacher), but with "trimmed" runtime controls? And if we do that, we also need to have QTask for the cases where the runtime controls are needed (for example QtConcurrent, qtcreator).
Best regards, Sona > -----Original Message----- > From: Allan Sandfeld Jensen <k...@carewolf.com> > Sent: Friday, January 31, 2020 7:40 PM > To: development@qt-project.org > Cc: Sona Kurazyan <sona.kuraz...@qt.io> > Subject: Re: [Development] Make a decision for asynchronous APIs > > On Freitag, 31. Januar 2020 17:24:20 CET Sona Kurazyan wrote: > > 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? > > > As I have expressed earlier I would love the simplified QFuture, just a > something that can hold the result of an async function, but no runtime > controls. Just ways to test if the result is ready and to be notified when it > is, > like with a waitForResult blocking method and a signal emitter of some kind. > > I think there are many cases where such an API would be useful. > > Best regards > 'Allan > _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
