Re: [boost] [outcome] Andrzej's review

Subject: Re: [boost] [outcome] Andrzej's review
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2018-01-27 13:02:32

2018-01-26 20:59 GMT+01:00 Emil Dotchevski via Boost <boost_at_[hidden]>
:

> On Fri, Jan 26, 2018 at 10:17 AM, Andrzej Krzemienski via Boost <
> boost_at_[hidden]> 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;