January 2018 - Boost - lists.preview.boost.org

Re: [boost] [review] outcome broken on clang/libstdc++ (Linux) and Apple clang/libc++ and gcc 7.2
by Glen Fernandes 28 Jan '18

28 Jan '18

I wrote a .travis.yml for your boost-outcome submission to run your unit tests against a few compilers: The output is at: https://travis-ci.org/glenfe/ned14.outcome/builds/334222400 I updated it to make sure the clang++-libstdc++ uses a more recent libstdc++. It looks like: - clang++-libc++ fails because of forgetting to #include a header. - GCC 7.2 with -std=c++17 is the one with the Internal Compiler Errors (I didn't investigate further) - clang++5-libstdc++ fails because it cannot find a type in std Is there a reason why you don't have travis and appveyor for boost-outcome? I remember your "Best Practices" document strongly advocating that every Boost library submission should have them. Glen

3 13

Re: [boost] [review] outcome broken on clang/libstdc++ (Linux) and Apple clang/libc++ and gcc 7.2
by Glen Fernandes 27 Jan '18

27 Jan '18

On Sat, Jan 27, 2018 at 4:55 PM, Glen Fernandes wrote: > I just tried boost-outcome unit tests with clang 4.0, 5.0 on Linux > with libstdc++ with -std=c++14 and -std=c++1z which fails with many > errors: > > e.g. [snip] > In file included from > libs/outcome/test/tests/../../include/boost/outcome/detail/result_storage.hpp:34: > libs/outcome/test/tests/../../include/boost/outcome/detail/../success_failure.hpp:54:42: > error: no template named 'conditional_t' in namespace 'std'; did you > mean 'conditional'? > template <class T> using devoid = > std::conditional_t<std::is_void<T>::value, void_type, T>; > ~~~~~^~~~~~~~~~~~~ > conditional > /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/type_traits:1780:12: > note: 'conditional' declared here > struct conditional > ^ > > > Then I also tried the boost-outcome unit tests with Apple clang 8.1.0 > with libc++ with -std=c++14 and -std=c++1z which fails with errors > like: > I pasted the wrong error output here; the right error output is: clang-darwin.compile.c++ bin.v2/libs/outcome/test/core-outcome.test/clang-darwin-4.2.1/debug/cxxstd-14-iso/tests/core-outcome.o In file included from libs/outcome/test/tests/core-outcome.cpp:30: In file included from libs/outcome/test/tests/../../include/boost/outcome/outcome.hpp:34: In file included from libs/outcome/test/tests/../../include/boost/outcome/detail/outcome_exception_observers.hpp:34: In file included from libs/outcome/test/tests/../../include/boost/outcome/detail/result_storage.hpp:35: libs/outcome/test/tests/../../include/boost/outcome/detail/value_storage.hpp:181:22: error: no matching constructor for initialization of 'value_type' (aka 'boost::outcome_v2::outcome<int, std::__1::error_code, std::exception_ptr, boost::outcome_v2::policy::error_code_throw_as_system_error<int, std::__1::error_code, std::exception_ptr> >') new(&_value) value_type; // NOLINT ^ libs/outcome/test/tests/../../include/boost/outcome/detail/result_storage.hpp:270:11: note: in instantiation of member function 'boost::outcome_v2::detail::value_storage_nontrivial<boost::outcome_v2::outcome<int, std::__1::error_code, std::exception_ptr, boost::outcome_v2::policy::error_code_throw_as_system_error<int, std::__1::error_code, std::exception_ptr> > >::value_storage_nontrivial' requested here : _state(std::move(o._state)) ^ > Is this also a known issue? Only gcc 6 and gcc 7 with lisbtdc++ on > Linux seem to pass. The other combinations I tried (clang + lisbtdc++ > on Linux, Apple clang + libc++) do not. > I spoke too soon, here gcc 7 does not pass. It ICEs: libs/outcome/test/tests/../../include/boost/outcome/detail/result_value_observers.hpp:45:17: in constexpr expansion of ‘((boost::outcome_v2::detail::result_value_observers<boost::outcome_v2::detail::result_storage<int, std::errc, boost::outcome_v2::policy::error_code_throw_as_system_error<int, std::errc, void> >, int, boost::outcome_v2::policy::error_code_throw_as_system_error<int, std::errc, void> >*)this)->boost::outcome_v2::detail::result_value_observers<boost::outcome_v2::detail::result_storage<int, std::errc, boost::outcome_v2::policy::error_code_throw_as_system_error<int, std::errc, void> >, int, boost::outcome_v2::policy::error_code_throw_as_system_error<int, std::errc, void> >::<anonymous>.boost::outcome_v2::detail::result_storage<int, std::errc, boost::outcome_v2::policy::error_code_throw_as_system_error<int, std::errc, void> >::result_storage<int>(boost::outcome_v2::in_place_type_t<int>(), <anonymous>)’ libs/outcome/test/tests/core-result.cpp:330:41: internal compiler error: in adjust_temp_type, at cp/constexpr.c:1206 constexpr result<int, std::errc> a(5), b(std::errc::invalid_argument); [...] 0x6db788 cxx_eval_constant_expression ../../src/gcc/cp/constexpr.c:4034 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <file:///usr/share/doc/gcc-7/README.Bugs> for instructions. Let me know if you need more context, but it appears boost-outcome is also broken on gcc 7.2. Glen

