Braddock Gaskill wrote:
This of course doesn't address your const-correctness question, which disappears if you make f.set const. :-)
Yes, I am considering that, but it seems semantically crooked.
What would you recommend? I'm trying to stay on the same page as your N2185 futures proposal. Your proposal does not define set_value() as const, so users will presumably face the same issues.
Very good question. I personally pass shared_ptrs by value all the time without feeling any guilt so passing a future by value in the cases where I want to call non-const methods is good enough for me. On the other hand, is this an issue in a split future/promise model? Are you moving back to N2185-style "combined" future and if so, why? There's a discussion on the committee -lib reflector at the moment which has raised an interesting point: if no futures remain, it might be desirable (in some cases) to cancel the thread that is executing the task as nobody is listening for the result. This is the opposite of watching for the case where no promise is left and breaking the future::waits, and another possible argument in favor of a split future/promise model. The chances of N2185 being accepted in the standard at this point are approximately zero, so there's no need to stick to it except as a sanity check against design regressions. :-)