Creating a future/promise object

[Frank Pagliughi via Digitalmars-d]

> Instead of pulling values out, have you considered pushing 
> them? E.g. by supplying a delegate that gets called when the 
> asynchronous action completed.

I've always been on the fence about push vs pull when writing 
libraries of this type. The callback/delegate method is probably 
more powerful and may reduce latency and context switching, but 
since the callback happens in the context of the library thread, 
it exposes the client application to the messiness and problems 
of managing threads, race conditions, locking and all that. And 
it can expose the library to performance issues by handing over 
it's thread to user code which may not return for a long, long 
time. Plus most of the time I've found that client apps just set 
a flag and signal a condition variable anyway.

Using a future hides the messiness of threads and race conditions 
from the user, and it seems that this "Task" paradigm is gaining 
popularity in a lot of languages.

But a lot of libraries of this sort seem to defer the choice to 
the user and provide both API's. Mine will have both.