[outcome] Outcome v2 has reached stability, WG21 paper will be P0762R0
For boost-dev's information: https://www.reddit.com/r/cpp/comments/6qo1m3/outcome_v2_has_reached_stability_wg21_paper_will/?ref=share&ref_source=link --- cut -- I am pleased to announce that Outcome v2, rewritten to fulfil the Boost peer review feedback from May and only reaching feature completeness three weeks ago, has been successfully deployed into two complex libraries which were heavily using Outcome v1. Lots of bug fixes and maturity has resulted, and if you were holding off on deploying Outcome into your own code until now, now is the time! The code itself is now ready for a second Boost peer review, it has all the same testing that v1 had, and I am highly confident as to its quality. What solely remains before Outcome v2 can reenter the Boost peer review queue for a second review is the documentation which remains parlous (and any help with it is greatly appreciated!), and the "Boostification" cronjob script as the peer review wants a "pure Boost" submission. I am also going to have to fix a number of bugs in Standardese the documentation tool first, it currently segfaults when fed the Outcome headers :). @foonathan's tool shows lots of promise, it does far better with C++ 17 than doxygen, just need to shave off some rough edges in the tool. What comes before that though is writing a WG21 paper P0762R0 summarising the Boost peer review which led to the stripped down, barebones v2 `result<T, E>` design and the rationale for the design deviations from `expected<T, E>` as according to the Boost peer review feedback. If WG21 feel warm feelings about a `std::result<T, E>` after reading P0762R0, then I will prepare a formal standardisation proposal for the Library Evolution Working Group (LEWG) and get the ball rolling for standardisation by attending meetings from 2018 onwards until it's through. I'll announce any draft D0762R0 here when it's ready for people to comment and give feedback on soon. My thanks to everyone here on Reddit, on boost-dev, on SG14 low latency, and privately who have helped out with testing, documentation, and so much more in making this library happen. I know those coming from Rust-land feel amazement how long it has taken C++ to replicate Rust's `Result<T, E>`, but I'm very sure ours is enormously superior to theirs already simply by doing so much less because it doesn't need to. Taking time to get design **right** is one of the big things which continues to separate C++ from the upstart systems programming languages. Long may it continue! --- context --- Outcome provides a C++ 14 STL-quality `result<T, EC>` and an `outcome<T, EC, E>` implementation of success|failure value transports, and is expected to pass a second Boost peer review and be submitted for C++ standardisation as the lowest level of an overall framework as proposed by: - http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0650r0.pdf C++ Monadic interface - http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0323r2.pdf A proposal to add a utility class to represent expected object (Revision 4) The idea is that result/outcome are the extremely lightweight struct-like success|failure value transports suitable for usage in public APIs, whereas expected is the much richer variant-like monadic success|failure value transports, and everything participates together under P0650R0. Outcome is a pure header only library with no dependencies. It works best with C++ 17 and Concepts enabled, but can work with C++ 14 on these compilers or better: - clang 4.0 (5.0 required for Windows) - GCC 7 (VS2017 Update 3 RTM is supposed to work too according to Microsoft, my thanks to them for swiftly fixing the several ICEs I reported) Github: https://github.com/ned14/outcome Docs (highly incomplete): https://ned14.github.io/outcome/ Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
On 07/31/2017 02:23 PM, Niall Douglas via Boost wrote:
[...] and the "Boostification" cronjob script as the peer review wants a "pure Boost" submission.
Where would one find the script and the result of the boostified headers? What's the rationale in having it run as a cronjob instead of having the CI do the boostification upon a successful build?
On 31/07/2017 15:04, Thomas Heller via Boost wrote:
On 07/31/2017 02:23 PM, Niall Douglas via Boost wrote:
[...] and the "Boostification" cronjob script as the peer review wants a "pure Boost" submission.
Where would one find the script and the result of the boostified headers?
As the announcement said, the boostification script has not been implemented. Nor will it be until the documentation and tutorial are finished for obvious reasons. That's some months away yet, probably November or December, after the Meeting C++ conference and the Albuquerque WG21 meeting. The implementation code however is ready to go, and works very well with Boost code as it's exactly like a STL vocabulary type. If you can meet the steep compiler version requirements of course.
What's the rationale in having it run as a cronjob instead of having the CI do the boostification upon a successful build?
Outcome runs on both Travis and Appveyor. Each cannot know if the other succeeded. So a cronjob which already exists scans nightly the CDash for Outcome, and figures out the last commit with all tests passing on all platforms. It then updates master branch to that commit, and publishes a tarball. That same cronjob will eventually also Boostify Outcome into the Boost.Outcome repo if and only if all tests pass i.e. master branch got updated. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
On 07/31/2017 05:01 PM, Niall Douglas via Boost wrote:
On 31/07/2017 15:04, Thomas Heller via Boost wrote:
On 07/31/2017 02:23 PM, Niall Douglas via Boost wrote:
[...] and the "Boostification" cronjob script as the peer review wants a "pure Boost" submission.
Where would one find the script and the result of the boostified headers?
As the announcement said, the boostification script has not been implemented.
D'oh ... missed that in the announcement... thanks for the clarification.
What's the rationale in having it run as a cronjob instead of having the CI do the boostification upon a successful build?
Outcome runs on both Travis and Appveyor. Each cannot know if the other succeeded. So a cronjob which already exists scans nightly the CDash for Outcome, and figures out the last commit with all tests passing on all platforms. It then updates master branch to that commit, and publishes a tarball. That same cronjob will eventually also Boostify Outcome into the Boost.Outcome repo if and only if all tests pass i.e. master branch got updated.
While the two CI systems don't know of each other, you can actually get notified when a commit status update occurs. That would require some service to listen on those status updates and logic to determine if all builders passed (which is moot if you have testers not running on travis or appveyor). So I guess a cron job is the only alternative for the lack of proper CI support on this.
Niall
What's the rationale in having it run as a cronjob instead of having the CI do the boostification upon a successful build?
Outcome runs on both Travis and Appveyor. Each cannot know if the other succeeded. So a cronjob which already exists scans nightly the CDash for Outcome, and figures out the last commit with all tests passing on all platforms. It then updates master branch to that commit, and publishes a tarball. That same cronjob will eventually also Boostify Outcome into the Boost.Outcome repo if and only if all tests pass i.e. master branch got updated.
While the two CI systems don't know of each other, you can actually get notified when a commit status update occurs. That would require some service to listen on those status updates and logic to determine if all builders passed (which is moot if you have testers not running on travis or appveyor). So I guess a cron job is the only alternative for the lack of proper CI support on this.
Oh for sure. But that would be more work for not actually a huge gain. Having to wait till midnight GMT for update to known-working-on-all-platforms is okay for 99% of end users. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
participants (2)
-
Niall Douglas -
Thomas Heller