- Boost - lists.boost.org

[review] Review of Outcome (ends Fri-June-2)
by charleyb123 . 31 May '17

31 May '17

Reminder -- On Fri-26-May the Review Wizards approved extending the Outcome review until Fri-02-June. (Notification was sent to the list, but considering the high traffic volume lately, one can be forgiven for having missed that message.) Thank you to everyone for your tremendous efforts in taking part in the review; for keeping up with high message traffic; and for the professional and deep exploration of the many (very broad!) topics touched on during this review. The review continues for several more days, ending Fri-02-June (it will not be extended further). Please consider posting a review to the boost mailing list, or privately to the Review Manager (to me). Here are some questions you might want to answer in your review: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? And most importantly: - Do you think the library should be accepted as a Boost library? For more information about Boost Formal Review Process, see: http://www.boost.org/community/reviews.html Thank you very much for your time and efforts. --charley

3 2

[gil] where is the mysterious boost::gil::read_image function?
by Frédéric Bron 31 May '17

31 May '17

I would like to read a jpeg image from a memory location, not from a file. According to this post http://boost.2283326.n4.nabble.com/gil-io-new-review-Reading-images-from-in… there is a boost::gil::read_image(input_stream, image, image_tag) function but I cannot find it in the header files. Thanks, Frédéric

1 0

[future.then] Should deferred continuation respect status of original future?
by Tomas Sturm 31 May '17

31 May '17

Hi, consider this code that wraps some library returning a future: // some async library boost::future<intermediate> DoLongAsyncTask() { return myPromise.get_future(); } // intermediate translation layer boost::future<result> GetResult() { return DoLongAsyncTask().then([] (boost::future<intermediate> f) { return TranslateToResult(f.get()); }); } // client event loop void RunInClientContext() { auto myFuture = GetResult(); while (stuffToDo()) { doStuff(); if (SafeToCallFutureGetWithoutBlocking(myFuture)) ProcessResult(myFuture.get()); } } What should the implementation of 'SafeToCallFutureGetWithoutBlocking' be? Normally, one would write something like: myFuture.is_ready() or myFuture.wait_for(chrono::seconds(0)) != future_status::timeout But this doesn't work in case the implementation of intermediate translation layer calls .then with launch::deferred! In Boost 1.63 the future returned from .then(launch::deferred, ...) is always deferred, so wait_for(...) always returns deferred no matter what (and is_ready() always returns false). In fact, there is no way to implement 'SafeToCallFutureGetWithoutBlocking' if the translation is to happen in the context of the client (launch::deferred). Wouldn't it be more natural to respect the status of the original future in this case? The documentation is already very clear that the continuation is executed only after the original future is ready. So in case a client asks whether the continuation future is ready, and the original future is not ready yet, the call should forward to the original future instead. What I propose is this: promise<int> p; future<int> f1 = p.get_future(); future<int> f2 = f1.then(launch::deferred, [] (auto f) { return f.get(); }); assert(f2.wait_for(0) == future_status::timeout); p.set_value(42); assert(f2.wait_for(0) == future_status::deferred); Is there any reason for the continuation future to not behave this way? Regards Tomas

2 1

[outcome] narrow-contract, wide-contract, and value_if
by Andrzej Krzemienski 31 May '17

31 May '17

