On 27 Aug 2015 at 5:05, Glen Fernandes wrote:
Niall Douglas wrote:
The idea is that no one ever need implement the Concurrency TS themselves ever again. Just pick up a copy of Boost.Monad/Outcome. Write your policy class for your custom variant. Profit.
Is anyone besides Boost or standard library vendors actually interested in doing this? Standard library implementors are not going to take a dependency on a Boost library.
For example: Are there many (or any) Filesystem TS implementations that people care about outside of standard library implementations and Boost?
I just can't imagine someone, say, proposing Boost.Path that provides a boost::basic_path that can be used to implement std::experimental::filesystem::path and expecting anyone to care about it. Anyone implementing the TS will just implement std::experimental::filesystem::path themselves and not take a dependency on boost::basic_path to do it.
What makes your basic_future so different to the hypothetical basic_path?
A basic_path is probably not going to attract much need for customisation without losing interoperability with other basic_path customisations. basic_future lets you implement any custom future type of your heart's desire without losing wait composure with other custom basic_futures. Also people do have a real need for custom futures. A big bone Chris picks with the Concurrency model in the Concurrency TS is its reliance on futures which he views (rightly) as being too chunky for low latency socket i/o. My lightweight futures don't address all of Chris' concerns, but they are a whole ton load better for low latency work than standard futures. If someone wanted even lower latency than my default implementation and wanted to give up standards conformance, they certainly can do that. My default implementation has to match the TS, and there is a definite overhead to that. I also suspect they'll be a real boon for C++ 1z coroutines given how that is designed, but testing that is many months away yet. If they are a real boon, I don't doubt Gor will be very interested. Finally, you may not be aware that my lightweight futures are dependent on a system future implementation. They do not replace system nor Boost futures, they act as a layer implemented on top dropping down onto the system futures when unavoidable. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/