May 2017 - Boost - lists.boost.org

[outcome] outcome without empty state?
by Andrzej Krzemienski 28 May '17

28 May '17

Niall, What do you think about the following alternate interface of outcome types? 1. Remove option<T> altogether. 2. result<T> (and outcome<T>) does not have a separate empty state. 3. A default-constructed result<T> is initialized as if `result<T>{error_code_extended{}}`. 4. Function r.empty() is implemented as `r.has_error() && !error()`. 5. Framework requires that type E in `expected<T, E>` is default-constructible, and its default-constructed value represents no error condition (already the case for exception_ptr, error_code). The rationale behind this is my assumption that `option<T>` is not as useful as the other types. (Or can you give an example to the contrary?) That there was no initial business need for an empty state, and the examples that illustrate its usefulness are just exploring how we can make use of it now that it is there. (Or am I wrong here?) I noticed a number of people report negative feedback about this empty state. Getting rid of it would take result<T> closer to "either T or reason for failure". What do you think? Regards, &rzej;

6 27

[review] Review of Outcome (starts Fri-19-May)
by charleyb123 . 28 May '17

28 May '17

Hi Everyone, The formal review of Niall Douglas' Outcome library starts today (Fri-19-May) and continues until Sun-28-May. Your participation is encouraged, as the proposed library is uncoupled and focused, and reviewers don't need to be domain experts to appreciate the potential usefulness of the library and to propose improvements. Everyone needs (and has suffered) error handling, and can compose an opinion on that topic. Outcome is a header-only C++14 library providing expressive and type-safe ultra-lightweight error handling, suitable for low-latency code bases. Key features: *- Makes using std::error_code from C++11's <system_error> more convenient and safe *- Provides high-quality implementation of proposed std::expected<T,E> (on C++20 standards track) *- Good focus on low-latency (with tests and benchmarks) *- Error-handling algorithmic composition with-or-without C++ exceptions enabled *- No dependencies (not even on Boost) This review is timely, as C++17 brings us std::optional<T>. The upcoming std::expected<T,E> (an implementation provided in Outcome) is a generalization of std::optional<T> that provides a <success|fail> value, where the unhappy result is a 'std::error_code' or an instance of "your-chosen-error-type". The library further provides 'outcome<T,error-code,exception-ptr>' for handling <success|error|exception> to safely wrap throwing APIs. Documentation: https://ned14.github.io/boost.outcome/index.html ACCU 2017 talk including design rationale: https://www.youtube.com/watch?v=XVofgKH-uu4 GitHub: https://github.com/ned14/boost.outcome Latest tarball: https://github.com/ned14/boost.outcome/releases/download/ boost_peer_review3/boost.outcome-v1.0-source-201705111650.tar.xz Note: Tarball might be easiest; but if you want to clone from GitHub directly, after the clone you should run the following command to get the source zip exactly: git submodule update --init --recursive Please post your comments and review to the boost mailing list (preferably), 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

17 70

[review] Review of Outcome (ends Sun-28-May)
by charleyb123 . 27 May '17

27 May '17

