2017-06-02 17:42 GMT+02:00 Peter Dimov via Boost :

Robert Ramey wrote:

And wouldn't making these things immutable, eliminate a large part of the

...

whole controversy?

An immutable result/outcome would have no default constructor (because it's default-constructed only in cases you need to put the value into it later) which would eliminate the motivation for an empty state as something into which to default-construct... but that's only a small part of the whole controversy.

Niall's argument for empty state does not rest entirely on default construction. He argues that it makes Outcome a four-state variant instead of a tri-state one and having the fourth state is useful in certain scenarios when the function that returns it has a legitimate need to report four states.

That is, he wants to be able to express this:

enum class no_difference { _ }

expected void return_first_difference( std::path const & p1, std::path const & p2 ) { // ... }

(or something along these lines, I may not have gotten the example entirely correct, but that's the spirit of it.)

There are different legitimate ways to draw the line; you could say three states are it, for more use expected<>,

This is a valid point. If you need this tricky fourth state once in 1000 use cases, you can afford to use std::variant instead and leave without the convenience of `outcome`. Regards, &rzej;

Or you could use expected, assuming we decide this is a direction worth pursuing. Proof of concept here:

https://github.com/pdimov/variant2/blob/master/include/boost/variant2/expect...

Now with some preliminary documentation: https://github.com/pdimov/variant2/blob/develop/doc/expected.md

Forgive me chiming in late, but what is the semantic difference between: enum class no_difference { _ } expected and this: using path_difference = std::variant; using error = std::variant; expected return_first_diff(...); Doesn't the latter form satisfy all concerns in that: 1. It conforms to a desirable 2-state 'value or error' KISS paradigm. 2. it contains all the information we'll ever need. 3. success code paths are now co-located, as are failure code paths. There is no need for N code-paths to cater for N states. Isn't this more maintainable? On 2 June 2017 at 18:11, Robert Ramey via Boost wrote:

On 6/2/17 8:42 AM, Peter Dimov via Boost wrote:

...

Robert Ramey wrote:

And wouldn't making these things immutable, eliminate a large part of the

...

whole controversy?

An immutable result/outcome would have no default constructor (because it's default-constructed only in cases you need to put the value into it later) which would eliminate the motivation for an empty state as something into which to default-construct... but that's only a small part of the whole controversy.

Right - so it would only eliminate a small part of the whole controversy.

Niall's argument for empty state does not rest entirely on default

...

construction. He argues that it makes Outcome a four-state variant instead of a tri-state one and having the fourth state is useful in certain scenarios when the function that returns it has a legitimate need to report four states.

That is, he wants to be able to express this:

enum class no_difference { _ }

expected void return_first_difference( std::path const & p1, std::path const & p2 ) { // ... }

(or something along these lines, I may not have gotten the example entirely correct, but that's the spirit of it.)

OK - I guess then that "expected" wouldn't be consistent with my expectations for a function result - which for me is the main (or only) use case. In my world, I would expect

template struct expected {...};

expected void return_first_difference( std::path const & p1, std::path const & p2 ) { // ... }

then use it like this

std::path p1 = "asdfasdfsdf"; std::path p2 = "34234324";

const expected result = return_first_difference(p1,p2);

if(result) // convertable to bool? // convert result to error_code const std::error_code e(result, error_catagory); throw ? std::system_error(e)

const std::path path = result;

I don't see why expected has to have more than two states. One for the legitimate result and one for anything else. The "anything else" doesn't have to be dealt with inside of "expected". Basically the E parameter is an "Escape" clause which is the user's responsibility to define.

There are different legitimate ways to draw the line; you could say three

...

states are it, for more use expected<>, or you could say, four states cover the majority of the legitimate cases, so let's have that.

Hmmm - maybe states and parameters are getting confused. An "Escape" parameter can contain an arbitrary number of states in one parameter.

Robert Ramey

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman /listinfo.cgi/boost

Richard Hodges wrote:

...

Forgive me chiming in late, but what is the semantic difference between:

There are various ways to represent the same four-state variant syntactically, and the main difference is in, well, syntax, when referring to it. You could, for example, use

outcome>

(assuming a never-empty tri-state outcome)

or

outcomestd::path>

Completely agree that in this case optionalstd::path is equivalent to variant. My concern is around allowing more than two

On 2 June 2017 at 18:43, Peter Dimov via Boost wrote: main code paths when testing the outcome. It seems to me that all outcomes will either 'pass' in some way or 'fail' in some way. These are the main concerns are they not? By all means the happy path might specialise happiness, but it's still happiness, right? we could argue that some process might partially complete, and that could be captured with: outcome> A partial result is not a failure. Isn't the purpose of outcome to simply offer a non-throwing alternative to exceptions without requiring in/out variables? Or is there some wider use case I haven't thought of? If so, couldn't that be trivially composed as above?

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman /listinfo.cgi/boost

On 02/06/2017 16:42, Peter Dimov via Boost wrote:

Robert Ramey wrote:

Niall's argument for empty state does not rest entirely on default construction. He argues that it makes Outcome a four-state variant instead of a tri-state one and having the fourth state is useful in certain scenarios when the function that returns it has a legitimate need to report four states.

Nearly correct, but not quite. My argument in favour of an emoty state is because the implementation will implement an empty state internally anyway, so either you expose that publicly, or you don't. It's no difference for the implementation. You then list the use cases for a formal public empty state, and on balance I came out in favour. During the review quite a few people came to the same conclusion: on balance, it's better than the alternatives. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

Le 03/06/2017 à 00:09, Peter Dimov via Boost a écrit :

Niall Douglas wrote:

...

My argument in favour of an emoty state is because the implementation will implement an empty state internally anyway, so either you expose that publicly, or you don't. It's no difference for the implementation.

The same argument has been used in variant's case and the initial proposal did include a bona fide empty state. It was however swept under the carpet because never-empty, or even the illusion of never-empty, as in the case of C++17's variant, was found preferable.

It's true that the implementation will have an empty state internally as an implementation detail, but it need not be user-visible.

The argument for never having an empty state, in variant's case, is that having an empty state makes people who don't use it pay for it in more complex code that has to check for empty because visit, for example, has to handle all alternatives. It's better, there, to make the default never empty. People who want an empty state can always put an empty alternative in the list.

The same argument justify IMHO the narrow contracts for the observers. Vicente

On 6/2/17 8:53 AM, Andrzej Krzemienski via Boost wrote:

2017-06-02 17:17 GMT+02:00 Robert Ramey via Boost :

The consumer of the `outcome` could just observe the state. But the producer may have legitimate reasons to change the value of `outcome` objects when preparing its final value.

That is exactly what I'm questioning. I'm suggesting that changing the value of a "result" is indication of a fundamental mis-understanding what a "result" is. I'm suggesting that requiring that "expected" be immutable will actually improve it's conceptual power for users. It require them to use a more suitable type when "expected" is not suitable. Of course I'm guilty of speculating myself here. I'm questioning the premise "component X is useful, but it would be more useful if ....". Maybe we should keep simple things simple. BTW TL;DR; - I'm coming to the opinion that the usage of immutable objects is a key attribute of the functional programming ala haskel and that perhaps we should think about this more when we design stuff.

Also, some use cases require being able to store outcomes in container

LOL - I can't prove it, but this sounds like a very bad idea to me. But it also raises an entirely different issue. The requirement of default constructors for container elements is an artifact of the way containers are implemented. So here, an implementation artifact is bleeding over to the abstract conceptual design of the element. This is recipe for brain soup.

I guess design would be easier if we could see all use cases listed.

Ahhh - the pitfalls when designing on speculation about the future. Mix in design by committee and you've got ... gridlock. The discussions are interesting, but when they evolve into communal design from a simple review things get ... complicated. Maybe if we kept reviews more focused on thumbs up/down and criticism and support rather than "design" they might be less of a death march and we might encourage more people to participate in reviews. Robert Ramey

...

The discussions are interesting, but when they evolve into communal design from a simple review things get ... complicated. Maybe if we kept reviews more focused on thumbs up/down and criticism and support rather than "design" they might be less of a death march and we might encourage more people to participate in reviews.

In this spirit, I have got a question to Niall, or whoever who used the library in their real projects: did the use cases required to change the state of a once constructed `outcome`?

I gave many examples throughout the review of changing the state of existing outcomes. Indeed, almost every AFIO object init function implementation does so, we construct an empty or valued result<T> on the stack and fill it in over time as part of the "two phase construction" used throughout AFIO. Also, in KernelTest, there is some constexpr code which statically constructs a std::array at compile time exactly matching the number of parameter permutations which will be run. After the test has finished, empty outcome<T> means test was skipped or death test failed, valued means test passed, errored means test errored, excepted means test threw an exception. So assignment of Outcomes, well I use it frequently. I've also passed in outcomes by lvalue ref to a set of filtering callbacks, and each callback may or may not change their state as part of their execution. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/