> > On 6 Sep 2024, at 22:36, Thiago Macieira <thiago.macie...@intel.com> wrote:
> >
> > On Friday 6 September 2024 16:21:56 CEST Mårten Nordheim via Development
> > wrote:
> >> But do we make it QList<int> _just in case_ there are multiple results
> >> added?
> >
> > From my limited exposure to QFuture/QPromise and in particular the bugs I've
> > had to triage, that is a design flaw.
> >
> > The future/promise doesn't know how many results will be provided, so 
> > there's
> > a race condition in it flagging the future has arrived with more results
> > arriving.
>
> QFuture is QGenerator in disguise.

I suppose that's more accurate, but if we are going to treat it it as a 
generator
then it shouldn't be co_awaited, generators are just iterated across until 
they're
exhausted.

We could in theory both provide co_yield and overload `operator co_await`  to 
try to
handle co_awaiting it, but IMO then we should just wait until it is finished, 
not just until
the next result is ready. What should happen in this scenario:

auto r = co_await future;
// result 1 and 2 are ready; r = 1?
co_await future;
// result 3 is ready; r = 3?

If we instead wait for the whole future to finish we avoid this. The iterated 
approach would
also avoid it. Though that brings us back to earlier - if we QFuture is both a 
generator and a
single-return-value task type, are we forced to always return a list of results 
for a co_await?

> Can we make it std::optional<T>? co_await awaits the next result, which might 
> turn out to
> be "no result” (we don’t know at the time of the co_await call). Would that 
> work?
> 
> Even in the case of a single result only that can still be “no result” in 
> case of
> cancellation, which again would suggest using an optional.

Yeah, I was thinking of this, though just an optional isn't the best.
We should have something like std::expected<T, Err> so we can return something
like "UserCancelledOperation", instead of just not having a value to give back.

> Morten

Mårten

--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Reply via email to