[fugalh]

It is along the same lines as boost's futures implementation. We have a different mechanism for expressing thread management, born out of trial and error and Facebook engineer feedback. At the time we set out to write this boost futures were slow and buggy (1.53), and C++ standard monadic futures proposals were in very early stages (it now appears that there will be monadic futures in C++17). I do not know if boost futures are now more robust and/or more performant in 1.58.

[Serow225]

Since it seems like you're at FB, do you know if anyone's working on an equivalent of FB's Swift but for C++ instead of Java? If so, I'd love an email to express interest in such a thing. Thanks in advance!

[electrum]

Swift uses annotations (reflection) and generates bytecode on the fly. This fits much better with modern Java development practices and tooling than source code generation. Is such a thing feasible C++, especially in an idiomatic way? Or perhaps I am misunderstanding your question.

To my knowledge, our C++ Thrift code is here: https://github.com/facebook/fbthrift

(I work on Presto and occasionally Swift at Facebook, but am not at all familiar with modern C++)

[Serow225]

Thanks for the reply! You're right, I should have been more clear - the goal would be to autogenerate Thrift IDL at compile-time from annotations in our C++ source, to avoid having to hand write the IDL. So more in the sprit of Swift rather than a direct parallel.

[vsl]

They seem to be more robust, but boost::future::then() has weird design that makes it all but useless for real-life use. They return the same kind of future that std::async() does, i.e. its destructor blocks until the future is ready. In other words, you can't write "fire and forget" code:

    void run_and_report()
    {
       something_long_running()
       .then([=]{ report_results() });
    } // blocks here until the then() block executes

[hatred]

thanks for the explanation.