Should `.then` be const qualified?

[brycelelbach]

If so, future authors will probably have to make something (the executor, at least?) mutable.

[RedBeard0531]

Futures will probably point-to rather than have an executor, so the pointer loophole to const already applies.

[griwes]

We guarantee that the shared state is synchronized; this would imply that the future objects themselves are synchronized, and I'm pretty sure we do not actually want to say that. (Think shared_ptr vs atomic<shared_ptr>.)

[RedBeard0531]

Although at least for non-shared futures, they are a logically mutating operation so the answer is clearly no. Should the title be restricted just to SharedFuture?

[jaredhoberock]

Execution functions are const qualified and executors are intended to be passed around by value. The idea is that the executor acts as a sort of pointer or handle to an execution context or some other thing which actually mutates when work is created. So no, I don't think that .then() needs to be const-qualified on behalf of executors.