Make a decision for asynchronous APIs

We all understand and know that it's hard to make a decision on asynchronous APIs.

But when we are honest, QFuture is a amazingly good shot in the right direction. But it ain't finished: you can't reset a QFutureInterface instance back to its initial state, after having reported it is finished. Also isn't QFutureInterface public documented. Also is its API claimed not to be official. This casts doubt at many of the companies I do freelance work for. And this makes people think in a varied way about it. This makes the type a "difficult sell". I understand the doubts about it. But I don't understand the many years that Qt is keeping it hostage.

I saw a mailinglist thread about bringing KJob to a QJob or a QAbstractJob. Because, of course, KJob can't be blocking. Because KJob has interactive questions while the job is ongoing (do you want to overwrite this file, yes or not?). I get this. But in itself, it's no reason to indefinitely block QFuture. Can we improve QFuture's API for such a QJob? Or can we extract common API out of QFuture and QJob and make a new type that both share? Anything is better than the current stalemate.

As a developer I feel like being blocked by you guys. I want to explain to my customers to use a good return type for asynchronous operations. But rightfully my customers are replying: well look, the Qt guys themselves have no fscking clue what to do here. How are we supposed to have a clue, then?

They are right. Please, guys, get a fucking clue on this. And sorry for my language.