June 2017 - Boost - lists.boost.org

[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

[sort] Timsort review
by Steven Ross 03 Jun '17

03 Jun '17

The review for C++ Timsort in Boost will commence tomorrow, June 3, and continue through June 12. I am the review manager. The code can be found here: https://github.com/boostorg/sort/pull/12 To merge it into a local copy of the Boost.Sort library: git checkout -b ZaMaZaN4iK-feature_branch/TimSort develop git pull https://github.com/ZaMaZaN4iK/sort.git \ feature_branch/TimSort If you want to see a proposed version of the Sort library source with Francisco's changes and Timsort included, download the zip file <https://drive.google.com/file/d/0B4s-GPKYVV0jOGx5ckJUTkZzMWM/view?usp=shari…>. Feel free to compare flat_stable_sort with Timsort. Please answer these questions in reply to this thread: 1. What is your evaluation of the Timsort implementation? 2. What is your evaluation of the comments? 3. Did you try to use the library? With what compiler? Did you have any problems? 4. How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? 5. How familiar are you with the details of hybrid and stable sorts? 6. Would you actually use Timsort if it was in Boost.Sort? If so, how is it better than the next best alternative? 7. Do you think Timsort should be included in Boost.Sort? Please ask Alexander Zaitsev any questions you have about Timsort for this review before submitting your final review. Thanks, Steven Ross

1 0

[poly_collection][VS 2017] Potential compiler bug
by Joaquin M López Muñoz 02 Jun '17

02 Jun '17

Hi, Boost.PolyCollection tests have started to cycle and I found VS 2017 aka MSVC 14.1 fails at test_algorithm.cpp: http://tinyurl.com/yb4zdkys whereas this test compiles and runs OK with VS 2015 aka MSVC 4.0 (_MSC_FULL_VER = 190023026). I've distilled down the problem to this test case: #include <algorithm> #include <utility> template<typename... Ts> struct all_of { template<typename... Args> auto operator()(Args&&... args)const-> decltype(std::all_of<Ts...>(std::forward<Args>(args)...)) { return std::all_of<Ts...>(std::forward<Args>(args)...); } }; int main() { int x; all_of<> alg; alg(&x,&x,[](int){return true;}); } which works fine with GCC and VS 2015 but fails in webcompiler.cloudapp.net with Compiled with /EHsc /nologo /W4 /c main.cpp main.cpp(9): error C3546: '...': there are no parameter packs available to expand main.cpp(18): note: see reference to class template instantiation 'all_of<>' being compiled (_MSC_FULL_VER = 191125331, which I think is VS 2017.3 or something). This looks like a regression to me. Deleting the ->decltype(...) bit makes the problem go away but I need to stay within C+11. * Can someone (STL?) confirm this is indeed a compiler bug? * Any rewording of the code that might be generally applicable to C++11 so that I don't have to include a specific workaround for VS 2017? Thank you, Joaquín M López Muñoz

2 1

[outcome] Outcome Review Period Closes Today (Fri-02-June)
by charleyb123 . 02 Jun '17

02 Jun '17

Hello Everyone, Today concludes the Outcome library review period (Fri-02-June-2017). Great thanks to all that invested so much time and effort to explore in such a disciplined and professional manner the dark corners of error/exception composition and a paradigm/API/implementation proposed by the Outcome library. Your efforts are truly appreciated. Reviews sent to the public list are the following (PLEASE contact me if I've missed your review): *- Paul Bristow (Tue-23-May) *- Daniz Bahadir (Wed-24-May) *- Robert Ramey (Wed-24-May) *- Peter Dimov (Sun-28-May) *- Emil Dotchevski (Sun-28-May) *- Vicente J. Botet Escriba (Tue-20-May) *- Andrzej Krzemienski (Wed-31-May) *- Gavin Lambert (Wed-31-May) My understanding is that as the review concludes today, further reviews are permitted only until the end-of-day UTC. In addition, many notable discussions and topics raised during the review period will also contribute to a final submission decision and summary report. Preparing this report will take some time. I've accumulated extensive notes, but my intention is to review (re-read) all discussion in the context of the "story-arc" and (in some cases) the shifted opinions of some persons during the course of the review (as topics were clarified and alternatives were explored). I assume other "satellite discussions" will continue (e.g., evolution of std::expected<>, suitability of wide vs. narrow contract in APIs, generalization of variant<>, etc.), which I will endeavor to continue to follow as the Outcome Review summary report is prepared (because these continued discussions may further clarify issues previously raised during the Outcome Review); but no more reviews can be accepted after the review period closes. Thank you all (again) for your (often thankless) contributions to the community, where the personal sacrifice in time and effort (and perhaps stressful emotional investment) is quite obviously extensive in many cases. --charley

2 2

[outcome] where is the monadic style tutorial?
by Mathias Gaunard 02 Jun '17

02 Jun '17

Hi, I just took a quick look at outcome today and I don't really understand what it is doing. I expected to have some kind of mechanism to manage control flow with propagation between states only happening if the previous expression in the chain resulted in an expected value, like with the Expected monad. I searched throughout the documentation and didn't find any. Why is there no example of this? More than how the error state is captured and stored or how to capture custom errors, I believe the programming model is what the tutorial should really focus on.

3 4

[outcome] Formal review
by Gavin Lambert 01 Jun '17

01 Jun '17

With the extended review period ending soon (or perhaps slightly overdue, depending on timezone), and given my many posts regarding the library, I feel like I should probably express my thoughts in review form. This is my first formal review and I am not myself a Boost library author (just a user) so please take that into account. - What is your evaluation of the design? A lot of thought has clearly gone into it, though I'm not sure I agree with some of the decisions made. Empty state I'm on the fence about; I can see it's convenient both for optional<T> success return semantics and for not-yet-populated/called pending result semantics, but I'm not sure these are consistently applied as it stands, and they seem at least partly opposed to the "empty state is weird, let's aggressively throw" behaviour in the actual implementation. Simplifying expected<T, E> into result<T> and outcome<T> makes sense, and the design of error_code_extended seems reasonable, including the content and ring buffer history. However I wonder if perhaps some middle ground might be better, where result<T, E> and outcome<T, E> exist but E is constrained to a type with specific characteristics (such as being constructible from error_code and having noexcept move). This might allow for more flexible error payloads. Alternately some way to use a similar error_code_extended-linked-to-ring-buffer system but with a user-defined payload data type. I don't consider this to be a defect or reason to reject the library, though, just something that would be useful if possible. I don't like that result<error_code{,_extended}> is not legal, as this seems like unnecessary asymmetry, though again I don't consider this a rejection reason. - What is your evaluation of the implementation? I have not looked in depth at it. The dual licensing and dual source distribution (preprocessed vs. not) bother me, but that will apparently be addressed in future. I don't like the total duplication of interface methods (get vs. value, error vs. get_error), but this will apparently also be addressed in future. (I am not opposed to having both narrow and wide accessors in the same type, though I prefer that the ones that can cause UB if abused require more typing. I *am* opposed to having multiple names for the exact same behaviour.) I'm not sure why it would be useful to provide const&& overloads of some of the value methods. Usually the only time I've seen these is to explicitly delete that overload. (Unless that is what's actually happening and doxygen is just not showing that correctly.) I like the use of wide contracts by default, such that it is safe to call value(), error(), or exception() without inspecting the underlying type and they will react sensibly (eg. throwing) rather than having UB, although some of the finer points of what a sensible reaction means are still being debated. But I can understand the desire of some people to have the other versions available for specific cases or in environments where static checking is more common. Even so, I hope that the narrow versions will at least BOOST_ASSERT their preconditions. The lack of use of Boost facilities such as Config, Assert, and Core (esp. BOOST_NO_EXCEPTIONS) bothers me more, and I do consider that a rejection reason. Use of StackTrace would be good as well but at this point I don't consider that a defect since it's not quite "in" Boost yet. (Possibly also Exception for boost::throw_exception, though using std::exception_ptr is the correct choice.) There is a critical defect in error_code_extended's backtrace API, which has already been brought to the author's attention and should hopefully be resolved later. - What is your evaluation of the documentation? Generally good, although it seems to spend a lot of time and pages talking about expected<T, E>, and only towards the end adds "but you should probably use outcome<T> instead" as a sort of afterthought, which seems a bit backwards. This is perhaps the correct order in a presentation, but it feels wrong in library documentation somehow. I think it needs to be more up-front about outcome and result (since those are the core types of the library) and recommended usage, and cover the other things as background material afterwards. The documentation refers to "monads" a lot, which is an unfamiliar concept to me. Not sure if this needs more explanation or just rewording. Doxygen's habit of putting hyperlinks that go nowhere in the reference pages is a bit disconcerting as well. - What is your evaluation of the potential usefulness of the library? Direct usefulness to me right now will be limited due to compiler support, but this seems like the sort of thing that would be quite useful in the future, especially to tidy up dual APIs such as those in ASIO. They have a fairly good chance of becoming standard vocabulary types, which of course has also helped drive a lot of the discussion thus far. - Did you try to use the library? With what compiler? Did you have any problems? I have not, as the compilers I use day-to-day are only C++11 or less, not C++14. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? Primarily a fairly detailed reading of the documentation, combined with discussion here. - Are you knowledgeable about the problem domain? Mixed. I have experience with exception handling internals in MSVC and regularly work with software in both contexts of using error codes everywhere with exceptions banned, and of allowing exceptions but preferring they never actually be thrown. I also regularly work with both low-latency and fixed-latency environments, in addition to more "normal" software. But other than interaction with ASIO I have not made much use of error_codes to date, or mixing the two environments in the "sea of noexcept" fashion, though I can see the appeal. - Do you think the library should be accepted as a Boost library? Eventually, yes, but currently no (rejection, with encouragement to resubmit). While the author claims that the actual implementation has changed little since initial submission, the changelog in the "review accepted feedback" threads sounds fairly serious, and I'm not sure I like some of its directions (such as separate types for contract variations). Perhaps it will indeed end up being no big deal, but I don't feel like I have a good handle on what the end result will look or behave like so I don't feel comfortable endorsing it until I can get a better look at it. Primarily though I think the Boost integration was done backwards; the library should make use of Boost facilities first (as previously mentioned); if also distributed separately then that separate distribution should have the Boost emulation layer in it, and not the reverse. (To clarify: using std:: facilities is preferred, so using <system_error> is better than using <boost/system/system_error.hpp>, although it would be nice if compatible with the latter without actually depending on it unless requested explicitly. But the main problem is lack of use of Config, Assert, and Core, unless I missed something.)

2 2