[Development] Moving QFuture from QtConcurrent to QtCore

[Marc Mutz]

Hi,

When QtConcurrent was been moved out of QtCore, some of it stayed behind in 
QtCore: QThreadPool, but not QFuture. I'm arguing here that QFuture should 
stay in QtCore, or else be renamed to QtConcurrent::Future, to not impede 
development in that area until Qt 6.

QFuture is currently very much tied to QtConcurrent in that it assumes the 
underlying runnable is executing on QThreadPool::globalInstance(), but I've 
already submitted a patch some time ago that makes QFutureInterface (the 
promise part of QFuture) independent of the QThreadPool instance: 
https://codereview.qt-project.org/16942

That change, plus packaging QFutureInterface in a public (and documented :) 
QPromise, would go a long way to making QFuture useful for all users of 
QThreadPools, not only QtConcurrent ones.

That would be an argument for moving QFuture back to QtCore, alongside 
QThreadPool.

If, however, there are mid-term plans to make a Future class in Qt that isn't 
tied to QThreadPool (and could thus be used in, say, the I/O subsystem, too), 
then I'd argue for keeping QFuture in QtConcurrent and, to free up the name, 
call it QtConcurrent::Future (or QtConcurrent::QFuture, but that might be a 
bit subtle once a new QFuture appears in QtCore).

Any opinions either way?

Thanks,
Marc

-- 
Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-Independent Software Solutions