Hi, Everyone, First a (very-)big "thank-you!" to all participating in the ongoing (and vigorous) debate and review for the Outcome library. The spirited discussion touches on tricky issues for composition and error handling (with and without C++ exceptions enabled), where the community is clearly searching for best convention and common ground. Thus far: (a)- some 300+ emails discussing Outcome (and more emails off-list) (b)- participation from: *- Andrzej Krzemienski *- D25fe0be *- Deniz Bahadir *- Emil Dotchevski *- Gavin Lambert *- Glen Fernandes *- Gottlob Frege (Tony) *- Hartmut Kaiser *- Ion Gaztanaga *- Jonathan Muller *- Niall Douglas *- Paul Bristow *- Pete Bartlett *- Peter Dimov *- Robert Ramey *- Thomas Heller *- Vicente J. Botet Escriba *- Vinnie Falco *- ...(apologies if I've missed anyone) (c)- Some points-of-discussion relate to: *- Outcome efficiency (copy/move) on today’s compilers *- Outcome speed/overhead (exceptions) *- Outcome purpose/motivation *- Outcome Tutorials, documentation *- Outcome “formal-empty-state”, default-initialization *- Outcome compiling, compiler support *- Outcome ABI, namespace usage, use of preprocessor *- Outcome alternative APIs *- std::expected proposal, possible changes (d)- Reviews to date (sent publicly to the list): *- Paul Bristow -- accept, conditional (Tue-23-May) *- Deniz Bahadir -- accept, unconditional (Wed-24-May) *- Thomas Heller -- (almost a review), ?reject, "not-ready-yet?" (Wed-24-May) (e)- Significant other discussion also contributes to evaluation of Outcome as a Boost library. However, I encourage further reviews to make clear any conclusions from these discussions that I might have missed. The review continues for several more days, ending Sun-28-May. 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

8 16

Detail headers moved
by Belcourt, Kenneth 26 May '17

26 May '17

Hi, I’m trying to build Boost.Graph and running into missing header files that used to live in boost/detail and now live elsewhere. Here’s a couple of examples of headers that moved and the code that still expects to find them there: detail/container_fwd.hpp libs/functional/include/boost/functional/hash/extensions.hpp: #include <boost/detail/container_fwd.hpp> libs/lambda/include/boost/lambda/detail/operator_return_type_traits.hpp: #include "boost/detail/container_fwd.hpp" libs/phoenix/include/boost/phoenix/stl/algorithm/detail/is_std_list.hpp: #include <boost/detail/container_fwd.hpp> libs/phoenix/include/boost/phoenix/stl/algorithm/detail/is_std_map.hpp: #include <boost/detail/container_fwd.hpp> libs/phoenix/include/boost/phoenix/stl/algorithm/detail/is_std_set.hpp: #include <boost/detail/container_fwd.hpp> detail/indirect_traits.hpp libs/iterator/include/boost/iterator/detail/facade_iterator_category.hpp: #include <boost/detail/indirect_traits.hpp> libs/iterator/include/boost/iterator/indirect_iterator.hpp: #include <boost/detail/indirect_traits.hpp> It seems that indirect_traits.hpp was moved from detail into python/detail, and container_fwd.hpp into container. Just curious but was it intentional to make many Boost libraries depend on Python through boost/iterator/iterator_facade.hpp? Noel

2 4

[outcome] some problems compiling
by Andrzej Krzemienski 26 May '17

26 May '17

So, I am trying to run my first test program with Boost.Outcome. The library fails to compile with GCC 6.3.0 on MinGW on Windows 7. I have filed the issue: https://github.com/ned14/boost.outcome/issues/36 But also, I can see in file <boost/outcome/outcome_v1.0.hpp>, lines 1267 to 1279 ``` #ifdef __cplusplus namespace { #endif typedef struct _IMAGEHLP_LINE64 { unsigned long SizeOfStruct; void *Key; unsigned long LineNumber; wchar_t *FileName; unsigned long long int Address; } IMAGEHLP_LINE64, *PIMAGEHLP_LINE64; ``` 1. Why do you check for __cplusplus? Is it a copy-and-paste of some Windows headers? 2. This class and subsequent functions are defined in anonymous namespace. This means they are redefined and recompiled in each translation unit, and remain a per TU definition. Is that intent? Regards, &rzej;

5 11

Re: [boost] [outcome] Possible extensions/changes to std::experimental::expected
by Andrzej Krzemienski 26 May '17

26 May '17

It looks like part of the discussion accidentally went into a private conversation. So, here we are back. 2017-05-25 22:39 GMT+02:00 Vicente J. Botet Escriba < vicente.botet(a)wanadoo.fr>: > Le 25/05/2017 à 18:40, Andrzej Krzemienski a écrit : > > > > 2017-05-25 17:32 GMT+02:00 Vicente J. Botet Escriba < > vicente.botet(a)wanadoo.fr>: > >> Le 25/05/2017 à 13:18, Andrzej Krzemienski via Boost a écrit : >> >>> 2017-05-25 9:44 GMT+02:00 Vicente J. Botet Escriba via Boost < >>> boost(a)lists.boost.org>: >>> >>> We have now the possibility for uninitialized variables, but static >>> analysis tools will help here. >>> >>> So, more specifically, I understand that you propose the following: >>> >>> - Default constructor works: no T or no E is construced (similar what >>> outcome<> does) >>> >> I was not aware of this. Do you know that from this reference >> documentation? >> >> constexpr outcome () noexcept(is_nothrow_default_constructible) >> Default constructor. >> > > Well, I just assumed that since outcome<> has this empty state, it is > exactly for the purpose of giving semantics to the default constructor. But > now that you have asked, I looked at the docs. They say nothing about what > happens in the default constructor. I tried to look in the code, but was > confused with these policies. So, I just run a small test program, and yes: > default constructor creates an empty state. > > Niall, please could you add an issue in order to document default > constructors (if it doesn't already exists). > This is already logged in https://github.com/ned14/boost.outcome/issues/26 > > >> >> Sorrty, I couldn't interpret it as you. >> But, if it is the case, yes, as outcome does. >> >>> - You can assing to and and destroy such an objetc (similar what >>> outcome<> does) >>> >> I don't catch what you mean here. Are you referring to the conversion >> between expected with convertible value type and error types? >> > > No, I am saying that the following should work: > outcome<T> o; // default-constructed > o = some_outcome<T>(); // this should be safe to execute > > This works already with expected even if it doesn't defaults to empty. > Ok, and you expect it to continue to work. > > >> - You will probably need to add an observer function that checks for >>> this singular state, like `is_singular()`. If not for anything else >>> it >>> would be used for assisting the static analysis tools. (again, >>> similar what >>> outcome<> does) >>> >> No. There will be no such observer. This is essential. There is no >> visible empty state. >> Or do you consider that chrono::duration should tell you if it was >> initialized or not? >> The user know if it is initialized or not, but there is no tool to check >> it. >> This could be against safe programming, but we are here in C++ and we >> should provide first the raw tools and then build on top of them when we >> want more. >> >>> - other observer functions (has_value(), value(), has_error(), >>> error()) >>> cause UB when `is_singular() == true. (this is the only difference >>> from >>> outcome<>) >>> >> Not the only one. >> outcome fixes its error types. I'm proposing an extension to the current >> expected so that it can take care of the Outcome use cases and needs. >> >>> >>> Did I understand your intentions correctly? >>> >> Not completly. I don't want an observer that tells me, attention you have >> not initialized your variable, or you have moved from. This is essential. > > > Very daring. It would be easier to accept if you could show a tool that is > capable of statically analying this kind of "used unintialized" bug for > `expected`. > > > Static analysis to check if uninitialized variables are used (read) works > very well already . I don't remember if it si with clang-tidy that I have > seen this kind of warnings. > Ok. Now I am thinking, another thing you can do, is to internally store something like varient<T, Y, Empty> but do not expose this Empty in the interface. Instead, rewrite observer functions like this: ``` bool has_value() const { if (BOOST_UNLIKELY(_is_in_empty_state())) __builtin_unreachable(); return _is_in_valued_state; } ```

3 12

[outcome] expected<T&>, result<T&>
by Andrzej Krzemienski 25 May '17

25 May '17

Niall, Are Boost.Outcome monads intended to work with references (at least lvalue references)? If I try to compile the following program that tries to use an `result<T&>` (on GCC 6.3.1): ``` #include <boost/outcome.hpp> namespace out = BOOST_OUTCOME_V1_NAMESPACE; int g_count = 0; out::result<int&> get_ref() { return out::result<int&>(g_count); } int main () {} ``` I get lots of compiler errors. But the messages ("constructor cannot be overloaded") indicate that it was just an omission and not a design decision. If I try it with `outcome::expected` I also get these messages, but I also get a static assert saying that as per LWG decision T must be default constructible. Vicente, does this mean you cannot use `std::expected` to return references? Regards, &rzej;

5 8

Re: [boost] [outcome] expected vs. result
by Niall Douglas 25 May '17

25 May '17

> It would be very helpful to have a documentation for comparing all types, > expected, option, outcome, and result, showing the use cases and best > practices. I have some hard time to understand what one can do and the > other can not and in which cases I should prefer one. One thing very obvious in this review so far is how overwraught it has made that choice seem. I think as soon as you start writing some code using Outcome, you'll find the choice flows naturally. Using this library in your code is far, far, far easier and more intuitive than this review makes it seem. They are very simple objects, and very easy to use. Often the simpler the object, the more bikeshedding and strong opinions and noise result. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

3 2

[outcome] Ternary logic -- need an example
by Andrzej Krzemienski 25 May '17

25 May '17

Niall Douglas wrote: > Finally, if you did have some special E value to mean empty, you would > have to write special checks for it in Outcome in order to give it the > stronger abort type semantics it has - if you don't have it being given > alternative semantics, then there is no point in having an empty state. > If you are writing special checks, then you might as well just have a > formal empty state in the first place. > > This argument can be generalised into the argument in favour of ternary > logics over binary logics. Sure, 90% of the time binary logics are > sufficient, but binary is a subset of ternary. And *you don't have to > use* the "other" state in a ternary logic just because it's there. Just > don't use it, so long as its implementation signals its unintentional > usage with a very loud bang, it's a safe design. > > (There is an argument that Outcome's "very loud bang" isn't loud enough. > I'd be pleased to hear feedback on that) Niall, you mention "ternary logic" here, and I guess it has to do with 'module' `tribool` exposed by Outcome library. But I do not believe I have seen in the documentation (I mean the tutorial section) how I am supposed to use it, and how it improves my programs. Or I might have just missed it. Could you give me an example? Regards, &rzej;

7 46

Re: [boost] Boost.Outcome review - First questions
by Hartmut Kaiser 25 May '17

25 May '17

Andrzej, Thanks for attempting to additionally clarify what you said before. > Again, sorry to reply on behalf of Niall, but it is my description that > might have caused the confusion. I'm glad you try to answer my questions as I know I will not get any from Niall directly. > There is still this case where you want to avoid exceptions in one part of > the program, but still use exceptions in other parts of the program. For > one example. in one "task" you launch another task with a callback > function `f`. You might want to throw from `f` and this is valid. But the > framework for launching tasks cannot afford to spill exceptions, so they > have to catch and somehow transport the exception (e.g., by exception_ptr) > then in the other task, you might want to re-convert to an exception. > (something similar to what std::future does.) I understand what you're saying, std::future needs a (conceptual) variant<T, exception_ptr> to store its state. So if I hear you correctly, outcome::expected<T, exception_ptr> could be used for that. > Other situation, is when you are using a third-party library, which throws > exceptions. You want to wrap it into a component that does not throw. > Boost.Outcome also supports in a convenient way this transition from and > to exceptions. Ok. > Also, maybe you will find of use the following example that tries to > illustrate the basic use case of the library: <snipped code example> Thanks, I think I've seen this in the docs. All of this could have been done with a variant<T, some_error_type> without changing the semantics, yes? So I guess the next question I would like to ask is: what is the benefit of using outcome::result<T> over std::optional<T>, and outcome::expected<T, E> over std::variant<T, E>? Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu

2 3