[outcome] Outcome v2 has reached stability, WG21 paper will be P0762R0

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[outcome] Outcome v2 has reached stability, WG21 paper will be P0762R0

Boost - Dev mailing list
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/


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [outcome] Outcome v2 has reached stability, WG21 paper will be P0762R0

Boost - Dev mailing list
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?


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [outcome] Outcome v2 has reached stability, WG21 paper will be P0762R0

Boost - Dev mailing list
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/


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [outcome] Outcome v2 has reached stability, WG21 paper will be P0762R0

Boost - Dev mailing list
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
>


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [outcome] Outcome v2 has reached stability, WG21 paper will be P0762R0

Boost - Dev mailing list
>>> 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/


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Loading...