- Boost - lists.boost.org

[review] Outcome Review Report
by charleyb123 . 07 Jun '17

07 Jun '17

# Boost.Outcome REVIEW REPORT In conclusion to the Outcome Library Review (19-May to 02-June, 2017): The library is REJECTED. Rejection is principally due to: (1) Unresolved key behavior at conclusion of the review period (2) Misunderstanding/disagreement regarding library’s intended purpose (3) Unclear precedent/implications from accepting this library in its current configuration into the Boost distribution The following weighed heavily to consider accepting the library into Boost: (a) The library demonstrates solutions to fundamental issues (error and exception handling) (b) The library effectively addresses constraints to serve the needs of several user-bases (c) New paradigms/idioms are enabled (d) Implementation is of high quality Some 20+ participants sent 850+ email messages to the public list discussing the Outcome library, plus additional (non-trivial) off-list discussion. Public reviews sent to the list were from: *- Paul Bristow -- ACCEPT (Tue-23-May) *- Deniz Bahadir -- ACCEPT (Wed-24-May) *- Robert Ramey -- REJECT (Fri-26-May) *- Peter Dimov -- REJECT (Sun-28-May) *- Emil Dotchevski -- REJECT (Sun-28-May) *- Vicente J. Botet Escriba -- REJECT (Tue-30-May) *- Andrzej Krzemienski -- REJECT (Wed-31-May) *- Gavin Lambert -- REJECT (May 31) *- Bjorn Reese -- REJECT (Fri-02-June) The remainder of this report is a summary of discussion with select issues specific to the Outcome library, plus some possible topics for further consideration by the Boost Community and Boost Steering Committee. This further elaboration is not intended to be comprehensive regarding issues raised during the review; Rather, it is to: (a) Provide historical “summary/context” for the level of discussion exhibited during this review, and which contributed to the final decision; (b) Highlight issues that may provide assistance in considering “readiness” for a later review for an evolved form of this library (or for a similar library intending to address the same domain); (c) Provide “discussion-points” for the Boost Community and Boost Steering Committee regarding possible future evolution or guidance associated with Boost tooling, distribution, and individual library dependencies (related to topics raised during this review). The conclusions will be: (1) Outcome Library Author: Consider re-submitting for review when... (a) Key behavior/design issues are resolved (see below) (b) Integration plan with Boost is more clear (and consistent with Boost Steering Committee Guidance) (2) Boost Community / Boost Steering Committee: Consider providing guidance to future library submissions regarding... (a) Attempted dual-license, this submission attempted: *- BSL+Apache2 dual-license (b) “Extra-build-steps”, this submission attempted: *- Custom preprocessing to “generate-source” (to significantly improve compile-time speed) (Note: During review, a template-based solution was proposed as a possible replacement mechanism, but code-gen should probably be explicitly addressed) (c) Class/namespace versioning, this submission attempted: *- Stable ABI/versioning mechanism through a framework provided with this submission (to enable multiple versions of this library used by differing third-party libraries to correctly coexist within the same binary) (d) Use of outside source; use of git (git-submodules), this submission attempted: *- Dependency to an outside (git-submodule) lib archive (gsl-lite: https://github.com/martinmoene/gsl-lite.git ) (e) Use of (non-test/Jamfile) for test, this submission attempted: *- Custom test mechanism (because “Boost.Test” won’t work with C++ exceptions disabled; lib needed “boost-lite” to run the test suite) (f) Use of CMake, Dependency upon Boost, this submission attempted: *- No Boost dependency (but provided a “boost-lite” shim to coexist in user-workspaces with-or-without Boost, providing common cmake machinery and test-running) # SUMMARY OVERVIEW As demonstrated through the volume and depth of discussion, the library attracted wide interest, which is consistent with a perception that it attempts to address an active need. Comments suggested the library’s purpose (enabling public APIs to pass <value|error|exception>) was useful, and that enabling a shared handling of <error|exception> to be somewhat novel. Several participants further suggested that the library attempts to serve a role as a “fundamental” library: to provide vocabulary types and pose new idioms, to be used in public APIs as a common <error|exception> exchange mechanism. One reviewer commented that the library’s documentation under-sold the library’s motivation, suggesting it compelling for: *- Cases where errors cannot be propagated by throwing exceptions (e.g., within callbacks where an error value is provided [e.g., ASIO]); *- When passing values between threads, such as in an Actor model where a message queue handles return values (e.g., pass outcome<T> instead of an std::error_code to handle <error|exception> in addition to desired <T>) Many/most reviewers that voted REJECT commented that they would like a similar library to be accepted, or perhaps an evolved form of this library after necessary changes (see below). To accept the importance of the domain which the library attempts to address, one need not agree with the design nor implementation of Outcome (indeed, the library is rejected in its current form at the conclusion of this review). Rather, this summary assertion is that the Outcome proposal successfully demonstrates a need for such a fundamental (and community-endorsed) solution (or direction) for error handling. # ISSUE: Unresolved key behavior at conclusion of the review period Key behavior (or design) issues that did not reach consensus by the end of the review period: (1) Narrow vs. Wide contracts -- consensus is not reached (2) Empty-state (allowed?) remains controversial (3) Ring-buffer appears uncontroversial; but perhaps needs additional scrutiny (a) Separate library implementation (for reuse elsewhere, and to enable evolution without touching the ‘result<>’/’outcome<>’ API)? (b) Bigger buffer? Some of the difficulties in this evaluation likely trace to the (in-progress) evolution of the proposed ‘std::expected<>’ (also discussed during this review). A future Outcome review would likely benefit from the clarity provided by fully resolved semantics for ‘std::expected<>’. # ISSUE: Misunderstanding/disagreement regarding library’s intended purpose The Outcome library attempts to define a paradigm and propose idioms in <error|exception> handling, where few can successfully argue that current practice, libraries, and idioms are sufficient. The review concluded that Outcome proposes a new paradigm that is demonstrated to be useful and effective. However, disagreement exists on the nature of that framework: PURPOSE: Outcome is a unified/universal <error|exception> handling framework for use in public APIs; (a) ...enabling user-customization to address domain-specific constraints ...versus... (b) ...for possible future consideration in a C++ Standards Track, likely within <system_error> The Library Author intended (a), while multiple reviewers advocated for (b). This disagreement-in-vision resulted in many difficult discussions during the review, and ultimately lack of consensus for several important API and design decisions (due to the corresponding implied future limitations). For example: Static-checked vs. Runtime-checked behavior. The library-as-presented attempts to serve both, citing orthogonal user bases with differing (latency) constraints, such as “with-or-without” runtime overhead, and “with-or-without” Undefined Behavior (UB). Current implementation enables integration of arbitrary third-party libraries (each with their own preferred error handling strategy and tradeoffs), with zero-cost conversion and inter-operation. However, this *significantly* complicates the design: The user composes ‘result<>’ and ‘outcome<>’ types with regards to module-specific static or runtime type safety and performance requirements, which (transparently) propagate through the library internals and across threads and public APIs to external modules. In contrast, a C++ Standards Track implementation is likely much simpler, introducing one-or-two vocabulary types merely parameterized on ‘<T>’, providing a simplified (and “standard”) mechanism to bridge <T|error|exception> transport across third-party module boundaries. For example, in advocating for a “Standards-Track” vocabulary type, reviewers argued for a mechanism that would enable user-libraries to obsolete the duplicate “throw/no-throw” APIs with a single API: R filesystem_api(); // throws filesystem_error R filesystem_api( error_code& ec ) noexcept; ...becomes... outcome<R> filesystem_api(); // <R|error|exception> The contrast between the two visions can more distinctly be termed: (a) “Multi-Modal” Usage -- Many varieties of usage style within the API is necessary, because there are a multitude of ways for library abstractions to be used in composition patterns due to domain-specific constraints (likely with some idioms not yet discovered, or not yet in widespread use) (b) “Single-Modal” Usage -- One (single) clean design and use model is encouraged The Library Author states that normal C++ design principles should prefer (b), but due to the vocabulary-type nature of the problem and domain-specific constraints encountered by real-world users, this particular library was forcefully evolved into (a). It is perhaps ironic that the suitability of a proposed library as providing vocabulary types and possibly evolving into a future standard demands that the Library Author change the library’s stated purpose due to this potential popularity; but that seems consistent with the current circumstance. The Library Author (of course) should have authority to characterize the actual intended use-case and resulting behavior provided through the authored work; with the Review Process providing analysis and feedback regarding possible missed opportunity resulting from those decisions. However, this review’s conclusion seems to encounter the curious scenario where the vision itself remains in conflict. Of course, these very differing outlooks resulted in some apparent “impasses” or circular discussions regarding type-safety (and number-of-types), wide or narrow contracts, optimization opportunities, “too-big” (or “cluttered”) interfaces, implicit or explicit conversion, the need for iterator and visitor patterns on ‘outcome<T>’, and the “empty” state and sentinel values. In support of the “Multi-Modal” design, the Library Author posits three main use patterns exist for error-handling objects-returned, and that a single design can serve only two at best: (Quoting the Library Author): > <quote> > (1) User wants failure reason type to be local to only the code to which > it applies. So think custom E type, nonconvertible to any other E type, and > E is never error_code nor exception_ptr. They specifically want to keep > failure handling local a small patch of code e.g. constexpr evaluation > contexts. > > All-narrow observers make sense for this use case as object usage is > tightly integrated to the code using it, and failure is handled entirely > locally. > > (2) User wants failure reason type to be globally understood and will be > choosing either E = std::error_code, or E = std::exception_ptr. They > specifically want failure handling to be able to traverse any or all code, > just like C++ exception throws. This is where Outcome was primarily aimed > at. > > All-wide observers make sense for this use case, as due to handling a wide > degree of uncertainty, most failure handling code is *generic* i.e. we test > for some specific failure causes, and for everything else we either ignore > or hand it off to other code to handle. > > (3) User wants to write functional programming logic using the basic > vocabulary of Maybe, Either and i/o monads and basic operators of bind, > fmap, do etc and probably some subset or refinement of Hana for the > collections monads, though my GSoC student may be making the Ranges TS a > choice here as well later this summer. > > All-narrow observers make sense for this use case as the monadic operators > ensure your function will never be called with the wrong state. > </quote> The Outcome library uses a, “single implementation, multiple personalities” to solve this problem, and makes the intentional decision to attempt targeting (2). # ISSUE: Unclear precedent/implications from including this library in its current configuration into the Boost distribution The library in its current configuration is perceived as setting precedent for changes to the Boost distribution, which reviewers commented added complexity to their analysis. Specific topics: *- Dual-license (BSL and Apache2) confused reviewers *- Add bjam support (author agreed) *- Packaging relied upon git-submodules to an outside lib archive (gsl-lite, https://github.com/martinmoene/gsl-lite.git) *- Library does tricks with the preprocessor to avoid significant compile-time costs; but these tricks were commented by some reviewers as being unnecessarily complex. *- The Author found these tricks necessary to reach reasonable compile metrics for large projects using Outcome in their public APIs, and believes some mechanism must address this build-speed-need. A proposed metaprogramming mechanism may eliminate the need for these preprocessor tricks in the future. # FINAL THOUGHTS In the very active years of “Classic Boost” (such as 2004-2008), fundamental libraries had a good chance of becoming vocabulary types that attempt to establish new Best Practice for the industry (and not merely be “just another library”). This awareness drove much of the review discussion, and underscored the importance of experimentation and “lessons learned” to result in a library that offered: (1) behavior and idioms that are understood; and (2) sufficient experience to make use recommendation to the wider user base in contrast to existing alternative approaches. Consistent with this historical context, it should be relatively uncontroversial to recognize that the Outcome library does not reach that threshold at this time (so it is rejected). However, this review also suggests: (1) A similar library is needed; (2) The community lacks agreement on direction (e.g., “Multi-Modal” vs. “Single-Modal”) In support of experimentation and to expand on our “lessons-learned”, it seems somewhat obvious that Outcome provides a strongly-implemented Multi-Modal low-latency library that will assist the community in gaining experience with these idioms proposed. Since conclusion of the review period, discussion continues (on and off-list) regarding possible evolution to the Outcome library, related to feedback provided during this review, and related to discussions of design evolution for pertinent libraries (e.g., possible changes to std::expected<>, and evolution of a never-empty ‘variant2<>’). It is promising that such a strong library as Outcome continues to receive critical attention and evolution by multiple interested parties. 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) for pushing the envelope for low-latency <error|exception> handling and for submitting his work to the Boost Review process. -- charley (Outcome Review Manager) If there be any in this assembly, any dear friend of Caesar's, to him I say that Brutus' love to Caesar was no less than his. If then that friend demand why Brutus rose against Caesar, this is my answer: not that I loved Caesar less, but that I loved Rome more. (3.2.19-24)

