Subject: [boost] Boost.Outcome and the C++ standard proposals
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2017-05-20 17:54:39
for those that will follow the Boost.Outcome review I wanted to share
some links related to the standard:
The draft of the next revision :
* D0323R2 -*A proposal to add a utility class to represent expected
monad *(Revision 4) -
The monadic interface draft proposal
* DXXXX - *C++ Monadic inteface* -
This is based on Hana customization in its pre-Boost version.
And last a very draft paper I don't pretend to send to the standard
meetings, at least not yet, about how FileSystem TS could be adapted to
take in account the proposes status_value and expected classes.
* DXXXX -*Refactoring FileSystem TS using **|expected|**or
This paper show that there is not silver bullet solution to reporting
errors, but that making abstractions as status_value or expected makes
the interface more clear, composable and readable (for me at least) than
using out parameters error codes.
The paper show also that wanting to have exception interfaces and
non-exception interface forces to double the interface. Using expected
could reduce it at the price of using .value().
I have an POC implementation in
Look for expected, functor, applicative, monad, monad_error folders for
the implementation and std for the customization.
My intention is to show that there is something on-going on the standard
aside the expected proposal as requested by the committee.
Note these drafts are of course not reviewed yet by the committee and I
don't know if they will like the direction. We will see in Toronto next July
P.S. The dead line for next meeting is the 19 Jun. Any feedback is
welcome, but as this is not C++ standard ML, I will prefer to have this
feedback either privately or vi a the std-proposals ML.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk