From the Library Author:
  > <quote>
  > “Outcome is really an abstraction layer for setting per-namespace
  > rules for when to throw exceptions. Exception throwing is absolutely at
  > the heart of Outcome. That's why Outcome != Expected, and why it ICEs
  > older compilers, and why C++ 14 is needed.”

Exhibited behavior is two-fold:

  (1) Expected errors are handled locally with low overhead (e.g., deterministic / predictable with low-latency)

  (2) Unexpected errors are type-erased into an 'exception_ptr' and pushed up the call stack (e.g., exception-throw stack-unwind)

For example, server-side code that is expected to handle a lot of failures, where “stop-the-world” is never suitable, may always handle errors locally.  In contrast, most other system-wide code may 'throw' an error, which should be handled within some caller-context.

# AT ISSUE:  DESIGN AND IDIOMS

What appears to be debated in this review are the Outcome library design and idioms; and not the quality of implementation (although the implementation is criticized as complex -- see below).  For example, even reviewers that voted to reject commented that the library seems sound, and seems useful for some cases.

This merits repeating:  This review has the highly positive characteristic (despite the accompanying discomfort) of debating the idioms that challenge what already exists, and which forces re-evaluation of our historical approaches.  

Many of these discussions might otherwise be summarized (and which has a fair chance of being agreed upon by all parties) as:

  *- Error handling can be done with exceptions, or with branch-testing on error instances;

      and some algorithms or constraints may favor one over the other for technical or

      compositional reasons.

It is this highly pragmatic observation that is at the core of the Outcome library submission.

Outcome enables a new idiom consistent with other pattern explorations deemed by the C++ community as useful, as demonstrated through acceptance into the C++ standard for 'std::optional<>' and the pending 'std::expected<>'.  Outcome enables value-transport of a multi-modal data object '<T|error|exception>' across API boundaries that provides the benefit of static compile-time type-checking, but places the explicit burden upon the user for 'visit / interrogation' of that multi-modal data object.

Outcome is intended for use in program areas with harsh resource constraints, where many inconveniences are expected, and tradeoffs are part of the design decision for creating and handling explicit 'out' values that include failure information.  These constraints may include:  interaction among one-or-more modules compiled without exception-handling enabled; deterministic or low-latency execution requirements; and use of custom 'error' and/or 'exception' objects that are expected to be populated and tested within the local context (such as to perform explicit conditional branching for error handling or recovery).

During the review there was some confusion regarding evaluating Outcome in the context of “generalized use” across an entire codebase, versus “localized use” where the algorithm intends to machine specific cases for statically-bound stateful handling of errors.

For example, it is not expected that Outcome might be used across all APIs across all modules within a system.  (Recall that current C++ community guidance might otherwise suggest 'std::error_code' or 'exception-throw' might be used across all APIs for all modules within a system, if such consistency is permitted.)  Rather, Outcome intends to address that nexus where an algorithm interacts with several modules, each with differing 'error' and 'exception' practices, where the library consistently transfers '<T|error|exception>' with compile-time type enforcement and runtime behavior and performance guarantees.

Design decisions within Outcome v2 are well-considered, and faithfully reflect feedback raised during the (quite extensive) v1 review.  Indeed, none of the issues raised during the v1 review were again raised within the v2 review.  And, it is noted that two reviewers previously voting REJECT on v1 now vote ACCEPT on v2.

Further, it should be noted that Outcome v2 has evolved into a collaborative effort with assistance from several contributors, with validation and feedback in multiple real-world codebases with specific engineering constraints.

In this review, reviewers found the idioms specifically useful (beyond alternatively available tools / idioms),  and consistent with practices in existing codebases and in other languages.  Further, the proposed direction appears to be consistent with evolving idiomatic practice within the C++ Standard enabling new idiomatic algorithm expression, as evidenced by multi-mode types such as 'std::optional<>' and the (proposed and evolving) 'std::expected<>'.