7 8

Deprecation indication
by Raffi Enficiaud 06 Jun '17

06 Jun '17

Hi, Is there anything in eg. boost.config or other that expands to a compiler indication that something is "deprecated", possibly with a message that appears only once? It may expand to `[[deprecated]]` or `[[deprecated("reason")]]` if available and supported, or `__declspec(deprecated)` / `__declspec(deprecated("reason"))`, `__attribute__ ((deprecated))` ... I could not find anything in boost.config. Has anyone an example of this in boost? Is there any indication/policy in boost about deprecation? Thanks in advance, Raffi

1 0

[Nowide] Links to source code
by Artyom Beilis 06 Jun '17

06 Jun '17

Hello Frederic and Boost Developers. I had noticed that the links to the source and git repository at http://www.boost.org/community/review_schedule.html are incorrect. It should be links to github https://github.com/artyom-beilis/nowide Can it be fixed before the review begins in order to prevent confusion? Thanks, Artyom Beilis

1 0

[outcome] High level summary of review feedback accepted so far
by Niall Douglas 05 Jun '17

05 Jun '17

Some reviewers have asked what form Outcome will take in the near future. The following is a high level summary of the changes already made on develop branch or will be made according to https://github.com/ned14/boost.outcome/issues logged from review feedback. I have left out some minor issues, this lists just the major changes. This should help reviewers to decide whether to recommend acceptance or rejection. If there are any questions, please do ask. Major design changes: ===================== - option<T> to be removed https://github.com/ned14/boost.outcome/issues/48 - outcome<T> and result<T> will have their empty state removed, and all observers gain narrow contracts. Default construction is disabled. https://github.com/ned14/boost.outcome/issues/44. Example: ``` result<Foo> v(make_errored_result(std::errc::invalid_argument)); assert(v.has_error()); // true assert(!v.has_value()); // true // As if Foo(reinterpret_cast<Foo &&> // (error_code_extended(std::errc::invalid_argument)); Foo f(std::move(v.value())); assert(v.has_error()); // still true assert(!v.has_value()); // still true ``` (NOTE: expected<T, E> will track whatever LEWG Expected does, but it differs from what will become result<T> by having a wide contract on .value() and narrow contracts on operator*(), .error(), operator->(). result<T> will have narrow contracts on everything, it is basically a thin wrap of std::variant<T, error_code_extended> except with strong never empty warranty) - New typedefs outcome_e<T> and result_e<T> are identical to outcome<T> and result<T> except for adding a formal empty state. Observer contract slightly widens, an attempt to use an empty object throws a bad_outcome_access exception. Implicit conversion from non-empty-capable varieties is permitted to empty-capable varieties, but not the other way round. Default construction is to **empty**. https://github.com/ned14/boost.outcome/issues/44 - New typedefs checked_outcome<T>/checked_result<T>, checked_outcome_e<T>/checked_result_e<T> are added. These mirror the editions just described, but checks and default actions occur on all observer usage so hidden reinterpret_cast<> never occurs. Implicit conversion from non-checked varieties is permitted to checked varieties, but not the other way round. https://github.com/ned14/boost.outcome/issues/47. Examples: ``` // Note result<T> implicitly converts to checked_result<T>, but not // the other way round. So we can use same make_errored_result(). checked_result<Foo> v(make_errored_result(std::errc::invalid_argument)); assert(v.has_error()); // true assert(!v.has_value()); // true // .value() throws std::system_error( // std::make_error_code(std::errc::invalid_argument)); Foo f(std::move(v.value())); ``` ``` checked_result<Foo> v(make_valued_result(Foo())); assert(!v.has_error()); // true assert(v.has_value()); // true // .error() returns a default constructed (null) error_code_extended // when result is valued to indicate "no error here" error_code_extended ec(std::move(v.error())); assert(!ec); // true ``` - The presented library self generates using lots of preprocessor based multiple #include's to stamp out finished editions of implementation. The git repo partially preprocesses this into a nearly finished edition for minimum compile time load for end users. Due to the many more varieties of outcome<T> and result<T> provided, the preprocessor machinery would be replaced with a template based machinery instead. I will look into making optional use of extern template and a static library to retain minimum compile time load, but header only usage will remain possible. Smaller design changes: ======================= - tribool stuff to go away in default configured build. https://github.com/ned14/boost.outcome/issues/22 - .get*() functions will be removed. https://github.com/ned14/boost.outcome/issues/24 - Don't include <windows.h> on winclang. https://github.com/ned14/boost.outcome/issues/39 Documentation changes: ====================== - Licence boilerplate missing on some files. https://github.com/ned14/boost.outcome/issues/38 - Reference API docs need to spell out exact preconditions, postconditions and semantics per API. https://github.com/ned14/boost.outcome/issues/26 - Reference API docs need to describe types void_rebound, *_type and raw_*_type in detail. https://github.com/ned14/boost.outcome/issues/29 - User overridable macros which throw exceptions and provide customisation points have vanished from the docs somehow. https://github.com/ned14/boost.outcome/issues/35 - Landing page and introduction to be broken up into bitesize single page chunks. https://github.com/ned14/boost.outcome/issues/41 Still to be decided: ==================== - Should *_e() varieties provide convenience .get(), .get_error(), .get_exception() which returns T, error_code_extended and std::exception_ptr by value moved from internal state, resetting state afterwards to empty? These would mirror future.get()'s single shot observers. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

