Hi,
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) -
https://github.com/viboes/std-make/blob/master/doc/proposal/expected/d0323r2.md
The monadic interface draft proposal
* DXXXX - C++ Monadic inteface -
https://github.com/viboes/std-make/blob/master/doc/proposal/monads/Monads.md
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 status_value
-
https://github.com/viboes/std-make/blob/master/doc/proposal/expected/DXXXXR0_fs_expected.md
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 https://github.com/viboes/std-make/tree/master/include/experimental/fundamental/v3
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
Best,
Vicente
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.