Idioms provided through Outcome are also demonstrated to be useful / successful in other languages.  As noted in the review, Outcome enables handling of failure with idioms similar to those found in Rust, a language which also supports RAII but which does not support exceptions (and reviewers commented that these idioms are sufficiently successful that exceptions are not viewed as an interesting nor desired mechanism in Rust).

One reviewer commented that it is not compelling to attempt to replicate Rust error handling idioms, which (as a different language) naturally offers different idioms.  And instead, offered that the natural idiom in C++ is to throw (and catch) exceptions.  However, it can be noted that the Outcome design approach is somewhat agnostic to the use of 'exceptions', but rather relies upon a multi-modal data object that the user must explicitly unpack (similar to 'std::optional<>' or 'std::expected<>'), and which makes explicit guarantees about unified transport and handling of '<error|exception>'.

The core of the dispute seems to be over the value of localized reasoning for handling errors:  Exceptions are good for “distant” handling (to seamlessly transfer handling to a parent context), while explicit error/result instances (possibly customized) encourage local reasoning for discrete handling within the local algorithm context.  Complicating the issue is that (of course) both are accepted practice in differing environments and with differing engineering constraints:  Throwing exceptions may be most expressive to avoid algorithmic edge cases or ensure errors are actually handled; but alternatively it may be more expressive to explicitly handle errors locally when it is not desirable to delegate the failure to an upper level.

# DISAGREEMENT:  ERROR / EXCEPTION HANDLING

Even prior to considering the Outcome library submission, error handling idioms and practices remain contentious and confusing within the C++ community (as well as within the Boost community).  Recent threads on the Boost email-list continue to highlight the ongoing confusion and disagreement even over the proper or idiomatic use of 'std::error_code', which boasts a decade of real-world experience and approaches a decade in the C++standard.  One might think such discussions should by now be resolved; but no, we observe that even semantic agreement of proper-or-intended behavior for 'std::error_code' was not reached on these recent Boost email discussions.

We also observe that discussion regarding 'error' or 'exception' handling can at times be clouded within the evolving C++ Standard itself, with discussions of 'throw'/'no-throw' (e.g., “dual”) APIs, semantics for 'wide' or 'narrow' contracts, and even the occasional (and “over-simplified”) discussion of “for vs. against” exception handling (a topic that alone is worthy of consuming a surprising number of evenings and libations).

The Library Author can be congratulated (or scolded) for exploring work or attempting Boost community review in such a contentious space.

However, these topics are also fundamental motivations in the creation of Outcome itself:  It provides a mechanism to unify 'error' _and_ 'exception' handling to enable unified localized reasoning across third-party modules; and directly exposes the resulting issues for cross-module error handling by charging the user with explicit unpacking of the '<T|error|exception>' object, but with the benefit of static binding (e.g., compile-time type checking).

The implication is that in such a library review attempting to address a portion of the C++ landscape already marked with disagreement regarding current-and-alternative approaches, we cannot expect but to see charged commentary where issues of “global reasoning” over a “generalized use case” were inevitably raised to sometimes overshadow the discussion of a library that specifically intends to address “localized reasoning” with specific performance constraints and behavior guarantees.  (Although compared to the v1 review, we might consider some threads to have missed opportunity to be yet more colorful.)

The beclouded discussion appeared at times to exhibit violent agreement:

Quoting reviewer (voting to reject):
  > However it looks like Outcome provides a solution for most of the practical
  > cases, while leaving the general case unsolved. Boost.Outcome is a set of
  > tools (rather than just one) and you are expected to choose one that best
  > solves your particular problem.

Quoting response by library author:
  > I was just about to say the same thing, but more pointed.  <...> Knowing that

  > a piece of code will never, ever see stack unwinding lets you skip handling

  > stack unwinding. Hence `noexcept`.
  >

  > Furthermore, unlike with exception specifications which were unhelpfully checked

  > at runtime, Outcome fails at compile time. .... You can't successfully compile code

  > if your E types don't have interop specified for them.
  >
  > Outcome is of particular use in a lower-level layer of code (closer to bare metal,

  > or in server contexts), where explicit deterministic error handling warrants

  > increased tedium or inconvenience in explicit checks for success/failure.

