Why accepting this library when we have `expected` being standardized? I do not really mind having two in Boost.
I agree, we should not be rejecting libraries just because another similar library already exists in Boost.
There is no similar library already in Boost. Expected will not be submitted to Boost, it's in LWG now. I believe Andrzej meant "second" or "alternative", not "two".
First, it is ready, being proposed, and applied in a number of non-trivial code-bases. Niall claims that his trade-offs are better tailored to predictable-latency applications. I do not have enough knowledge to asses it. They look convincing. The only way to test it is to give this library the Boost blessing and have the user test it.
Here I disagree. If there are issues with a library, they should be addressed before it is accepted; we should be proposing/accepting only relatively mature libraries that have seen real, if limited, deployment.
At a minimum, Outcome v2 is already in production use at Microsoft and at Google. I have received bugs reports :) I suspect a few other multinationals are also using it in production, but I cannot be sure.
First, this is a matter of quality standards. Secondly, fixing problems when there already is substantial user base is messy, and often requires further compromise.
I believe Andrzej was specifically referring to the fixed latency use case only. On that the only hard evidence I can provide is AFIO benchmarking on Intel Optane technology. AFIO, which uses Outcome throughout, benchmarks at a minimum of 100 nanosecond i/o latency on Linux (pre Meltdown mitigations). This is statistically indistinguishable, to a 99% confidence interval, to calling the kernel syscall directly. How useful Outcome is for fixed latency programming below 100 nanoseconds per operation I cannot say with any statistical confidence. Also, other workload patterns may differ significantly to kernel i/o. In the end, people ought to give Outcome a try for their use case and see how it goes for them. Which is what Andrzej was saying I believe. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/