Hi Everyone, Some comments about `outcome`'s observers with narrow and wide contracts. First, the wide-contract functions. We have a situation when someone assumes that `o` currently stores an error_code, and with this assumption in mind calls `o.error()`, but somehow his assumption is incorrect. What do we want to do? 1. Try to report programmer's bug at run-time? 2. Since in this case it is a bug anyway and are screwed, at least let's make such behavior useful for other situations where `error()` is called conciously on `o` without an error code? The first scenario attempts at identifying a bug, bringing it to attention of developers (maybe in form of a log), and minimizing its consequences by perhaps skipping the execution of some part of the program in hope that the bug will no show symptoms again. The second scenario in a way ignores the bug, and lets the program continue, as though it was correct, and from now on the program is doing something else than what the programmer intended. But the semantics of the function are useful in itself. Users who check `o.has_error()` before calling it can use it as if `error()` had a single purpose and a narrow contract; and users who know the additional semantics can use it for other useful things, like saving themselves of writing some boilerplate code. It is my impression that some of these observer functions in `outcome` follow this second scenario: just do something useful for people who use it unchecked. Saving boilerplate is useful, but let's state it clear: these functions offer no protection against inadvertent mistakes: no run-time or static protection. If I call `o.error()` and it throws when `o.is_empty()`, it is a form of protection. If `o.error()` returns `E{}` when `o.has_value()`, this is no protection, it is convinience function that can be used as a narrow-contract observer. Maybe the interface of `outcome` should make this distinction and offer two sets: one for observers with run-time protection, and the other for nice convenience functions? Second, narrow-contract functions. Narrow functions acheive the following goals: 1. Simple design: function only does one thing, it does not have any if inside. 2. The interface of the library makes a clear distinction of what is valid and what is an invalid usage of the library. It helps in code reviews. For instance, you are looking for a bug in a big code, you find the following piece: ``` auto e = o.error(); ``` and it turns out that `e` contains a value. Did you just find a bug, or was it the author's intention to get an `E{}` at this point? You do not know with wide contracts. With narrow contracts you know: it is a bug. 3. Narrow contracts assist instrumentation in test builds and runs. If I have function `just_value` with a narrow contract, I leave myself the freedom: I can do whatever I want when has_value() is false. What can I do with this freedom: A. In test build, I can check the precondition at run-time and launch the debugger B. I can (run-time) check the precondition, and std::termiante() or throw an exception. C. I can ignore the potential precondition violation, check nothing and aim at some performance gain. D. I can put some code that assists the static analyser (like __builtin_unreachable()) E. I can put some instrumentation code that assists an UB sanitizer (like __builtin_unreachable()) F. I can put hints for optimizer (like __builtin_unreachable(), again) G. Finally, I can put a macro `PRECONDITION(has_value())` which can do any of the above based on the build configuration. Given that, the proposed function `value_if` (which returns a pointer to value) will not satisfy my needs. It has a wide contract, so I cannot put macro `PRECONDITION()` inside. It rturns a pointer. The pointer's operator-> inded does have a narrow contract, but it gives me no room where I can put macro `PRECONDITION()`. So I get some narrow contract, but without the benefits I am looking for. So that is my view of the observer functions. Now my proposal is to provide a pair of observers for each value, error_code and exception -- narrow and wide: `value()` and `just_value()`, `error()` and `just_error()`, `exception()` and `just_exception()` Or maybe, even three for narrow-contract, wide-contract with run-time protection, and for convenience function: `error()` -- wide-contract, runtime-checked precondition `just_error()` -- narrow contract `as_error()` -- convenience function, e.g. returns E{}, on value, monad::has_exception on exception, etc.. Regards, &rzej;

2 2

[outcome] user's experience
by Andrzej Krzemienski 30 May '17

30 May '17