An observer might note that the reviewer (voting to reject) and library author have a shared view of what the library proposes to do; but the reviewer desires a generalized solution, rather than an interop-solution that provides specific performance constraints and behavioral guarantees.  They agree on what it does.  They disagree regarding the value and likelihood of a future possible generalized solution to perform a similar function, which is not currently proposed for review.

The (perhaps unstated) concept is that no generalized solution may be possible with today's language, or perhaps ever:  Both 'error' objects and 'exception' throws fundamentally serve different use cases:

  (a) 'error / status' instance (i.e., “opt-in”):  A discrete object that can be inspected (or ignored), such as to perform conditional processing

  (b) 'exception' throw (i.e., “opt-out”):  A control transfer-to-caller that avoids accidental instruction execution (e.g., stack-unwind) and which cannot be ignored

Proponents of (a) talk of contract and execution simplicity, and of determinism / efficiency.  Proponents of (b) talk of composition simplicity, and avoidance of edge cases due to liberation from local tedium.

A further complication is due to how arbitrary (implementation-specific) data is returned for failure handling:  It can be encoded into the type system (increasing coupling across APIs), or may be type-erased (such as done by 'std::error_code').  Noted in the review is that 'exception' throws are a special case of type erasure, as the C++ runtime performs the type erasure without impacting the declared API (thus providing a very large part of the convenience for using exceptions).

The Outcome library attempts to unify '<error|exception>' handling for localized reasoning, and (re-)throw only in specific well-defined contexts.  It is not a generalized pattern, but a unified mechanism for discrete handling of those scenarios where the design choice is explicitly made to perform localized reasoning of failure from dependence upon heterogeneous modules that may perform surprising (and evolving) behavioral changes for failure-notification.

A generalized solution intends to provide uniformly simpler code, or generalized idioms.  This might not (ever) be possible when we explicitly talk about localized reasoning of error handling within the local context:  By definition, we want to enumerate and handle discrete failure cases specific to the local algorithm; so the best we can do is to utilize (compile-time) type-checks that verify our unwrapping-and-interrogation of our '<T|error|exception>' instance that bubbles up from within some far-away dependency that chooses the most inopportune time to exhibit surprising changes in behavior.  Also by definition, localized reasoning requires localized tedium to _handle_ specific error cases, which are also enumerated locally.  In such cases, a generalized solution does not apply.

Much of the concern over Outcome acceptance appears to be based on concerns of the effects of the library on the ecosystem.  It is true that users might wrongly apply localized reasoning tools to (widespread) generalized use.  However, that same issue already exists with the C++ community's dichotomous split between 'error' or 'exception' handling, and with our Groundhog-Day revisiting of the same irreconcilable patterns that bring us the “dual-APIs” for “throw/no-throw” in the C++ Networking TS and Filesystem TS (and presumedly, many more Standard libraries to come).

Of particular note is the assertion raised during the review that:

  *- The error being exceptional or not depends upon context, and not the algorithm.

For example, connection failure on a game client and a game server are both backed by the same function; but Outcome permits the context to convert an 'error' into an 'exception', or not (based on caller-context).

To quote one reviewer (voting to accept):
  > Boost.Outcome is not to “replace exception handling in your programs”:  It is

  > used to cover those isolated places where exception handling proves inferior

  > to manual control flows.

We might now expand our Matrix Of Confusion for preferring 'error' or 'exception' to include:

  (a) “Generalized-pattern” vs. “Localized-reasoning”
  (b) Expected vs. Non-Expected failure
  (c) Dependency upon subsystem providing 'error' vs. subsystem providing 'exception'

While technically a “matrix”, commonly this is (quite) multi-dimensional:  Frequently we depend upon many subsystems, each of which make very different decisions for how they relay disappointment, and where each individual subsystem will *change* that decision in surprising ways merely when we perform a version update.  This is the brittleness that Outcome intends to address.