10 104

DocBook toolchain: Disable auto toc for just one section's children?
by Vinnie Falco 05 Jun '17

05 Jun '17

My documentation has a reference section whose children are themselves sections automatically generated by a doxygen->xml->xslt->QuickBook chain. I want an automatically generated table of contents, but when I turn that on I get hundreds of entries for all of the individual classes and functions in the reference. Is there a way to disable just the child sections of my Reference section? Perhaps marking the section somehow and passing an xsl:param in the Jamfile or something? This would really help to put that last bit of polish on these docs. I noticed that Boost.Asio docs had the same problem, so the author just disabled the auto-toc and created a very small, manual one. Not the same. Ideas?

3 5

[property_tree] Issue: erase is corrupting the tree
by lukas.exler＠barclays.com 05 Jun '17

05 Jun '17

I have following JSON structure loaded into boost::property_tree: { "animals" : ["fox","dog","cat"] } I'm trying to delete the second item from the array by: auto assoc_it = loadedJSON.find("animals"); auto it = loadedJSON.to_iterator(assoc_it); it = it->second.begin(); it++; // move to second item loadedJSON.erase(it); After this, when I try to use boost::property_tree::write_json to write the JSON back the app crashes. Do I use the property tree in a wrong way, or is there a bug? Thanks, Lukas. _______________________________________________ This message is for information purposes only, it is not a recommendation, advice, offer or solicitation to buy or sell a product or service nor an official confirmation of any transaction. It is directed at persons who are professionals and is not intended for retail customer use. Intended for recipient only. This message is subject to the terms at: www.barclays.com/emaildisclaimer. For important disclosures, please see: www.barclays.com/salesandtradingdisclaimer regarding market commentary from Barclays Sales and/or Trading, who are active market participants; and in respect of Barclays Research, including disclosures relating to specific issuers, please see http://publicresearch.barclays.com. _______________________________________________

