Andrzej Krzemienski wrote:

2017-05-25 23:34 GMT+02:00 Peter Dimov via Boost :

...

Andrzej Krzemienski wrote:

...

Instead, rewrite observer functions like this:

bool has_value() const { if (BOOST_UNLIKELY(_is_in_empty_state())) __builtin_unreachable();

Please no. This is horrible. Actually it's doubly horrible; merely horrible would be putting the above in value(). In an observer function... it's just evil.

Can you explain?

What is there to explain? This makes calling has_value undefined if empty ("narrow contract"), which makes the user responsible of checking empty() before doing ANYTHING with a result/outcome object. This applies to each and every result/outcome object you receive from somewhere. auto r = function(); if( r.empty() { /* always have to do this*/ } else if( r.has_value() ) { /* otherwise UB here */ } As I said, I don't like undefined behavior for its own sake, and I most certainly don't like putting a "Requires: not empty" contract on every function, including observers. Putting a contract is not even a good fit for value(), because it already checks and throws, to enable auto r = function().value(); where you go from noexcept land to exception land. If UB on empty, goodbye one liner, you still need to save the outcome and check for empty first, before retrieving value().

Andrzej Krzemienski wrote:

Also, they way I look at this solution is not "when I get this value I have to check ...", but "when I produce this value I have to make sure...". Is there no way to acheive this in the language?

By not providing a default constructor, I suppose. Otherwise not, there's return value elision so if you do result<T> function() { result<T> r; // do things return r; } nothing is ever called on 'r' on your side if you forget to initialize it. Putting "outcome_errc::not_initialized" inside r made sense, because the principle is that when the returned result has no value, it has to contain the reason for its failure to contain such, and here the reason is that whoever wrote the function left it uninitialized. This looks logical to me, apparently to others not so much. It's not really that much different from returning EINVAL in r because the programmer made some other kind of logic error - instead of forgetting to initialize r, he forgot to initialize some argument to some lower level function he called, so it returned EINVAL and that's what ended up in r.

2017-05-26 0:17 GMT+02:00 Peter Dimov via Boost :

Andrzej Krzemienski wrote:

Also, they way I look at this solution is not "when I get this value I

...

have to check ...", but "when I produce this value I have to make sure...". Is there no way to acheive this in the language?

By not providing a default constructor, I suppose. Otherwise not, there's return value elision so if you do

result<T> function() { result<T> r;

// do things

return r; }

nothing is ever called on 'r' on your side if you forget to initialize it.

Putting "outcome_errc::not_initialized" inside r made sense, because the principle is that when the returned result has no value, it has to contain the reason for its failure to contain such, and here the reason is that whoever wrote the function left it uninitialized. This looks logical to me, apparently to others not so much.

It's not really that much different from returning EINVAL in r because the programmer made some other kind of logic error - instead of forgetting to initialize r, he forgot to initialize some argument to some lower level function he called, so it returned EINVAL and that's what ended up in r.

This is only one way of looking at it. Another one is that I have function like, `open_file`, I want it to either return the file handle or the information about run-time situation that prevented opening the file. "reading from uninitialized `expected`" is no such situation: it is simply a bug. In this sense I consider Niall's choice better: just throw, even if it means to terminate(). Regards, &rzej;

2017-05-26 13:03 GMT+02:00 Peter Dimov via Boost :

Andrzej Krzemienski wrote:

This is only one way of looking at it. Another one is that I have function

...

like, `open_file`, I want it to either return the file handle or the information about run-time situation that prevented opening the file. "reading from uninitialized `expected`" is no such situation: it is simply a bug.

As I say in the paragraph immediately before, if your open_file calls open_file_impl, feeding it invalid arguments, this is simply a bug. Yet when open_file_impl returns EINVAL to indicate invalid arguments, and you return that back to the caller, you end up in the exact same situation.

And I feel that something is wrong with all these artificially wide contracts: std::sqrt() is well defined for any number, including negative ones. Maybe sometimes it is the worse of the two evils, but implementing this in `expected` (I mean this yet annother error code, I guess I must accept expected's wide contracts), wil impose this quesionable choice on everyone. Regards, &rzej;

2017-05-26 13:12 GMT+02:00 Peter Dimov via Boost :

Peter Dimov wrote:

...

Andrzej Krzemienski wrote:

...

Also, they way I look at this solution is not "when I get this value I have to check ...", but "when I produce this value I have to make > sure...". Is there no way to acheive this in the language?

By not providing a default constructor, I suppose. Otherwise not, there's return value elision so if you do

result<T> function() { result<T> r;

// do things

return r; }

nothing is ever called on 'r' on your side if you forget to initialize it.

Actually, there is a way, by providing two types, one default-constructible with a singular empty state, one without. In the code above, you will still declare the function to return result<>, which can never be empty and has no default constructor, but declare `r` to be of type result_option, or optional_result, or optional<result>, or whatever. Then the `return r` line will convert and check.

(Or you could use `result r` and return `r.value()`, which is a funny exercise in ambiguity.)

Nice. On the other hand, maybe the solution to this should come in the form of clever, programmer-assisted, static analysis. Regards, &rzej;