Hi Everyone, In order to test Boost.Outcome, I applied it to the problem I had to solve at work a while ago. For people who do not know what Boost.Outcome is for, this could be an introduction. For me it can be an opportunity to obtain feedback from Niall and Vicente, If I am using `expected` correctly, and they can get some feedback from me. Here is the task. I get an std::string as input: it is a data structure encoded in ASCII text: "1-10|11-20|21-99;1-10|10-50|51-99" Semicolons separate "distributions". Within distribution, vertical bars separate "ranges". Within ranges, dashes separarate integer numbers. There are some additional constrains. like ranges within distribution cannot overlap, no gaps between ranges are allowed, and a couple more. I need to validate if the input matches the required format, and build a corresponding data structure. But the vaidation cannot be just binary valid-invalied answer: I want to give user a description of what exactly is wrong with her input, as detailed as possible. So, I have function parse, that internally calls parse_distribution, which in turn calls parse_range. Each of them can return different parsing error that needs to be propagated up. My original implementation used "out" function parameters for signalling errors. Code was unnecessarily long and it was easy to forget to check results from functions, but I didn't want to use exceptions to indicate validation failures, because there is nothin exceptional about it. You expect input validation to fail -- quite often. Now, this is a more philosophic question: when to use (or not) exceptions. One citerion I sometimes use is, "do I want my debugger to automatically break if this function reports faiure?" So I didn't use exceptions for input validation, but the ugliness of the code forced me to go back to rewrite it with exceptions. The code was shorter, and "saer" in the sense that I could not forget ot pass the failure up the stack. Now with Boost.Outcome I have a third option. It is almost as concise as exceptions, but does not use exceptions. Here is my implementation: https://github.com/akrzemi1/__sandbox__/blob/master/outcome_practical_examp… Note a couple of things. I am creating a number of temporay strings under way, they all can throw bad_alloc. I am fine with that. I am not affraid of throwing an exception, it is only the validation failures that I want to report with `expected`. For other failures I want exceptions. This is input validation. It does not have to be super fast. In the public API of this file, I will not be exposing the information about parsing failues. `process` will consume the error information and just output something. So, the choice of `E` in `expected<T, E>` is internal to a file, and I can choose something specific to my use case. I provid my own type, which encodes different erroneous situations in an enum, and two ints for additional details. ``` struct BadInput { enum { no_distrib = 1, range_count_not_3, distrib_starts_with_no_1, distrib_ends_with_no_99, gap_between_ranges, overlap_between_ranges, inverted_range, no_2_numbers_in_range, not_a_number, } type; int val1; int val2; }; ``` It is quite similar to Outcome's error_code_extended. Now, I also wanted to have an std::string member inside, but `expected` forbids it: It says as per LWG requirements `E` in `expected<T, E>` must not kave a throwing copy constructor. Is that right? In my use case it wouldn't harm anyone: if copying of `expected` throws, entire function `process` is exited, with a bad_alloc, which is fine. No `expected` with partial state will be ever observed. Do we need this restriction? Also, at some point I will be returning an `expected<vector<T>, E>`, which makes me uneasy. Returning vectors wrapped in something: will I get runtime penalty for it? So, I naturally arrived at a pattern that Niall described in the other thread: ``` out::expected<vector<T>, E> parse (...) { out::expected<vector<T>, E> ans {out::value}; vector<T> & vec = ans.value(); // will if statement be ellided?} // fill vec return ans; } ``` (BTW, this constant out::value is not documented in the docs, unlike out::value_t.) It has been mentioned a number of times that an optimizing compiler can remove a redundant if-statement. I know that the if-statement inside `value()` is redundant, but in this particular case, will compiler know it to? Nobody has called `has_value()` before. Also, the following piece of code illustrates how concise the implementation of a single function can be: ``` // I use a shortet alias for macro BOOST_OUTCOME_TRYX. // It is not portable, though. It only works on Clang and GCC. #define TRY(ex) BOOST_OUTCOME_TRYX(ex) out::expected<Range, BadInput> parse_range (const std::string& input) { tokenizer numbers_s {input, sep_3}; auto it = numbers_s.begin(), itEnd = numbers_s.end(); int count = std::distance(it, itEnd); if (count != 2) return out::make_unexpected(BadInput{BadInput::no_2_numbers_in_range, count}); Range r {TRY(parse_int(*it++)), TRY(parse_int(*it++))}; if (r.lo > r.hi) return out::make_unexpected(BadInput{BadInput::inverted_range, r.lo, r.hi}); return r; } ``` It is almost as short as if I used exceptions, except for the TRY macro. Note in particular this line: ``` Range r {TRY(parse_int(*it++)), TRY(parse_int(*it++))}; ``` `parse_int()` returns `out::expected<int, BadInput>`.Now, `TRY(parse_int(...))` is an expression and means, "if parse_int() failed immedaitely return function `parse_range` with the same BadInput, otherwise use its `value()` to initialize `r`. What do you think. Am I using the library correctly? Regards, &rzej;

4 7

[outcome] Exception safety guarantees
by Andrzej Krzemienski 30 May '17

30 May '17