Outcome is merely a mechanism to enable 3rd party module inter-operation.  It does not make the decision for whether 'error' or 'exception' instances are provided by some subsystem, nor does it care.  Rather, it is a unification mechanism that enables an algorithm to be _authored_ with specific performance and behavioral guarantees when reliance is upon one-or-more modules that _made_ that 'error' vs. 'exception' decision in a manner your specific use case finds unfortunate.

Lastly, reviewers most critical of Outcome point to 'exceptions' as the C++ language mechanism to be leveraged in design, such as to enforce strong guarantees of object invariants (e.g., RAII permits ctors to throw to ensure invariants are not violated), and thus the Outcome library is not needed.  However, despite this language feature, alternative idioms such as private ctors and 'make_xxx()' factory functions are not uncommon to also enable successful instantiation with internal state upholding invariant values; and we again must concede that modules employ differing decisions to compile with exception handling enabled.  Thus, it seems reasonable that a library such as Outcome might exist to present a unifying interface across 3rd party code with differing design decisions, rather than hope for a simpler world where a single (exception-based) approach is mandated system-wide across modules.

# CONCERN:  CUSTOMIZATION POINTS (COMPLEXITY)

Outcome attempts to bridge vocabulary types for '<error|exception>' handling among subsystems, including:  C++ with or without exceptions enabled, C subsystems, and modules providing customized errors and/or customized exceptions.  These goals necessarily complicate the design beyond a simple 'variant<>' value-type with no such customization points.

This complexity was commented on by reviewers that voted to reject, suggesting:  (1) Complexity is too high for the features provided; (2) Additional complexity to support C compatibility is unnecessary; and (3) Complexity is unnecessary if the library required subsystems not using exceptions to be wrapped behind a C-style API and to compile only those wrapped-subsystems with exception handling disabled.  Further, other indirect comments suggested:  (4) Complexity is lessened if Outcome assumed use of only 'std::error_code' (not user-customized error instances), and the type-erased payload provided through an exception (e.g., 'throw').

In response, the Outcome library premise is that a simpler world does not exist (where such customization is unnecessary):  Despite nearly a decade of experience, the C++ community has yet to adopt 'std::error_code' as the ubiquitous mechanism to identify error (where instead bespoke error types remain in widespread use); and even in modern C++ codebases, it is not uncommon to compile with exceptions disabled.  A heterogeneous landscape exists, and likely will continue to exist.

For both practical and technical reasons, it is expected that domain-specific customization for error and exception handling will continue to be required, such as to address engineering constraints and needs for 'constexpr'; for small-embedded environments with severe restrictions on memory allocation; and for context-specific payload transferred or accumulated into journals / logs as a part of error handling.  It is even expected that the C++ Standard itself will adapt to its own evolving idioms exposed through new language features, and (future) standard types that we might assume will be consistently applied across standard library APIs.

This underscores the need for such customization points, where proposals such as Outcome attempt to provide an effective mechanism within a rather bleak current landscape with guaranteed future changes.

In the face of this (currently-seen and continually expected) evolution, we have today's practical real-world issues:  Commonly today's systems are composed of 3rd party modules that must interoperate in a well-behaved and deterministic manner, where '<error|exception>' customization becomes a system requirement.

Of particular note is that in large codebase environments, current practice is to adopt customization policies to impose consistent and bespoke rules across the entire codebase, and across modules.  Prior to Outcome, this customization is often done with preprocessor macros.  In these environments, Outcome is viewed as a positive evolution.

Today's Outcome customization points exist “out-of-the-box” to be compatible with existing module-specific 'error' or 'exception' needs, and to provide API/source-compatibility with a possible future-compatible 'std2::error_code'.

Reviewers critical of the provided customization points want type-erased error state, but the library author asserts that this is hard to do in a manner that is (1) efficient, and (2) permits evolution (such as to support user-specific error values, or a possible future 'std2::error_code').

