vicente.botet wrote:
Imagine now we had a function which returs a value and had an out parameter (maybe by reference)
Result f(InOut& ref);
Now we want to refactor this function (either because the new implementation will introduce an IO wait, or because the old blocking implementation could not be supported. Which should be the interface of the new function. The first thing could be to try with
future<Result> f(InOut& ref);
but nothing forbids the caller to use the ref parameter before the operation has completed and which could be invalid. If we want consistency what we would need is something like
future<Result> f(future<InOut&>& ref);
Firstly, this is a dangerous design. The calling thread must keep the reference alive until the future is ready - no matter what. For instance, what if it's owner thread tells it to terminate? Secondly, you can't prohibit the calling thread to access it's original reference. So the problem isn't really solved. Presently, I haven't seen any use cases which would motivate reference support for futures. Not allowing references is a safety net in it's own right. vicente.botet wrote:
Yet another example future<Out&> f();
This is also very dangerous, the promise-fulfilling thread must guarantee that the reference is valid until program termination as it can't detect when the future dies. Even if it could detect future destruction, it would be a strange design. Shared_ptrs or some kind of moving should be applied here. Johan -- View this message in context: http://www.nabble.com/Review-Request%3A-future-library-%28Gaskill-version%29... Sent from the Boost - Dev mailing list archive at Nabble.com.