1 0

[outcome] non-interface-related concerns
by Andrzej Krzemienski 05 Jun '17

05 Jun '17

The discussion mostly revolves around the design of the interface of `outcome::expected` and even `std::expected`. My questions here are about the way this library will be distributed to users. And I am uncomfortable with the situation. I am not necessarily saying it is wrong, but I do not understand what is going on here. 1. The current GitHub repository consists of sub-repos. Do you (Niall) plan to have it like this when the library is accepted? Is it relevant? 2. This macro BOOST_OUTCOME_DISABLE_PREPROCESSED_INTERFACE_FILE, it controls whether I use this "preprocessed" file versus if I use... what? Normal header files? What is gained by this preprocessed file? Not having to include more than one header, or something else? Can I get different results when compiling with and without this macro? 3. I am recommended to use this macro BOOST_OUTCOME_V1_NAMESPACE. I am told it has something to do with ABI stability? Can you elaborate on how this guarantees ABI stability. Or is its purpose different? I have a certain problem with understanding this philosophy. A couple of days back, I reported the compilation failure in MinGW. I can see that the issue (https://github.com/ned14/boost.outcome/issues/36) is reorted as fixed in branch 'develop'. I would like to confirm that the bug is fixed. I checkout branch develop. There is no branch develop for the sub-repos, so what am I supposed to checkout, master, or some particular commit? I went with master. I do not understand a lot of CMake, but since it is a header-only library, I assume that I can just #include the file "include/boost/outcome.hpp", and my programs (compiled manually) should compile. But the only change in the commit that was supposed to fix the bug, was in a .cmake file, so I cannot see how it would help fix a header only library. Also, would the fix be visible in a "precompiled" header, or normal headres, or both? I am not complaining about this particular fix. I would like to know how in this system of mcros, sub-modules and preprocessed headers, I can figure out what changes will be observed in my program, when I see a particular change in git sub-repo. Regards, &rzej;

10 42

[outcome] Review
by Bjorn Reese 03 Jun '17

03 Jun '17

I apologize in advance for the rather meek review below; I did not have the time to be more thorough. > - What is your evaluation of the design? The review discussions provided many insightful arguments in favour or against various aspects of the design, and I have not formed a final opinion about most of these. I do believe that fixing E for result<T> to error_code is the right decision. I would prefer a design without an empty state, because we already have a vocabulary type for it. The choice of C++14 seems motivated solely by performance considerations. A slower C++11 version should be considered. > - What is your evaluation of the implementation? I did not have enough time to review it. > - What is your evaluation of the documentation? The introduction (Description) only provides a vague description of the purpose of the library. For example, it does not mention that its types are used to carry either a value or an error. Instead, it assumes that the reader can derive this from prior familiarity with expected<T> (or Rust.) The first motivating example is too large (as indeed are the examples in the tutorial.) Instead I suggest a "Tony table" that shows the essense of the library (either value or error.) For example: Before: FILE *file = fopen("myfile", "r"); if (!file) throw std::system_error(errno, std::system_category(), "Error delivered out-of-band by errno"); fclose(file); After: result<FILE *> file = fopen_wrapper("myfile", "r"); if (!file) throw std::system_error(file.error(), "Error delivered in-band by file.error()"); fclose(file.value()); This may not look overly convincing, but it does demonstrate the either value or error aspect in a few lines. The library is weakly motivated -- the motivation boils down to a less expensive alternative to throwing exceptions. A stronger motivation would have been to mention use cases were errors cannot be propagated by throwing exceptions. Here are two examples: One motivating use case where exceptions cannot be throw are callbacks, such as Boost.Asio asynchronous handlers. Here the return value is not returned by the asynchronous operation (the initiating function), but will be passed to the provided callback once the operation completes. In other words, the following synchronous operation return_type operation(arg_type, error_code&); is turned into this asynchronous operation: void async_operation(arg_type, void (*)(return_type, error_code)); Exceptions cannot be thrown into the functions (here the callback), so errors have to be passed as arguments (whether error_code or exception_ptr.) The above works if the return_type has a reasonable "unengaged" value that can be passed as the first argument in case of an error. While this is true for Boost.Asio, where return_type is a std::size_t, it is not necessarily true in general. A much better solution is to pass an outcome<T>, result<T>, or expected<T>: void async_operation(arg_type, void(*)(result<result_type>)); Another motivating use case is passing results between threads. For instance, in the Actor model of concurrency information is passed between actors/threads via a message queue. Some of these messages are replies to requests that may or may not have failed. A queue containing one of the Outcome types is well-suited for this kind of interaction. Apart from the above-mentioned shortcomings, I found the remainder of the documentation quite readable. I did not find the inheritance diagrams in the reference documentation useful though. > - What is your evaluation of the potential usefulness of the library? The idea of an either-value-or-error return type is very useful. > - Do you think the library should be accepted as a Boost library? No, not in its current form. I have two reasons for this rejection. First, some of the design discussions (especially on narrow/wide contracts) are not settled yet, so it would be premature to vote for the design. Second, whilst the lastest offer from the author about a fully-fledged Boost.Outcome repository without a dependency on the non-reviewed library called "boost-lite" is a step in the right direction, it is unclear to me how that repository will end up. Having been surprised by the current submission and the author's opinions, I will defer any vote of acceptance until the a repository is submitted for review.

2 2

[outcome] expected, etc. why are these assignable
by Robert Ramey 03 Jun '17

03 Jun '17

It just occurred to me that for a similar component I created some time ago for my own purposes, I (intentionally?) support of the assignment operator. Copy construction was permitted however. So the only way to use the component is: checked_result<int> = function(...); something void function(checked_result & cr, ....) will be the same as void function(const checked_result & cr, ...) because checked_result only contains const functions. That is, once constructed, it's immutable. Personally I never use an interface which passes a mutable type to a function. To me it violates the mathematical idea of what a function is. Doesn't this simplify things? Doesn't this eliminate the whole questions about about empty state, etc. Doesn't this better model the "mondad" concept we're trying to leverage on. And why the hell are we modifying and an object designed to model a result in the first place? It doesn't make logical sense in terms of we expect a "result" to be. I plunk down my money (a function) and ask for a pepperoni pizza. Either they say they don't have pepperoni and give me my money back or give me a pizza. I don't think of modifying this result - it's an artifact of history. And wouldn't making these things immutable, eliminate a large part of the whole controversy? Just a thought. I think sometimes something is hard because we haven't thought enough about what we're really trying to do - what problem we're trying to solve. Robert Ramey

6 16

[outcome] To variant, or not to variant?
by Gavin Lambert 03 Jun '17

03 Jun '17

I probably should have thought of asking this earlier, but it occurs to me now that my own mental model of how an "outcome"-ish type should act is probably not suited to variant storage at all. So just out of curiosity I thought I'd ask whether people prefer this sort of interface: template<typename T> class outcome { public: bool has_value() const { return m_storage.has<T>(); } T& value() { return m_storage.get<T>(); } bool has_error() const { return m_storage.has<error_code>(); } error_code& error() { return m_storage.get<error_code>(); } bool has_exception() const { return m_storage.has<exception_ptr>(); } exception_ptr& exception() { return m_storage.get<exception_ptr>(); } void set(none_t) { m_storage = none; } void set(const T& val) { m_storage = val; } void set(error_code err) { m_storage = err; } void set(exception_ptr ep) { m_storage = ep; } private: variant<none_t, T, error_code, exception_ptr> m_storage; }; Or this sort of interface: template<typename T> class outcome { public: bool has_value() const { return !!m_value; } T& value() { ensure(); return m_value.value(); } //bool has_error() const { return !!m_error; } const error_code& error() const { return m_error; } //bool has_exception() const { return !!m_exception; } const exception_ptr& exception() const { return m_exception; } void ensure() const { if (m_exception) { rethrow_exception(m_exception); } if (m_error) { throw system_error(m_error); } } void set(none_t) { m_value = none; m_error = error_code(); m_exception = nullptr; } void set(const T& val) { m_value = val; m_error = error_code(); m_exception = nullptr; } void set(error_code err) { m_value = none; m_error = err; m_exception = nullptr; } void set(exception_ptr ep) { m_value = none; m_error = ep ? error_code(errc::has_exception) : error_code(); m_exception = ep; } private: optional<T> m_value; error_code m_error; exception_ptr m_exception; }; (Don't get too hung up on the specifics. This is a sketch, not a real implementation. I've obviously omitted things that a real implementation would need such as more const methods and move support, and construction and assignment rather than using set methods. The focus is on variant vs. non-variant.) Anyway, the point is that this could actually transport multiple things; in particular as above both an error_code and an exception_ptr; perhaps set(error_code) could construct an exception as well, although I've explained elsewhere why I don't like that option. Perhaps this could even be exposed even more so that user code could explicitly provide both a value and an error -- think "here's a value, but it was truncated" or "here's the 5 values you asked for, but there's more", both fairly common in system APIs. Or for things like ambiguous matches where you still return the most likely candidate. Or dictionary insertion (duplicate key, but here's the value that's already there). Or many more such examples. (Though obviously in this case value() couldn't call ensure(). But that should make some people happy.) Also note has_error() and has_exception() don't even need to be provided in this version since you can always call error() and exception() in a boolean context anyway, with the same result. (Or actually a slightly better result than the implementation shown here.) The obvious downside is that it now uses more storage, which might hinder some inlining cases.

9 63