Further, the library author asserts that the library is not in fact complex; but that it can be overwhelming to the uninitiated merely because it enables customization of '<E>', and customization enables possibilities (which by definition implies complexity); and that such customization is characteristic of most (all?) vocabulary libraries.

Despite concerns over complexity, v2 is greatly simplified over v1 where changes were directed through v1 review feedback; and provides a single-header version with reasonable compile-time overhead.  Using (integrating) the library should not be difficult, and explicit efforts to establish ABI stability should make extended use over evolving codebases possible, and not-hard.

Because enabling cross-module '<error|exception>' handling is fundamental to the library, it is conceivable that the library offers the minimal interface with the minimal possible complexity to do this job.  And, this is a job that is (1) needed by real-world users; and (2) unavailable through alternative mechanisms (and which would not be provided through a simplified value-type composed of 'variant<T,error,exception>').

From the library author:
  > As the last section of the tutorial covers, there is a non-source-intrusive mechanism

  > for externally specifying interoperation rules to handle libraries using one policy

  > interoperating with libraries with different policies. This lets Eve stitch together the

  > Alice and Bob libraries without having to modify their source code, and without

  > affecting any other libraries. I personally think this Outcome's coup de grace and

  > why it's the only scalable choice for large programs considering using this sort of

  > error handling.

In this context where Outcome may possibly exhibit minimal sufficient complexity to address its intended target of cross-module '<error|exception>' transport, one might recall the Fred Brooks quote:

  > “The complexity of software is an essential property, not an accidental one.

  > Hence, descriptions of a software entity that abstract away its complexity

  > often abstracts away its essence.”  -- Fred Brooks, “No Silver Bullet” (1986)

# DISAGREEMENT:  REQUIRES C++14 (versus C++11)

Outcome requires C++14 and is identified as failing on some toolchains exhibiting non-conforming C++ Standard behavior.  The review raised concerns that requiring C++14 (rather than C++11) would limit the library's suitability for Boost inclusion.

In this context, it might be suggested that an error variant is needed by everyone, so we might reject a C++14 implementation in the hope that a future C++11 compatible library will be proposed.

It is noted that Outcome v1 supported old compilers back to clang 3.1 and gcc 4.9, and had many workarounds to suppress non-conforming compiler behavior; and used preprocessor metaprogramming to work around compile-time selected CRTP (because of compile-time costs, and issues on older compilers).  However, these approaches were rejected in the v1 review as too complex; and reviewers were not persuaded by concerns raised by the library author that their removal would demand dropping compatibility with older toolchains.  Outcome v2 removed these workarounds based on v1 feedback, resulting in a requirement for newer toolchains.

Similar discussions have been raised in other contexts regarding Boost distribution packaging, and the possibility of forking “pre/post” C++11 (e.g., “modern C++”) libraries into separate Boost distributions.  This is an unfortunately complex issue, as Boost already contains libraries supporting varying levels of “minimum” requirements including varying support for compilers exhibiting non-conforming behavior for C++98, C++03, C++11, C++14, and C++17 (and others).  Some libraries such as Boost.Hana or those reliant upon heavy 'constexpr' behavior demand the very-latest C++17 toolchains.  

Further, it is recognized that in some cases backward-compatibility can be undesirable, or fundamentally limiting to the library's usefulness.  For example, at a recent 'BoostCon' / 'C++Now' conference an attempt was made to evolve the 'Boost.Date_Time' API to use the seemingly highly suitable C++17 'structured binding' declaration to decompose 'date / time' objects.  

Unfortunately, this work was abandoned:  Due to use by other Boost libraries restricted to a previous C++ Standard, and the discovery that 'Boost.Date_Time' library semantics fundamentally changed when using this new language feature, it was concluded to not be feasible to support both the legacy API and new API using structured bindings.  It appears in this case a new library must be authored without consideration of backward-compatibility to enable this evolution for what appears to be an otherwise obvious or natural expressiveness to decompose 'date / time' objects using 'structured binding' declarations.

