[Boost-users] Boost.Outcome and the C++ standard proposals

Subject: [Boost-users] Boost.Outcome and the C++ standard proposals
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2017-05-20 17:54:39

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.