2018-01-26 20:59 GMT+01:00 Emil Dotchevski via Boost
On Fri, Jan 26, 2018 at 10:17 AM, Andrzej Krzemienski via Boost < boost@lists.boost.org> wrote:
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.
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. 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 am sorry if this sounded this way. I did not mean to say "add it to Boost so that the users can check if it is fine". I consider the library design correct and sound. Also the implementation (modulo bugs - but they are trivial to fix in my judgement). However, I believe that there are some things that we cannot judge by inspecting the code, the docs, the design: that is, if it will prove convenient in practice. To me `std::expected` looked reasonable and correct. But it is not as "usable" due to the lack of TRY operations and upgrade to outcome. But no-one could invent them by only reviewing the library and discussing it. It required field experience. And now we have something convincing and seemingly practical. But it will require a vaster experience to check if there aren't any unforeseen shortcomings or better usage patterns. Regards, &rzej;