Re: [boost] [outcome] How to write a review considering the broad scope

Subject: Re: [boost] [outcome] How to write a review considering the broad scope
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2017-05-27 07:15:12

Le 26/05/2017 à 23:13, Andrzej Krzemienski via Boost a écrit :
> 2017-05-26 22:58 GMT+02:00 Vicente J. Botet Escriba via Boost <
> boost_at_[hidden]>:
>
>> Le 26/05/2017 à 18:52, Niall Douglas via Boost a écrit :
>>
>>> 2. Read the changes I've accepted from peer review feedback at
>>>>> https://github.com/ned14/boost.outcome/issues
>>>>>
>>>>> 3. If you like the library after all those issues were implemented,
>>>>> recommend acceptance, possibly conditional on further things you
>>>>> personally think need to be changed yet.
>>>>>
>>>>> 4. If you dislike the library after all those issues were implemented,
>>>>> recommend rejection, preferably with a list of what should be in the
>>>>> library instead. Nobody wants a flawed design in Boost, myself included.
>>>>>
>>>>> The issue list don't tell us what will be done.
>>> If any of the issues are insufficiently specified for you to make a
>>> review recommendation, please do say which and I will expand their
>>> description.
>>>
>>> I would say that I think it very highly likely I'll be implementing my
>>> proposed typedef factory API at:
>>>
>>>
>>>
>>> That way everybody gets the Outcome they want. I will of course typedef
>>> outcome<T> and result<T> to whatever the consensus recommendation is
>>> from here, but say if Peter really wants the default constructor to make
>>> a singular empty state, he gets that. If I want a totally unavailable
>>> default constructor, I get that. And so on.
>>>
>> This will clarify my review. If after all the discussion you find that
>> this is the way to go, clearly I'll not support you.
>
> I think what Niall is saying here is that In the public API, you will get
> `expected<T, E>`, `outcome<T>` and `result<T>`, but he will provide a
> "secret API" that normal programmers will never know about, but people like
> me and you, who have participated in all these discussions, and learned
> about it, may of curiosity quite easily build a new type of `expected` and
> experiment with it, and have useful feedback to LWG about practical
> consequences of different design decisions.
If the library will provide a generic class that support I don't 
remember how many combinations I will against its acceptation.
I have not see too much people adhering to the design Niall proposed in 
the previous link, quite we can deduce the opposite from the comments.
But maybe it si my bad and people want this hyper-generic design.

I would start a straw-pool here
Who is strongly for, for , neutral, against, strongly against] the 
design of the generic class presented by Niall in

http://boost.2283326.n4.nabble.com/outcome-Ternary-logic-need-an-example-tp4694199p4694620.html

In fact, I am increasingly thinking that a consensus position could be

this type factory template:

// What to default construct to

enum class default_to

{

   none,

   T,

   EC,

   E

};

// How much empty state to implement

enum class emptiness

{

   never,    // imposes restrictions on T, EC, E

   formal,   // formal empty state

   tolerant  // empty state iff EC and E don't have nothrow move construction

};

// How narrow or wide the observers will be

enum class observers

{

   narrow,      // accessing not the current state = reinterpret_cast

   wide,        // default actions already described earlier this review

   single_shot  // you can observe state precisely once only

};

// Replacement for basic_monad

template<

   class T,   // what .value() returns, or void

   class EC,  // what .error() returns, or void

   class E,   // what .exception() returns, or void

   default_to default_to_config,

   emptiness empty_config,

   observers observers_config

> class outcome_impl;

// Outcome as apparently desired by reviewers

template<class T> using outcome = outcome_impl<

   T,

   error_code_extended,

   std::exception_ptr,

   default_to::none,     // default constructed instance =

reinterpret_cast uninitialised memory

   emptiness::never,     // Never possible to be empty, not ever

   observers::narrow     // reinterpret_cast all observers

>;

// Result as apparently desired by reviewers

template<class T> using result = outcome_impl<

   T,

   error_code_extended,

   void,                 // there is still a .exception(), but it returns

void and is not usable

   default_to::none,     // default constructed instance =

reinterpret_cast uninitialised memory

   emptiness::never,     // Never possible to be empty, not ever

   observers::narrow     // reinterpret_cast all observers

>;

[SF F N A SA]

I'm SA for the reasons described in linked thread.

Best,

Vicente