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@lists.boost.org> 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