> > 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