Hi All, This is in connection with Vicente's question: what exception safety should we expect of copy assignment of `expected`? Now, this is really funny because we are talking about exception safety in something that is used as a substitute for exceptions. That is, one of the use cases for `expected` is to be able to get rid of exception handling altogether (while still reporting failures). But this fundamental problem, "what state my object is in if this mutating operation fails" is not specific to exceptions. It is speciffic to operations that might fail; and how (and if) they signal failures is of secondary importance. So, let's talk about *failure safety* rather than 'exception safety'. First, let's consider the use case for `expected`, where we want to disable exception handling altogether. This means `T` or `E` cannot throw on any operation. But copy assignment can still fail, right? Or maybe in these domains you are only using trivially-copyable types as `T` and `E`. Or maybe in these domains you never have a need to copy-assign instances of `expected`? Is so, they provide a *no-fail* guarantee, and any implementation of `expected` will be good and offer no-fail guarantee also. Bus if some copying operation on T or E can fail, how is the failure reported? Through a return value? Output parameter? But whatever the answer, we are arriving at the "nested failure" problem: we are processing a (potential) failure report, and this processing fails. What should we do? report the new error condition and ignore the previous? This is very close to a double-exception during stack unwinding. In C++ it std::terminates, other languages ignore the original error, or build a combined error report. All these solutions not satisfactory, and maybe no satisfactory solution exists. I would like to hear an opinion from people who deal with `expected` in exception-disabled environments. On the other extreme, you fave my example with parsing input (which Vicente observed is not parsing, but matching): https://github.com/akrzemi1/__sandbox__/blob/master/outcome_practical_examp… In that case, If I get an exception anywhere (not only upon copying T or E) I want stack to be unwound so far, that all not `expected` objects will remain. So I only care about basic failure guarantee: just let me correctly destroy these objects. In the middle: you have the situation where you copy-assign an `expected` and a copy-constructor of assignment of T or E throws. But where did this exception come from, given that you are using `excepted` for signalling failures? Or are you signalling some failures with exceptions and some with `expected`? And if so, are exceptions not more panic-like? And in that case yu would like to abandon the processing of any `expected`? Anyway, the most difficulties stem from the case where you are storing an E in `expected` and you want to assign an `expected` storing T. You have to first destroy E, and then may not be able to construct a T. My solution to this would be to go to the advice from the first days of forming exception safety guarantees: provide basic guarantee by default, and strong guarantee only if it does not cost too much. We are used to STL containers providing strong assignment, but this is because they are pointers, and they can implement it for free. But does std::touple provide a strong guarantee? No. Do aggregate types provide stron guarantee? No. And can it result in inconsistent data? It can: ``` struct Man { std::string fist_name, last_name; }; Man m1 = {"April", "Jones"}; Man m2 = {"Theresa", "May"}; try { m2 = m1; } catch(...) { } ``` `m2` may end up being {"April", "May"}. And we are taught to write types like this. But if this hapens, the blame is on whoever allowed these objects to outlive the "stack unwinding bubble". So my view, as of today, is not to strive for a strong or even never-empty guarantee. Provide a conditional guarantee, if types T and E don't throw, you get no-fail guarantee. If they do, you only have a basic guarantee: you can destroy, assign to, or maybe call valueless_by_exception(). Nothing more. I think `std::variant` made the optimal choice. And people should code so that instances of `expected` (at least those with T or E throwing on copy/move) should not outlive the "stack unwinding bubbles". Also, note what vector::push_back does when T is non-opyable and its move constructor is potentially throwing: if T's move throws upon reallocation, the behavior is undefined. Regards, &rzej;

8 42

[outcome] Review of Outcome
by Peter Dimov 30 May '17

30 May '17

