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

2017-05-26 22:58 GMT+02:00 Vicente J. Botet Escriba via Boost < boost@lists.boost.org>:

...

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`, `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

Le 26/05/2017 à 23:13, Andrzej Krzemienski via Boost a écrit : 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-tp4... 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