2 1

Re: [boost] [review] outcome broken on clang with libstdc++ (Linux) and Apple clang with libc++
by Glen Fernandes 27 Jan '18

27 Jan '18

On Sat, Jan 27, 2018 at 3:07 PM, Niall Douglas wrote: > b2 libs/afio/test works fine with VS2017. So it would seem that that ICE > Vinnie encountered is some weird corner case nobody could have > anticipated. As I mentioned, almost all of the development of Outcome > was done on MSVC. It's very well tested on MSVC, and I've never seen > anything like that ICE before. I just tried boost-outcome unit tests with clang 4.0, 5.0 on Linux with libstdc++ with -std=c++14 and -std=c++1z which fails with many errors: e.g. In file included from libs/outcome/test/tests/comparison.cpp:35: In file included from libs/outcome/test/tests/../../include/boost/outcome/outcome.hpp:34: In file included from libs/outcome/test/tests/../../include/boost/outcome/detail/outcome_exception_observers.hpp:34: In file included from libs/outcome/test/tests/../../include/boost/outcome/detail/result_storage.hpp:34: libs/outcome/test/tests/../../include/boost/outcome/detail/../success_failure.hpp:54:42: error: no template named 'conditional_t' in namespace 'std'; did you mean 'conditional'? template <class T> using devoid = std::conditional_t<std::is_void<T>::value, void_type, T>; ~~~~~^~~~~~~~~~~~~ conditional /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/type_traits:1780:12: note: 'conditional' declared here struct conditional ^ Then I also tried the boost-outcome unit tests with Apple clang 8.1.0 with libc++ with -std=c++14 and -std=c++1z which fails with errors like: clang-darwin.compile.c++ bin.v2/libs/outcome/test/outcome-int-int-1.test/clang-darwin-4.2.1/debug/cxxstd-14-iso/outcome-int-int-1.o libs/outcome/test/compile-fail/outcome-int-int-1.cpp:12:26: error: no matching constructor for initialization of 'outcome<int, int, int>' outcome<int, int, int> m(5); ^ ~ libs/outcome/test/compile-fail/../../include/boost/outcome/outcome.hpp:222:31: note: candidate constructor (the implicit copy constructor) not viable: no known conversion from 'int' to 'const boost::outcome_v2::outcome<int, int, int, boost::outcome_v2::policy::all_narrow>' for 1st argument class BOOST_OUTCOME_NODISCARD outcome ^ Is this also a known issue? Only gcc 6 and gcc 7 with lisbtdc++ on Linux seem to pass. The other combinations I tried (clang + lisbtdc++ on Linux, Apple clang + libc++) do not. Glen

1 0

Re: [boost] [review] outcome broken on MSVC, plus questions
by Glen Fernandes 27 Jan '18

27 Jan '18

Hi Niall, Still working on the review; I had the following questions while reading the threads: 1. Which versions of MSVC 2017 does boost-outcome not work on, right now? 2. According to the documentation, outcome and boost-outcome both require MSVC 2017, right? i.e. They do not support MSVC 2015 or lower? 3. Is standalone outcome fine with MSVC2017, only boost-outcome that is broken? 3.1. If so, is it right that the boost-outcome repository is "generated" from the outcome repository? And is that the reason that boost-outcome is broken on MSVC 2017? 4. Would you happen to know how does your outcome/result compare to Peter's outcome/result in variant2? (I saw you point out that Peter implemented expected, and then I saw he also had an outcome/result implementation in variant2). 4.1. What different compilers and standards does his support compared to yours? 4.2. What kind of code is generated from his implementation compared to yours? Thanks, Glen

3 2

[outcome] Purpose of value_type_if_enabled?
by Bjorn Reese 27 Jan '18

27 Jan '18