It is noted that C++11 is already eclipsed by C++14 and C++17, and that current Boost library requirements merely require C++ Standard conforming behavior, whereby the library must clearly document those platforms that are supported.  Further, it is noted that a v1 implementation supporting older tool chains was rejected (so v2 now requires C++14).  As this is a complex issue that demands consideration of many tradeoffs (including feasibility and behavior fundamental to the library itself), it is expected that the Library Maintainer constantly review and evolve these decisions as the C++ language evolves; toolchains are updated; and users raise issues or provide contributions.

# CONCERN:  LIBRARY FUTURE EVOLUTION

A concern is raised that upon acceptance into Boost, Outcome may evolve beyond the design reviewed for acceptance.  Further, a specific concern was raised regarding Outcome exploring evolution of an 'std::error_code' (which we might call a proposed 'std2::error_code').

Within the context of Outcome, the 'error' type exists as a mere customization point by which the user may supply a bespoke definition, or incidentally use the 'std::error_code' provided by the C++11 Standard.  Both of these are seen today in common practice.  It is expected that users (and perhaps the library author) will continue to explore possible 'error' implementations for specific purposes (such as exploration of an 'error' for small-embedded that does not rely upon allocation machinery).  This is viewed as a necessary and healthy advancement of the science, for which the library (by design) conveniently empowers the end-user to parameterize domain-specific 'error' types into 'result<>' or 'outcome<>'.

Indeed, it is hoped (and expected) that a greater amount of user-experimentation or flirtation with 'error' value transfer will be performed (not less) in the context of user-specific needs or engineering constraints:  This is a fundamental benefit from having Outcome as a design option for authoring interfaces across module boundaries.

Regarding a possible future “drift” from its clearly-stated mission, this review considers the library as submitted; and defers to the Boost community regarding policies and procedures for handling libraries included in the Boost distribution (which exist in varying states of evolution and maintenance).

# FINAL THOUGHTS

The Boost community is stronger for enabling and exploring idioms, and for not shying away from the difficult (and sometimes contentious) effort to discover new approaches that address the dark corners that stress our real-world systems.  These are (perhaps) the only noble efforts that someday may lead to new best practices.

If experience (otherwise known as, “painful memory of limitation”) is a prime driver for the design and implementation choices made by developers, then it is unreasonable in a review such as this to expect agreement on all fronts.  Indeed, our systems have differing constraints and evolutionary / scaling prospects, and we fear different things.  However, it seems important to keep in mind that this disagreement continues to be necessary and expected:  Rather than pretending to hide within an echo chamber, the Boost Community does the “hard work” of challenging perspectives, pushing the envelope, and questioning assertions in the face of a constantly shifting technological landscape and evolving C++ language.  Dissenting or critical reviews are essential, and desired.

The long Boost history includes many examples of speculative and risky approaches, which in hindsight are now considered common and "best" practice.  Few C++ developers today can practice professionally without at least passing knowledge of template-metaprogramming, which used to be an esoteric ritual only within the confines of Boost.

Outcome was designed under the proposition that cross-module 'error' / 'exception' handling in today's systems is unnecessarily brittle and problematic.  Reviewers found Outcome to effectively address a serious concern of transporting different '<error|exception>' instances across modules.  It attempts to solve a hard problem, which spans 3rd-party module composition, while adhering to specific performance constraints and behavioral guarantees.  Its use is demonstrated to be effective in some environments exhibiting severe engineering restrictions.  As such, it is not expected that all users everywhere will have direct need for Outcome.  However, it is hoped that evolution of similar idioms will eventually permit the broader C++ community to consider this domain of cross-module stateful control transfer to be a “solved problem” (or certainly “less-brittle” or “less-problematic”).

Great thanks to the Boost Community for their tremendous efforts, disciplined review, and detailed exploration of topics in considering this library submission.

Sincerest appreciation to Niall Douglas (Author of the Outcome Library) and other contributors for pushing the boundary for '<error|exception>' handling and for submitting this work to the Boost Review process.

--charley
Boost.Outcome (v2) Review Manager