What follows is my review of the Outcome library. I. DESIGN --------- The general idea of an error handling framework is sound, extremely appealing, and I found it well explained in the documentation. I like the concept very much and agree with many of the design decisions taken throughout. Specifically, constraining the error type to be the fixed std::error_code (or equivalent) and providing a wide accessor interface. I don't think that option<T> should have been included at all. It duplicates optional<T> and has no good reason to exist other than to showcase that the underlying policy-based implementation can produce it. I don't consider expected<T, E> a particularly needed part of the library; the focus should be on result<T> and outcome<T>, the two classes that represent the error handling philosophy on which the library is built. As already stated, I consider the interface of result<T> and outcome<T> a bit too cluttered. Not everyone shares my design preferences for minimal but complete interfaces, so there's legitimate argument to be had over whether, for instance, operator*, operator-> or value_or ought to be included, but the needless duplication between get() and value() is, well, needless. For an initial submission, it's better to err on the side of too little, rather than too much, because it's easy to add later, hard to remove. The empty state has been a source of controversy, and with reason. My initial stance was that it simply needs to go. This however presents a legitimate design question as to what the behavior of the default constructor ought to be. After seeing the suggestions of leaving the object uninitialized there, I now see the empty state as a significantly lesser evil. Having an empty state without the default constructor putting the object into it however is pointless. I do not agree with the direction things have taken of providing a multitude of result classes instead of a single one. Components that are intended to be used in interfaces should provide one, carefully designed option, which encourages what the designer deems best practices. The idea here, assuming that we shoot for standard acceptance at some point, is to provide std::result<T> and have APIs return it, not provide a bag of options and let everyone pick its own thing. (They already do that today and we're not better for it.) I do not agree with making value() unchecked by default. As I explained, one expression of the error handling philosophy behind the library is the following snippet: auto r = function().value(); where function() is noexcept and returns result<T>, whereas the place where the above line appears is a higher level component that signals errors not via error_code, but via exceptions. This one-liner provides the transition in an elegant way; losing it obscures the vision behind the library. Instead of using std::error_code, the library provides its own error_code_extended, complete with an interesting and very useful ring buffer logging mechanism that stores additional information along with the standard code/category values. Specifically, it returns error_code_extended from result<T>::error(). I would separate things a bit further here, attaching the additional information not to a separate error_code_extended class, but to result<> itself. That is, result<>::error() would return std::error_code, and I'd provide a separate accessor, result<>::error_info(), say, that would return the ring buffer entry associated with this result<>. This for me provides a cleaner separation between the basic result<> functionality, and the extended one, although this is a matter of taste. I would also support chaining result<>s by storing the index of the parent ring buffer entry in the current ring buffer entry. This is a straightforward and very useful extension. Instead of providing a macro BOOST_OUTCOME_CATCH_EXCEPTION_TO_RESULT, I would provide result<T>::set_error_from_exception(std::exception const& e); and outcome<T>::set_error_from_exception(std::exception const& e, std::exception_ptr const & p); that would do more or less what the macro does, except the fallback in the second case would be to store p instead of (EINVAL, e.what()). I'd also use make_error_result and make_value_result instead of make_errored_result and make_valued_result, as the former seem more grammatically correct. II. IMPLEMENTATION ------------------ The implementation, from a cursory look, appears of high quality, which is not surprising given that it was in use for two years. The preprocessed header is not easy to review, but the non-preprocessed form is available and amenable to study. Simple examples using outcome<T> compile and work well, although under VS2017 Clang/C2 windows.h is included, which is unfortunate but fixable. The library does not provide a test/Jamfile, which means that as submitted it will not integrate into Boost's testing infrastructure. Given that a Jamfile that performs the equivalent of withmsvc.bat is trivial to write: import testing ; project : requirements <include>../include/boost/outcome/v1.0 ; run unittests.cpp ; the omission is inexplicable. (Further integration into the Boost test matrix would ideally entail splitting unittests.cpp into separate .cpp tests so that success/failure can be tracked independently.) With the above Jamfile, trying to test the library with Cygwin gcc fails with: D:\tmp2\boost-master\libs\outcome\test>b2 toolset=gcc-cxx14 [...] gcc.compile.c++ ..\..\..\bin.v2\libs\outcome\test\unittests.test\gcc-cxx14-6.3.0\debug\unittests.o In file included from ../include/boost/outcome/outcome.hpp:26:0, from unittests.cpp:34: ../include/boost/outcome/outcome_v1.0.hpp:1446:22: fatal error: execinfo.h: No such file or directory #include <execinfo.h> ^ compilation terminated. I realize that Cygwin is not a supported platform, but this is what I have here and this is what I test with, so I figured I'll give it a try. Trying to test with VS 2017 fails with: D:\tmp2\boost-master\libs\outcome\test>b2 toolset=msvc-14.1 [...] compile-c-c++ ..\..\..\bin.v2\libs\outcome\test\unittests.test\msvc-14.1\debug\threading-multi\unittests.obj unittests.cpp unittests.cpp(780): error C3245: 'boost::outcome::_1_0_std_std_9274c0d4::basic_monad<boost::outcome::_1_0_std_std_9274c0d4::policy::monad_policy<udt>>::is_constructible': use of a variable template requires template argument list d:\tmp2\boost-master\libs\outcome\include\boost\outcome\outcome_v1.0.hpp(4271): note: see declaration of 'boost::outcome::_1_0_std_std_9274c0d4::basic_monad<boost::outcome::_1_0_std_std_9274c0d4::policy::monad_policy<udt>>::is_constructible' unittests.cpp(780): fatal error C1903: unable to recover from previous error(s); stopping compilation I get the same failure with /std:c++latest. Testing with the msvc-14.0 toolset works. The library as submitted contains both a preprocessed, fully self-contained, single header named outcome_v1_0.hpp, which is used by default, and a traditional non-preprocessed form that can be chosen with a macro. For the non-preprocessed form to be functional, a git submodule is incorporated by reference: [submodule "include/boost/outcome/boost-lite"] path = include/boost/outcome/boost-lite url = https://github.com/ned14/boost-lite.git branch = master fetchRecurseSubmodules = true ignore = untracked which in turn incorporates two more submodules: [submodule "include/gsl-lite"] path = include/gsl-lite url = https://github.com/martinmoene/gsl-lite.git branch = master fetchRecurseSubmodules = true ignore = untracked [submodule "pcpp"] path = pcpp url = https://github.com/ned14/pcpp.git branch = master fetchRecurseSubmodules = true ignore = untracked The first of these is not by the library author, and the second is a derived work. It is not possible for a Boost release, say, boost_1_65_0.zip, to incorporate git submodules by reference, so there remains a question of what, exactly, is being submitted for inclusion. My attempts to clarify this with the author have proven unsuccessful. I consider this a critical defect of the submission. It is simply not possible for a reviewer to give an opinion whether the submission ought to be included into Boost releases without it being known what, specifically, is being proposed to be included. There is no problem with the library containing implementation details under its directory, but we need to know what these details are. What the library actually needs as dependencies from boost-lite is not much and it's perfectly possible to extract the necessary parts and prepare a self-contained submission. This should have been done prior to the review. The files in the library contain the following: ``` Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License in the accompanying file Licence.txt or at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. Distributed under the Boost Software License, Version 1.0. (See accompanying file Licence.txt or copy at http://www.boost.org/LICENSE_1_0.txt) ``` This intends to dual license the library, but as written, it doesn't. What it does is apply the terms of BOTH licenses to distribution and use. This is also a critical defect. If the library is included in a Boost release, it should make it perfectly clear that it's licensed under the Boost license, and not under the intersection of Boost and Apache 2.0. There are several ways to do it, one is to clarify the above to specifically say "ASL2 or BSL, at your option" in the appropriate legalese, another is to license the Boost-included Outcome under BSL and the standalone Outcome under whatever. My recommendation would be to just license the lot under BSL and be done with it. Dual licensing creates unnecessary legal complications and may, from a legal point of view, be more burdensome than just using the BSL. Contributors need to be aware that they are licensing their patches under both licenses, it might not be very clear whether they have been aware, and so on. At times, the library duplicates certain functionality present elsewhere in Boost. I do not consider this a defect. It's a legitimate design decision to avoid intra-Boost dependencies, although the author needs to be aware of the downsides - using Boost components is basically taking advantage of free work instead of having to maintain everything oneself. III. DOCUMENTATION ------------------ I found the documentation perfectly adequate and was able to get a very good outline of how the classes were designed, how they were intended to be used, and what problem they intend to solve. It focuses a bit too much on expected<T, E>, which is not in itself a bad thing but is, for me, not exactly what the library is about. Fixing E to std::error_code is a fundamental (and correct) design decision from which these classes derive much of their utility. The Doxygen-generated reference will not win any awards, but it does the job. It however contains too many implementation details that would ideally either not be there at all, or tucked away in their own separate section. The monadic content is also a bit too high for my taste, and I would prefer if a user of result<> and outcome<> does not encounter the word monad at all. IV. VERDICT ----------- Should Outcome be accepted? In short, eventually. This, at present, is a NO. Ideally, what I would like to see is the library resubmitted in a conventional form, consisting of exactly the files that are intended to go into the libs/outcome directory in boost_1_65_0.zip, licensed under the BSL, only containing the files necessary for the non-preprocessed version of the code to compile and work. In addition, the test/ subdirectory would contain a Jamfile that is ready to integrate into the Boost test matrix.

