Re: [boost] [review] Review of Outcome v2 (Fri-19-Jan to Sun-28-Jan, 2018)

Subject: Re: [boost] [review] Review of Outcome v2 (Fri-19-Jan to Sun-28-Jan, 2018)
From: degski (degski_at_[hidden])
Date: 2018-01-30 23:12:46

I'll be short and add my comments to ED's review...

In general, I would like to state that if there is so much to say about
something relatively simple, red flags are up.

On 30 January 2018 at 15:07, Emil Dotchevski via Boost <
boost_at_[hidden]> wrote:

> It is wise to take the author seriously on his intentions to evolve...
>

This, I feel, is related to what's raised below: " It seems like Outcome
wants to stay away from Boost."

> There is a reason why in C libraries the default error reporting mechanism
> is to return int, even
> though the language does permit programmers to return structs, which would
> be more flexible.
>

 KISS...

Speaking of interoperability, it is especially tricky to report errors from
> C-style callbacks. This would be nice to support because C++ exceptions are
> off-limits in this case, yet it is sometimes desirable to communicate
> user-specific information across the third-party C callback mechanism (this
> is sometimes supported by a void * user data pointer, but that is not
> always the case).
>

C is a dirty word...

> Further, I disagree with the motivation to avoid using exceptions to begin
> with. The supplied decision matrix, I think, does not reflect reality. In
> my experience, the decision matrix to use C++ exceptions vs. something else
> is much simpler: "Do you hate exceptions?" No => use exceptions, Yes => use
> something else, because exceptions suck.
>

+1

Yes, exception handling has overhead. No, you can't afford this overhead in
> every last corner of a complex program, but yes, you can afford it in
> general.

And it's builtin...

And this is trivially true: if exception handling causes problems in some
> subsystem, the solution is to hide that subsystem behind a C-style API and
> compile only that subsystem with exception handling disabled.
>

 Or write some defensive code to make sure a potential problem doesn't need
to become an exception...

This is important, as it
> is typical for programmers coming from other languages to be shocked by
> various C++ language features, and this should not be confused with
> problems in the C++ language specification.
>

 I'm shocked, coming from C, that simple things have to become so complex...

- What is your evaluation of the implementation?
>
> Lack of C++11 support could be problematic. The use of macros to
> disambiguate namespace is cumbersome. Overall the library relies heavily on
> macros, which is not a good thing for a C++ library.
>

This seems so weird (and contradictory), we're using advanced C++, but
still rely on C concepts (PP) to make it work, ugly...

> It seems like Outcome wants to stay away from Boost.
>

To me it seems Outcome wants to be able to break with Boost at any moment,
and that safety-net is already builtin...

- Are you knowledgeable about the problem domain?
>
> Yes.
>

I'm not, I'm just a simple guy...

> - Do you think the library should be accepted as a Boost library?
>
> The library should be rejected.
>

+1, a lot of mental m.

degski