Are value_type_if_enabled and error_type_if_enabled supposed to be used by the library users? If so, how?

2 1

[spirit]why x3::alternative::parse not short-circuited?
by Larry Evans 27 Jan '18

27 Jan '18

https://github.com/boostorg/spirit/blob/develop/include/boost/spirit/home/x… shows both left.parse *and* right.parse are called. Shouldn't right.parse be skipped if left.parse succeeds?

1 1

[outcome] Andrzej's review
by Andrzej Krzemienski 27 Jan '18

27 Jan '18

Hi Everyone, This is my review of Boost.Outcome v2. The library should be *accepted* subject to conditions that I list down below. What is your evaluation of the design? Clean and logically divided. What is your evaluation of the implementation? > Some bugs aside, it is clean and well structured. I was able to read it and understand how things work. I will be filing bugs in GitHub. What is your evaluation of the documentation? > Good. You can get the idea what the library is doing and how you can use it. But I should mention that I wrote some pieces thereof, so my opinion is likely biased. The docs need some modifications before they can get into Boost. I mean macro names, and the technology required to build it. What is your evaluation of the potential usefulness of the library? > I find the library very useful in certain domains. I myself have found two applications in my job project, and they are not really related to light-speed efficiency: 1. We have a task scheduling framework built atop ASIO, and signalling failures through exceptions makes the code really difficult to read because try-catch blocks need to work as control statements. Also, we cannot pass them by exception_ptr as sometimes we need to classify the kind of failure to determine if we want to deal with it in the framework, or if we want to forward them to the user. 2. I have a validation routine that validates (and parses) the input data written using some syntax. I wan the syntax-errors in input files to be forwarded as failed `result`s (no exceptional about these), but other errors like memory shortage during the file parsing to be signaled via exceptions (and I will probably kill the module in response). Why accepting this library when we have `expected` being standardized? I do not really mind having two in Boost. First, it is ready, being proposed, and applied in a number of non-trivial code-bases. Niall claims that his trade-offs are better tailored to predictable-latency applications. I do not have enough knowledge to asses it. They look convincing. The only way to test it is to give this library the Boost blessing and have the user test it. I am bought by the TRY operations, and the upgrade to `outcome` looks really convincing. Did you try to use the library? With what compiler? Did you have any > problems? > Yes. A lot of compilers. For instance GCC 6.4.0, also different GCC and Clang versions in WandBox. No problems encountered. How much effort did you put into your evaluation? A glance? A quick > reading? In-depth study? > I have read most of the final implementation. I have read many versions of the documentation. I have spent a lot of time (prior to the review) asking Niall lots of questions about the details. I have also built lots of small examples to test the library and some corner cases. Are you knowledgeable about the problem domain? > I do report failures (by different means) in my programs. I have given it quite some thought. I am well familiar with implementation and formal specification of `boost::optional` and `std::optional` which had to address some similar implementation problems. Do you think the library should be accepted as a Boost library? > Yes, conditionally. Here are three conditions: 1. Documentation is adjusted to use boost-standard names of macros and namespaces. Also, it is not clear if Boost release process is capable of handling the technology that Niall has chosen. If not, the contents of documentation should be migrated to another format, manageable by Boost release process. 2. Because there has been some confusion around the meaning of storing default-constructed `std::error_code` (is it an error or lack thereof?) and `std::exception_ptr` (e.g., see this issue: https://github.com/ned14/outcome/issues/115) I request that you state in the docs, before the API Reference how library treats default-constructed values of `EC` and `EP`. For instance, you can say "default-constructed error_code is considered an error, and treated as such by the library", or "the library sometimes may make use of the fact that a default-constructed EC/EP is not an error, so make sure not to pass us such values": I am fine with any answer, but I need you to spell it out, so that I know what to expect. 3. Similarly, I request that you put in the docs what is the "value" of an object of type `outcome<>` or `result<>` in the sense in which John Lakos talks about "salient attributes". I know that T, EC, and EP constitute the value. But in the middle of the tutorial we learn that apart from these you also store "spare_storage" -- is it also included in copying and comparisons? API reference on `operator==` only says "compares if two objects are equal", but it is not that clear what it means. Also, what does it mean that result is equal to optional. Define it somewhere and paste links to it. Finally, I wan to thank Niall for his now many-year effort to deliver this really cool library to the community. Regards, &rzej;

4 7

Re: [boost] [review] Outcome: internal compiler error
by Vinnie Falco 27 Jan '18

27 Jan '18

On Thu, Jan 18, 2018 at 2:07 PM, charleyb123 . via Boost <boost(a)lists.boost.org> wrote: > GitHub: > *- https://github.com/ned14/boost-outcome > > 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: I have put together the following sample program to test integration of Outcome into Boost.Beast: #include <boost/outcome.hpp> int main(int argc, char** argv) { } The result of compilation for this translation unit is shown here: 1>c:\users\vinnie\src\boost\boost\outcome\detail\value_storage.hpp(141): 1>fatal error C1001: An internal error has occurred in the compiler. 1>(compiler file 'msc1.cpp', line 1507) Compiler used: MSVC Part of: Microsoft Visual Studio Community 2017 Version 15.5.1 Upon investigation, I discovered a newer version of the compiler and IDE. Updating to "Version 15.5.5" produced the following results when compiling the same translation unit: 1>c:\users\vinnie\src\boost\boost\outcome\detail\value_storage.hpp(141): 1>fatal error C1001: An internal error has occurred in the compiler. 1>(compiler file 'msc1.cpp', line 1507) Is this a supported configuration? Thanks

3 4

[review] outcome
by Vinícius dos Santos Oliveira 27 Jan '18

27 Jan '18

That is my review of Boost.Outcome. What is your evaluation of the design? Niall did an excellent job weighting trade-offs and coming up with such an pleasant and convenient interface that not only is convenient, but it has customization points in the appropriate layers to fit not-close-to-trivial use cases. I've read the changes between v1 and v2 and I agree with the rejection reasons of previous version (the v1's null state specially made little sense at all). Version 2 is a very realistic and solid project. It might seem teasing to just port abstractions from functional languages to C++ (e.g. Expected), but C++ is its own beast and we cannot just ignore some features that we have been dragging all along like exceptions if we expect to have any realistic usage in the real world. Niall's intuition on how to weigh trade-offs was outstanding and just proves his C++ familiarity and expertise. In special, default actions/behaviours could only be defined by intuition of some experienced programmer and not "mathematically". What is your evaluation of the implementation? I did not check the implementation. What is your evaluation of the documentation? Very well written. The tutorials are excellent-quality. The use cases and examples were chosen in such a way that it was intuitive to understand why/when Boost.Outcome and not Expected. I noted a few small problems, but they were reported already. The comments on the example codes were seemingly foreseeing ahead enough about "pumping doubts" so that my mind would calm down and actually pay attention to the documentation instead doing mind exercises trying to guess the non-point of the example. I wish I had this skill. What is your evaluation of the potential usefulness of the library? Very useful. Error handling is a core constant in any programming activity. Introduction of Boost.Outcome could potentially remove duplication of throwing and non-throwing APIs. I personally prefer Expected with its monadic operations, but it is unrealistic to ignore exceptions in many code bases and I'd certainly go for Boost.Outcome in these cases. Did you try to use the library? With what compiler? Did you have any problems? Yes. The one-header version of the library made testing incredibly easy. No problems. Clang 5.0.1. How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? A few hours over a span of a few days. I've tried to examine documentation carefully and end up sending a pull request and a few comments to ask for further changes. I've read all threads that came up during review. I also tested the library when in doubt. Are you knowledgeable about the problem domain? I worked for more than one year under contract using the Rust programming language and Boost.Outcome is pretty much the error system we have in Rust (with some C++-ification and an experienced C++ unique programmer "intuition" to also cover exceptions... and w/o monad ops, of course). Do you think the library should be accepted as a Boost library? Yes. -- Vinícius dos Santos Oliveira https://vinipsmaker.github.io/

2 1

[config] Positive feature macros, r2
by Peter Dimov 26 Jan '18

26 Jan '18

I'd like to revisit the topic of Boost.Config feature macros, specifically that in my opinion, positive feature macros (BOOST_CXX17_FEATURE) make more sense than negative macros (BOOST_NO_CXX17_FEATURE) in the current environment. Negative macros made sense in the past when they signified bugs and deficiencies in the compiler as measured against a static standard. Nowadays, the standard, such as it is, is in constant motion and macros indicate merely a current state of development for both the compiler and the standard. The arguments for positive macros are the same as last time: - adding a new negative macro requires changes to all legacy compilers that do not and will never implement the feature; a positive macro only requires changes to active compilers. - positive macros are a better match for the standard feature macros, which are positive. When we see a standard feature macro being set, we typically would set ours as well. This means that the amount of changes required to add a new macro is further reduced; we only need to touch compiler-specific config files if the compiler either does not implement feature macros, or sets them incorrectly (in our considered opinion.) TL;DR we should switch to positive feature macros in Boost.Config, and delaying this switch just accumulates more unnecessary code in Boost.Config.

7 13