4 14

[build] conditional run of unit-tests?
by Oliver Kowalke 30 May '17

30 May '17

In the unit tests I want conditionally run some unit-tests - depending on property <target-os>- On Windows systems the unit-test should apply/build with property <context- impl>winfib and on POSIX (non-Windows) <context-impl>ucontext. The Jamfile below doesn't work (Windows version build on POSIX) - xould I get a hint how to fix it (couldn't find a reference of rule 'run'). Oliver [ run test_callcc.cpp : : : <context-impl>fcontext [ requires cxx11_auto_declarations cxx11_constexpr cxx11_defaulted_functions cxx11_final cxx11_hdr_thread cxx11_hdr_tuple cxx11_lambdas cxx11_noexcept cxx11_nullptr cxx11_rvalue_references cxx11_template_aliases cxx11_thread_local cxx11_variadic_templates ] : test_callcc_fcontext ] [ run test_callcc.cpp : : : <context-impl>ucontext [ requires cxx11_auto_declarations cxx11_constexpr cxx11_defaulted_functions cxx11_final cxx11_hdr_thread cxx11_hdr_tuple cxx11_lambdas cxx11_noexcept cxx11_nullptr cxx11_rvalue_references cxx11_template_aliases cxx11_thread_local cxx11_variadic_templates ] : test_callcc_ucontext ] [ run test_callcc.cpp : : : <context-impl>winfib [ requires cxx11_auto_declarations cxx11_constexpr cxx11_defaulted_functions cxx11_final cxx11_hdr_thread cxx11_hdr_tuple cxx11_lambdas cxx11_noexcept cxx11_nullptr cxx11_rvalue_references cxx11_template_aliases cxx11_thread_local cxx11_variadic_templates ] : test_callcc_winfib : <target-os>windows ] ;

2 2

Re: [boost] [outcome] Possible extensions/changes to std::experimental::expected
by Vicente J. Botet Escriba 30 May '17

30 May '17

Hi, I believe that this private mail I sent to Niall could concern the Boost community and the Outcome review. While the post concerns the proposed std::experimental::expected, this is applicable as well to Outcome. I've added a more points at the end and some additional information about possible open points for std expected. Le 24/05/2017 à 01:04, Vicente J. Botet Escriba a écrit : > > Hi, > > > After better understanding of the goals of Boost.Outcome I would like > to share two possible extension of std::experimental::expected > > > 1. Implicit conversion when the errors are convertible and the type is > the same. > > I believe this is a missing constructor. > > EXPLICIT expected<T, E>::expected(expected<T, G>); // E is > convertible from G > > I see that the other constructor is also useful > > EXPLICIT expected<T, E>::expected(expected<U, E>); // T is > convertible from U > > and so > > EXPLICIT expected<T, E>::expected(expected<U, G>); // T is > convertible from U and E is convertible from G > > We could as well have an adapt function that transforms expected error explicitly to do error propagation adapt : (E->G) x expected<T,E> -> expected<T,G> (E->G) stands for a function that takes an E and return a G. > 2. variadic expected<Y, E1, ..., En> > > I suggested this already in revision 2 of the Expected standard proposal. > > expected<Y, E1, ..., En> should be something like variant<Y, E1, ..., > En> but with some syntactic sugar. > > > expected<T, E1, ...., En> could be EXPLICIT convertible from > expected<T, G1, ...., Gm> as far as for all Gj we find a unique Ek > that is convertible to. > We can refine the subsumption relation this could take too long to the compiler (as the previous relation has quadratic complexity as Andrzej reported to me). > > I believe this will cover exactly what outcome covers and in addition > it will let open the error types used by the user. > > It acts as a exception specification, which we have abandoned in C++11. > > expected<T, E1, ...., En> f(); > > T f() throw (E1, ...., En); > > > We can consider that this is bad, as we have abandoned it. > > Anyway, I think that expected<T, E1, ...., En> is a good > generalization of the proposed outcome<T> where E1 could be none_t, E2 > could be error_code and E3 is exception_ptr. > > At the end users could use variant<E, E1, ..., En> are return code, so maybe we could to make their life easier. > > In this way we could have > > template <class T> > > using option = expected<T, nullopt_t>; > > Note that this is different to std::optional as the default is T not > nullopt_t :( > I'm not proposing it. Just to say that this could be a possibility for option. > > template <class T> > > using result = expected<T, error_code_extended>; // and possibly none. > > template <class T> > > using outcome = expected<T, none_t, error_code_extended, exception_ptr>; > > > I believe we would need the syntactic sugar as expected<T, > variant<E1,... En>> should have a lot of user code noise. > In addition it will be less efficient than variant<T, E1,... En>. > > E.g. expected<T, variant<E1,... En>> should be convertible from > unexpected_type<G> as soon a one of the Ek is convertible from G. > > I believe variant<E1,... En> is not convertible from variant<G1,... > Gm> under the conditions described above, but maybe this should be the > case. > Andrzej told to me that this is already the case for optional<T>, but I've not found yet on which paper this was added? > > Of course, the never empty warranties could be supported only if the > types Ek allow it and we need to change the standard to ensure it for > exception_ptr. > > > I will not have time to implement a POC for 2, but I believe I could > do it for 1 before Toronto. Anyway I believe it will be worth > discussing these 2 extensions. > > > Best, > > Vicente > > > P.S. EXPLICIT above has the sense given in the standard. > 3. uninitialized default constructed expected<T,E> I know this could be conflictual, but there are a some advantages to doing it. We don't spend time initializing with something we will assign later. This state corresponds to the moved-from state. Initializing it by default to T() is not better initializing to E(). Is expected<Date, error_code> default constructible even if Date is not? Currently it is not the case. There are of course liabilities. We have now the possibility for uninitialized variables, but static analysis tools will help here. 4. About comparisons Outcome doesn't implement comparisons between Outcomes. He pretend that we don't need them. In addition the mix of comparisons and implicit conversion give us some surprising cases as described in Andrzej blog. [1] A gotcha with Optional - https://akrzemi1.wordpress.com/2014/12/02/a-gotcha-with-optional We have that std::future is not comparable (as exception_ptr is not comparable). Instead of comparison we could specialize std::less<> if we want to use them in ordered containers. What others think? 5. About implicit conversion from T The implicit conversion from T to expected<T,E> is a consequence of wanting that expected<T,E> should behave like a T. But this is not right. A expected<T,E> is not a T. We have in some way that expected<T,E> is explicitly constructible from E bu the use of make_unexpected(e). If we had only and explicit constructor from T the code will be much more uniform. Either you build it with a modified make_expected or with make_unexpected. In my opinion the implicit conversion from T to expected<T> is a mistake. 5. About the exception to throw std::experimental::expected throw bad_expected_access<E>. I adopted the design of optional and bad_optional_access We could have as well a bad_expected_access_base class as Outcome has. My question is why don't throw directly E? Some are requesting a way to get a specific exception from E, but either there is one exception that works for all and we can set it using some kind of trait or we need to add a trait parameter to expected to the the mapping :( Do we really want this to be configurable? 6. Implicit conversion from E outcome::expected<T,E> outcome::expected<T,E> is implicitly convertible from E when there is no risk of ambiguity. std::expected<T,E> is implicitly convertible from unexpected<E>. What people thing we should have? In Boost? in the standard? Vicente

5 21

[build] [config] check_target_builds and feature.subfeature composition
by Edward Diener 30 May '17

30 May '17

The Boost library config uses the check_target_builds rule to provide build time feature testing. Other Boost libraries use config checks in their own build and test jamfiles. I have found that this works reliably when a particular toolset is used in a normal manner. However when using the feature.subfeature and feature.compose rules to extend the toolset-version designation with a subfeature, such that the toolset designation now becomes toolset-version-subfeature, the use of the check_target_builds rule does not work as expected. In particular the individual check_target_builds rule results are put into a subdirectory based on the toolset-version and not based on the toolset-version-subfeature when toolset subfeature composition is used. I also suspect that the cached value reflects setup. This causes wrong results in tests where the toolset designation uses subfeatures, and a library's jamfile is using config and/or predef checks. As an example My toolset designation looks like: using gcc : 6.3 : some_path ; feature.subfeature toolset gcc : cxxstd : c03 c11 c14 c17 : optional composite propagated ; feature.compose <toolset-gcc:cxxstd>c03 : <cxxflags>-std=c++03 ; feature.compose <toolset-gcc:cxxstd>c11 : <cxxflags>-std=c++11 ; feature.compose <toolset-gcc:cxxstd>c14 : <cxxflags>-std=c++14 ; feature.compose <toolset-gcc:cxxstd>c17 : <cxxflags>-std=c++1z ; A library's test looks like: import ../../config/checks/config : requires ; run some_test.cpp : : : [ requires cxx11_hdr_forward_list ] ; If I run some some_test with toolset=gcc-6.3-c03, the config result for checking if forward list is supported is put into a subdirectory reflecting the toolset-version while the test result will be put into a subdirectory reflecting the toolset-version-subfeature. Subsequently if I run some_test with toolset=gcc-6.3-c11 the config result is taken from the subdirectory reflect the toolset-version even though whether the forward list is supported or not depends very much on the subfeature I am designating as part of the toolset. This naturally causes incorrect results for the test. Is this a known problem ? Is it a problem with Boost Build or is it a problem with how config uses the check_target_builds rule ? I have run into this problem extensively in my testing once I started to use the feature.subfeature ability of Boost Build.

5 9